With the increase in the need for speed to market and the popularity of more flexible agile software methodologies, the large QA team has largely disappeared over the past 20 years. Those 50-to-100-person QA teams—with separate management, directors, and full testing cycles—are mostly gone.
Large teams still exist in some cases, but they're mostly in businesses that are highly regulated, where QA testers help verify that requirements and quality processes are met.
For the rest of us—the QA software testers who are now part of development teams—the change has been interesting. In many of today's leading technology companies, the shift away from more formal QA software testing practices is widespread.
Is the QA profession losing respect or being replaced in the name of speed and efficiency?
No respect lost: It's about productivity
Overall, the change from large, independent QA teams to QA team members as coders, or as testers within a development team, is not due to a loss of respect for the QA profession. It's a cost and efficiency improvement.
Does any company hire a QA tester first? No. It hires developers and product managers first. Is that a lack of respect? No, it’s realistic. After all, the application has to be developed and exist before QA testing is even necessary. Granted, the sooner the QA testing starts, the more time testers have to learn the system as it's being developed.
In today's reality, if a QA tester is hired at all, it's typically right before an application is set to initially release. Perhaps that's a loss of respect for the business value of a QA tester. But consider that the company has hired a QA software tester, and that act alone—regardless of the timing—means management believes there is value in QA testing.
Testing pro wanted: What's in a job description?
Over the course of my career, I've experienced both working on large QA teams and being an independent QA tester assigned to one or more agile development teams. I wholeheartedly prefer the latter.
The QA professional is a software development team member who performs manual, feature, and functional testing. The QA pro who focuses on QA—as in auditing compliance with regulatory requirements—is a separate function.
Large software companies such as Google, Facebook, and Microsoft use SDETs—software development engineers in test—to create unit and automated tests at the code level. Any additional testing, for features and functionality, is performed manually. Software testing is also largely done continuously these days, rather than during a defined test cycle.
Exploratory testing is the modern manual testing technique most used in practice. It is valuable for regression testing, as well as for testing features (requirements or acceptance criteria for stories), and for general system functional testing.
James A. Whittaker's book about exploratory testing techniques discusses a method where "tours" are created to test the workflow of an application from several unique viewpoints.
Why large teams fail
Large QA testing teams fail because they're simply not efficient or effective. Software testing is an integral part of development, not a separate function. Politics among managers, leads, and QA members means that leadership, QA processes, and functions are constantly changing to the point of consistent chaos within large teams.
No one QA tester can keep up with testing and the need to learn and apply automated testing, along with the constant change of QA process requirements and demands to keep up with manual testing simultaneously. What happens in large QA teams is that every team member forges his or her own path.
In other words, you develop a personal test methodology that best suits your understanding of the application, personal integrity, and ability to work constructively with development. You function inside the team, but every QA is marching to his or her own drum, attempting to focus on testing rather than the persistent, chaotic static from large QA team management.
Today’s application development companies are focused on efficiency, costs, and results. Testing effectiveness is hard to prove, but proving that testing is worthwhile is not difficult. The QA profession losing respect is less about testing being unnecessary and more about being effective at finding relevant defects quickly and continuously.
QA respect is literally bound into results. How many and what types of bugs are found? How is QA helping developers create successful features? How often does a QA ask questions about the application design before or during development? QA respect is gained by proving QA testing is a worthwhile cost to the company.
Who needs testers?
Development and testing are separate functions, but they can be combined, as they often are, when a QA professional becomes an SDET. SDETs create code-based automation scripts and likely code when needed, and they test manually as necessary. The problem with relying solely on developer-based testing is that developers design code, test their code, and merge the code into a build.
Developers generally tend not to use the application as an end user but focus on how the code executes in the background. Same with automated test developers. In practice, it becomes more important to management to meet deadlines, and over time, it is more important that unit and automated tests pass so the application can release, rather than verifying that the end-user experience performs as expected.
The missing piece is an independent test of the application functionality performed by a resource who did not create it and isn’t responsible for making sure the automated and unit tests pass.
Tips for proving a QA tester's worth
Being the QA tester on a development team ensures that you’ll need to prove your worth by testing with an end-user perspective—not by counting defects entered or reported by customers, but rather by becoming an active, integrated team member focused on testing for the end user. In order to prove that QA testing is valuable, you need to find workflow or integration defects in the application and be able to constructively work with developers to correct them.
The psychology of testing comes into play when you feel threatened, or less than others. Start by dropping the ego. Let go of the need to be the most important resource in the company, and be secure in your knowledge and your function as a tester. Ask questions of everyone on the team when you don’t understand a story, a fix, or even the acceptance criteria. Bring it up when there are contradictions in the story, or when you see that a developer and a business analyst or product manager are not on the same page. Focus on protecting the end user from defects, regardless of the cause.
QA testers must be courageous and secure with their professional worth. It’s okay if you’re wrong. You’ll gain more by asking questions, dumb or otherwise, then you will by worrying about whether your role is respected. Don’t stop at asking questions; listen to the response, fully and completely. By asking and listening, you’re respecting your team members' knowledge and encouraging a work rapport. Respect is earned over time. QA testers gain respect by preventing end-user defects.
Improve your QA testing worth by not avoiding difficult testing tasks. Don’t be the QA who only tests the surface of the application repeatedly. Stretch your abilities, and tackle the hard, brain-pounding items with enthusiasm. Take opportunities to expand your skills and understanding.
I often see QA testers avoid a story or project that’s difficult—whether it’s the developer doing the work or the subject matter. QA respect is gained from hard work and perseverance. Remember to let go of your ego, set your priorities, and test. Ask, listen, and learn, and don’t fear being honest when you don’t understand. Respect is earned over time and by not being afraid to tackle difficult testing tasks.
QA testers who lose professional respect are those who:
- Sit back and let others do the work.
- Surf the Internet or waste time while they wait for stories to come through, rather than continuing to test or testing continuously.
- Don’t stretch their abilities and only want the easy items.
- Restrict how many tests they’ll execute.
- Are always afraid to bring up questions and concerns or to express ideas.
- Blame the developer, business analyst, or product manager for defects.
Do the profession a favor: Test your heart out, tackle anything, and let your ego go, so you can work with other team members at a quick, constructive pace and provide the highest business value. That's how testers will continue to command respect.
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.
