3 Ways To Increase Your Value As A Tester

A couple of tweets by Justin Hunter (@hexawise) recently got me thinking about what makes a tester really valuable for the long term.  He tweeted:

3 things more testers should know more about: test design approaches, Context Driven Testing, Bach & Bolton-style Exploratory Testing (tweet)

As a tester, if you want to maximize your ST earning potential, learn Selenium. To maximize your LT value, study Context Driven Testing. (tweet)

(In the last tweet, ST and LT refer to “short term” and “long term” respectively.)

While I agree these are all valuable skills for testers to have today, I believe these hint at deeper skills that are actually immensely more valuable over the long term.  

Before we begin, consider what “valuable” means to you. Is it money? Is it getting the opportunity to work on cutting edge products or products that help change the world? Is it the flexibility to work remotely or to be able to travel around the world? Is it getting to work with brilliant people? Depending on your answer, your path to becoming “highly valuable” will vary greatly.

Since the tweets above mentioned earning potential, I’m going to focus on that aspect for now, though I personally rank some of the aspects above higher.


Thinking about the law of supply and demand, one way to look at “value” as a tester is having the ability to stay in high demand but short supply throughout your career. Given the rapidly changing pace of software development technologies and practices, you’ll need to rapidly evolve your testing skills along with them. As a quick example, my first job as a tester required writing test automation in C++ and COM. After that, I worked with C#, SQL, JavaScript, and most recently Objective C. At any of those points, I could easily have chosen to stay put (yes, people still use COM today!), but because I knew other programming languages and had demonstrated I could adapt to change, many other opportunities wre open to me.

Here’s another way to think about it: your industry is changing every day. Your team is hiring new people with new skills and different experience. Why? It wants to be more efficient and more effective. Staying static in a dynamic world is extremely risky if you want to keep your role for very long.

Learn How To Automate Tests Effectively

There is a heated debate that has been raging for years about whether testers should learn to automate or not.  My personal opinion is that nobody should do anything they don’t want to do. Having said that, testers who can automate tests effectively in addition to doing a great job at all the other stuff (test planning, manual testing, attention to detail, etc.) are more valuable in the long term. I claim this in the same sense that any skilled craftsperson who is an expert with two tools is more valuable than one who is an expert in only one tool.  Manual testing is essential to validating many types of products, and I would never suggest removing all manual testing in favor of automation for a product with a user interface.  However, all great craftspeople know that it’s best to use the right tool for the job, and manual testing isn’t always the right tool.  Much of what testers do on a daily basis is repetitive and predictable and could be automated.  Testers who know how to write automation that is fast, reliable, and maintainable will have an advantage in the long term over those who don’t. 

Selenium is a great platform for automating web sites, and Justin is correct that knowing Selenium will probably help you earn a well-paying job in the short term.  While the web seems to be pretty popular these days, websites are just one type of product in a sea of many. Knowing the “elements” of test automation is what’s most valuable. This comes with years of experience and learning by trial and error for many. I’ll cover these elements in depth in a future post. 

Communicate Effectively

Written and verbal communication are critical elements of being effective as a software tester, and it is a fallacy to think you could be highly valuable if you don’t “work well with others”. Think about all the parts of our jobs that require effective communication: writing test plans, filing bugs, clarifying requirements, reporting test results, sending e-mail, documenting processes, giving presentations… Yet examples of ineffective communication are all too easy to find every day in each of these scenarios. I’m not perfect by any means; communicating effectively is a life-long pursuit. This is equally important if you work remotely or in a team room with other engineers. 
When you communicate effectively, others will “hear” you the first time. You won’t waste precious time going back and forth asking and answering questions. You’ll be less randomized, and so will your team. You’ll be seen as someone who can be trusted, because your communications will inspire confidence rather than doubt. All of these will contribute to higher earning potential over time.
One of the best tips I can offer for testers is to say as much as you can in as few words as possible. This holds for your defect reports, presentations, emails, test plans, etc. Don’t assume you have to fill up a certain amount of space with “fluff”. Just say what needs to be said and be done. Look for words like “utilize” as smells that you’re off track. 
For defect reports, try to anticipate what questions others would have after reading your report. Did you report enough detail in the “steps to reproduce” section, or did you make assumptions that the reader might not also make? Including screenshots or videos can be extremely valuable too.

Lastly, smile. A tester’s role is highly critical, and many testers come across as unnecessarily grumpy. Of course, many developers also come across as grumpy, but who wouldn’t when there’s an army of people paid to point out how bad your code is? If you think about your role from the developer’s point of view, you can see how a friendly smile (no, not a Dr. Evil smile!!) can go a long way in convincing a developer to pay close attention!


There are many ways to maximize your long term earning potential as a software tester. We discussed three such ways above: adapting to change, learning how to write effective test automation, and communicating effectively. Each of these deserve much more attention than a single blog post and can take years to master, but hopefully by putting them on your radar you’ll stop to think how well you do them now and how you might want to change.


Increasing Your Influence On Product Design

A common complaint I have heard from testers is that they don’t feel like they have enough influence on product design.  

The pattern goes like this: A designer, program manager, or analyst comes up with a plan for how a particular feature should work.  The developer team builds it and then hands it off to the test team.  After using it for a while, the tester identifies some improvements or changes they feel would make the feature better for customers.  

From here, any number of things can happen.  In an ideal world, the tester has a perfect understanding of what the customer (or the market) really wants, the change is made, and the product sells like hotcakes!

But what if this doesn’t happen for you?  What if your suggestion is considered but ultimately not accepted, or worse – ignored altogether?  How can you increase your influence on the product?  Here are some suggestions:

