A few topics have been a constant source of discussion over the past several years at Barrel — QA is one of them. The past few months have been no exception.
Last week, I met with our Team Leads to discuss QA, specifically to begin answering: Which team should own and maintain our QA standards?
Currently, our teams share QA with project managers facilitating most of the process. Designers and developers work with project managers and part-time contractors to review the work and highlight any issues with the design or functionality.
When I joined Barrel in 2013, we had an entire team dedicated to QA. We've since transitioned away from this model for numerous reasons. When challenges with QA come up today, a natural thought is that building a team around it will solve all of our problems. While we've learned (the hard way) that hiring people to fix issues rarely works, I am not sure that creating a QA team is the right vision to march toward, at least with who we are as an agency today.
QA is an opportunity to do a final check to ensure our work is up to spec with what we've scoped and designed. Before beginning QA, our aim should be to do everything in our power to get the work right. In other words, it doesn't make sense for anyone to spend time checking if the work is up to spec if we know it is not.
I believe this has been the source of many recent challenges. For one reason or another, typically the timeline, there are projects where QA begins QA on a website that we rushed to build. Maybe the website is working correctly but doesn't look great, or — it looks great but is missing functionality. Either way, these situations often result in:
Even when we get the site launched on time and spec, it can be difficult for the project team to celebrate, given what it took to get there. There can also be a backlog of tickets marked "post-launch" that still need to get resolved.
A few years back, we adopted a "send it back" policy where team members would hold on QAing the work if it didn't appear ready. While this has helped prevent wasted time, it can have unintended consequences like project delays due to shifting milestones.
The projects with the most enjoyable and efficient QA process have been ones where QA started with a website in a near-launchable state. In that way, ownership of QA standards will not entirely prevent the above issues if we haven't done everything in our power to get the work done right beforehand.
In my session with the Team Leads, I communicated my perspective on where I see our challenges today. Our Director of Client Services, Kate, then shared her experience working with teams where QA sat with the tech team. As we discussed this as a group, a new vision started taking shape.
We left the discussion with a taste of what a future where QA lives with our Software Engineering team could look like at Barrel. At a high level:
A few of the open questions we need to dig into more are:
I'm eager to explore this more with the Team Leads. What I'm most excited about is this approach offers a new way to look at an age-old challenge. It also evolves our process to lean on doing our best work first, not checking to see if we did later.
I'd been lying if I said that talking about QA has been exhausting in the past. It feels good to feel energized to dig in more this time around.