Agile has revolutionized the software development life cycle, making it faster and more efficient. Awesome, right? We’re big fans of the Agile QA process. But if used incorrectly, it can actually slow things down. So how do you make sure your development process is optimized for QA?

What is Agile?

Agile is a process that (unlike Waterfall) delivers functionality updates regularly. It’s common for releases to happen every few weeks with an Agile process.

For example, you may have noticed that apps like Spotify and Starbucks often have new updates in the App Store or Play Store. If you look at the release notes, you’ll see new features or bug fixes that are in the update.

The Agile QA process can be challenging, as it means having lots to test in a short amount of time. QA has to test existing functionality, new features, bug fixes, data, and even more depending on the type of website or mobile app.

Manual vs. Automated Agile QA

If manual testing is the only defense against bugs, Agile can be an even bigger undertaking. That’s why it’s a best practice to have both manual and automated testing in an Agile QA process. Even if you only have automation for a handful of test cases, it can still make a big difference. Additionally, if the QA team is not included in planning activities, or if the QA-to-developer ratio isn’t optimal, there can be pretty significant consequences. But if the team incorporates some common sense strategies, these issues can be minimized — and in many cases, eliminated completely.

(If you want to know more about what type of QA is right for your situation, see our guide, What Type of QA Testing Do You Need?)

What are the Principles of the Agile Manifesto?

Satisfy the Customer Through Early & Continuous Delivery of Useful Software

There’s a lot to unpack here — above all, satisfying the customer. A client or user is not going to be satisfied if a release is riddled with bugs, which further reinforces the importance of QA. (If you’re a B2B company like a digital agency, you might even have multiple levels of “customers” to satisfy!)

The second point emphasizes early and continuous delivery. For this to be an ongoing success, the process itself needs to be on point. Ideally, this means QA would weigh in from the planning phase through delivery. By following this process, even if issues come up during development, release risks can be addressed.

Product managers can then make adjustments to scope in order to meet the release date. They can also put out any other fires when they come up — instead of waiting until the last two days of the sprint. (This can also be helped by including QA in Sprint Planning.) Continue reading →