Recently I was discussing one such challenge with a fintech organisation. They wanted to implement automated testing but felt paralysed to progress the idea. The benefits of automated testing are well documented especially for teams that are developing iteratively. However, they struggled to get started and develop any momentum. They had put in requests for funding, to buy testing product licences and to hire dedicated automation engineers, which had been knocked back.
That approach is great if you have a spare million kicking around and you can convince your investors of the return on investment. For many organisations this is a big ask.
So, they enter a phase of continuous coping. They don’t have any automation, so they have to do it manually. As they build more product there’s more to test and no more people to do it. They now have to be “pragmatic” and decide what good enough testing is.
This complexity of this problem is quite low and doesn’t require a boil the ocean strategy. In fact, no matter how much effort you put into a problem like this, there will always be more to do and will eventually just become a red queen problem.
An alternative approach would be to start small and grow iteratively, just like how many agile teams develop their software. If we agree that automated testing is good, and we also agree that no automation is a problem, then it follows that one test is better than no tests.
By shrinking the problem to something small there is no need to wait for approval. The team can get behind the idea and complete the task with only a couple of days effort. While the overarching problem has not been solved the team will have made its first and most significant step in solving it.
“Once the crack appears the dam will burst”
The product backlog approach
The product backlog contains all the future ideas for the product. Start by picking the part of the system that you’d like to create the first test for. It could be a part of the system susceptible to failure, based on risk, or another reason. Then create a product backlog item (PBI). Refine the PBI so that it’s small enough to deliver within a sprint. Bring forward the refined PBI to the next sprint planning event.
The definition of done approach
Once you have your first test, adding more tests become easier. The important thing is to now create a habit. This is the continuous part of improvement and expanding the definition of done is the best way to establish a new quality habit. Moving forward, each new feature is built with a corresponding automated test, sprint after sprint.
Solving one challenge iteratively will help the team learn that any challenge they face can be shrunk into a small first step. This will give them courage to challenge themselves further and continue to improve.
Boil the ocean – An overly large and potentially impossible task given the reality of your resources.
Red queen problem -The Red Queen’s race is from Lewis Carroll’s Through the Looking-Glass and involves both the Red Queen, and Alice constantly running but remaining in the same spot.
