Testing software is a real challenge, because there are so many types of test cases that come in so many different shapes and sizes. The truth is, there is no “one size fits all” method for software QA testing. You have to take the time to stop and assess every project that hits your desk. In some instances, you’ll want to create a comprehensive set of test cases as part of a detailed plan that will document your every step. Other projects will lend themselves to a more casual, exploratory approach, where agile test cases are helpful. The vast majority will fall somewhere in the middle.
Making the Case for a Test Case
When you are making the decision about whether to create a set of software test scripts, there are some influencing factors that you can’t ignore. The argument for documenting software test cases grows stronger when you have to conform to specific business rules. The project may have legal compliance requirements, or there may even be contractual obligations to provide documentary evidence of exactly what you tested. In that scenario, you obviously need detailed test cases.
Most applications present pros and cons when it comes to test cases. If it’s an enterprise application that you expect to be in use for years, then a set of well-thought-out agile test cases will provide value for money because they’ll be reused again and again. They may even form the basis for automated tests down the line. If it’s a topical mobile app that needs to hit the market fast and won’t likely be updated, then it may not be worth spending the time to draft test cases at all.
You also have to consider how catastrophic a bug might be. Most software that caters to medical professionals simply cannot afford to go wrong. The consequences are too great. Software test scripts with detailed acceptance criteria must be written to prevent any possible human omission when verifying base system requirements. Other applications might not be that mission critical and so can afford to ship with some minor bugs.
Testing in an Agile Environment
What if your development team is adopting an agile approach where features are designed on the fly and changes are continuously introduced? If there’s no clear picture of the application that you’re going to end up with at the start of development and if requirements are likely changed, then writing a lot of agile test cases is going to be pointless because you’ll have to rewrite them completely within a few builds. You might opt for a checklist approach instead and combine exploratory testing with a simple list of compatibility requirements that don’t need to be spelled out in full. It may even be possible for testers simply to refer to the original user stories that informed the design or talk directly to the customer to find a basis for their testing.
Know Your Audience
Audience is another vital consideration, and it breaks down in two ways—the test team and the end-user. How skilled are your testers? What background knowledge do they possess, and how complex is the software they will be testing? An experienced test team with relevant background knowledge won’t need as much guidance. A rookie squad, on the other hand, will benefit from a set of test cases.
Software in a specific niche or for a specific profession will probably lend itself well to a tight test plan. You can predict how the end-user will interact with the product and test accordingly. Software that’s aimed at the mass market should be subjected to more exploratory testing. Intuitive and experienced testers have a feel for how the end-user will try to interact with a piece of software, and they can uncover important bugs if they are given the freedom to find them.