cmwforms - Test Management

Purpose

cmwforms – Test Management is a test case management solution that can be used to store and manage test cases and associated results.

This solution allows you to perform the following:

• Document test cases.
• Create test plans that include references to one or more test cases.
• Document the outcome of the manual execution of test cases.
• Initiate a defect report when a manual test fails.

This solution competes with other commercial solution such as:

• Mercury Test Director
• TestTrack TCM

Features

cmwforms – Test Management is a CMW Application that is designed to manage test cases, document their execution results and manage the resolution of test case failures using the CMW Defect Management application.

This application is made up of the following:

• Test plan.  This is used to create a test plan for different types of test cycles.
• Test case.  This is used to document the instructions to be followed when performing a manual test.
• Test result.  This is used to document the outcome of manually executing a test case.
• Defect report.  This is used to manage the resolution of a failed test case.

A test plan is created for each test cycle and this is used to document the following:

• Title and Description
• Project or application being tested
• Component being tested
• Author of the test plan
• Approver of the test plan
• CMW Test Cases

The CMW Test Cases tab is used to link one or more test cases with the test plan.  Once the test plan is created you have a self contain record that identifies all the tests that will be performed.

The test case record is used to document the individual test cases.  Each test case is used to document the following:

• Test case Title
• Test case Id.  This is a unique number generated by cmwforms for each test case.
• Project or application for which the test case applies.
• Component being tested using the test case.
• Test Input.  This is a description of how the test should be run.
• Expected Result.  This is a description of the expected outcome of the test.

The Test Input and Expected Result fields are rich text fields and can be used to store text and graphics.  Alternatively you can attach images to the Attachment tab of the Test Case record.

The test result is used to record the outcome of manually running a test case on a given date.  Each test result is used to document the following:

• Test result Title.  If the Test Results is created from within the Test Case record, using the New Test Result command, then this Title will be populated with the Test Case Title.
• Name of person documenting the test result.
• Date when test result was documented.  This should be the same as the date when the test case was run.
• Test Status.  This can be either Success or Failure.
• Test Result.  This is used to document the actual result that was recorded when the test was manually executed.

If the Test Status is failure then the tester can create a new defect report from within the test result record.  When doing so the test results Title will be copied to the defect report Title.

If you wish to populate the defect report with more information from the test result then you can select the test report record and then use the clone command and select defect report as a target.  The clone command will copy the test result record into a new defect record.  All information found in common fields (fields that exist in both record types) will be copied across.

Putting into practice

Create test cases

The first step in using cmwforms – Test Management is to create the individual test cases.  These can be created by different authors and then saved.

If you are using the CMW Requirements Management application then you can select the individual requirements records and then use the clone command to create the test cases automatically.  The clone command will copy the common information from the requirements record to the appropriate test case record and then link the two together.  When using this feature, you will still need to update the test case with step by step instructions on how to execute the test.  This is necessary because the requirements record does not contain the implementation information that describes how the application will operate.

Create test plan

Before a test cycle is started a test plan should be created and this should be updated to include a link to each of the test cases that will be executed as part of the test cycle. Creating this link will enable you to define and communicate the scope of the test cycle without any ambiguity.

Execute test plan

To execute the required tests you need to notify your testers and point them to the plan.  Testers should execute the tests from within the test plan.  This is very important as a test plan may contain a small subset of all tests that are available for an application.

When the test cycle is executed the testers should go through the test plan and execute each of the test cases.  They should open each test case and then perform the test as described in the Test Case Input.

When the test is run, the tester should compare the outcome of the test with the Expected Results that are documented in the test case.  The testers should then create a test result for each executed test case.  The test result should be created from within the test case; this will update the Title and establish a link between the test case and the test result automatically.

In the test result the testers should update the Author’s name, the Date and the Test Status fields.  Also the detailed description should be provided in the Test Result field.  In practice the Test Result field only needs to be updated if the actual test result is different from the expected test result.

If the test status is failed then a defect record should be created from within the test result record.

By following the above procedure testers will be able to create a hierarchy of test records showing what tests are needed for a test plan, which of these have been run and what results have been obtained and for those tests that have failed which show the defect records created.  cmwforms drill down features can be used to navigate between the various records.

Resolve test defects

Testers should create a defect report for each failed test case.  This should be created from within the test result record.  CMW Forms will link the two records together.

When the defects are resolved a second test cycle can be executed.  This may execute all the test cases from the last test cycle or can include only the tests that have failed.  Creating the new test plan is a manual process and you will need to reassign the required test cases to the test plan.

Customising application

All aspects of the cmwforms - Test Management application can be modified without the need for any programming or database work.  Also these changes can be made without the need to modify existing records.

This section contains a list of what can be changed.  For detailed instructions on how to make the changes, please consult the CMW documentation.

• Modify field captions.
• Modify field order.
• Add new fields or remove existing fields.
• Modify the list of values for any of the lookup fields.

You can make all the above changes on the fly, even if there are active users.

Active users have a cached copy of the application definition and they will continue to use this until they re-start cmwforms or switch workspaces.  Once the cached copy is updated they will automatically start to view and create records using the new application definition.

Most changes to an application are allowed and supported and you will be able to make these with relative ease and without having to worry about the impact on current stored information.

Changes that will impact current information will be automatically disabled. Following are examples of changes that you will not be allowed to do:

• Change rich text field to normal text field.
• Change rich text field to text field.
• Change text or number fields to date.

If you delete a field from a form then the data associated with this field will not be deleted but will become invisible to users.  If you re-introduce the field then the information associated with the field will become visible again.

Security and role based access control

cmwforms information for a given workspace will only be visible to users of that workspace.

The access rights that a user has will be determined by their role in the workspace.

• Users with User role will be able to create read and modify all information.
• Users with Submitter role will only be able to create new information.
• Users with Guest role will only be able to read information.

Existing information cannot be deleted by anyone regardless of their role.

General Usability features

The default cmwforms view will show all information that is assigned to the current user.  Users will therefore be able to start cmwforms, open a workspace and then see all records that are assigned to them for action.

cmwforms will send a notification by e-mail when records are assigned to users.  The user will be able to start cmwforms, Open the workspace and select the required record by clicking the cmwforms link on the e-mail message.  When using the Test Management application you need to switch scope to All Records.  This is necessary since most of the Test Management forms do not have an assignee field.

Users can easily find all records that they have created by selecting the required workspace and then setting the view scope to My records.

Users can view all information for a given workspace by setting the view scope to All Records

Users can filter data by creating filters.  These filters may include a single filter conditions, all records with status equal to raised for example.  Alternatively users can create a filter with two or more filter conditions.

Filters can be saved and re-used.