“We’re agile, but not sure how QA fits into that.” I heard this at a conference recently while discussing my role at Detroit Labs. I was surprised because QA fits well into DL’s team structure. This got me thinking about the causes for teams to struggle with QA. After listening to many QA professionals at other companies talk about their work, I developed this list of challenges that face many of us testers. Some of these may hit pretty close to home!
- QA feels unappreciated
- Developers feel superior to QA
- Bugs are given a lower priority than new features, diminishing the value of a QA’s work (and the quality of the app)
- QA isn’t looped in with changes as they’re being discussed or the direction of the app
- Too much down time waiting for features to be coded
- Not enough time to test features that need to be shipped right away
- Testing doesn’t fit within sprints; the testing done during this sprint is for the features developed last sprint
- Development sprints end on a Friday and testers feel obligated to test all weekend to have bug reports ready by the following Monday
- QA tests features that are changing, so bug reports are inaccurate once reviewed several days or weeks later
We can break these reasons into two broad categories.
- Team organization struggles, which are easier to change.
- Team and company philosophy struggles, which are notoriously difficult to change.
Every company has a different idea of what agile means. With each variety of agile, QA fits in slightly differently, but I hope that you can take away a few ideas from how DL implements QA to improve your agile teams. I’ll cover team organization in today’s blog and team/company philosophy next week.
Team Organization
Include QA in everything
Your QA teammate should be invited to every team meeting where app decisions are made, including: standups, retros, sprint planning, demos, team outings, and client meetings. This is Agile 101 and most teams already do this, but if you aren’t it’s time to send out those calendar invites. Additionally, your QA should sit with the rest of the team. It makes a HUGE difference to be able to walk 10 feet to discuss a potential bug with the developer instead of using Slack or email or sending positive thoughts into the universe. If your developers, designers, delivery lead (project manager), and QA aren’t sitting near one another, they’re probably experiencing a very real disconnect.
Account for QA time in sprint planning
When story cards are estimated, QA testing time and bug fixes should be included in the estimation. I know what you’re thinking, “WHAAHT!?!? You can’t predict how long it will take to test a card or how many bugs each card will create or how long it will take to fix them!!!! The estimations are for development time, not QA!!!” Estimations can be tough and accounting for QA time can make it a little tougher. However, by considering bug fixes, you are planning to have the story card 100% done by the end of the sprint. This prevents a disconnect of developing a feature in one sprint, testing it in the next sprint, and fixing bugs in yet another sprint. Bugs should be fixed during the same sprint that a feature is first developed. Otherwise, this asynchronous development and testing pattern can cause the QA to feel disconnected as well as the developer to became less familiar with their code as time passes, inevitably requiring more time to fix any bugs.
Immediate delivery to QA
Features shouldn’t be saved up until the end of the sprint and then released to QA all at once. Once a feature is built it should be tested immediately. If a story card can’t be coded AND tested within the same sprint it should be broken into smaller pieces.
QA continuity throughout a project
It’s not uncommon for a QA to split their time between multiple projects. However, the same QA should still work on a project from start to finish. This allows developers to work with the same QA every day, building a stronger bond and putting a face with their bugs. From a testing perspective, this allows the QA to become deeply familiar with the app. QA will understand the client’s brand and suggest feature requests based on user experience, catch harder to find bugs, and, overall, deliver a higher quality app. QAs shouldn’t be cycled on and off projects as they become available. This makes it difficult to develop a deep understanding of the project and increases the likelihood of reporting false bugs or missing bugs altogether.
QA retros
QAs across projects should hold their own retros to discuss what they’ve learned from their current projects. This allows them to share their experiences of finding unexpected bugs and discuss challenges they’re facing so they can get the tools and resources they need to ensure their team is creating a quality app.
Do you have an amazing way of organizing your agile team to make sure everyone is on the same page? Tell me about it, stud.