Test Archeology

Remember the first chapter of Winnie-The-Pooh, where Christopher Robin drags Pooh down the stairs, bump, bump, bump, and Pooh feels there must be another way to get downstairs, if only he could stop bumping his head for a moment and think of it?

This is exactly the situation that many testing organizations are facing. For example, you may have chosen to write BDD scenarios using the Gherkin syntax. Initially, everything worked fine, but under constant time pressure, the existing test cases need to be revised, the sooner the better. Unfortunately, these tests rarely get “better.”

Instead, they tend to become more and more (if limited to the scope of single user stories) or they become longer and longer (if also used for system and E2E testing). Basically, it is similar to development activities. If we do not pay attention, technical debts build up over the years, limiting the scope for action more and more.

In the end, there is no time for improvements because we are struggling to survive in the project. If only we could stop bumping our heads and think of it!

Let’s spend half an hour on this. How do we recognize technical dept in testing? There are warning signs other than time spent troubleshooting testing issues. Next, how can we refactor existing test cases that have already been running for some time? Because there is little point in waiting for a fresh start when we feel the pressure of suffering here and now. There are currently two trends that might help. On the one hand, new solutions based on artificial intelligence arise that help analyzing the quality of existing tests (e.g. in terms of coverage or by identifying redundancies). On the other hand, we have model-based testing (MBT), a method that has often proven useful for reverse engineering of requirements and can also help in refactoring test cases.