Test Run Workflow and Signatures

Every ALM or Test Management solution focuses on collaboration, bringing people together in a virtual digital office, online task boards, etc. Polarion enables teams to collaborate on shared assets easily but also securely. You can control who can see what, who can change what, and when via granular permission controls and robust configurable workflow automation.

What does it mean?

We understand that the way the people collaborate has to be controlled... maybe better to say, "guided". Not with 100 pages of documented SOP procedures, but guided by the tool itself. For example:

• A requirement can be marked as verified done only if the implementation task is done and the testing procedure was executed and passed in all the supported environments.
  
  
• A test can be marked as passed only if all the test cases passes and a test results were reviewed by second pair of eyes.
  
  We can continue ad infinitum, but the beauty of Polarion is that YOU can continue on your own: whatever operating procedure you have to follow, you can configure and/or customize the Polarion workflow to support you in ensuring the procedure is followed … with all steps happening at the right time.
  
  

Work Items and Document Workflow

Polarion workflow coveres the lifecycle of both elementary granular entities (requirements, test cases, tasks… we call them Work Items,) and higher-level containers: specifications (as LiveDoc documents, for example).

It's not just about automation and control of sequential workflow transitions. In Polarion 2015 we added Document Signatures that let you control parallel workflow transitions (i.e. enable status transition only if specified stakeholders sign the transition).

Note: Polarion's Document Signatures were implemented in compliance with FDA CFR 21 Part 11.

Test Runs

Let's speak now about Test Runs. The Test Run object in Polarion supports the test execution process. It acts as a test plan, and defines which test cases  are to be executed in which environment(s). But it also tracks important information about the execution of the test cases: what are the results of the executed test cases, actual vs expected values, time spent, user records, etc.

Test Runs generalize the concept of manual and automated tests, static source code analysis tasks, performance and load tests etc. Whatever QA activitiy is performed, there is always evidence in our unified repository - traceable and fully auditable. If QA activity reveals issues, Issue type Work Items are instantly generated and auto-assigned for processing, thus speeding up the resolution process significantly, As we all know, the sooner the issue is reported to the responsible developer, the less time (exponentialy) we spend overall. No hours (or even minutes) spent on issue assignments to save days or hours spent on fixing.

Test Run Workflow

Polarion 2016 delivers workflow automation to control and secure the lifecycle of testing. Instead of just setting a Test Run's status, you can now model the full workflow of your testing.

You will benefit from:

• Automating of status change condition checks. For example, a Test Run can be marked as "Passed with failures" only if all the issues related to failed test cases have been tagged as reviewed
• Status change function triggers. For example a Task type Work item can be created when a Test Run is pushed from status "draft" to "planned". The Task is linked with the Test Run, and this is where testers can fill in test records. Another example:  an epic Beta test run can be created when an Epic type Work Item reaches the "implemented" state. When the Test Run is executed and passes, the Epic can be marked automatically as "verified".

Test Run Signatures

Required by FDA for medical, but it also applies for other functional safety development, requiring that e-signatures be applied to test execution: the fact of executing test cases as well as approving the test results. The practice is called as "each action shall be seen by 4 eyes". One person (2 eyes) executes the test cases and marks them passed/failed, and a second person approves the final test result, reviewing the test case results and marking the Test Run overall as "verified passed" or "failed".

Polarion 2016 delivers electronic signatures for Test Runs  as an optional part of the Test Run workflow configuration. Signatures can be required to certify execution of each test case as well as an entire Test Run.