James Thew - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

How to meet QA responsibilities during a software tester shortage

An organization facing a dire shortage of QA engineers can't just dump these tasks on developers. Here's how to keep up software quality with limited QA resources.

In the midst of a software tester shortage, it might seem smart to temporarily shift QA responsibilities to other team members, such as programmers. After all, they all work on the code, so they know the product. But do they know testing?

Programmers don't offer the same skill set as dedicated QA resources or testing as a service (TaaS) professionals. Also, those programmers are likely already swamped. To staff QA, contractors might provide a better option than overworked developers, particularly when the competitive advantage is an intuitive product for end users. TaaS can fulfill demand for effective usability testing and around-the-clock responsiveness.

Though, in the long run, organizations should still create policies and mechanisms that enable it to temporarily move software QA responsibilities and processes to developers. Circumstances could arise that call for this immediate -- and generally cheaper -- alternative. The best way to handle a software tester shortage is to accurately gauge the importance of QA for your company and what kinds of testing you need.

We're all software testers here

No QA staff doesn't mean no software QA responsibilities, but it does mean getting creative with how those responsibilities are assigned out.

"If you're an early-stage startup still trying to figure out a good market fit, then having existing personnel do their own testing is often the most cost-effective solution," said Joann Chuang Anderson, VP of engineering at Scoop, an enterprise carpooling network. If companies can't hire QA engineers, she recommended that they train internal customer support agents to handle quality checks. These people interact with customers most frequently; thus, they are familiar with the problems users run into.

Once the business stabilizes, QA managers should evaluate the cost of bugs and nonintuitive UX in both monetary and less tangible terms, Anderson said.

Some business questions to ask include the following:

  • Are you in a highly competitive market?
  • Does your competitive advantage come from being an intuitive product?
  • Could competitors take over your market share simply because they have fewer bugs?

Also, evaluate how the team deploys fixes. In a web application, you can issue a fix quite quickly. A mobile app update, however, often requires a day or two to get app store approval, which means those users experience a problem for a longer period of time.

"If either the cost of bugs is high or the time to deploy a fix to users could be long, then you should hire specialized QA," Anderson said. QA engineers act as ambassadors for users; they gain a deep understanding of the product and come up with customized test plans that address user concerns.

All companies should implement an onboarding program that trains new engineers on the overall product, Tal Broner, Executive VP of engineering at Egnyte, an enterprise file sharing service, said, as well as the rest of the organization's software portfolio, to understand the broad digital context. After training, pair a senior engineer with a new engineer for the first few months so the newbies have guidance and support.

Developers and QA think differently

While knowledgeable about code, developers primarily create software. QA engineers focus on all the different ways software can break and how customers could misuse it. So, developers' ability to evaluate software quality is limited in practice.

"Developers are great at writing unit tests," Anderson said, but they might not test the entire end-to-end user flow. If developers must fill the gaps in a software tester shortage, help them out.

Internal policies should include explicit expectations on what tests are required before developers can check in code, which shifts their mindset to software QA responsibilities. Create clear documentation about what entails a good test -- i.e., one that is easily readable, repeatable, stable and free from interdependence. Each test action should have its own assertion to make it easy to debug.

Anderson recommended that an organization create mechanisms, such as regular automation runs with predefined reporting or alerts via dashboards, to ease QA tasks for developers. Also, provide guidelines that explain what to do if a code check-in causes test failures. Clarify, for example, if developers should remove the code from the branch and who or what could block code from being checked in.

When TaaS makes sense

In-house QA personnel typically possess deeper knowledge and a better understanding for testing complicated scenarios and use cases than a hired hand. But, for simple scenarios, especially when testing UX, consider bringing in an external tester -- or dozens of them.

"Their perspective on ease of use is much more objective [than internal employees']," Broner said. "TaaS can be complementary to the existing personnel and close the gap for testing in times when the existing team is not available."

When organizations require manual testing at scale, a TaaS contract provides a roster of testers who are up to QA tasks. TaaS, if the provider has sufficient scale and footprint, can also operate around the clock with continuous deployment.

Shift QA to the left

One strategy on the rise is to incorporate more software QA responsibilities into the development process. Here, you're not asking developers to take over QA tasks during a software tester shortage. Instead, you're making testing part of development forever.

Called shift-left testing, this process requires some additional effort but pays off down the road; teams catch bugs earlier in the software development lifecycle, where the defects can be more quickly and inexpensively remediated than they are with QA as a separate, sequential step.

Initially, shifting left can place an extra burden on QA engineers, who must establish good testing processes for everyone and educate developers -- which, of course, means extra work for developers too. QA engineers must effectively convey the importance of unit tests and automated end-to-end tests to get developers to buy in.

"A developer should know the whole application and understand it and not only the functionality they currently are working on," said Celestyna Górska, senior QA and team leader at Netguru, a custom software development company.

Assign a QA specialist to each development team. If there's not enough QA personnel to make that happen, then the organization should establish precise processes that the team sticks to, such as well-defined quality gates.

Find ways to change the approach within the whole team so that developers have time to write tests and follow processes, in addition to their classic dev responsibilities. QA engineers need to work with managers to ensure developers are accountable for software quality.

After all, Górska said, "Good quality is everyone's business."

Dig Deeper on Software testing skills and career advice

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How do you adapt to deal with limited QA resources or personnel?
I do like the ideas of shift left.

There is a problem however.   Many companies give all the power in this transition to the devs and their management chain.  This is fine if the managers are clear and understanding of both sides of the shop, but if not, then managers may rely on self organizing teams to take up the banner of testing, and not realize like the soldiers in Captain America the First Avenger, have no clue how to get that flag down, let alone where to start.  This is compounded when metrics for performance reviews, make testing feel like a waste or after thought, not docking devs for their lack of testing, but threatening the job of a tester who is transitioning to doing coding as well as testing.  It would be comical if not for the fact its a little like having two gifted twins, praising the one who can't do testing, while being strict with the one not as good in the favored area.

Yet many companies it seems have done just that.  This is why many report that companies that cut their QA department, giving that responsibility to devs, eventually encounter a quality crisis of their own, often taking 2 years or more to undo the damage.  It saddens me still, that people with gifted knowledge and experience end up feeling like cattle sent off to be harvested when companies decide they are no longer productive members of teams.  I feel worse for the teams who saw the benefit those Testing eyes had been in the team.  Being blind to the need for those people, may be worse for those who actually know and can do nothing except try to cover their own work because now, they might be next.

It smells like a type of dysfunction that a company can do with all good intentions, but in the end only harm themselves and their hires.  Is it any wonder the average programmer near a hub lasts not much longer than 3 years, perhaps changing as often as every 18 months?  Its not just about salary, its about how effective you can be.