There are a number of core test management activities that you will be performing as part of any QA process. What we cover here is good software testing practice and should form the bedrock of any QA teams setup. The activities we’ll look at are :
1. Developing testcases in a library.
2. Defining releases and configurations that we’ll use during the execution.
3. Grouping into sets ready for execution.
4. Execution.
In this discussion we’re going to look specifically at carrying out those activities with QAComplete. With QAComplete we’ll see how we can streamline this approach. We’ll see how this can improve on the process that we’d normally see with an excel based approach.
The first part of this process is developing the tests. We’re focusing on the test management activity of writing good testcases. At this point we’re not thinking at all about the execution phase. It’s important to keep these two test management activities completely separate. If we don’t the temptation is to write what we see whilst we are using the application. So the case content is driven by what the application does. This of course defeats the whole point of testing. We’re defining what we expect to see before we check that the application conforms to our expectations.
The second part is to define the releases and configurations that we expect to run our testcases against. There is no point running any checks if you are not recording or tracking what you are running against. The first aspects we need to track is the version, build or iteration of the product. The second aspect is the configuration of the system or software (e.g. the operating system we’re running the product on). So the test management activity we need to concern ourselves with here is identifying the release and configuration combinations we need to work with.
Once we’ve written our testcases and defined releases/configurations we should look at grouping our tests in to sets. This helps on several levels. Firstly a group of similar testcases is easier to manage and simpler to maintain. At execution time a group of similar tests can be quicker to run. Whilst there are no hard and fast rules on how to go about grouping the following grouping approaches could be considered:
i. type of test (e.g. integration, system, etc)
ii. feature or module
iii. process
iv. scenario
v. complexity
Clearly there are many ways to group here. However, the most important point to consider is how you would like to see your reports structured once you are finished. If you need to report on progress based on product features then grouping by feature may be a good approach.
With sets created we can then move on to the execution. At run time the test management activities we’ll be focusing on will be selecting the set to run and specifying which configuration/release we’ll run the set against. Once we’ve identified these attributes we can step though each testcase and record the results.
In principal these 4 core test management activities are quite simple to grasp. As always though the devil is in the detail. Developing and writing the testcases can be considered an art form and requires a good degree of skill. Identifying releases and configurations, whilst easy enough, is complicated massively by the combinations and permutations. Again skill and experience come in to play here. Grouping into sets is probably the easiest of the tasks here. Just keep in mind your reporting requirements. And then finally we come on to the execution. If we’ve completed the other tasks well this should be pretty straightforward. With all of this keep in mind that these core test management activities will remain constant and will provide a good framework to help you manage the underlying complexities.
