How to Defuse a Bomb... Wait, I Mean a Bug - Michele Campbell
Have you ever felt the incredible pressure of trying to get a story tested in a very short deadline? When last the last time your PM said this has to go out tomorrow? How about developers demanding their story gets tested immediately even though there are five others in front of it? The pressure feels like trying to defuse a bomb especially when you’re balancing the emotions of everyone around you, the almighty customer, and the business values. You know the story needs to get out, but you are stressed about that bug hiding waiting to explode right when it gets to the end user. The first step is preventing the bomb from going off in the first place. This is where the most testing effort is placed. However, sometimes an issue escapes into production, and you need to know how to defuse it quickly when it does.
Expect to learn some useful processes such as:
- pair testing
- session-based testing
- bug scrubs
- daily bug triages
- QA standups & planning
- cross team testing
Testing is most often seen as the end of a process. However, it’s critical to begin testing from day one of a project. You want to start when UX and PM's are designing and follow through to when you know the end user is satisfied. Comparing the scrum team to a bomb team is how I hope to enforce the mentality. I want to do an introduction of the following methods to help reach the goal of making testing a priority from start to finish with the whole team:
- Pair Testing: Pair testing is when testers take time before a story is finished to sit side by side with developers on their stories early on in the process. Basically as soon as code is working, a tester is sitting next to a developer going through the story. The big bonus of pair testing is that it gets the developer to start thinking like a tester. Other bonuses include less context switching for developers, finding bugs sooner, and creating meaningful relationships with other people on your team.
- Session Based Testing (SBT): To improve knowledge in specific areas of a very large product, we use SBTs to track our tests and go over them with fellow testers. SBTs have improved the onboarding experience of our newest hires and the capabilities of more senior staffers.
- Bug Scrubs: Bug scrubs are when we go over different aspects of the product as a team with a fine tooth comb. The key point is to always include members from various parts of the organization. A tester will typically lead a test session about a feature and allow the different parties to “bang” on it. By including testers who have not really seen the feature before, UX, and even customer support, you catch issues much faster because of their unique perspectives. A UX team member will quickly catch a color being a few shades off, and a PM will be able to rethink the flow of the product to see if there is a way a feature can be improved.
- Daily Bug Triage: Everyday a QA member, a scrum master, and a product owner will sort through bugs reported to our backlog that day. As we prioritize and assign each issue, it prevents the backlog from becoming an overwhelming, unknown entity. Instead, we know the issues, and each scrum team can work in more manageable chunks.
- Cross team testing: We affectionately call this process “test all the things”. It is a meeting once per sprint for QA team members to go over the new aspects of the product added most recently. When the QA organization gets large and spread out across scrum teams, it can be daunting to stay on top of all the new things being released As a result it is important to meet and actually walk through the big stories with the entire QA team.
- QA stand-ups & planning: Our QA team is spread out across twelve scrum teams. It would be impossible to stay on top of what is going on if we didn’t have our daily standup. It is a 10-15 minute meeting where we discuss what we are working on that day and how it might impact other scrum teams. It also allows us to coordinate when someone needs additional QA help on a larger story. Our planning session is a more formalized meeting, occurring once a sprint, to organize our regression test plan, learn new testing processes, and discuss new features.
Working with each member of your team, including other testers, developers, product managers, design, and customer support/success is the key to preventing issues and working through the ones that inevitably make it to production. Testers can feel trapped and think their only sphere of influence is with other testers and maybe a few developers willing to listen. However, implementing testing ideas across the company benefits not only the overall quality of the product, but the speed with which you release new features and bug fixes. Plus, you get the added bonus of killing the “QA as a bottleneck” mentality.