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