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:
- Hundreds of JIRA tickets
- Strained team members
- Concerned clients
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.
Send It Back
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.
A New Future
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:
- Designers would have scheduled time to sit with the lead developer on the project to review annotations and requirements. Together, their job would be to ensure all functionality is understood and accounted for before beginning the build process.
- Our QA resources would function almost like assistants to developers, working alongside them to make sure their work is up to spec.
- Project managers would ensure that QA begins, no different than ensuring developers have what they need to start their sprints.
- We'd introduce a new phase of QA called Creative Review, where designers, client services, and other relevant parties review the work for the first time.
- During Creative Review, we'd expect there are fewer than ~15 issues. For Creative Review to begin, the Software Engineering team would agree on a standard for the work. Perhaps a checklist or other way of confirming standards.
A few of the open questions we need to dig into more are:
- When do clients get involved?
- How much time does this add to the development process?
- How do we uphold the standards for Creative Review?
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.
This post originally appeared in Edition No. 107 of my newsletter. Subscribe here.
Monday, September 26, 2022
