How to Get QA Involved Early in the Software Development Process

Read in Spanish

This is a question I often hear from companies: “We have a QA department, but we struggle getting them involved early enough in the project.” My answer is always the same: To fix this, you need to put testing at the heart of software development and include the entire agile project team.

Introducing quality practices early into the development process—not just during formal testing—has numerous benefits: Higher-quality deliveries, closer alignment with customer needs, and earlier defect detection and resolutions, to name a few. But how do you achieve this?

Here are three simple ways to get QA involved earlier in your software development process:

1. Invite QA team members to all meetings

Assuming they have good time management skills, let your testers decide which team meetings to attend. In between writing and executing test cases, they should be invited to architecture meetings, backlog refinement meetings and acceptance criteria review meetings. Even if they just sit and listen, they could learn information that makes their job easier.

For example, knowing what is coming in future Sprints—or what is changing due to customer feedback—can help testers better manage their test case management duties. Plus, if they attend an acceptance criteria review meeting, they can even provide feedback to business analysts to ensure the acceptance criteria is clear, understood and fully covers the product backlog item (PBI).

Testers think differently than business analysts—on many occasions, I’ve seen additional acceptance criteria get added after testers joined the review meetings.

2. Test early and test often

It is no longer taboo to test in the development environment—in fact, it’s encouraged because it gives developers valuable information regarding their code.

Sure, developers can run unit tests on their code in development and it will work. But testers can run other tests—like workflow tests, UI tests and even backend tests on the API or endpoint—and often, these tests will fail. If these tests fail, the developer will know before the faulty code gets moved to the test environment, thus allowing them to fix the issue(s) before builds are deployed to upstream environments.

Another benefit of testing in development is its ability to give the tester a visual of what the expected outcome of the backlog item is. Since the tester knows how the test case behaves, it gives them the opportunity to finetune it even more to meet customer needs.

Finally, there’s an automation factor to consider: Your testers can work with your DevOps team to get a small set of automated smoke tests—usually tests for API and endpoints—in the build pipeline, so they run automatically every time a build is executed. Having these automated smoke tests on the pipeline will uncover bugs earlier in the process and nip them in the bud before they become problems down the line.

3. Perform internal demos for the Product Owner

Why wait until the end of the Sprint to show the Product Owner all the progress the team made? Schedule short demos during the Sprint once backlog items are development complete and tested. These short demos allow the Product Owner to give early feedback to the developer and tester at the time of completion, which eliminates any context-switching—plus, it ensures that what was agreed upon in acceptance criteria is what gets delivered.

Another benefit of short Sprint demos is that it allows the Product Owner to create enhancements in the form of new PBIs for the backlog. Often, the Product Owner thinks they know what they want until they actually see it on the screen. Once they see it for the first time, they often want to make changes—so, these short demos offer them a way to provide more explicit feedback.

Let’s recap on the benefits of getting QA involved earlier in your project: First, you can reduce costly bugs that are normally found in the QA environment or during business user testing in a staging environment. Secondly, the test coverage will increase—which means the number of regression bugs that slip through should decrease—and developers will have a better understanding of the acceptance criteria, so they don’t waste time coding the wrong thing.

Plus, your business analyst will gain a better understanding of how the testers think about PBIs, so they can write better acceptance criteria for which test cases are written against. And finally, the Product Owner will get a higher-quality product that meets their expectations, and they’ll have more opportunities to provide feedback at the right time along the way.

If you’re still unsure how to introduce QA earlier in your software development process, we can help. Contact us to learn how our experts can help you develop and maintain a successful software quality assurance process.