Imagine this scenario: A team is a couple of days away from a release when the last few features finally make it to the server. The testing team digs in and starts finding bugs. Circles of bug discovery, fixes, rebuilds, and retesting is happening hours before the release. Things aren’t looking good.
When things slow down in a release, the initial blame almost always points toward the testers. Unfortunately, this is how it works in many (unhealthy) organizations. Kaizen, the Japanese concept for constant improvement, can help avoid these last minute problems.
How to Be a More Productive Software Tester
One possible reason for that testing bottleneck is test management systems and how testers and managers use them. Typical usage of these systems look something like this:
Testers spend the first third of a release documenting test ideas
- Each test idea is broken down to a specific set of step, with some assertions along the way
See below example:
Test Idea Example
The above style of documentation doesn’t do a great job of illustrating how testing is performed, and it isn’t very good at helping people find bugs. So how can teams get better documentation that drives productivity? We will talk about two methods — removing unneeded information, and generalizing.For every small variation in data, or change in steps that should be performed, a new test idea is documented. Eventually, the software changes and these steps are no longer relevant, resulting in a lot of wasted work. Maybe the search bar moves to a different page in the software, maybe a new filtering tool is added to the search bar that complicates the test, or maybe that test data is no longer relevant. That test, in theory, should have usable by anyone in the building. But, now it is like a loan collecting interest in the form of time.
Test Documentation Can Slow Down Productivity in Two Ways
Time spent making new documentation that could have been spent testing
- Time spent referencing documentation could have been smaller
Speeding up testers is a matter of hacking out the parts of documentation that are not currently adding value.
At least half of the information in the ‘test idea example’ above is either useless or could be presented in a different format, to shrink the maintenance problem. If someone is testing a web page, they don’t need to be told to open a browser and navigate to that page. If a person needs to know that, then either they shouldn’t be testing software or the teams communication is really bad.
The other obvious part is generalizing. People can and do create test cases for every permutation of data that exists. This is often useful when documenting setup procedures. But for the most part, this high level of detail slows down the team in the future because of the time it takes to create, maintain, and use. Most of that could be easily replaced with a format like this:
Less detailed test idea Example
- Browsers: Chrome, IE9, 10, FireFox
- Date values: past, future, subset in good range
- Date formats: mm/dd/yy, , mm/dd/yyyy, dd/mm/yy, bad formats of your choosing
A tester using this format can take what formerly might have gone into 10 or more individual ‘test cases’ and mold that into one, creating a more information-dense story about how something might be tested. This introduces some much-needed variability into how the software will be tested, and at the same time makes most aspects of the documentation burden faster and more useful.
The question of ‘how will someone know what tests were covered’ is bound to come up next. Here’s the answer. While testing a new date field change, a person might say “tested with date values 3/2/81, 03/02/81, and 3/2/1981 using Internet Explorer 10 and Chrome”. Note taking like this moves past explicit test steps and helps to share the story of how the software was really tested. It also lets future testers know what sort of coverage the feature had in the past, and where it might need to be extended.
There are plenty of factors that affect a testers productivity. Sometimes those are in the test group, sometimes the problems are in documentation and sometimes testing is just the last thing that happens in the release. Being proactive about what is documented and how the team uses management systems can avoid that productivity hit.