This post is part of a series of blogs on Atlassian QA. We will cover how the QA strategy has been implemented in different teams, the tools and techniques we use, and the personal experiences from members of the team.
Goliath online
After arriving at the office, you stop by the kitchen to grab your morning cereal and head to your desk. You settle down and begin responding to customer emails regarding bugs under investigation. After standup, you join up with your team lead and PM to triage bugs that have been raised in the last few days. You check your Jira Agile board and see that one of your developers has picked up a new story, so you write some development notes, asking questions about cases they have not considered and influencing their development to prevent bugs before they’ve even been written.
Another developer has just finished her story and demos it for you to prove the functionality and get final feedback before passing it on to testing. You assign a developer on test to test this story themselves. You trust this developer to really run the feature through its paces, and not just do the “happy-path” because you trained them yourself through pairing.
“You want a piece of me, boy?”
Your belly grumbles, so you head to lunch and join in on a quick poker game while munching a delicious sandwich. Because you can read developer’s minds like a book, you win all their money (naturally).
Looking up at the clock, you realize you have a meeting with Support to show them the latest functionality about to be released. When this functionality goes live, they will know the innards, context, and intentions to better communicate with customers who come with questions and possible bugs.
Explorer reporting
When you get back from your meeting, you create a test session in Jira Capture to track an exploratory test session on the latest pull of the big feature branch being developed before the developer merges it to master. You experiment with wild and not-so-wild ideas for 30 minutes. At the end, all the bugs and concerns you raise are reviewed via the test session, then pulled into the sprint.
Somebody call for an exterminator?
Because the last story was just tested and fixed, the release is ready to be cut – but not before you organize a blitz test. You gather up your developers in a standup and run through ideas you all think could break the new features. Assigning them browsers, you challenge them to find the most bugs in an hour of uninterrupted experimentation on the new features. After a healthy blitz, you all gather around a monitor and triage the blockers that must be fixed, those that aren’t valid, and those that are minor and can wait until another day.
With this sprint over and the release cut, it’s time to draw up a quality scorecard for how well you and your team performed, to be presented in your team retrospective. Your team grabs a bunch of beverages, discusses the measurements, and brainstorms ways to improve their efficiency and initial development quality. With the day and sprint finished, you walk home with your chin held high for all the value you’ve provided the company and think about what you can achieve tomorrow.