Posts tagged with: jenkins


1.2.2019

Official support for Jenkins Pipelines

A continuous delivery pipeline is an automated process for delivering your software to your customers. It is the expression of steps which need to be taken to build your software from your version control system to a working and deployed state.

In Jenkins, Pipeline (with a capital P), provides a set of tools for modeling simple and complex pipelines as a domain-specific language (DSL) syntax. Most often this pipeline “script” is written and stored to a Jenkinsfile stored inside your version control system. This way the actual Pipeline definition can be kept up-to-date when the actual software evolves. That said, Pipeline scripts can also be stored as they are to Pipeline-typed jobs in your Jenkins.

 

Meliora Testlab plugin for your Pipelines

Meliora provides a plugin to Jenkins which allows you to easily publish your automated testing results to your Testlab project.

Previously, it was possible to use the plugin in Pipeline scripts by wrapping the plugin to a traditional Jenkins job and triggering it with a “build” step. A new version 1.16 of the plugin has been released with official support for using the plugin in Pipeline scripts. This way, the plugin can be directly used in your scripts with a ‘melioraTestlab’ expression.

When the plugin is configured as traditional post-build action in a Jenkins job, the plugin settings are set by configuring the job and entering the appropriate setting values via the web UI. In Pipelines, the settings are included as parameters to the step keyword.

 

Simple Pipeline script example

The script below is an example of a simple Declarative Pipeline script with Meliora Testlab plugin configured in a minimal manner.

pipeline {
    agent any
    stages {
        stage('Build') {
            // ...
        }
        stage('Test') {
            // ...
        }
        stage('Deploy') {
            // ...
        }
     }
     post {
         always {
             junit '**/build/test-results/**/*.xml'
             melioraTestlab(
                 projectKey: 'PRJX',
                 testRunTitle: 'Automated tests',
                 advancedSettings: [
                     companyId: 'mycompanyid',
                     apiKey: hudson.util.Secret.fromString('verysecretapikey'),
                     testCaseMappingField: 'Test class'
                 ] 
             )
         }
     }
}

The script builds, tests, deploys (with the steps omitted) the software and always as post stage, publishes the generated test results and sends them to your PJRX project in Testlab by storing them in a test run titled ‘Automated tests’. Note that advanced settings block is optional: If you configure these values to the global settings in Jenkins, the plugin can use the global settings instead of the values set in the scripts.

 

Pipeline script example with all settings present

The example below holds all parameters supported (at the time of writing) by the melioraTestlab step.

pipeline {
    agent any
    stages {
        // ...
    }
    post {
        always {
            junit '**/build/test-results/**/*.xml'
            melioraTestlab(
                projectKey: 'PRJX',
                testRunTitle: 'Automated tests',
                comment: 'Jenkins build: ${BUILD_FULL_DISPLAY_NAME} ${BUILD_RESULT}, ${BUILD_URL}',
                milestone: 'M1',
                testTargetTitle: 'Version 1.0',
                testEnvironmentTitle: 'integration-env',
                tags: 'jenkins nightly',
                parameters: 'BROWSER, USERNAME',
                issuesSettings: [
                    mergeAsSingleIssue: true,
                    reopenExisting: true,
                    assignToUser: 'agentsmith'
                ],
                importTestCases: [
                    importTestCasesRootCategory: 'Imported/Jenkins'
                ],
                publishTap: [
                    tapTestsAsSteps: true,
                    tapFileNameInIdentifier: true,
                    tapTestNumberInIdentifier: false,
                    tapMappingPrefix: 'tap-'
                ],
                publishRobot: [
                    robotOutput: '**/output.xml',
                    robotCatenateParentKeywords: true
                ],
                advancedSettings: [
                    companyId: 'mycompanyid', // your companyId in SaaS/hosted service
                    apiKey: hudson.util.Secret.fromString('verysecretapikey'),
                    testCaseMappingField: 'Test class',
                    usingonpremise: [
                        // optional, use only for on-premise installations
                        onpremiseurl: 'http://testcompany:8080/'
                    ]
                ]
            )
        }
    }
}

If you wish to familiarize yourself to the meaning of each setting, please refer to the plugin documentation at https://plugins.jenkins.io/meliora-testlab.

 

(Pipeline image from Jenkins.io – CC BY.SA 4.0 license)

Facebooktwitterlinkedinmail


Tags for this post: automation best practices features jenkins plugin release usage 


13.7.2017

Testlab – Bookhouse Boy release

To celebrate the warmth of the summer months, we are proud to release a new feature version of Testlab: Bookhouse Boy.

 

Custom fields for projects
Custom fields for projects

Just like requirements, test cases, and issues, the project asset can now also be defined with custom fields. You can find the field settings for your project asset from Testlab > Manage company … view.

When you customize the fields for your project asset these field settings will take effect in all your projects. For example, you can use these fields to track some high-level project details inside Testlab such as project deadlines, resourcing related details or something else.

For reporting out these details two new project templates have been added:

  • “List of projects” which is basically a list of project details from your Testlab instance. The project filters in projects by the criteria set and lists out project details as a listing.
  • “Project grouping” which can be used to group project data by defined fields. This report includes a bar graph for the grouped data and a listing of projects matching the set criteria.

Please note: As these two reports expose details on project level, “report.all” permission does not grant permission for these two new reports. This way, these two reports might not show up with your permission set automatically. You should adjust the role your have in your projects to include “report.projectlistreport” and “report.projectgroupingreport” to have access to these reports.

 

Comments for test results
Test result comments

Each result of the test case can now be set with a distinct comment. Earlier, test case assets themselves and also steps of executed tests could be commented.

Now as you create test runs, the test cases get bound as items in these runs. As you list out test cases in your scheduled runs in the Test execution view, there is a new column in this table for an execution comment. Note that you set the comment when you wish – You don’t have to execute the test and give it a result to include a comment: This way you can also use this comment field for some information before execution of the actual tests.

The comments for executed (or scheduled) tests are also shown in test cases’ execution history view, on related reports and on test coverage view (for tests with a result set). Also for Jenkins integration, the comments sent via the API are also set to this field, if any.

 

Report page sizing and orientation

Reports can now be rendered in different page sizes and in chosen orientation. The size of the page can be set as A4 or the larger A3 and the report can be laid out in portrait or in landscape orientation. Please experiment with these settings if you have trouble fitting all your data on your reports.

 

Reporting enhancements
  • Test case related reports now support filtering in test cases from test sets and test runs. If you filter in test cases with test runs, keep in mind, that the latest execution status of the test case is then reported against these filtered in runs.
  • “Results for run tests” report now has an option to filter in latest executed result for each test case. This way, if the same test case is included multiple times, only the latest executed results are left in on the report.
  • A project can now be set with a logo which is included in each report. You can upload the logo of your choice by editing the project details.
  • Grouping reports can now be grouped also with custom field values.

 

Progress indication

