All of us are problem solvers. We love to solve complex problems.
Developing software is a complex problem. Understanding abstract requirements is a difficult problem. Getting shared understanding about these complex requirements is a difficult problem. Converting these requirements in a language which machine understands is a complicated problem. Testing software and ensuring that software meets explicit and implicit requirements of user and stakeholder are a difficult problem.
However, we are in the business of developing and delivering software because we love to solve problems. Whenever any challenge is thrown at us, our first reaction is to jump at it and find a solution. We look at the problem, get excited and start finding a solution.
How am I going to solve it? This question becomes a driving force for us!
When we develop software in an agile environment and discuss stories, testers (and the whole team) are often encouraged to ask ‘how.’ How would we know we are done with this story? How would we test this story? How can we write automated tests for this story? How can we ensure that this feature will continue to work? How can we include tests related to this story in continuous integration?
All of these questions are important. Very important. However, as far as testing is concerned, focussing on how can be dangerous. It is dangerous for everyone, but especially, when testers jump at the problems and focus on how – The whole team loses the opportunity to look at the problem critically. The team, may inadvertently, start solving the wrong problem.
Solving wrong problem in the best possible way, efficiently and effectively, is still a waste and should be avoided.
So the question is – how do we know that we are dealing with the right problem? How do we know the team is on the right track? In agile teams, the involvement of product owners and regular demos aims to solve this, however, are they always right? What testers (or anyone else on the team) can do to increase our chances of being on the right track?
In my opinion, focussing on WHY may help us get that assurance.
In many cases, I have realised that asking why resulted in the elimination of unnecessary work. Any amount of time and energy spent in designing, developing and testing something which is wrong or not even needed is a dangerous waste. Focussing on why ensures that we are not solving the wrong problem and has potential to reduce this waste.
Unless we have clarity on why we are testing (or automating), there is no point in discussing what needs to be tested and how. Clarifying why becomes more important if there are multiple stakeholders as they may have conflicting interests and priorities.
Let me share my experience to demonstrate how easy it is to indulge in wasteful activities. Also, hopefully, this example can also highlight the usefulness of asking why.
Last year I was working with TFL. I was the first hire in their test team, and I started automation and it became very useful for TFL. They were genuinely excited about test automation and continuous integration. One day my manager came to me and asked me to estimate a piece of work. I was told that there is an important project which is scheduled to go live soon. They would love to have some automation in place. I was told it is a simple CMS based publishing platform.
It was good to know that people were excited about automation. I could have built more automation. The problem was not new to me; I knew how to automate web applications with the CMS. I understood the problem, and so I could have started with questions related to WHAT.
‘WHAT’ gives information about scope.
What has been tested? What needs to be tested? What needs to be supported? What browsers do I need to worry about? Any many such questions to understand the scope before giving any estimate.
After getting the answers of all the What’s, I could have moved to HOW.
HOW defines my strategy.
Given the scope, team, and resources, how best I can do it? How many people are working with me? How am I going to test it? How much can I automate? How am I going to report it – all these questions become part of my strategy and define how am I going to execute.
These questions are crucial, but they miss one crucial part. WHY.
Why is the soul of these questions, it gives us purpose. So I started with why.
Let me share the conversation I had with my manager.
Me: Why do we need to automate?
Manager: Well they saw value automation is adding in the current project you are working on and so they want to do it too.
Me: Why do they think automation would add value in their project?
Manager: They will frequently change content on the site using this platform and broken/bad content on the page is not good for the brand.
Me: Why do they think changing content on the site would break page? Is this the first time this CMS is going in the production? Is CMS going to change frequently as well or only content would be updated?
Manager: No, they have been using this CMS for a while. It is supplied/managed by a third party. Only content will be changed. I don’t think there will be frequent releases for CMS.
Me: Why do we need to write automated tests for a system supplied by the third party?
Manager: Fair point. Guess they think automation is cool and I want to do it too. They probably need a bit of assurance.
Me: Okay, so they are using an off-the-shelf software which is developed/released/sold to TFL. They use this software to update content. The software is not going to be frequently updated and all they want to test is updating content is not breaking the pages to feel confident.
Based on the information you have given, I do not think it’s a right candidate for automation. Should we just not spend a day on this project and plan some exploratory testing sessions? Also, if we automate and if there is no in-house development team for this project, who will maintain it, who will run it – is it worth?
My manager saw the point, and we ended up not doing anything with this project. Not even exploratory testing as they realised all they need is user acceptance testing and editors, who would be real users of the system, are probably the best group for this exercise.
Do you see the power of asking why?
One of the most important contribution testers can make in the team is press pause button and stop teams from progressing on the wrong path. If I didn’t pause and ask these why questions to seek clarification, we would have spent weeks in automating an off the shelf CMS. Not only that, we would have invented a continuous stream of work in maintaining that automation going forward.
In almost every team I have worked with, I have found it useful to pause and ask following questions to have clarity
- Why they want me to test or automate?
- Who will be benefited by this testing? Who are my stakeholders? [You may have to go back to why if you find a new stakeholder]
- What they want me to cover?
- How am I going to do it?
These questions help us in identifying stakeholders, understanding mission & scope and formulating strategy.
Did you find this useful? What techniques do you use to get clarity? Please share, would love to discuss and learn more.
Also, if you liked this article, please share this in your network.