The attempt to define testing sounds like a good thing, at least to start. Too often, though, testing can sound...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
like a paperwork-shuffling, low-value role that might as well be outsourced. Here, I'll share some ways to take charge of your career in software testing. It's time for management to see testing as a more value-added role and for testers to generate more influence.
What do testers do, anyway?
A few years ago, here on SearchSoftwareQuality, I published an article on how to answer "Why is QA always the bottleneck?" The article took issue with the question as unfair but it doesn't have to be. Tim Lister, one of my heroes, mentioned in a keynote at the Better Software Conference that the job of software tester is to release only things that are good; other things get sent back. In other words, when testers inhibit flow they are doing their job.
That's the old view that testing, or quality assurance (QA), protects the user from errors. It sets up a confrontation between developers, who want to get new code out, and testers, who want it to be right. But that view is not the only one. The context-driven school of software testing tends to suggest that testing informs decision-makers of the software's status. That is, testers perform the analysis, including actionable detail, but then leave it up to management to decide what to do about the software. As the pace of delivery moves ever faster, I find that some leaders do not have time, or interest, to help decide if this bug or that bug should be fixed. My goal then becomes to get to know them, and what they think, so we can make the decision the product owner would have made if the product owner were available. In this way, the tester becomes a sort of junior product owner by having some product and feature authority passed down. This isn't a "trusted advisory to senior management," but it does mean a tester can make a larger impact on the delivery team with less friction.
Within a career in software testing some companies have a "test architect" role, but in my experience what that person does exactly seems to be more than a little fuzzy. My friend, Noah Sussman, suggested an alternative role: A QA architect.
QA as counter-balance to velocity
People typically frame test and quality as preventing errors. We're making sure the software is good enough before it ships. That leads to IT spending a lot of time thinking about how to deploy, when to deploy, change control, and so on. If testers are punished for errors, they will work really hard to prevent them, thus slowing down the system. Imagine a game where you drop pieces on a board, and when the pile gets too high, it breaks and falls. Your goal is to make sure no pieces fall off the edge of the board. You'll be very careful where you drop the pieces, which will slow delivery of new features (the pieces) to a halt.
Programmers, on the other hand, want to get as many pieces on the board as possible.
Sussman's fix, to end the conflict, is to have the role of quality include minimizing the impact of failures. Some of these concepts overlap with DevOps, including quick deploys to quick rollbacks, monitoring production to find problems quickly, staged rollouts and feature flags.
Instead of running away from these ideas, I am suggesting that -- to benefit your career in software testing -- we embrace them, creating a true QA architect who is responsible for ensuring the stability of the system in the face of rapid change and expected failure. One place to start is with historical data: How often does the system fail, how long is it down, and, if possible, how many people does the failure affect?
Compare, for example, a team performing continuous delivery to a classic Scrum team with two-week sprints. The Scrum team moves code to production Sunday night before the new sprint. If the bug is found Monday morning during week one of sprint one, it will be added to the backlog for the next sprint, fixed in sprint two, and deployed to production four weeks after it was introduced.
A team that practices continuous delivery could fix the bug the same day it was found, which is 20 times faster than the Scrum team. The continuous delivery team could have dealt with 10 times the bugs but with half the impact on the customer.
Those numbers are a best-case example, but they do match my experience. If there's an opportunity to improve delivery times by focusing on responding to problems more quickly, testers can get involved in being part of the solution. In some cases, testers are even designing the solution -- and that's great news for your career in software testing. One company I worked with, for example, had a technician write automated checks against production. They didn't do much, they just logged in and explored the website for a specific user on a loop, but they included timing data. When customers started to complain about timeouts trying to login, that timing data provided insight into when the problems were occurring and exactly how bad the impact was.
The final analysis
People who can succeed at testing are good at taking an infinite problem set, coming up with a few key experiments, drawing reasonable conclusions and communicating about those results in a way that can be heard. That overlaps entirely with the qualifications for senior management. The biggest difference is that testing is much closer to the work itself; testers can see what is actually happening on the project and what people talk about at the coffee pot. Too often, senior management is disconnected from that work and reliant on reports from the people who do that. That means testing can serve a role as a sort of independent auditor -- in the best possible way.
The tester-as-advisor may work best in traditional companies that have a test phase. In organizations that ship every few weeks or more often, there is much less uncertainty around product quality and deadline. In that case, you might be better off advising on the stability of the system long-term and finding ways to measure and manage that. Either way, the key is to own your own process. Figure out how which of the models above makes the most sense for you and your company right now, and frame your words, actions, and thoughts to move in that direction.
Many corporations today lack a compelling vision for test and quality. That creates a vacuum, an empty space. Instead of telling people how it should be, act as if it is … and see what happens.
Should you get a QA certificate to help your career?
If you're in QA, you need to be doing this
Want to change industries? Here’s how