Principals of Test Management
Test management is the term given to the process of managing the resources, materials and artifacts associated with testing a product or system under development. Good test management depends on implementing and executing a consistent well though out process. With an effective test management process in place a development team can be confident in delivering high quality product releases to clients and customers.
There are a number of core test management principals associated with managing test cases. The core comes down to just 5 test management principals:
1. Tracking details about the product under test
2. Developing a repository of reusable test cases
3. Grouping test cases in some way to create runs
4. Dividing the testing up into logical areas
5. Recording results against a run
Tracking details of the product or system under test means recording aspects of your system like requirements it is expected to meet, components that make up the system and the different versions of the system created. In tracking these aspects about your system the overall aim is to build up a picture of requirements covered, components of the system covered and the versions of the system that the test cases were executed against.
Whilst many products can be tracked simply in terms of a version, complexities can arise here. For example where the end product is going to be a group of sub products it may be necessary to track the versions of all the sub products. In this case part of the test management process needs to focus on how results are logged against versions of these multiple sub projects. The simplest approach is usually to have a single overall version that then references all the versions of the sub project. Whilst this tracking of versions numbers (or revisions) is important to the test management process this aspect really depends on a good configuration management process.
In tracking the requirements that the tests cover you can build up a requirements traceability matrix that allows you to see which requirements have failed results logged against them and which requirements are fully tested before a release. The same goes for tracking against the components of a product, in so much as you can see which components have failed or passed test cases logged against them. The purpose behind tracking the versions and/or builds is so that individual results can be logged against a specific version of the product being tested. Clearly different versions of the product may pass or fail different tests when they are executed.
In building a repository of cases the goal of the test management process is to allow tests to be reused on a scheduled basis against different versions of the system. In fact this ability to reuse cases is the aspect of good test management that allows testers to run an efficient and effective test management process. Being able to identify cases for reuse against different versions of the system meets the need for a system to have comprehensive regression tests run against every versions of the system.
With a repository of test cases created it is common for these cases to be grouped in to logical sets so that the group can be executed in one go. This grouping may be based on similar types of tests, ranges of disparate tests in the case of creating a regression run or tests aimed at covering a specific requirement/component of the product. In testing these groups of tests can be referred to as a suite, a script or a run. Terminology differs but the end result is the same; a group of similar cases that are expected to be run together.
To further aid the process, testing is usually divided up into logical areas. For example; functional, non-functional (e.g. usability), performance and load testing are all common titles given to different types of testing. So categorising the cases and groups of cases further helps to organise the test management process. Categorising the test management process in this way helps with aspects like reporting and allocation. So a particular category, say performance, may be given to one team lead to manage. Each category can then be reported on separately. This allows people interested in the test management process to see the status for each category of testing. From this status information resources can then be allocated as required to the different team leads.
A group of test cases can then be executed in series and the results recorded. In recording the results against a particular version of the product the goal is to find defects with the product. Tests that fail will usually result in a defect or issue record being raised in a defect tracking tool. This is the point in the test management process where test management links together with the defect management process. Providing traceability between the cases and defects is essential in helping with many aspects of the development process, not least of which is the process of using a test case to retest a fixed defect.
In short the process of running the test management function is core to the success of a product or system release. The ability to develop reusable test cases delivers the ability to complete consistent regression runs. The process of grouping these tests then allows for runs to be executed with a group of similar test cases. Recording these results against a run ultimately allowing a development team to judge the quality of a system before release. Linking all these aspects together with a good test management process helps ensure high quality system releases.
William Echlin
http://www.TestManagement.com
William Echlin is managing director of Traq Software Ltd, the company behind www.TestManagement.com providing news, reviews and articles on test management tools.
