Manage Learn to apply best practices and optimize your operations.

For 2016, take charge of your career in software testing

Software testers, it's time to stand up for yourselves and the value of your career. Expert Matt Heusser's advice: Become management's trusted advisor.

The attempt to define testing sounds like a good thing, at least to start. Too often, though, testing can sound...

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.

The tester-as-advisor may work best in traditional companies that have a test phase.

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.

Next Steps

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

This was last published in December 2015

Dig Deeper on Building Software Project Teams

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

11 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How would you go about becoming a trusted advisor to management?
Cancel
I think you have to earn your reputation. Start by being honest with them. I’ve seen, all too often, people not being completely honest with management because they are afraid of the consequences. However, in my experience, it’s the ones that are honest with management that earn their trust, and there’s no better way to do that to establish a reputation for honesty.
Cancel
Show them that it is your job to confirm that software works as they expected.  Software testing is not just about finding issues. It is also to give them the assurance that it works.
Cancel
I agree that honesty is the best policy. Sometimes that is going to mean that you have to tell management things that they don't want to hear. It might be uncomfortable, but in the long run it's the best thing for your reputation. 
Cancel
Own the advice you give. And get it right (almost) every time. And when you (rarely) make a mistake, learn from it and improve on it. Never walk away from a mistake; it's yours, fix it. If your bosses are as smart as they keep telling you, you'll be fine. And so will the company. When I hire, I don't expect perfection, but I do demand honesty and a resolution to the problems.
Cancel
How to go?

Find those in management who cares.
Speak their language.
Build reputation. Earn the trust.

These are not just steps. It's an organic and incremental process, with wins and setbacks. Ultimately, not everyone needs an advisor.

Cancel
Kudos to Matt for promoting the idea that software testers become part of the solution. This is an idea that I’ve experienced countless times in other contexts, but not that much when applied to software testing. How many times have you heard a boss say, “don’t bring me problems, bring me solutions?” Let’s apply that to testing, and not just bring bugs, bring information about those bugs that can be used to help[ the team respond to problems more quickly.
Cancel
@Michael -
"How many times have you heard a boss say, “don’t bring me problems, bring me solutions?” "

- I know what you mean. But let's take another look here.

1. Testers are very rarely, almost never fully informed about strategic situation in their department, let alone the whole business. Solutions are tied to costs and schedules - and impact of those is unknown to testers. How can they make or even suggest a fully informed solution?
2. There must be a reason why the boss is paid the big bucks. I'd guess it's largely because of the weight of making decisions and taking accountability.

From the perspective of these 2 points I'd rather stay a "microscope" and "telescope" for the boss supplying information that helps him/her to make better informed decisions and implement the solutions respectively.
Cancel
That’s what I’m saying. I don’t think it needs to be (or can be, for that matter) a fully informed solution, but we need to do more than simply report that something is broken. Effective bug advocacy involves supplying more and better information about the bug to get it fixed. The team may be more willing to fix a bug if you’ve been able to help narrow down the root cause while isolating the steps required to reproduce the bug, or perhaps your follow-up tests indicate that it’s a boundary value problem. In that case, you’re not just bringing the problem, but also part of the solution.
Cancel
Testers may have a different perspective when it comes to problems. They may see conflicts in the way a project is heading and be able to head off potential issues from the start. This can save man hours of needless work. I have worked on many projects over the years and it's amazing in some companies one department want a project not realizing the impact on other departments. This is where a good tester can shine with their knowledge.
Cancel
I think he model of continuous delivery and more agile methods, reveal that many things can be deployed as is, an fixes can be rolled in a bit by bit each sprint leaving only really crucial bug fixes as needing immediate action that may require bumping a release.
Cancel

-ADS BY GOOGLE

SearchMicroservices

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close