The UI now includes automatic notification on server operations that might take some time to complete. Also, most operations expected to run some time such as imports of data also support showing the progress of the operation in this notification dialog.

 
Support for new file formats

Exporting data is now possible as modern Excel-files (.xlsx). Also, reports can now be exported as .docx-files for Microsoft Word.

 

Other changes
  • The changes in the tags of the asset are now stored and included in the changes history of requirements, test cases, and issues.
  • The number of defects found -column in test execution view can now be used as a filter in the table.

 

Thanking you for all your feedback,

Meliora team


Bookhouse Boys

With Bookhouse Boy, we wish to celebrate and give homage to the true visionaries behind Twin Peaks – one of the greatest television drama series created. After 25 years, a new season of this great television is currently running offering new bizarre twists in the story of interesting characters including the small town of Twin Peaks itself. With the excellent writing of Frost and visionary directing of Lynch, the series is sure to leave it’s mark to the history of television.

All Testlab releases are code-named with some weird fact, theory, historical event or something else that should give some food for your imagination. As such, a code-name from Twin Peaks is more than fitting.

(Image from Twin Peaks (the original series) / Lynch/Frost Productions)

Facebooktwitterlinkedinmail


Tags for this post: announce features jenkins product release reporting screenshots 


12.4.2017

Testlab – Lilliput Sight released

Meliora is proud to announce a release of new major Testlab version: Lilliput Sight. This release includes some new major features such as asset templating but in the same time, bundles various smaller enhancements and changes for easier use. New features are described below.

 

Asset templating

 
Asset templating

Creating assets for your projects in a consistent way is often important. This release of Testlab includes support for templates which you can apply when adding new requirements, test cases or issues.

A template is basically a simple asset with some fields set with predefined values. As you are adding a new asset, you have an option for applying templates. When you apply a template, the asset is set with the values from the applied template. You can also apply multiple templates, so designing templates to suit the needs of your testing project is very flexible.

A set of new permissions (testcase.templates, requirement.templates, defect.templates) has been added to control who has access to using the templates. These permissions have been granted to all your roles which had the permission to edit the matching asset type.

 

Robot Framework output support
Robot Framework output support

When pushing automated results to Testlab, we now have native support for Robot Framework’s custom output file. By supporting the native format, the results include detailed information of keywords from the output which are pushed to Testlab as the steps executed.

The support for Robot Framework’s output has also been added to the Jenkins CI plugin. With the plugin, it is easy to publish Robot Framework’s test results to your Testlab project in a detailed format.

 

Copying and pasting steps

The editor for test case steps now includes a clipboard. You can select steps (select multiple steps by holding your shift and ctrl/cmd keys appropriately), copy them to the clipboard and paste them as you wish. The clipboard also persists between test cases so you can also copy and paste steps from a test case to another.

 

 

Filtering with operators in grids

The text columns in Testlab’s grid now feature operator filters which allow you to filter in data from the grid in more specific manner. You have an option of choosing the operator the column is filtered with such as “starts with”, “ends with”, … , and of course the familiar default “contains”.

With a large number of data in your project, this makes it easier to filter in and find the relevant data from your project.

 

 

Mark milestones, versions and environments as inactive

When managing milestones, versions, and environments for your project, you now can set these assets as active or inactive. For example, if a version is set as inactive, it is filtered out from relevant controls in the user interface. If your project has numerous versions, environments or milestones, keeping only the relevant ones active makes the use easier as the user interface is not littered with the non-relevant ones.

For versions and environments, the active flag is set in the Project management view. For milestones, the completed flag is respected as in completed milestones are interpreted as inactive.

 

Usability related enhancements
  • Editing asset statuses in table views: You can now edit statuses of assets in table views – also in batch editing mode.
  • New custom field type – Link: A new type of custom field has been added which holds a single web link (such as http, https or mailto -link).
  • Support deletion of multiple selected assets: The context menu for requirements and test cases now includes “Delete selected” function to delete all assets chosen from the tree.
  • Delete key shortcut: The Delete key is now a keyboard shortcut for context menu’s Delete-function.
  • Execution history respects revision selection: The execution history tab for a test case previously showed a combined execution history for all revisions of the chosen test cases. This has been changed in a way that the tab respects the revision selection in a similar manner to the other tabs in the Test case design view. When you choose a revision, the list of results in the execution history tab is only for the chosen revision of the test case.
  • Custom fields hold more data: Earlier, custom fields were limited to a maximum of 255 characters. This has been extended and custom fields can now hold a maximum of 4096 characters.
  • Test cases already run in test runs can be run again: If the user holds the permission for discarding a result of an already run test case, you can now choose and execute test cases already with a result (pass or fail) directly from the list of test cases in Test execution view. Earlier, you needed to discard all the results one by one for the tests you wish to run again.
  • Enhancements for presenting diagrams: The presentation view for relation and traceability diagrams has been improved – you can now zoom the view and pan the view in a more easier manner by dragging and by double clicking.
  • Copy link to clipboard: The popup dialog with a link to open up an asset from your Testlab has been added with a “Copy to clipboard” button. Clicking this button will copy the link directly to your clipboard.

 

Reporting enhancements
  • “Filter field & group values” option added for grouping reports: Requirement, test case, and issue grouping reports have been added with an option to apply the filter terms of the report to the values which are fetched via “Field to report” and “Group by”. For example, if you filter in a requirement grouping report for importance values “High” and “Critical”, choose to group the report by “Importance” and check the “Filter field & group values” option, the report rendered will not include reported groups for any other importance values than “High” and “Critical”.

 

Enhancements for importing and exporting
  • Export verified requirements for test cases: Test case export now includes a “verifies” field which includes the identifiers of requirements the test cases are set to verify.
  • Input file validation: The input file is now validated to hold the same number of columns in each read row than the header row of the file has. When reading the file, if rows are encountered with an incorrect number of columns, an error is printed out making it easier to track down any missing separator characters or such.

 

Thanking you for all your feedback,

Meliora team


Alice

Various disorientating neurological conditions that affect perception are known to exist. One of them is broadly categorized as Alice in Wonderland Syndrome in which the people experience size distortion of perceived objects. Lilliput Sight – or Micropsia – is a condition in which objects are perceived to be smaller than they actually are in the real world.

The condition is surprisingly common: episodes of micropsia or macropsia (seeing objects larger than they really are) occur in 9% of adolescents. The author of Alice’s Adventures in Wonderland – Lewis Carroll – is speculated to have had inspiration for the book from his own experiences in Micropsia. Carroll had been a well-known migraine sufferer which is one possible cause of these visual manifestations.

(Source: WikipediaThe Atlantic, Image from Alice’s Adventures in Wonderland (1972 Josef Shaftel Productions))

 

Facebooktwitterlinkedinmail


Tags for this post: announce features integration jenkins plugin product release reporting 


23.1.2016

New feature release: Oakville Blob

We are proud to announce a new major release of Meliora Testlab: Oakville Blob. A major feature included is a Rest-based API for your integration needs. In addition, this release includes numerous enhancements and fixes. Read on.

 

