Stop Using Passive Voice

As I mentioned in a previous post, testers must learn to communicate efficiently and effectively. Today, I want to focus on a form of communication I see all too often and why you should try to avoid it at all costs.

The term “passive voice” refers to a form of grammar in English where the subject of a sentence is being acted upon rather than doing the acting. For example, “The decision was made to move forward with the current plan” or “The bug was found during the test pass.”  In the first example, “the decision” is the subject, but it’s not clear who made the decision; it was just “made”.  In the second example, “the bug” is the subject, and again… who found it?

Alternatively, an “active voice” sentence is one where the subject is doing the acting: “Sally found the bug during the test pass.”  In the latter, Sally is the subject, and in this sentence there is no question about who found the bug.

Hopefully, you can now see why active voice is the better choice. For one, active voice provides more clarity, whereas passive voice leaves the reader/listener with questions.

Another reason to prefer active voice is that it more directly attributes the result with the “doer”. Passive voice can come across as not taking accountability for a bad result or not properly attributing success to the specific behaviors that led to it. Hopefully you work in a culture that applauds and encourages taking accountability rather than shifting blame to some unseen actor. If you don’t, run.

Luckily, many word processors with grammar checking can help point out usage of passive voice for you. Before you try that, let’s try a quick example. Which sentence do you think is more helpful for knowing what went wrong and how to fix it?  

  1. The tests weren’t included in the test pass because a miscommunication occurred.
  2. Oscar did not execute the tests in the test pass because he misread Rolph’s instructions.

I tried to make it obvious there by including not one, but two passive voice phrases in the first sentence and two active voice phrases in the second. After hearing the first sentence, you might be left wondering who didn’t run the tests, what the miscommunication was, etc. The second sentence makes these points clear, however. Of course, you still need to understand whether Oscar was careless in his reading of the instructions or if Rolph’s instructions were too confusing, but at least you’re one step closer to getting to the bottom of the situation.

As testers, part of our job is to root-cause problems in products and processes. Active voice provides a much more direct way to present a root cause, and that should in turn provide a more direct route to a solution.


Pay attention to communication you receive today and try to count the number of times you hear or see passive voice being used. Pick one or two examples and re-form them in active voice.

If you have any questions on how to rephrase passive to active voice, let me know and I’ll try to help.

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.