Test cases are the keystone of the QA house. Test cases document functionality of the applications we test, training material for new team members, and the building blocks of our test plans. With them we can demonstrate and clarify what we are testing during our regression and production test runs. Without them the following problems arise:
- We do not have a record of our testing,
- Expanding the team has additional cost because testers will need to train personnel and not test,
- Starting automation efforts becomes difficult to get off the ground.
So, what do test cases do?
In the most basic sense, test cases document what testing is to be done for a feature to show that it works as expected. This implies that there is a structure to the test case and a format for the team to use. There are several types of test cases that can be written and used for every type of situation. The three most common are exploratory, scenario, detailed/stepped. Each of these test case styles have a similar format and elements. Test cases can be managed in various ways, the two main ways are managed and unmanaged.
The managed way of maintaining test cases is through a test case management tool such as TestRail or SpiraTest. These tools allow you to create test cases in a structured and consistent way. Test cases can be added to test plans and test runs to document testing activities and results. They include reports to show testing trends and overall health of the application or release candidate before a release. TestRail includes API access for creating new test runs and sending automation test results back to it. While SpiraTest includes an automation tool that you script test results in. Both tools integrate with popular issue tracking systems like JIRA for pushing failed test case results to.
The second way of maintaining test cases is the unmanaged approach. This includes using tools like Word, Excel, Google Sheets, and wikis (such as Confluence). They are structured by the team and can be very flexible for what the team needs, especially when the team is smaller. As a result of how they are stored, there is not a single place to see testing results or status of testing. This causes additional overhead on the team, but it is better than not having any test cases.
What should test cases include?
Good test cases, like well written bugs, have structure and several basic fields. These include title (metadata), steps/actions, and expected results. The metadata may include where to test in the application, type of testing (e.g. manual, stress, load, automation, etc), time estimates, and prerequisites. The key elements are the steps/actions and the expected results. With these you have strong repeatable test cases that can be used for tracking results and training.
- Steps/Actions: Depending on the style of test case, the number of steps will vary, but the intention is to clear. It’s the steps taken for verifying a result. These should be as detailed as possible to show an expected outcome. Again, the definition of detailed might vary depending on if it’s an end to end test case or an exploratory test case.
- Expected Result: What are you expecting to see after the step is complete? How do you know that the step is complete or the validation point exists? This is especially helpful for training and automation purposes, as the people creating automation are usually not the same people who created the test case.
But we’re an Agile shop, so we don’t need them.
Yes, it’s great that you have taken the idea of “minimum documentation needed” in Agile to the extreme case of “in Agile we don’t need documentation”. I have heard this argument before, I’m sure others have too. There is always a minimum set of requirements in Agile, otherwise, why would there be a Product (or Business) Owner? What would the development team produce, or what will you test? In the best case, everyone would be on the same page with their understanding of the feature, but later on when a bug comes in, how do you know it is a bug?
Being Agile does not give you a “get out of jail free card” for documentation and test cases are documentation. Ideally you have started creating test cases for tickets based on grooming sessions so that you are better able to estimate the complexity of the tickets. At the start of each sprint you should be updating your test cases for tickets in the sprint based on the discussion during the planning session. Your test cases will be part of the release artifact once the sprint is over.
Conclusion
Test cases are the keystone that good testing practices. With them you have your testing artifact for peace of mind and low cost training materials for new hires. Test cases can also be used for cross training team members on different projects, allowing testers to take vacation and relax. If you’re not writing test cases, you are making your task more difficult.
One Reply to “The Key to Lasting Testing Success are in the Test Cases”