Integration API

 
Integration API

Meliora Testlab Integration API offers Rest/HTTP-based endpoints with data encapsulated in JSON format. The first iteration of the API offers endpoints for

  • fetching primary testing assets such as requirements, test cases and issues,
  • fetching file attachments and
  • pushing externally run testing results as test runs. 

We publish the API endpoints with Swagger, a live documentation tool, which enables you to make actual calls against the data of your Testlab installation with your browser. You can access this documentation today by selecting the “Rest API …” from the Help menu in your Testlab. You can also read more about the API from the corresponding documentation page.

Tagging users in comments

 
 
Tagging team members to comments

When commenting assets in your project such as issues or test cases, you can now tag users from your project to your comments. Just include the ID, e-mail address or name of the team member prefixed with @ character and this user automatically gets a notification about the comment. The notice scheme rules have also been updated to make it possible to send e-mail notifications for users who are tagged to the comments of assets. Also, a new out-of-box notice scheme “Commenting scheme” has been added for this.

See the attached video for an example how this feature works.

 

Execution history of a test case

Sometimes it is beneficial to go through the results of earlier times of execution for a test case. To make this as easy as possible, Test design view has been added with a new “Execution history” tab.

This new view lists all times the chosen test case has been executed with the details similar to the listing of test run’s items in Test execution view. Each result can be expanded to show the detailed results of each step.

 

Notification enhancements

When significant things happen in your Testlab projects, your team members are generated with notifications always accessible from the notifications panel at the top. Oakville Blob provides numerous enhancements to these notifications such as

  • notifications panel has been moved to the top of viewport and is now accessible from all Testlab views,
  • notifications panel can now be checked as kept open meaning, that the panel won’t automatically close on lost focus of the mouse cursor and
  • detailed documentation for all notification types has been added to the help manual.

In addition, the following new notification events have been added:

  • if an issue, a requirement or a test case which you have been assigned with is commented, you will be notified,
  • if during testing, a test case or it’s step is commented, the creator of the test run will get notified,
  • if a step of test which you have been assigned with is added with a comment during testing, you will be notified.

 

Targeted keyword search

The quick search functionality has been enhanced with a possibility to target the keyword to specific information in your project’s assets. By adding a fitting prefix: to your keyword, you can for example target the search engine to search from the name of a test case only. For example, 

  • searching with “name:something” searches “something” from the names of all assets (for example, test cases, issues, …) or,
  • searching with “requirement.name:something” searches “something” from the names of requirements.

For a complete listing of possible targeting prefixes, see Testlab’s help manual.

 

Usability enhancements

Several usability related changes have been implemented.

  • Easy access to test case step’s comments: Test execution view has been added with a new “Expand commented” button. By clicking this button the view expands all test run’s test cases which have been added with step related comments.
  • Rich text editing: The rich test editors of Testlab have been upgraded to a new major version of the editor with simpler and clearer UI.
  • Keyboard access:
    • Commenting: keyboard shortcuts have been added for saving, canceling and adding a new comment (where applicable).
    • Step editing: Step editor used to edit the steps of a test case has been added with proper keyboard shortcuts for navigating and inserting new steps.
  • Test coverage view: 
    • Test case coverage has been added with a new column: “Covered requirements”. This column sums up and provides access to all covered requirements of listed test cases.
    • Test run selector has been changed to an auto-complete field for easier use with lot of runs.

 

Reporting enhancements

Several reporting engine related changes have been implemented.

  • Hidden fields in report configuration: When configuring reports, fields configured as hidden are not anymore shown in the selectors listing project’s fields.
  • Sorting of saved reports: Saved reports are now sorted to a natural “related asset” – “title of the report” -order
  • Better color scheme: The colors rendered for some fields of assets are changed to make them more distinct from each other.
  • Test run’s details: When test runs are shown on reports, they are now always shown with the test run’s title, milestone, version and environment included.
  • Wrapped graph titles: When graphs on reports are rendered with very long titles, the titles are now wrapped on multiple lines.
  • Results of run tests report: The report now sums up the time taken to execute the tests.
  • Test case listing report: Created by field has been added.

 

Other changes

With the enhancements listed above, this feature release contains numerous smaller enhancements.

  • New custom field type – Unique ID: A new custom field type has been added which can be used to show an unique non-editable numerical identifier for the asset. 
  • Editing of test case step’s comments: The step related comments entered during the testing can now be edited from the Test execution view. This access is granted to users with “testrun.run” permission.
  • Confluence plugin: Listed assets can now be filtered with tags and, test case listing macro has an option to filter out empty test categories.
  • Test run titles made unique: Testlab now prevents you from creating a test run with a title which is already present if the milestone, version and environment for these runs are the same. Also, when test runs are presented in the UI, they are now always shown with this information (milestone, version, …) included.
  • “Assigned to” tree filter: The formerly “Assigned to me” checkbox typed filter in the trees has been changed to a select list which allows you to filter in assets assigned to other users too.
  • File attachment management during testing: Controls have been added to add and remove attachments of the test case during testing.
  • Dynamic change project -menu: The Change project -selection in Testlab-menu is now dynamic – if a new project is added for you, the project will be visible in this menu right away.
  • Permission aware events: When (the upper right corner floating) events are shown to users, the events are filtered against the set of user’s permissions. Now the users should be shown only with events they should be interested in.
  • Number of filtered test runs: The list of test runs in Test execution view now shows the number of runs filtered in.
  • UI framework: The underlying UI framework has been upgraded to a new major version with many rendering fixes for different browsers.

 

Thanking you for all your feedback,

Meliora team


Oakville

“On August 7, 1994 during a rainstorm, blobs of a translucent gelatinous substance, half the size of grains of rice each, fell at the farm home of Sunny Barclift. Shortly afterwards, Barclift’s mother, Dotty Hearn, had to go to hospital suffering from dizziness and nausea, and Barclift and a friend also suffered minor bouts of fatigue and nausea after handling the blobs. … Several attempts were made to identify the blobs, with Barclift initially asking her mother’s doctor to run tests on the substance at the hospital. Little obliged, and reported that it contained human white blood cells. Barclift also managed to persuade Mike Osweiler, of the Washington State Department of Ecology’s hazardous materials spill response unit, to examine the substance. Upon further examination by Osweiler’s staff, it was reported that the blobs contained cells with no nuclei, which Osweiler noted is something human white cells do have.”

(Source: WikipediaReddit, Map from Google Maps)

 

Facebooktwitterlinkedinmail


Tags for this post: announce features integration jenkins plugin product release reporting 


24.10.2015

Testlab Girus released

Meliora Testlab has evolved to a new major version – Girus. The release includes enhancements to reporting and multiple new integration possibilities.

Please read more about the new features and changes below. 

 

Automatic publishing of reports

Testlab provides an extensive set of reporting templates which you can pre-configure and save to your Testlab project. It used to be that to render the reports, you would go to Testlab’s “Reports” section and choose the preferred report for rendering.

