2 years ago I was the only tester in the team of 9 developers, 1 scrum master and 1 product owner. Our product was 5 years old social platform with massive technical debt. Many persons responsible for writing the core code were no longer working with our company. At some point, we had over 200 reported known issues. Some of them many years old. There was no written documentation of how the system should work. Additionally, we had a tangled network of connections with other systems and products. And we were just about to go live…
Therefore there was a huge pressure to reduce the number of known issues. But the pressure itself was not enough – it required some actions. My choice was to go with blackmail, terror and martial arts… But my scrum master suggested a more subtle way. So we introduced changes step by step.
Plan of action
The project was as it was for a very long time. All developers were aware that we had lots of issues and they all got used to it. They had no idea if how many of them were old issues, how many were new and in what module they occurred. So our first action was to build the awareness within the team about what is happening during 2 weeks sprints. I did it by creating the charts with the number of defects in “New” status. The fun part was that with every 3 weeks those charts took the form of a cat. Fat, bug-filled cat.
With those charts, we had some information to investigate what was happening. Additionally, I had tags in the brackets to identify issues within this same module. Next step was the call to action since I do not know about anything that got better by simply looking at it. So I’ve created Bugzilla. Each day someone would find this little creature at his or her desk. This person was responsible for updating the chart. This way everyone was aware how to find all new issues, not only the ones assigned to them.
Next step of my call to action was fixing the current state. It wouldn’t be agile without long meetings. The first set of meetings was going through issues in pair tester – product owner. We wanted to filter the defects can live with and that we will not fix. During those meetings, we identified the modules with a massive amount of issues. With that information, Product Owner was left with the decision to make if we should rewrite the whole module or simply remove it.
Next set of meetings was in a bigger group with at least few developers. They got so much into it that they run the meetings themselves inviting me only to confirm if the issue still exists and sometimes provide more details. At those meetings, they would look up into the code and write down what is required for a fix with effort estimation. Sometimes they would already assign the person responsible.
Thanks to our charts we were able to see that we have two types of defects: those old that sometimes required a dive into the legacy code and the new ones incoming with regression tests. Fixing those defects required two separate approaches. In the first case, developers needed longer investigation and sometimes re-writing the code. In the second case, we needed a fast investigation and reaction since we knew the issue might be within the new code. All it was time-consuming and required undivided developer attention. We decided to save time for bug fixes and created two slots during planning – maintenance & disinfestation. Maintenance was dedicated to new issues so each week different developer could have this role, while disinfestation was a long process so it was usually one person for all 3 weeks.
Slowly it was getting better. So much better, that we were able to resign from disinfestation role and leave only the maintenance role. Moreover, the person on maintenance duty was able to work on normal User Stories only waiting for testers cries for help.
Piece of advice
This was the story of my past project. Something I consider that worked in this case, but only for the short time. Could I have done something better? Yes, for sure! When new tester joined in my place to this project the issues count went back to 3 digit number, so there was still a lot of space for improvement. But there are some things I want You to get from this story:
Keep it positive!
No matter how bad is the situation. Bad release, raising issue count … As testers, we should not take it personally. I am this kind of person, that trapped in the deep mud will start bubbling happily. It is better for my mental health. Of course, when the situation gets serious the shots get fired, but I’d rather not stay discouraged, sad or demotivated for a longer period of time.
Don’t get discouraged by being new or inexperienced. It is our courage that allows us to take action, take responsibility and be proactive. When facing a problem, even a little one, I’m thinking about possible solutions and then I take the action. I know it is nice to whine about things during the coffee break, but active solving problems is much better (and then we have something to brag about during coffee instead of whining). Develop a mindset that looks to solve problems instead of dwelling on them.
For every problem there is a solution – often it is more than one solution. We need to be creative, coming up with new ideas and bringing them to life. Many obstacles can be overcome with a little bit of imagination. Moreover, creativity is better with a friend – so if You have a problem ask around!