Testers In a Pressure Cooker
Introduction
With each passing year, consumer expectations rise and more products enter the market, so companies need to react quickly and efficiently to stay relevant and gain maximum visibility. This could lead to the delivery team being under increasing pressure to deliver higher quality products in reduced timescales or add more features faster. The wider delivery team are often under pressure to speed up the process to release a product. Although some pressure is healthy and can achieve positive results, too much pressure can cause a “rush to failure”.
Today’s reality of fast paced agile practices and quick release cycles seemingly decreases the sense of pressure as delivery is managed in small increments over time. Fundamentally, software development comes with pressure, how it is handled depends on individual team members and in turn this demonstrates how well a team operates collectively.
Agile promotes communication and collaboration. If people are communicating and collaborating effectively, then naturally there will be a less pressured environment. Mainly because everyone is working towards the same goal and everyone is taking responsibility for the product. In addition to this, Agile encourages change requests throughout the whole cycle. However these are managed as a team just like planning together for a sprint to ensure it doesn’t result in situations where individuals might feel pressurised to deliver more than they have the capacity for.
At Scott Logic we believe in do it early, do it together and own the outcomes as a team. This is a topic that has been on my mind for a long period of time and I thought it would be very interesting to share my views on it.
The Problems
“Is the testing going well?”, “Have you found any bugs?”, “Why didn’t you test for this?”, “Why didn’t you explain the risks?”, “Why didn’t you ensure the quality of the product before signing it off?”, “Can you add another test?”
Why do we undergo so much pressure, especially during deadlines?
Fluctuations in a project can lead to pressure as assumptions can be made, and sometimes there is no visibility of new change requirements. Agile processes allow us to work collaboratively and start testing as early as possible. Leaving testing until the end means everyone else’s delays get accumulated making the testers a bottleneck before the product goes live.
Another misconception is quality assurance. What is it? Who owns it? I have heard and observed these statements many times, “you are responsible for the quality, without a pass from you we cannot release”. I disagree, testers are not the quality gatekeepers. The overall product quality is the responsibility of the entire agile team.
In addition to this tension may be built up due to mistakes made in the past. There are situations where all of the planned stories cannot be delivered or stories are delivered but something might have been missed out. Furthermore the costs or delays that come with it can haunt and pressurise team members, nonetheless these costs and delays can be better than releasing an untested product.
The waterfall approach can also lead to some pressuring situations. The project is planned in detail before development starts, leaving no room for errors. Therefore a mistake committed during planning process, a requirement missed out or new requirements from the client mid project can lead to delays, disruptions and stress. Not to forget testing is done once the code has been deployed, so finding and fixing flaws can then be difficult and time consuming. In today’s changing marketplace, new ideas, technologies and competitors appear frequently, and users have valuable input. The inability to adjust to these on-the-fly can be the Achilles Heel of waterfall.
I asked this as an open question to the testing community to understand what comments they have heard during their experiences which can be pressurising and these were some of their responses :
Can This Be Improved?
Nelson Mandela said “It always seems impossible until it’s done.” This highlights that if we all work collectively and take the same responsibility to deliver the best we can, we can achieve a less stressful working environment. Although these are not the only contributing factors to stress and pressure in a working environment, addressing these could aid in improving levels of pressure. In my experience as a tester and according to studies about communication within software development teams, collaboratively working helps a team improve the delivery process. In turn there is more transparency due in part to collaborative tools, constant communication and everyone feeling involved, enabling the team to work towards the same goals by everyone having the information they need. A great example is the art of Pair Testing, where developers can pair test with testers or testers pair with each other as a fresh pair of eyes, potentially picking up errors that might have been made.
Another interesting action to take would be to be honest in the analysis of a situation; if you feel that you cannot commit to delivering and testing the product within a sprint make it visible and communicate that view early.
The following questions can be used by a tester to help avoid pressurised situations :
What is the problem? What is the cause of the problem? What are the possible solutions? What is the best solution?
If a tester can think of possible answers or solutions to the above questions and share it with the team, you never know, these questions might help them untangle some of the burden and difficulties being built within the team!
A Whole New World
I asked some of our Scott Logic testers how they would implement ways of staying pressure-free and be more positive in pressured situations. These are some of the useful insights they provided:
Handle With Care
Any member of a development team being under duress has a negative effect. There is no one reason for, or cause of pressure, rather it’s a combination of poor planning, or execution of delivery practises. All of this can be addressed and modified to make each tester feel less pressured and enjoy their work .
With regards to what development methodology process your team uses for delivering the product, the main focus would be on what is the best fit for you and your project. Whichever process is utilised, the team members should not feel pressurised to deliver but feel a part of the team and work together.
We should strive to protect our team from these pressures in order to continually improve and thrive. An environment where pressure builds stifles creativity and passion meaning overall product quality could suffer, through poor practices or lack of thoroughness. Let’s not blame each other, instead collaborate, cooperate and communicate for less oppressive situations.