Girus enhances reporting in a way where all saved projects can be scheduled for automatic publishing. Each report can be set with a

  • recurrence period (daily, weekly and monthly) for which the report is refreshed,
  • report type to render (PDF, XLS, ODF),
  • optionally, a list of e-mail addresses where to automatically send the report and
  • an option to web publish the report to a pre-determined web-address.

When configured so, the report will then be automatically rendered and sent to interested parties and optionally, made available to the relatively short URL address for accessing.

 

Slack integration

slack_rgb (1)

Slack is a modern team communication and messaging app which makes it easy to set-up channels for messaging, share files and collaborate with your team in many ways.

Meliora Testlab now supports integrating with Slack’s webhook-interfaces to post notifications about your Testlab assets to your Slack. The feature is implemented as a part of Testlab’s notice schemes. This way, you can set up rules for events which you prefer to be publishes to your targeted Slack #channel.

You can read more about the Slack integration via this link.

 

Webhooks

Webhooks are HTTP-protocol based callbacks which enable you ro react on changes in your Testlab project. Webhooks can be used as a one-way API to integrate your own system to Testlab.

Similarly to the Slack integration introduced above, the Webhooks are implemented as a channel in Testlab’s notice schemes. This way you can set up rules to pick the relevant events you wish to have the notices of.

An example: Let’s say you have an in-house ticketing system and you need to mark a ticket resolved each time an issue in Testlab is closed. With Webhooks, you can implement a simple HTTP based listener on your premises and set up a notification rule in Testlab to push an event to your listener everytime an issue is closed. With little programming, you can then mark the ticket in your own system as resolved. 

You can read more about the Webhooks via this link.

 

Maven plugin

Apache Maven is a common build automation tool used primarily for Java projects. In addition, Maven can be used to build projects written in C#, Ruby, Scala and other languages.

Meliora Testlab’s Maven Plugin is an extension to Maven which makes it possible to publish xUnit-compatible testing results to your Testlab project. If you are familiar with Testlab’s Jenkins CI plugin, the Maven one provides similar features easily accessible from your Maven project’s POM.

You can read more about the Maven plugin via this link.

 

Automatic creation of test cases for automated tests

When JUnit/xUnit-compatible testing results of automated tests are pushed to Testlab (for example from Jenkins, Maven plugin, …), the results are mapped and stored against the test cases of the project. For example, if you push a result for a test com.mycompany.junit.SomeTest, you should have a test case in your project with this identifier (or sub-prefix of this identifier) as a value in the custom field set up as the test case mapping field. The mapping logic is best explained in the Jenkins plugin documentation.

To make the pushing of results as easy as possible the plugins now have an option to automatically import the stubs of test cases from the testing results themselves. This way, if a test case cannot be found from the project for some mapping identifier, the test case is automatically created to a configured test category.

 

Jenkins plugin: TAP support

Test Anything Protocol, or TAP, is a simple interface between testing modules in a test harness. Testing results are represented by simple text files (.tap) describing the steps taken. The Jenkins plugin of Testlab has been enhanced in a way, that the results from .tap files produced by your job can be published to Testlab.

Each test step in your TAP result is mapped to a test case in Testlab via the mapping identifier, similarly to the xUnit-compatible way of working supported previously.

The support for TAP is best explained in the documentation of the Testlab’s Jenkins plugin.

 

Support for multiple JIRA projects in Webhook-based integration

When integrating JIRA with Testlab using the Webhooks-based integration strategy, the integration now supports integrating multiple JIRA projects to a single Testlab project. When multiple projects are specified and an issue is added, the user gets to choose which JIRA project the issue should be added to.

Due to this change, it is now also possible to specify which JIRA project the Testlab project is integrated with. Previously, the prefix and the key of the projects had to match between the JIRA and Testlab project.

 

Miscellaneous enhancements and changes
  • Results of run tests report added with new options to help you on reporting out your testing results:
    • Test execution date added as a supported field,
    • “Group totals by” option added which sums up and reports totals for each group of specified field,
    • reports have been added with columns and rows of sum totals and
    • test categories selection supports selection of multiple categories and test cases for filtering.
  • Updates on multiple underlying 3rd party libraries.
  • Bugs squished.

 

Sincerely yours,

Meliora team


Pithovirus

Pithovirus sibericum was discovered buried 30 m (98 ft) below the surface of late Pleistocene sediment in a 30 000-year-old sample of Siberian permafrost. It measures approximately 1.5 micrometers in length, making it the largest virus yet found. Although the virus is harmless to humans, its viability after being frozen for millennia has raised concerns that global climate change and tundra drilling operations could lead to previously undiscovered and potentially pathogenic viruses being unearthed.

A girus is a very large virus (gigantic virus). Many different giruses have been discovered since and many are so large that they even have their own viruses. The discovery of giruses has triggered some debate concerning the evolutionary origins of the giruses, going so far as to suggest that the giruses provide evidence of a fourth domain of life. Some even suggest a hypothesis that the cell nucleus of the life as we know it originally evolved from a large DNA virus.

(Source: Wikipedia, Pithovirus sibericum photo by Pavel Hrdlička, Wikipedia)

 

Facebooktwitterlinkedinmail


Tags for this post: announce features integration jenkins plugin product release reporting 


7.7.2015

Meliora Testlab – Polybius – released

Meliora Testlab team is proud to announce a new version of Testlab – Polybius. In addition to smaller enhancements many of the new features revolve around parameterization of test cases. It is now possible to create test cases as templates and when executing them, enter the parameters of the template to easily create variants of the test case.

Please read more about the new features and changes below. 

 

Test case parameters

 
Test case templating with parameters

Test cases can now be embedded with parameters. Parameters are basicly tags entered to test cases’ description, preconditions, steps or to the expected end result. In the content text, parameters should be entered as

    ${PARAMETER}

When test case is entered with parameter values later on, the actual description shown to the tester will include parameter tags replaced with entered values.

Using parameters is an easy way to create many executable variants for a test case with similar description content. For example, if you have a set of test cases intended to be run with each different web browser variant, you can describe your test case with a appropriate ${BROWSER} tag. This way you can easily plan & execute this test case for different web browsers by entering fitting values for this parameter later on.

 

Parameter typing

Testlab includes a management view for all project’s parameters. You can configure your parameters as selection lists, which restricts the values that can be selected for these parameters.

 

Planning and running tests with parameters

To create test case variants for parameterized test cases you can now enter values for the parameters in Execution planning view. The editor features a column showing all possible parameters for the test case and allows you to enter values for them. When a parameterized test case (template) is added to a test set and it is set with parameter values, the test case becomes a parameterized instance to be run.

Test execution view has similar controls where you can enter parameter values for test cases already added to a test run.

 

Issue management enhancements
  • Issue is added with a new field “Found with parameters” which always includes the parameters of the test case the issue was added for (if any).
  • The issue listing includes a similar field as a column which allows you to easily filter in issues with specific parameter value.
  • When adding a new issue while executing a test case, the failed steps and their comments so far are now automatically copied to the issue’s description field.

 

