AGILE QUALITY ASSURANCE
Is your team spending too much writing and updating test cases? And not enough time actually testing? Is there code ready to be tested, but testing can’t start because the test cases aren’t ready? If so, then lightweight test cases might be the answer you are looking for.
Lightweight test cases evolved out of exactly these circumstances. The testing team was falling behind, and needed to find a way to keep up with development. We weren’t willing to give up test case documentation altogether. So, we came up with the concept of lightweight test cases – the minimal amount of information needed for a knowledgeable tester to execute the test. They are a single line description of the test without detailed steps or expected results. This makes them very quick to write. The test team can typically write all of the test cases for a 3 week sprint in just a day or two.
Lightweight test cases are also easy to maintain. If the user interface or even the expected results of the test changes, the test case likely doesn’t need to be updated at all. We rely on the user story for these details, eliminating any duplication of documentation.
We have run into a few challenges with this approach. The biggest one is that the testers must be knowledgeable about the system to run these test cases. You can’t simply assign a new tester to the project and expect him/her to be able to run test cases right away, since there are no steps to follow. Instead, testers need to learn the software first. Only then can they effectively run test cases. Especially on an agile project, there are lots of reasons why you need a full-time, dedicated team of testers, so the “new tester” scenario is not all that common. When it does occur, training up-front is a small price to pay for such an efficient, lightweight process. It also ensures that no one is “blindly” running test cases, without sufficient knowledge of the system to notice bugs as they test.
This approach is proving to be effective. Our test cases continue to give us excellent coverage and defect escapes in the single digits. Test cases are always written by the time a story is ready for testing. And testers spend less than 10% of their time writing and maintaining test cases, freeing up their time to do more testing!