Pressure is part and parcel of any software development team’s working day. How we handle this defines how well we operate. I have noticed that the bulk of the pressure that gets applied is to the testing specialists within a team. It is a topic that has been bubbling in my thoughts for some time after being burned by pressure.
“Is the testing going well?”, “Have you found any bugs?” or “Have you found all the bugs?” are some common questions that get asked of testers all the time. Let’s analyse those three questions.
- Is the testing going well?
What do we mean by the term “well”? You may wish to see visible progress, so might define well as “finding a lot of issues”, because at the end of the day no software is bug free thus if we are not finding any, we are not testing well enough.
Alternatively, “well” could mean, we are managing to execute test cases at a steady rate to move closer to greater test coverage?
The question itself is so vague that it can be interpreted multiple ways (for example as listed above). Asking this question implies to the tester that if it is not going well this reflects badly on them.
- Have you found any bugs?
The number of bugs found is not an indication of quality, also it depends on what we mean by the question. Do we class raising concerns at a planning stage for previously unconsidered areas as finding bugs?
In an agile world we should be looking to reduce the number of bugs we write in software by involving testers from the beginning and despite what people believe the questions being asked during these early phases is equivalent to finding bugs.
- Have you found all the bugs?
It is impossible to find all the bugs. It is impossible to accurately state how many bugs will be in a piece of software.
We should accept that bugs will sometimes be missed and find our way in front of users. The key thing is what the things to learn from this failure are. We should not attach blame but look to understand why something happened and how we can prevent this from occurring again.
In an earlier blog post, I wrote about what testing is and how it is all about learning. If we are not learning about the product then we are not testing. The same applies here. By missing a bug, we have learnt some new behaviour of the system (whether it be undesirable or not) and we can apply that to any future testing we carry out.
There is the notion in some circles that testers break software and are a quality gate that the software has to pass through in order to be released. Fostering this kind of mentality can lead to the belief that testers do not care about working to deadlines and are a roadblock when releasing new pieces of work.
This leads to people questioning why the product hasn’t “passed testing” yet. I am not a fan of this question being posed to anyone as, subconsciously, people fall into the trap of thinking deadlines have been set when in reality they are arbitrary. People look to a tester for approval to release software (a quality gate if you will) and while I have strong opinions on that being a rule, rushing a person we look to for approval can only end badly.
I have talked about deadlines and a desire for progress as reasons for pressure but another reason is ignorance. Ignorance in the sense that people do not understand what is required when it comes to testing. Now this isn’t unique to testing of course because people could have a fundamental lack of understanding of how a system is architected and in their head they oversimplify their understanding. However, this is less common as teams regularly talk about how they are going to build an application. They unfortunately seldom discuss how they are going to TEST an application.
I have talked about why pressure is applied but how can we stop it? Or at the very least alleviate it so that testers can focus on the task in front of them. I have come up with three key pointers we can follow to help reduce pressure on testers (and in fact all team members) within a team: –
- Education: Educate the team in regards to what testing entails. There is a gross misunderstanding within many development teams about what value testers bring to the table. Once an understanding has been formulated other team members can start to appreciate the work being put in
- Discuss testing earlier: Testers should be brought to the table earlier on in the lifecycle. Test approach, test coverage and prioritisation are all worthy discussion points to give us a better understanding. Drawing upon the experience of the entire team allows for the formulation of solid test ideas. These conversations will also prevent many issues from ever making it into the product.
- Not being afraid to fail: Failure is part and parcel of software development. If it happens we need to respond positively and learn from our failings. A missed bug still teaches us something new about our product and we can take that into any future work.
Ultimately, pressure on any member of a development team has a negative effect. We should strive to protect our team from these pressures in order to continually improve and thrive. An environment where pressure builds does not allow people to flourish meaning overall product quality will suffer. Identifying when it is being unnecessarily applied and learning how to stop the rot will ultimately make for a better team culture.