Coverage and reporting with parameterized tests

Test coverage view with coverage views via requirements and test cases have been enhanced to include parameterized test cases. Each parameterized variant of a test case is now calculated as a single verifying test case in the coverage calculation. The view also shows the parameters the test cases were run with.

The reports also now include the test case parameters in appropriate places (Issue listing, requirement coverage, results of run tests and execution status of test cases report). Issue listing, results of run tests and execution status of test cases reports also have test case parameter values as filters which allows you to filter in specific results from your test runs.

 

Jenkins plugin changes

Meliora Testlab Jenkins plugin now supports passing test case parameters from Jenkins’ environmental variables. You can list the variables which are passed as they are with the results and will be included as parameters at Testlab side.

For example, test case(s) in your Testlab project might have a parameter titled ${BROWSER}. When running automated UI tests in your Jenkins, enter a value “BROWSER” to this new setting and ensure that your Jenkins job sets an environmental variable BROWSER to some sensible value. This way running the job sends and sets the ${BROWSER} test case parameter value to all run tests to a value matching to the environmental variable.

 

Importing test runs

A CSV import of test runs has been added. Importing test runs supports importing test run details, test cases run in them and testing results of test cases and their steps.

 

Centralized authentication (CAS) improvements

Registration of new user accounts

Previously, when users authenticated via an external source via CAS came into Testlab, if they had not yet been created with Testlab user account, they could not log on. This is because authorization to Testlab’s projects are done via Testlab’s user accounts the needed roles and permissions must be granted to these users for the access.

This version is improved in a way, that when a user without Testlab account gets authenticated via CAS, he/she is shown with a welcome screen allowing her to register a personal Testlab account by entering few details (e-mail address, full name). The Testlab user account is then automatically created and an e-mail messages is sent to the company administrators notifying them about the new account.

Granting roles to new accounts (Onpremise)

On-premise version of Testlab can be configured to automatically grant a set of roles in a set of projects when a new user account is registered via CAS.

Relaxing the SSL verification of the host name for ticket validations

When setting up CAS, the client can now be configured to skip the host name check of the SSL certificate when verifying CAS tickets. This may help setting up CAS with self-signed certificates or with proxy configurations.

 

Sincerely yours,

Meliora team


eisernermann

Fancy a game ? Polybius is an arcade game which is said to have induced various psychological effects on players. The story describes players suffering from amnesia, night terrors, and a tendency to stop playing all video games. Around a month after its supposed release in 1981, Polybius is said to have disappeared without a trace. [Wikipedia]

In the span of a week, three children really did fall ill upon playing video games at arcades in the Portland area. Michael Lopez got a migraine, the first he’d ever had, from playing Tempest. Brian Mauro, a 12-year-old trying to set the world record for playing Asteroids for the longest time, fell ill after a 28-hour stint. And only a week later 18-year-old competitive gamer Jeff Dailey died due to a heart attack after chasing the world record in Berserk. One year later 19-year-old Peter Burkowski followed suit for the same reason playing the same game. [Eurogamer]

(Photo by DocAtRS [CC BY-SA 3.0], via Wikimedia Commons)

 

 

Facebooktwitterlinkedinmail


Tags for this post: announce features jenkins product release reporting video 


25.9.2014

Integrating with Apache JMeter

Apache JMeter is a popular tool for load and functional testing and for measuring performance. In this article we will give you hands-on examples on how to integrate your JMeter tests to Meliora Testlab.

Apache JMeter in brief

Apache JMeter is a tool for which with you can design load testing and functional testing scripts. Originally, JMeter was designed for testing web applications but has since expanded to be used for different kinds of load and functional testing. The scripts can be executed to collect performance statistics and testing results.

JMeter offers a desktop application for which the scripts can be designed and run with. JMeter can also be used from different kinds of build environments (such as Maven, Gradle, Ant, …) from which running the tests can be automated with. JMeter’s web site has a good set of documentation on how it should be used.

 

Typical usage scenario for JMeter

A common scenario for using JMeter is a some kind of load testing or smoke testing setup where JMeter is scripted to make a load of HTTP requests to a web application. Response times, request durations and possible errors are logged and analyzed later on for defects. Interpreting performance reports and analyzing metrics is usually done by people as automatically determining if some metric should be considered as a failure is often hard.

Keep in mind, that JMeter can be used against various kinds of backends other than HTTP servers, but we won’t get into that in this article.

 

Automating load testing with assertions

The difficulty in automating load testing scenarios comes from the fact that performance metrics are often ambiguous. For automation, each test run by JMeter must produce a distinct result indicating if the test passes or not. The JMeter script can be added with assertions to tackle this problem.

Assertions are basically the criteria which is set to decide if the sample recorded by JMeter indicates a failure or not. For example, an assertion might be set up to check that a request to your web application is executed in under some specified duration (i.e. your application is “fast enough”). Or, an another assertion might check that the response code from your application is always correct (for example, 200 OK). JMeter supports a number of different kinds of assertions for you to design your script with.

When your load testing script is set up with proper assertions the script suits well for automation as it can be run automatically, periodically or in any way you prefer to produce passing and failing test results which can be pushed to your test management tool for analysis. On how to use assertions in JMeter there is a good set of documentation available online.

 

Integration to Meliora Testlab

Meliora Testlab has a Jenkins CI plugin which enables you to push test results and open up issues according to the test results of your automated tests. When JMeter scripted tests are run in a Jenkins job, you can push the results of your load testing criteria to your Testlab project!

The technical scenario of this is illustrated in the picture below.

jmeterkuva

You need your JMeter script (plan). This is designed with the JMeter tool and should include the needed assertions (in the picture: Duration and ResponseCode) to determine if the tests should pass or not. A Jenkins job should be set up to run your tests, translate the JMeter produced log file to xUnit compatible testing results which are then pushed to your Testlab project as test case results. Each JMeter test (in this case Front page.Duration and Front page.ResponseCode) is mapped to a test case in your Testlab project which get results posted for when the Jenkins job is executed.

 

Example setup

In this chapter, we give you a hands on example on how to setup a Jenkins job to push testing results to your Testlab project. To make things easy, download the testlab_jmeter_example.zip file which includes all the files and assets mentioned below.

 
Creating a build

You need a some kind of build (Maven, Gradle, Ant, …) to execute your JMeter tests with. In this example we are going to use Gradle as it offers an easy to use JMeter plugin for running the tests. For running the JMeter scripts there are tons of options but using a build plugin is often the easiest way.

1. Download and install Gradle if needed

Go to www.gradle.org and download the latest Gradle binary. Install it as instructed to your system path so that you can run gradle commands.

2. Create build.gradle file

apply plugin: 'java'
apply plugin: 'idea'
apply plugin: 'jmeter'

buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath "com.github.kulya:jmeter-gradle-plugin:1.3.1-2.6"
}
}

