If the STP is the strategy we apply to our testing efforts then Test Cases (STC) define our tactical efforts.
In the past couple of years more and more testing projects require definition of tests at Test Case level.
Using a Test Case Management System or incorporating Test Cases into your ALM grants you: –
- Traceability from Use Cases, Requirements, Specifications through to Test Cases.
- Coverage analysis.
- Metrics: whilst I have stated clearly in an earlier post that failing to understand test metrics can lead to abuse, there is incredible value in being able to monitor and evaluate the time and effort required to test either at feature or version level. Should you make changes to the Test Suite containing your Test Cases then prior test cycles will allow you to give a better estimate when planning the next iteration.
- Analysis / BI: simply creating Test Cases that provide optimal test coverage isn’t enough. There is an ongoing process of refinement based on product maturation, bug discovery and tester experience (as the tester gains deeper understanding of the product / technology being tested they gain a deeper understanding of what and how the Test Cases should be defined and run).
All Test Cases Are Created Equal?
With a hat tip to George Orwell’s Animal Farm let’s say,
All Test Cases are equal, but some Test Cases are more equal than others.
In several cases I’ve encountered this concept on projects I’ve been hired to troubleshoot.
The final bullet above “Analysis/BI” offered me the best solution in these cases. Those Test Cases that are more equal than others are the ones built on shared steps.
If you are prone to what I called Testing Kata in my previous post then after analyzing the Test Cases various patterns should become apparent. If you haven’t built your test suite from scratch this way or as in my case, you inherited a project then you will discover Test Cases that have shared steps. This can lead to several choices: –
If you don’t have a Test Case Manager / ALM that supports creating Shared Steps as distinct entities to add to Test Cases then don’t despair; fall back on using Excel to map them out.
The Warptest POV
The likelihood is that if this isn’t your first testing rodeo then at least you have Shared Steps and related tests mapped out (at least in your head) for UI Elements so you have a good starting point.
Like many things we do Test Cases involve repetition, both during writing and running. With good analysis and understanding you can extract the Shared Steps and save a lot of time.
The UI example I used in my previous post is a classic example of this:
Once you try this you might be surprised at what a difference having Shared Steps in your Test Cases will make to your efficiency.
If you are having some trouble with this then get in touch. Help is just an email away.