This guest blog post is part of an Atlassian blog series raising awareness about testing innovation within the QA community. You can find the other posts in this series under the QA Innovation tag.
The only surefire way to guarantee bug-free software is to prevent their creation in the first place. Preventing bugs starts with communication and collaboration between product management, development, and QA. Atlassian Bonfire provides the tools and lightweight structure to foster discussion and connect stories from planning, through work, and into testing – so everyone understands expectations and acceptance criteria before testing even begins!
Bonfire’s flexibility is a key advantage for agile teams. It doesn’t come with a prescribed workflow, or impose methodologies or practice upon testers or dev teams; rather, Bonfire works with all varieties of agile development. I interviewed Andrew Prentice, QA lead at Atlassian, to learn more about how different teams – scrum, kanban, and anything in between – are using Bonfire to prevent bugs from ever seeing the light of day.
How are Scrum teams using Bonfire today?
“Bonfire fits into the existing scrum workflow without adding heavyweight process. At the start of an iteration, a QA team member or two will sit in on the planning meeting and add test sessions to stories during discussion. This means when a developer starts work on the story, the test session associated with it shows that dev what’s planned to be tested – so the dev can factor this into their work.
“Expectations are set up front, which prevents many, many bugs from popping up when the story is passed to QA for testing. Then when the story passes from development to testing, people start those sessions and work through them. When stories are marked as Done the scrum master or product owner can look at Test Sessions tab and see when all the testing is completed and follow that process through, to see what has or hasn’t been tested.
“Even better is that the test session creation sparks conversation during the planning stage. Those discussions highlight incorrect assumptions and gaps in thinking, which prevents many, many bugs from being created in the first place. There are other tools that help teams capture test session objectives and acceptance criteria, but Bonfire ties these directly to the story and the status of both the story and any sessions associated with the story – so everyone from product management, development, QA, and even management gets the big picture view.”
So what’s the advantage to Kanban teams who aren’t doing these planning meetings?
“Well, the difference in the Bonfire workflow from scrum is that there isn’t this up front discussion – instead, many of the ad hoc conversations between testers, product managers and developers happen verbally or by email or IM, and that can get lost pretty easily. With Bonfire, as these stories come into the testing bucket, you’re getting traceability that you wouldn’t otherwise have – and the ability to go back and look at previous stories and refine the testing that’s carried out.
“Kanban teams focus on moving work across the board quickly and at a consistent rate. You can add test sessions incrementally or iteratively, so rather than having to put up this blocker up front, you can add sessions with new testing ideas as the story progresses through dev work. Bonfire facilitates that just-in-time actioning of work.”
Fostering Communication
Ever play the game ‘telephone’ as a kid? You whisper a sentence in a friends ear, and that friend turns to the next person and whispers it in their ear – and on it goes around the circle. By the time even half a dozen people have passed it along, the message is usually mangled in some way or another and key points have changed.
Software development can be like a game of telephone sometimes – parts of the customers wants and needs can get lost along the way.
- customers talk to sales people
- sales people talk to marketing
- marketing talks to product management
- product management talks to development
- development talks to QA
The key to better software is preventing bugs and building what users want and need. Bonfire ties many of these people together, because people (not resources – people!) write code – and communication and collaboration between people ultimately leads to better software.
Ready to make better software?