As we are going to run all the tests with plugin’s default settings this is all we need. The build file just registers the “jmeter” plugin from the repository provided.

3. Create src directory and needed artifacts

For the JMeter plugin to work, create src/test/jmeter -directory and drop in a jmeter.properties file which is needed for running the actual JMeter tool. This jmeter.properties file is easy to obtain by downloading JMeter and copying the default jmeter.properties from the tool to this directory.

 
Creating a JMeter plan

When your Gradle build is set up as instructed you can run the JMeter tool easily by changing to your build directory and running the command

# gradle jmeterEditor

This downloads all the needed artifacts and launches the graphical user interface for designing JMeter plans.

To make things easy, you can use the MyPlan.jmx provijmeterplanded in the zip package. The script is really simple: It has a single HTTP Request Sampler (named Front page) set up to make a request to http://localhost:9090 address with two assertions: 

  • Duration -assertion to check that the time to make the request does not exceed 5 milliseconds. For the sake of this example, this assertion should fail as the request probably takes more than this.
  • ResponseCode -assertion to check that the response code from the server is 200 (OK). This should pass as long as there is a web server running in port 9090 (we’ll come to this later).

It is recommended to give your Samplers and Assertions sensible names, as you refer directly these names later when mapping the test results to your Testlab test cases.

The created plan(s) should be saved to the src/test/jmeter -directory we created earlier, as Gradle’s JMeter plugin automatically executes all plans from this directory.

 

Setting up a Jenkins job

1. Install Jenkins

If you don’t happen to have Jenkins CI server available, setting one up locally couldn’t be easier. Download the latest release to a directory and run it with 

# java -jar jenkins.war --httpPort=9090

Wait a bit, and Jenkins should be accessible from http://localhost:9090 with your web browser. 

The JMeter plan we went through earlier made a request to http://localhost:9090. When you are running your Jenkins with the command said, the JMeter will fetch the front page of your Jenkins CI server when the tests are run. If you prefer to use some other Jenkins installation you might want to edit the MyPlan.jmx provided to point to this other address.

2. Install needed Jenkins plugins

Go to Manage Jenkins > Manage Plugins > Available and install

  • Gradle Plugin
  • Meliora Testlab Plugin
  • Performance Plugin
  • xUnit Plugin

2.1 Configure plugins

Go to Manage Jenkins > Configure System > Gradle and add a new Gradle installation for your locally installed Gradle. 

3. Create a job

Add new “free-style software project” job to your Jenkins and configure it as follows:

3.1 Add build step: Execute shell

Add a new “Execute shell” typed build step to copy the contents of your earlier set up Gradle project to job’s workspace. This is needed as the project is not in a version control repository. Setup the step as for example:

jmeter_executeshellplugin

.. Or something else that will make your Gradle project available to Jenkins job’s workspace.

Note: The files should be copied so that the root of the workspace contains the build.gradle file for launching the build.

3.2 Add build step: Invoke Gradle script

Select your locally installed Gradle Version and enter “clean jmeterRun” to Tasks field. This will run “gradle clean jmeterRun” command for your Gradle project which will clean up the workspace and execute the JMeter plan.

jmeter_gradleplugin

3.3 Add post-build action: Publish Performance test result report (optional)