1. Suggest Solutions, Not Just Problems

This point is probably worth its own post as it applies in so many aspects of testing.  When you suggest a change of plans, helping the team get to the ideal solution quickly is much more valuable than just calling out a problem.  Chances are, your team is overbooked, under-staffed, and up against tight deadlines.  They probably have several other features in development and a deadline looming overhead.  The last thing on their minds is going back to a feature they’ve already coded up and revisiting the initial design (this is often true even for teams who think they’re operating in an Agile fashion).

If, however, you suggest a path to success, that’s one less step for the team to take in order to get to your solution.  Research suggests that humans are better at iterating than innovating in general, and when you throw in the other pressures of shipping products, my observations are that it’s more common for teams to look for a small iterative solution rather than throw out the whole feature and start from scratch.  By providing that first step, you’re helping the team get started in the redesign process and removing a big barrier to change.

The anti-pattern here is to assume “It’s not my problem. I just point out the problems, and someone else has to fix them.”  This is a very dangerous and counter-productive mindset for testers, and I highly encourage you to check yourself if you even come close to this line of thought.  Falling prey to this way of thinking is essentially giving up.

If you don’t have an immediate suggestion for how the feature can be made better, you should at least state that and then offer to be part of a virtual team to go figure out a solution.

2. Provide Supporting Evidence

Perhaps you’re certain your suggestion is perfect, but that really doesn’t matter unless you are able to convince others in time to make the change.  Your mission at this point is to collect data or other evidence that supports your feedback.

Feedback from usability studies or beta users can be a very powerful tool.  Also consider asking the team to add logging or instrumentation to the feature to understand how users interact with it, what they do and undo, how quickly they accomplish the task at hand, etc.  If you can get them to build two versions of the feature and test one vs. the other with beta users, you can determine more scientifically which approach is more effective.

Another possibility is to seek out others with similar features to see if they have solved the same problem.  For example, if your organization produces both a native app and a website version of your product, has one team already gathered the supporting evidence you need?

3. Pick Your Battles Carefully

While you could “go to battle” for every single product change you feel is right, ultimately you have limited “funds” available, so you’ll need to choose carefully which issues to pursue.  

For the purposes of this discussion, your “funds” are all the resources you could diminish while trying to convince others that your idea or change is worth taking.  One such resource is your own credibility, because if you routinely pursue issues that the team deems aren’t worth fixing, the team may start to expect your future ideas to be of similar merit.  Once this happens, it can be very difficult to turn around this bias.

Another resource to consider is the time/energy you could put into driving the conversation.  Is the suggestion really worth all that effort?  Will it result in an incremental improvement or something monumental?  

Each of these have an associated opportunity cost – the cost of not doing some other task (such as fixing a bug or feature that would potentially help more users).  

4. Know When To Quit

Once you’ve clearly made your points and supported them with evidence, it’s time to let the decision maker do their thing.  Either you were right and he/she is wrong, or you’ll learn something when the feature hits the market and is successful as designed (or the team discovers bigger opportunities or problems to chase). 

If, however, you continue to badger the decision maker or get stuck in a depressive shame cycle because your idea was ultimately rejected, then frankly, you’re wasting your time and energy.  Worse, you could be eroding your influence on the team with this behavior.  Instead of being perceived as a smart and insightful representative for the customer, you risk being seen as whiny or annoying.  The team will start to ignore your feedback for fear of encountering another time-wasting battle.  The next time you have a great idea, you’re even less likely to get the attention you need to influence the team.

In practice, this is much trickier to do than to write about.  It may take months or years of experience with a particular set of people to fine tune your timing.

5. Follow The Decision To The User

If your idea is ultimately rejected, you should pay close attention to what happens once users ultimately get their hands on the feature.  If it’s successful without your suggestion (where success is defined by happy customers and reaching business goals), then take a moment to consider why you cared SO much and whether the data you provided to support your suggestion was flawed in any way.

If the feature is unsuccessful in market, then reflect on whether your suggestion would have addressed the specific concerns being raised by customers.  If so, then perhaps it’s time to bring it up again with the new data (from unhappy customers in market).  If the team sees they had the perfect solution sitting in front of them all along, then your credibility will go up a bit, and hopefully the next conversation about change will be a little easier.

One team I worked on developed a very clever way to find ways to crash the product with automation that exercised the product in random ways.  Most of the bugs they filed, however, were rejected by the development team as “theoretical” because who would ever do that?  The team was unsuccessful in getting these bugs fixed before the product shipped.  But they stuck to it and tracked incoming crashes to determine how many had been found before shipping by their stress test.  It turns out a very large percentage had been found!  They took this evidence back to the developer team, who then made it mandatory to fix all bugs found by the tool before each release, even if the steps to reproduce those crashes seemed crazy.  As a result, the overall incoming crash rate dropped significantly in the next release, support costs, dropped, and the team was less randomized with shipping patches and could focus more on the building new features.

6. Don’t Be A Jerk

The old adage, “you catch more flies with honey than vinegar” holds in this context too.  Always start (at least) your conversations with a polite tone and try to find a common ground with other decision makers.  If you haven’t read it yet, I highly recommend the book Crucial Conversations: Tools for Talking When Stakes Are High as a great way to learn how to influence others through civil discourse.  Dale Carnegie’s books (example) are another fantastic resource.

Wrapping Up

Building credibility as a tester is an important part of being successful in your role.  For many testers, having influence on product and feature design is also critical to job satisfaction.  We covered several ways to improve your influence on the team, but there are certainly more.  If you have others not listed here, please share!