Regression testing should be shared, either within the delivery team as a whole or between development and QA. But in too many companies, this testing is still seen as primarily QA’s problem. But with QA now seen as a key driver of business growth, according to the World Quality Report, it's now a business problem.
Historically, testers have spent days, and sometimes weeks, in regression testing mode, usually at the end of a sprint or when preparing for a big release. During that testing, dev teams often support QA's efforts by making themselves available to help fix bugs.
However, while developers are available, they're usually disengaged from the detailed regression testing information-gathering process—arguably the most important part—until bugs arise.
Because developers are focused on other work at this point, they remain unaware of the valuable information that QA is uncovering. This far from optimal because if developers focus only on their own area within the application, they can become siloed.
The better approach is for developers to understand how their areas integrate with others from a user advocacy standpoint. In this way everyone can troubleshoot effectively when issues are found.
So, on the one hand, QA discovers new information that dev is missing; on the other, dev is working on new projects that QA can't influence. The result: QA is always playing catch-up on work it should have been integrally involved with from the start. Ultimately, this leads to time lost, other inefficiencies, and money wasted.
Here's why regression testing responsibility needs to be shared between QA and devs.
QA has become a crutch for dev
Dev is usually considered a more valuable team than QA for several reasons. Developers' time is more valuable because they're paid more than QA professionals, and devs see their main value as to simply produce as much code as possible.
Because of this antiquated perspective, QA has become a crutch for dev. QA has assumed the responsibility of ensuring that dev's work meets established industry quality standards. That's wrong. And QA shouldn't be just the mistake finders.
People sometimes compare the roles in the software development process to those in the building construction trades, with such titles as general contractors, skilled tradespeople, architects, project managers, and general laborers. While the analogy works to some degree, QA's role is misunderstood.
A skilled tradesperson such as a plumber ensures that seals are built correctly, drains work, water flows in, and everything is up to code. While plumbers might ensure that the structure of the design is sound, they don't usually provide input into the building's design, colors, or features; they focus exclusively on the plumbing.
They are experts in their areas of specialty—the technical aspects of creating and installing plumbing—and theirs alone. The same is true with other trades.
QA should be the project's general contractor
That's why you need a general contractor. These professionals can advise, even in a technical capacity, but usually don't have deep expertise in every trade. The general contractor's job is to ensure that the desired level of quality has been met, including in design and user experience.
Finally, you have the inspectors. These professionals have expertise in at least one trade, and they ensure that the associated building codes have been followed.
In software development, people think of QA as the inspector. But QA should function as the general contractor instead. QA teams are familiar with multiple components of the software cycle, but that doesn't mean they are experts in any specific area, the way a construction inspector is.
As the general contractor, QA should work with the owner/user throughout the course of the project, and they should be responsible for ascertaining the user requirements and specific needs.
As long as QA is viewed as the inspector instead of the general contractor, it will continue to serve in the capacity of a crutch to dev.
QA's correct role: User advocate
QA’s role should be to ensure that the needs of the client, business, and delivery team have been satisfied. QA teams can provide consulting services when doubts arise in the software development cycle. They can examine the situation from a 10,000-foot view and see the entirety of the project.
Because QAs are aware of the entirety of the project, QA is in the best place to see the big picture. Unlike devs, who work on specific pieces or functions, QA teams see all aspects of the project.
On the other hand, QA will never be the subject-matter experts devs are. We should have "just the right amount" of depth in each trade, but our true value is seeing how each trade works with the others to advocate for users. QA must depend on the expertise of each component owner in the software cycle, and must foster relationships with them.
That's why QA can't be the only ones responsible for regression testing. QA should not be simply an inspector of dev code, but rather should explore the overall customer experience from a broader, more user-based vantage point.
Come to my presentation at STPCon Boston, "Modernizing your testing approach," where I'll explain ways the modern QA/QE can be influential, and present practical (and actionable!) suggestions to implement them. I’ll also host an in-depth workshop about "Implementing efficiencies within your SDLC." Register with discount code "TECHBEACON" to get 10% off any package. The conference runs September 23-26, 2019.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
