If you find yourself in a hole, stop digging. That’s the law of holes. Really, look it up.
There are different sort of holes, shovels and diggers. But this time I’m talking about test automation effort kind-of-a-hole.
Adding more test scripts is something inherent into development. We build new features, and we want to cover those features with test scripts, as much as we can.
But if our test suite is not stable, and breaks for different reasons every time, and we’re spending whole mornings debugging and reading logs, and finally giving up, we should stop digging.
I mean, stop adding more test scripts into an unstable suite.
I know, blasphemy. But hear me out.
Chances are, the new tests will suffer from the symptoms of the rest of the suite. They run on the same infrastructure, same environments and built by the same developers. So how would they be different?
And you ask, will we be able to catch up once we stabilize?
I can answer that easily. “Definitely not”. We’re not doing anything to stabilize the suite, and complexity doesn’t just disappear. We may cover more, but get no value from the broken suite.
What would the bored automation engineers do while *not* adding test scripts?
Well, let me tell you a secret. The developers should not be working on new features, either.
Still here? Good.
The team’s goal is producing code that works. Developers write the code, but the team’s not done, until the automation runs smoothly.
Everyone, as in the WHOLE team, should be working on stabilization. This is a team effort, because the instability comes from code, tests and environment.
And this is how you solve both the stability and the coverage gap. Two birds, one stable stone.
Want to learn more about automated tests? Check out my API test automation workshop.
0 Comments