I’ve discussed about DRY in software testing earlier also which involved reusing test cases across projects, today I’m going to discuss a similar topic: reusability/repurposing of test cases within project itself.
During your software development life cycle, there are several phases where your team tests the application. Let’s see how a typical development cycle works before checking out the problem (it’s somewhat similar to what we do for Test Collab):
- During development, developer executes set of few tests in order to make sure their changes don’t break the build before committing the code. (Smoke tests)
- A continuous build verifies that all the code is fine by executing some specific tests. (Some functional tests)
- Tester executes a few tests manually at the end of the day to make sure application is running as it should. (All functional tests)
- Then there’s a staging / testing server, where all the automated testing is carried out. (All functional tests)
- Before every release, manual load testing is done so it can be made sure that this version is going to be okay after released. (Load tests)
- After every release, specific tests are executed every 7 days to make sure your application is running online. (Production monitoring tests)
Now, this may or may not resemble to your software development lifecycle, it’s just there to show you how testing or software QA has multiple contexts.
Do you notice something wrong with above image? It’s most common issue among QA teams. Each testing context is treated as a container/category for these test cases, and when some test case, say, Test Case #1 also needs to act as a ‘Load test’, it is copied in ‘Load test’ container as it is. This is absolutely wrong. So what happens is you end up with hundreds/thousands of test cases which are often duplicates of each other. A test case should not be hard coded for a single context if it is required in other contexts too.
For example a test case which verifies “User registration” in my app might be treated as ‘smoke’ test and at the same time a ‘production monitoring’ test. Similarly, I might add more information in this same test case, so it can also act as ‘Load test’.
So what is the correct way?
Treat each testing context as a “Tag”. Tags are not new to the blogging world, but they also make sense in testing and here’s how:
So by applying tags we’ve avoided creating 3 new duplicates. Now one single test can belong to multiple testing scenarios or contexts:
Few days back, we’ve released tagging feature which was long awaited by some of our customers. I hope this article helps you getting best out of it.