There’s a misconception that bringing together Agile and quality assurance testing is like jamming a stick into the spokes of a bicycle wheel—everything crashes to a halt. Agile is all about continually moving forward and iterating in a flexible way. In the minds of many, solid QA practices imply a need to impede progress with testing.
You might have one of two misconceptions about QA in an Agile workflow:
- A rapid development process means you sacrifice quality in the finished product.
- Testing slows down progress and delays launch.
These outcomes can occur for a number of reasons, including poor requirements and improperly implemented testing.
So is QA testing antithetical to the Agile process? Do you have to sacrifice quality for speed?
We don’t think so.
At Four Kitchens, QA testing is built into our workflow process from the beginning, so it happens continuously and seamlessly. QA testing doesn’t pause the project.
Quality Assurance Starts at the Very Beginning
The first step in Agile is to eliminate problems before they occur and to keep them from happening in the first place. And that means taking a holistic, integrated approach to quality that starts from the discovery process and continues on throughout the project. In other words, QA begins on Day 1 of any client engagement.
A number of things need to be in place to ensure the quality of deliverables. Features need to be clearly defined and understood by both the stakeholders and the team, the “definition of done” (or criteria for a feature to be considered complete) needs to be clearly defined, but most importantly, the features need to be prioritized and aligned with project goals.
Whatever the desired digital result, Four Kitchens has a quiver of proven facilitation and communication tools that we bring to every venture to keep your team and ours tracking on the same course.
QA Is Baked into Our Process
In an Agile environment, testing only works when it’s an integral part of the process, not a separate step that trips up the workflow. That’s why for us, QA isn’t a distinct phase in a project or performed by a separate team. Our methodology calls for our development teams to constantly be alert for quality issues.
We put the right people—your specific project team at Four Kitchens—in charge of quality. Every line of code that a developer writes is reviewed by another developer working on the project rather than a separate group of QA specialists who may not be familiar with the specs and your business goals.
Our code review process goes beyond a quick peek at others’ work. It involves developers looking at each other’s code, so they can catch even the smallest details before they become larger problems, and validating architectural choices that are difficult to change later. Next, they perform functional tests to ensure that the feature works as expected and doesn’t create any unintended side effects.
Having developers complete functional tests might seem inefficient at first, but it has two important benefits. Since they are involved in the project closely, they understand the requirements and context better than a separate QA team, and it provides an almost magical accountability since regressions and errors are found by peer developers rather than a somewhat anonymous QA team “throwing them over the fence.”
The code review process is core to our process, but it’s not the end. Automated linting tools (tools that read code and find common problems) allow us to test for basic code and accessibility best practices. Next, we strategically employ automated testing, using a mix of unit, behavioral, and visual regression tests to balance development speed and test coverage. Finally, we incorporate periodic audits from specialists to guarantee that specific aspects, such as SEO, accessibility considerations, and performance, are delivered without fault. This nuanced approach means we spend maximum time on building quality features, not fixing mistakes.
Of course, we pause at the end of a project to triple-check the work against an extensive launch checklist, which is customized for every project. But through our alignment of QA with development from the start, there’s often little cleanup to be done at that point.
For us, the development and pace of a project are in the hands of the same people.
‘Quality’ Means Meeting Client Needs
QA isn’t just about making sure an online form works properly or that an app scales to different mobile screens. The highest level of quality means meeting client specs; in other words, we won’t build stuff you don’t need. The No. 1 bug we work to prevent is a product that doesn’t meet your needs. Each feature is delivered, and solutions are right-sized so they work on a micro-level.
Don’t Debug; Prevent Bugs
In a traditional approach to QA, features are built and then tested. At Four Kitchens, we avoid this time- and budget-consuming debugging stage of development. Instead, we prevent bugs from getting into the codebase in the first place.
QA isn’t a separate step in the process or a line item on a budget; it’s just how we work. We don’t deliver partial features; we deliver whole, delightful features. Four Kitchens doesn’t build things and then make them right. Our fundamental workflow incorporates frequent checks to make sure best practices are followed, features are accessible, and testing is done well as we go.
You can have speed and quality that work together hand in hand. It’s not a tradeoff.