The 2011 book The Lean Startup by Eric Ries changed the way many companies pursue value, and that approach can lead them to slash the QA budget in favor of other IT staff members.
The old methodology, to summarize it, was "if you build it, they will come." Now, a startup sells a product before it exists and then pivots if the product doesn't garner the right or a sizeable audience.
Some enterprises follow this technique for new features and products. Sell-then-build initiatives can skimp on personnel with deep QA testing skills. Software testing might seem like an unnecessary expense.
Yet, organizations can't abandon QA. So, here's the business argument for software testing and how to enact some QA measures if there aren't enough resources to hire dedicated testers.
Programmers introduce uncertainty every time they commit code without thoroughly testing the system. To address this, some organizations constantly release new features to customers in the hopes that the amount of risk with each change is minimal.
Other organizations batch up changes, which enables them to grow until the development team can initiate a long regression test cycle -- in which the team finds and fixes bugs -- and retest the system. However, regression testing is slow, so teams release systems less often. This, in turn, leads to more expensive test cycles.
Early tests performed by programmers, such as unit and integration tests, can decrease uncertainty within a build. Forms of human-driven testing, like exploratory tests, can reduce it even more. And QA professionals can adjust tests to account for evolving risks. Within this approach, a team can test around each change and reduce the uncertainty of functionality and performance -- but that's just the start.
Tighten the feedback loop
When programmers write code and run unit tests, the feedback loop between them and the test results is tight and quick. At best, these tests verify that new code does what the programmer expects it to do. However, the outer loop of feedback -- the customer feedback loop -- hasn't run yet.
Web companies including Twitter, Facebook and Flickr made their platforms what they are by going directly to the user. Early customer feedback might work when a product has no price and when the immediate goal is user engagement, not revenue.
However, most organizations create software or products for purchase. When the customer pays, they expect the software to work, or to at least work well enough to solve a pressing problem.
To mitigate the risk of ineffective software, app dev teams can use configuration flags and user categories to only turn features on for a select initial group that is willing to take risks.
Or, of course, they could test the software. Professionals with deep QA testing skills perform this task well and provide actionable insights to decision-makers who set the direction of a product. To test without a tester, consider asking the developer or the product owner, scrum master, assistant or manager to review the software before it goes out to the customer.
In the 1990s, customers put up with occasionally faulty software. After all, it was a hassle to get a new program; you needed to drive to a store, spend money and install it. Plus, there was a chance the new program would turn out to be a downgrade from the original one that had problems now and again.
Today, to replace software, you simply open up a new tab in your browser. If someone doesn't like Spotify, they can use Apple Music or Pandora. If they don't like Twitter, they can switch to Facebook or another social media platform.
There is almost no cost to make a switch, which makes usability paramount for customer retention. Companies get one chance to make an impression on the customer.
Early stage startups likely can't afford formal usability testing. Usability tests, wherein real users are assigned a task and must navigate the software to accomplish it under close observation by the product team, are expensive and take a considerable amount of time. Professionals with QA testing skills, however, can point out where a GUI might confuse customers -- and they're not afraid to say it.
A functional defect caught early in production might not negatively affect customers significantly. However, a security defect could result in a leaked customer list or password file, a federal fine, or even Chapter 11 bankruptcy for a startup.
Code vulnerability scanners check for malicious code and backdoors into applications, but they can fail to find nontechnical risks. For example, a software product could be set up to send private customer information directly to an outsourced customer service vendor, which could use it for nefarious purposes.
A tester could identify that problem and recommend a product design that hides private information from the customer service representative using an alternative path to access accounts. For that matter, a tester can identify who has access to a customer database and what that person can do with it. Have a human with QA testing skills, rather than a vulnerability scanner, perform that kind of threat assessment because they inherently understand human behavior and context for the product's use -- so they'll complete the task faster.
Usability testing tends to point out problems, while product insights help find opportunities.
For example, Google Maps doesn't just provide a route to a destination -- it suggests food, gasoline and hotels along the way. Similarly, it was Google that recognized that it could sell keywords directly related to users' search terms, which led to AdSense.
It's a powerful -- and profitable -- realization that two product features can enable a third with some more development, and that is one natural outcome of an effective testing process. Product insights create scenarios where QA testing skills naturally turn up product design ideas.
Put it all together
The second, macro-level view is that testers provide information about more than just errors. Trained QA professionals can find missing features, usability problems and trends that could lead to future problems -- all of which help programmers build better products much more quickly than without a tester's support.
Human QA testing skills enable these results, but that does not have to mean testing -- if an organization is really strapped -- has to exist as a dedicated role. Instead, think of QA testing as a skilled activity.
Testing in startups might be lighter, quicker, less documented and less challenging than it is for enterprise IT. However, there needs to be some check of a software product's usability and security vulnerabilities before its release, as well as an effort to make feedback loops as tight as possible.