Jenkins CI’s Performance plugin provides you trend reports on how your JMeter tests have been run. This plugin is not required for Testlab’s integration, but provides handy performance metrics on your Jenkins job view. To set up the action click “Add a new report”, select JMeter and set the Report files as “**/jmeter-report/*.xml”:

jmeter_performanceplugin

Other settings can be left to defaults or you can configure the settings for your liking.

3.4 Add post-build action: Publish xUnit test result report

Testlab’s Jenkins plugin works in a way, that it needs the test results to be available in so called xUnit format. In addition, this will generate test result trending graphs to your Jenkins job view. Add a post-build action to publish the test results resolved from JMeter assertions as follows by selecting a “Custom Tool”:

jmeter_xunitplugin

Note: The jmeter_to_xunit.xsl custom stylesheet is mandatory. This translates the JMeter’s log files to the xUnit format. The .xsl file mentioned is located in the jmeterproject -directory in the zip file and will be available in the Jenkins’ workspace root if the project is copied there as set up earlier.

3.5 Add post-build action: Publish test results to Testlab

The above plugins will set up the workspace, execute the JMeter tests, publish the needed reports to Jenkins job view and translate the JMeter log file(s) to xUnit format. What is left is to push the test results to Testlab. For this, add a “Publish test results to Testlab” post-build action and configure it as follows:

jmeter_testlabplugin

For sake of simplicity, we will be using the “Demo” project of your Testlab. Make sure to configure the “Company ID” and “Testlab API key” fields to match your Testlab environment. The Test case mapping field is set to “Automated” which is by default configured as a custom field in the “Demo” project.

If you haven’t yet configured an API key to your Testlab, you should log on to your Testlab as company administrator and configure one from Testlab > Manage company … > API keys. See Testlab’s help manual for more details.

Note: Your Testlab’s edition must be one with access to the API functions. If you cannot see the API keys tab in your Manage company view and wish to proceed, please contact us and we get it sorted out.

 

Mapping JMeter tests to test cases in Testlab

For the Jenkins plugin to be able to record the test results to your Testlab project your project must contain matching test cases. As explained in the plugin documentation, your project in Testlab must have a custom field set up which is used to map the incoming test results. In the “Demo” project field is already set up (called “Automated”). 

jmeterplanEvery assertion in JMeter’s test plan will record a distinguishing test result when run. In the simple plan provided, we have a single HTTP Request Sampler named “Front page”. This Sampler is tied with two assertions (named “Duration” and “ResponseCode”) which check if the request was done properly. When translated to xUnit format, these test results will get idenfied as <Sampler name>.<Assertion name>, for example:

  • Front page/Duration will be identified as: Front page.Duration and
  • Front page/ResponseCode will be identified as: Front page.ResponseCode

To map these test results to test cases in the “Demo” project,

1. Add test cases for JMeter assertions

Log on to Testlab’s “Demo” project, go to Test case design and

  • add a new Test category called “Load tests”, and to this category,
  • add a new test case “Front page speed”, set the Automated field to “Front page.Duration” and Approve the test case as ready and
  • add a new test case “Front page response code”, set the Automated field to “Front page.ResponseCode” and Approve the test case as ready.

Now we have two test cases for which the “Test case mapping field” we set up earlier (“Automated”) contains the JMeter assertions’ identifiers.

 

Running JMeter tests

What is left to do is to run the actual tests. Go to your Jenkins job view and click “Build now”. A new build should be scheduled, executed and completed – probably as FAILED. This is because the JMeter plan has the 5 millisecond assertion which should fail the job as expected.

 

Viewing the results in Testlab

Log on to Testlab’s “Demo” project and select the Test execution view. If everything went correctly, you should now have a new test run titled “jmeter run” in your project:

jmeter_testrun

As expected, the Front page speed test case reports as failed and Front page response code test case reports as passed.

As we configured the publisher to open up issues for failed tests we should also have an issue present. Change to Issues view and verify, that an issue has been opened up:

jmeter_defect

 

Viewing the results in Jenkins CI

The matching results are present in your Jenkins job view. Open up the job view from your Jenkins:

jmeter_jenkinsview

The view holds the trend graphs from the plugins we set up earlier: “Responding time” and “Percentage of errors” from Performance plugin and “Test result Trend” from xUnit plugin. 

To see the results of the assertions, click “Latest Test Result”:

jmeter_jenkinsresults

The results show that the Front page.Duration test failed and one test has passed (Front page.ResponseCode).

 

Links referred

 http://jmeter.apache.org/  Apache JMeter home page
 http://jmeter.apache.org/usermanual/index.html  Apache JMeter user manual
 http://jmeter.apache.org/usermanual/component_reference.html#assertions  Apache JMeter assertion reference
 http://blazemeter.com/blog/how-use-jmeter-assertions-3-easy-steps  BlazeMeter: How to Use JMeter Assertions in 3 Easy Steps
 https://www.melioratestlab.com/wp-content/uploads/2014/09/testlab_jmeter_example.zip  Needed assets for running the example
 https://github.com/kulya/jmeter-gradle-plugin  Gradle JMeter plugin
 http://www.gradle.org/  Gradle home page
 http://mirrors.jenkins-ci.org/war/latest/jenkins.war  Latest Jenkins CI release
 https://www.melioratestlab.com/wp-content/uploads/2014/09/jmeter_to_xunit.xsl_.txt  XSL-file to translate JMeter JTL file to xUnit format  
 https://wiki.jenkins-ci.org/display/JENKINS/Meliora+Testlab+Plugin  Meliora Testlab Jenkins Plugin documentation 

 

 

 

Facebooktwitterlinkedinmail


Tags for this post: example integration jenkins load testing usage 


9.7.2014

Testlab – Flannan Isles released

Summer is here! We’re happy to announce a new feature release of Testlab: Flannan Isles. The version has a number of new features and user interface enhancements described in detail below. As expected, all features are immediately available for all our hosted users. Enjoy! 

 

video_tagging

 
Tagging assets

Ever had a situation where you’d like to pin some data in your system of choice to find it later on or, group it up with similar data ? This is now possible in Testlab as it implements tagging of assets where you can pin your assets with keywords of your choice.

  • Tag requirements, test cases, test sets, test runs, issues and reports
  • Easy tagging of single assets
  • Tag multiple assets by selecting your assets from a tree or, tag multiple issues using issue listing filtering
  • Easy to use project tag cloud – click a tag to search content by your tag. Or search manually by entering a search word in format “tag:your tag”.
  • Filter tree content by searching with “tag:your tag”
  • Reporting and coverage analysis now support filtering with tags

Tagging assets is especially useful in situations, where you have a need to group some of your assets for later use. For example, you might want to tag all your requirements targeted for future release for easier management of your next release.

 

video_directediting

 
Direct editing of requirements and test cases

The views for managing the central assets of Testlab, requirements and test cases, have been enhanced with more snappy direct editing mode.

In previous Testlab versions we had separate viewing of assets and a transition to an editing mode. From now on, the forms and controls on requirement and test case editing are always editable with just a click for everyone with needed permissions.

In addition, the form controls have now a more clear disabled look to indicate what is editable and what is not.

 

video_controlandmonitorautomatedtests

 
Control and monitor automated tests

Dashboard of Testlab now features a new widget Jenkins Jobs which enables you to monitor and trigger jobs in your Jenkins CI server.

  • View your jobs’ build trend, latest build result and build number directly on your Testlab dashboard
  • Launch builds directly from the widget
  • Open up the related views on your browser from your Jenkins server with just a click
  • Pick the jobs you prefer – even from multiple different Jenkins servers if needed. Up to four different Jenkins servers can be controlled from a single dashboard.
  • Easy UI – if you are familiar with Jenkins’ UI you feel at home with this one
  • Integrates directly from your browser utilizing the Jenkins’ Meliora Testlab plugin at your Jenkins server

 

Reporting enhancements

The reports of Testlab have been enhanced with following addition:

  • New filtering options added for
    • Listing of requirements: covered & assignee
    • Listing of test cases: status & priority & assignee
    • Listing of issues: resolution & environment & related test case & resolved in version
  • Issues per priority report has been added with a sub report listing all issues counted to the totals
  • Similarly, execution status of test cases now includes a list of related test cases

 

Regenerating requirement identifiers

Requirement management now has a feature in the menu to regenerate IDs. During design, this can be used to easily regenerate all IDs in some folder or even for entire project. The identifiers will be regenerated in 1, 1.1, 1.1.1, 1.1.2, 1.1.3, … format prefixed with the same prefix as in the selected folder. If IDs are regenerated for the whole project the identifiers will be prefixed with project’s key.

Keep in mind, that regenerating IDs will overwrite and possibly change the current IDs – so use this feature sparingly.

 

Sincerely yours,

Meliora team


letter

The Flannan Isles are a small island group close to Scotland, west of the Isle of Lewis. In December 1900, three men occuping the lighthouse vanished, leaving behind an unfinished meal and a mystery that’s never been conclusively solved.

The only sign of anything amiss in the lighthouse was an overturned chair by the kitchen table. No sign of the three men was found, either inside the lighthouse or anywhere on the island. Many rumours of their disappearance surfaced, from a murder to sea serpent eating the men and to foreign spies abducting them, but no conclusive evidence was never found in the investigations.

Photo by Marc Calhoun from geograph.co.uk.

 

Facebooktwitterlinkedinmail


Tags for this post: announce features jenkins release reporting video 


24.1.2014

New feature release with importing and exporting

We are proud to announce a new major release of Testlab (Henrietta Lacks). This update brings you new major features such as importing and exporting data from spreadsheets, quick searching of assets in your project, enhancements to our plugins and many more!

 

video_organize_as_projects

 
Importing and exporting data

For easy adoption Testlab now offers import feature for your existing test cases, requirements or issues with a CSV format using office tools such as Microsoft Excel. Data from your projects can also be exported in identical format.

The feature supports importing requirements and their hierarchy, test categories, test cases including steps and issues. We also support importing values for custom fields, file attachments and comments.

video_adapts_to_your_process

 
Searching assets

Enjoy a fast and thorough searching function to find the assets you are interested in your project. Type in a keyword and you’ll get an organized result list for matching assets for easy access.

The search is implemented as an always accessible search field in your Testlab toolbar. The use of this field should be familiar for all users of some kind of embedded search, such as Mac’s Spotlight.

video_verify_track_and_report

 
Coverage enhancements

The coverage view is essential for knowing what has been tested for your application – how your design has been verified. We added some features for coverage reporting such as:

  • Filtering in features which have testing results in your project. This helps to filter out all the features from the view which you never intended to be tested in your version or a run you’re reporting against.
  • Content popups for related assets: By hovering your mouse on coverage related test cases and issues you’ll get instant popup describing the hovered asset.
  • Added “Not in test run” status as a reported state in results bar. This tells you if there are tests still to be scheduled for the feature.

 

video_manage_users

 
Drag and drop files

Attaching files to your assets in Testlab cannot get easier. You can now drag and drop files on your browser to automatically upload and attach them. You can even drop multiple files to upload them all at once (feature requires dropzone support and works currently in Chrome, Firefox, Safari 6+ and IE10+).

 

  

JIRA plugin enhancements

Our two-way JIRA plugin has been enhanced with the following features:

  • Issue types which are synchronized to Testlab can be now chosen. This way you can for example synchronize only defects and leave new features unsynchronized.
  • The fields which are not automatically mapped to Testlab’s fields can now be configured to be mapped to Testlab’s custom fields. This way you can synchronize custom field content or synchronize a missing JIRA field (such as estimate) to a custom field of your choice in Testlab.

 

Session management UI

Testlab now offers an user interface for administrators for which they can see all active Testlab sessions. This way they can transparently see how many licenses are in use and optionally terminate sessions from their Testlab.

 

Other enhancements

In addition to the above, the version features numerous other enhancements. Some of most notable include:

  • Jenkins plugin class level mapping: Test cases in Testlab can now be mapped to Jenkins’ run tests at parent level. For example, mapping a test case with “com.example.tests.ui” in Testlab will be set as failed if any tests in Jenkins with identifier starting with “com.example.tests.ui” fail.
  • Reordering test case steps: Steps of a test case can be now reordered by dragging and dropping.
  • Adding issues for test run’s test cases: A new icon button has been added to test runs panel which allows you easily add a new issue for a test case in an existing test run. For example, this way you can add issues later on to the test run if some are missed during the execution.
  • More quick links: The user interface now contains more quick links between assets. For example test run panel’s “Added issues” counts can be clicked to open up the related assets in a popup window.
  • Requirement class icons: Different requirement classes (user stories, use cases etc) now feature different icons. This way the different types of requirements are easily distinguishable in the user interface.
  • Rich text editor tab / de-tab: Pressing tab or shift+tab in rich text editor now indents and outdents text for easier editing.
  • Better keyboard navigation: Keyboard navigation in the user interface is now better, especially in the hierarchy trees.
  • Opening attachments inline: Attached files with browser supported content types are now opened inline directly in the browser window instead of forcing the document to be saved to disk.

 

Sincerely yours,

Meliora team


henrietta_lacksHenrietta Lacks (1920 – 1951) was an African-American woman who passed away of cervical cancer in 1951. Little did she know that her fatal tumors would hold a key to numerous medical advancements (polio vaccines and chemotherapy for example). Her biopsied cells were found to really thrive outside her body and would be used to create the first immortal cell line for medical research so that her cells are still alive today – over 60 years after her passing. Her cells were used to create the so called HeLa cell line for scientific research – currently the oldest and most commonly used human cell line. They were also the first human cells successfully cloned in 1955.

Henrietta’s cells have been mailed to scientists around the globe for research and scientists have grown some 20 tons of cells. Henrietta is still living today, around the globe and bigger than ever. Find out more by listening Radiolab’s great short story about the subject!

 

Facebooktwitterlinkedinmail


Tags for this post: announce features jenkins jira release video 


19.9.2013

Testlab integrates to Confluence and Jenkins, “Toynbee Tile” released

Meliora is pleased to announce Testlab “Toynbee Tile” with integration plugins to Atlassian Confluence and Jenkins CI included. Please read more about the new features below.

E-mail notifications

The version includes fully configurable E-mailing notice schemes. A scheme allows you to configure the rules and events for which Testlab will send your users notifications via e-mail.

E-mails are neatly formatted as HTML messages with asset details included. E-mail message also includes an easy button for you to jump to Testlab with and open up the related asset.

In addition to the notification e-mails all requirement, test case and issue related e-mails are now sent with the new template when the “Send as E-mail” function in Testlab is used.

 

Notice schemes and e-mailing rules

Testlab allows you to design your own schemes for e-mail notifications. These schemes are shared for all projects in your company and can be re-used if applicable. 

A scheme is a collection of asset related rules which define the events which trigger the sending of a messages and receivers for these messages.

We’ve included a set of default schemes in Testlab to make the use of e-mail schemes as easy as possible for you.

 

 

Atlassian Confluence integration 

Toynbee Tile brings in with it a support for Atlassian Confluence plugin. The plugin includes macros for your Confluence site which allow you to include

  • lists of requirements,
  • lists of test cases and/or
  • lists of issues

to your Confluence pages.

Macros are fully configurable with options to pick the relevant assets from your Testlab projects and also render an easy to use “Open in Testlab” action for each asset for easy transition from Confluence to Testlab.

 

Jenkins CI integration 

Jenkins CI is a popular open-source continuous integration server. A typical Jenkins build often includes automated tests which might be for example unit tests or integration tests.

Meliora Testlab Jenkins plugin allows you to publish the results of the automated tests to your Testlab project. The plugin pushes the results to Testlab by creating a test run with automated tests mapped to Testlab’s test cases.

The plugin allows you to automatically open up issues in Testlab if tests in your Jenkins build fails. Issues can also be automatically assigned to some user in your Testlab project.

If you are using Jenkins for your development this makes Testlab a great choice for your test management efforts.

 

In addition to the major changes described above, some notifiable changes include:

Project’s time zone

Each project has now a default time zone which is used to format for example dates and times in the e-mail messages sent from Testlab. This information will also be used with reporting in the future.

Snappier user interface

Toynbee Tile includes an improved drawing strategy for the browser client. This should make your user interface more snappier than before in every day use.

Improved printing

When printing out individual assets (requirements, test cases or issues) from Testlab we now use the same layout as is used with e-mails.

That’s it for now! We hope the integrations to Confluence and Jenkins make the use of Testlab even more easier for you in your enterprise. All plugins will be released to their respective repositories (Atlassian Marketplace, Jenkins update center) as soon as possible but in the mean time all plugins are available to our customers by request.

Sincerely yours,

Meliora team



Toynbee tile
? The Toynbee tiles are tiles embedded in asphalt of streets in numerous major cities in the United States and South America with unknown origin. All tiles contain some variation of a message “TOYNBEE IDEA, IN MOVIE 2001, RESURRECT DEAD, ON PLANET JUPITER“. Since the 1980s several hundred tiles have been discovered.

What ? Yes, someone or some group of people are and have been embedding this message to the streets of major cities for 30 years now. Why – nobody exactly knows but some theories exist and there is a nice documentary about this intriguing subject with one in it for all interested parties there. 

Facebooktwitterlinkedinmail


Tags for this post: announce confluence features jenkins plugin product release 


 
 
Best-of-class cross-browser hosted SaaS quality and test management, testing and issue management tools to improve your quality. Site information.