How to take your QA test cycle from two weeks to two days

, Managing Editor

Pressure to produce rigorously tested software and launch quickly leaves over 54% of software teams struggling to meet demands for new and updated products. But even as the software development lifecycle shifts to incorporate testing, long QA test cycles can stall steady iterations.

In competitive industries where each release is an opportunity to differentiate, shortening your testing cycle can be the difference between leading the market and fueling customer churn. If your QA test cycle is leaning towards weeks instead of days and you want to shave testing turnaround, employ sprints, focus on utilization metrics, and choose the right testing model.

Employ sprints

Sprints, part of scrum and Agile software dev methodologies, are timeboxes with specific goals that guide DevOps and testing teams when releasing or updating software. Employing sprints streamlines the software testing cycle and establishes strict timeframes that encourage quick turnaround. 

Establishing a predictable testing cadence by negotiating a schedule for builds that works for both DevOps and QA teams. Start with sprint planning to finalize goals, priorities, and estimations for total work time. Sprint cadences will depend on your team structure, but generally dev teams require a full two weeks to get updated code merged with the master, perform unit tests, and ship code to QA teams. 

Then, your QA model (more on that later!) will determine the latter half of your sprint. Networked testing teams can complete QA turnaround in days, while crowdsourced and offshore testers work anywhere from 1-2 weeks to test and build a report. Keep in mind when planning sprints that this is not total time to market: if the code needs another cycle or redesign, the cadence starts again. Sitting at a 4-5 week sprint can be untenable, especially for mobile-facing teams who can’t roll back versions if bugs make it into production. 

If your team wants to tighten their software dev lifecycle, focus on creating shorter testing sprints without sacrificing quality. Some ways to reduce testing cycle turnaround times:

  • Use more testers. Find a large pool of testers and run 30 net hours of regression tests in three hours. If one expert tester can perform one localization test per hour, then 30 testers can net 30 tests in the same hour. Using large testing teams distributed across timezones allows dev teams to share the build on a Friday and have a full QA report ready Monday morning. 
  • Choose mission-critical tests. Create a roster of time-sensitive, critically important tests to run before release/update. Any tests not covered can be backlogged and added into the next sprint, or worked into the post-sprint schedule. 
  • Wield automation. Adding automation into the testing sprint can drastically reduce tester time spent on unit tests, smoke tests, functional, or regression testing. 
  • Shift left. Collaborate with DevOps to include a suite of basic tests run during the development sprint. Shifting lefts checks unit functionality and helps avoid major compounding bugs that eat up time in the testing cycle.

Prioritize and increase utilization

Taking your QA cycle from two weeks to two days requires a hard focus on utilization and burstable testing. If you pay offshore QA firms or freelancers anything other than hourly rates to complete QA runs, you’re not getting 100% utilization of your paid time.

To reach higher utilization, employ burstable testing teams with a set number of hours that can be used flexibly. A burstable approach to testing allows for frequent sprints when dev teams are ready for QA, fast. If you need to tighten a QA test cycle to meet a release, limit exploratory testing across that month and flex your hours over one weekend. Burstable, on-demand testers can swarm tests when you need them and then intentionally go dormant. As a result, capacity is available when you need it, but you never pay for idle time.

Focusing on utilization metrics also extends to time spent per individual tests and the time saved by using experienced testers. Grabbing the readily available (or cheapest) offshore testers you can find can result in more time per test due to inexperience, language barriers, inflexible contracts, and timezone differences. Instead, build a core roster of talented QA testers that make every second count and use them for each run. Experienced testers not only work faster, but consistent engagement with your company makes each run smoother, better, and uniquely tailored to your product.

Augment internal talent

Unless you have a robust in-house QA team, you’ll likely need to bring in a software testing partner to augment your talent. With or without internal QA and QE experts, in order to take your QA test cycle from weeks to days, you need to bring in additional team members and testers.

Outsourcing to offshore QA teams allows companies to scale quickly and perform large testing runs without the cost of full-time employees or internal device labs. But when you utilize an offshore QA testing team, you’re at the mercy of their turnaround time. Some companies take three days for a single regression test and weeks for a complete QA turnaround and report. 

Utilizing crowdsourced testing teams is fast and efficient, but low skilled testers mixed with incentivized non-essential bug finds can mean that your testing window, though short, produces a low quality product. Without a centralized platform or strong leadership, crowdsourced teams are less inclined to go above and beyond to find unique, hard-to-diagnose issues. 

Networked testing teams have strong leadership and rigorously vetted testers that enable quick turnaround times without sacrificing quality. Specialized testers provide transparent processes and have the flexibility to perform in sprints when you need them. Networked testing teams have the immense added benefit of engagement managers and leaders to guide runs. 

Jumbotron image

Want to explore the benefits of a networked testing team?