Is QA in Software Development Redundant?
Some organizations no longer see QA as a separate part of the development flow. Companies in this camp want to change the mindset of everyone involved in building software so that they don’t mainly rely on a QA group to validate their work. These businesses add more responsibility to the software developer, changing the traditional mindset where the developer finishes code and it becomes someone else’s job to ensure it meets quality standards. The shift-left paradigm gets to this idea where quality is infused into the building process and issues are discovered shortly after they are created.
People and organizations pondering the QA redundancy topic often intensely focus on quality from each developer. Many developers have a “no one is going to understand this better than me” attitude. It’s understandable. Other factors play into the reduce-QA mindset as well:
The move to agile environments – Organizations want to drive speed. To do this, you promote test automation. This puts more responsibility on the developer and treats automation and the product code as equals.
Different advanced release methods – Development groups use A/B testing and experiments with real users; dog-fooding, where employees use the software first; and canary testing, where a small group of customers get a software release before the masses.
A push to become leaner – All firms want to reduce overhead and unnecessary layers, driving more efficiencies.
Consider the significant difference between developers and testers. Developers are inherently more biased about their software. When they test their own creations, they approach the process knowing the code. They have specific assumptions. QA testers look at the customer experience and the testing process is completely “open,” less subjective. This is where DevOps focuses today: more closely connecting the developer to the customer. If there’s an issue, the developer knows about it right away.
QA is still critical in spite of the strong shift toward automation
When you’re working with products that humans will use, you must have some sort of QA. No organization would ever release a product without some form of manual testing. My favorite example is building a car. Lots of robots build and test cars through the assembly line, but at the end, someone needs to drive and check how the vehicle feels, handles, how the various features work by themselves and together for the ultimate customer experience. This is the function of software QA. Robots simply can’t feel what humans can. The industry will continue to invest in AI and machine learning - an advantageous additive - but we’ll still need human testing capabilities to validate the user experience far into the foreseeable future.
Still, software development must include test automation. Automation is made for:
Unit level and integrations (APIs)
Repetitive tests, done on a schedule
Tasks that have high-business impact, that is, if something were to break here, it would have a major repercussion on the business
Manual, scripted tests with step-by-step activities
Until we progress machine learning and AI, test automation will remain pretty dumb. It doesn’t think or make decisions based on analyzing results. So, some of it can become unnecessary waste in the pursuit of getting leaner. Manual testers are smart. They consider results and adapt their approach.
Automation goals are different from those of traditional manual testing. When test automation fails, it keeps a software build from getting into customers’ hands by stopping the “assembly line.” UI test automation should identify high-priority defects, not fail on every low priority issue. It requires effort to see why something fails during automated tests. When manual testers find failures, they determine whether the defects should block the build as they go. They add major value to the quality of the testing results analysis. QA is your “special missions” team, bringing human intelligence focused on customer experience and satisfaction.
How developers can realize the value of QA
I believe that most developers rely on and trust QA to find major issues so they don’t get in customers’ hands. Bottom line – developers create the code and they own the bugs, no matter who they think has ultimate responsibility for them. The more QA finds good bugs and reduces the number of escaping defects, the more trust is built. It’s a symbiotic relationship. Even world-class organizations produce products with bugs. But for detecting high-risk bugs that majorly impact the customer experience, there simply is no replacing human QA testing.
Using manual testers frees developers to mature your automation. Developing automation requires time and constant improvements. Having a manual group test while others evolve your automation is a major benefit. The balance between manual and automation will be specific to your organization. I don’t believe that most of my colleagues in the software development industry think that QA is redundant, it’s that there is a shift from QA into Quality Engineering (QE), which is changing the conversation.
Suggestions for organizations considering the QA redundancy issue
The developer/QA topic is important, but there’s no safe path to eliminating QA anytime soon. There’s too much risk associated with a bad customer experience. Quality is the most important factor. If it suffers, increased speed in development cycles means little. The improvement of both quality and speed is the formula for success.
As I mentioned previously, the software development industry is moving from traditional QA to QE where no one organization is responsible for all testing. The quality effort is shared. Many practices beyond testing ensure high quality software. Product practices that drive quality include defining new specs for services, test-driven development, and specific definitions for work units and completion. Development has best practices for code design, DevOps practices, and various testing levels (API, UI level etc.).
These and other practices fold into QE. It’s not just QA’s responsibility. QE must ensure all of these practices work cohesively together and train the organization to uphold this distributed responsibility for quality throughout the development lifecycle.
It comes down to these key points:
Make no mistake, automation is the way to go. It’s a critical part of software development today. Firms need to do this thoughtfully, with the right blend of manual activities. UI test automation relies on your manual testing scenarios, so companies must invest in good test design prior to automating customers’ journeys. Manual testing and automation interact and intervene with each other.
Understand the risks and challenges that you want to resolve with better testing. Only then – based on the benefits that each discipline brings – can you decide on your strategy. Testing is a proactive risk mitigation activity.
Create a test architect role (or similar). This role’s goal should define and utilize all aspects of QA and testing to ensure the most effective use of resources. It guides which tools are used, the level of automation vs. manual testing, the test environment, timing etc. and aims to be laser focused on testing and quality best practices to benefit the end product.
Focus on the right goal. The ultimate business goal is delivering the best digital experience possible. Testing practices, whether manual or automated, enable teams to reach that goal. Any investment in quality and testing should be evaluated in terms of contribution to the business goals.
Click here to find out more about how Applause helps QA teams.
