Zibtek’s Shift Left Strategy: Boost Quality Assurance

We’ve previously written about how important a team approach to sprint planning meetings can be. In the world of agile software development, that means getting Quality Assurance involved in sprint planning as well. Zibtek uses an agile strategy called “shift left” to push testing toward the early development stages. Testing early and often ensures a project has fewer bugs and improves code quality.

Shift Left vs. Traditional Testing

Traditional waterfall software development projects see testing occurring immediately before product release. The inevitable bugs or usability issues uncovered could easily delay a project’s release until they are fixed. Testing becomes a bottleneck that seriously impedes the ability of projects to deliver on time.

Shift left testing simply moves some testing from the far right side of the software development process and “shifts” it back to an earlier time. It doesn’t mean moving all testing closer to a project’s beginning; it just means sprinkling it throughout each step and iteration.

How to Improve Quality Assurance?

When using the shift left strategy at Zibtek, we have all our Quality Assurance people, whether they’re doing automated or manual, come to sprint planning meetings. While some think it’s a waste of time, experience has taught us it’s actually extremely valuable, because when QA team members are in the planning exercise:

They can walk through all the acceptance criteria and see what’s missing.
They know the edge cases or input values better than anyone, because they’ve been hammering them out.
We can start adding acceptance criteria based on what they bring to the table.

It’s also helpful because we talk about things like who owns the quality control measures in each story.

Everyone’s a Sprint Team Member

At Zibtek, we don’t believe Quality Assurance is an individual or separate team. Instead, the whole sprint team, including the Devs, is QA. That’s why you’ll see everyone, including product owners (POs), doing some acceptance testing to ensure predefined requirements are met to mark a user story as complete. It’s a great way to catch things other team members might not have thought of or didn’t even know could be connected.

One of the greatest advantages to a shift left strategy is eliminating the “blame game” that’s so prevalent on other software development projects; the entire team owns quality. If everyone is Quality Assurance, no one gets to say, “hey, Quality Assurance didn’t find it.” When you build a culture from day one of “everyone’s in it together,” by the time you get to the end of the process, it will be faster because problems were discovered and fixed along the way.

For instance, there are times we may decide a ticket shouldn’t even go to QA. If the PO or Dev looked at it, we’re fine. So out of 10 tickets, we might have 2 or 3 of them that don’t need a QA step. That’s valuable to the project because it lets QA folks focus their time and attention on more difficult tickets and their automation efforts on things that are more complicated.

Finally, because we now have all the acceptance criteria, we can start writing automation test cases, even before the code’s there. The tests are written knowing they’re going to fail (because there’s no code), but as code starts coming through, the tests start one-by-one to pass. That gives engineers real-time feedback as to what’s going on.If you want to learn more about the shift left strategy and how it can help you get the most out of your software development, contact us online today to schedule a consultation.