It’s time to stop undervaluing QA testers—here’s why

After I graduated with a degree in computer information systems, I surprised people by accepting a job as a QA tester. People said I was selling myself short, that the testers don’t have degrees, and I should have taken a job programming. But I liked the idea that QA testing combined business and technical knowledge and made sure software enhancements would work well for end users.

QA testing isn’t seen as a glamorous role like programming, but there are opportunities for advancement, and the influence you can have on projects is massive. If you’re feeling undervalued as a tester, here are some things to keep in mind.

Software testers find all the wrong answers

When people implied that programming was “harder” than testing, I don’t think they understood what I did all day. Did they envision I clicked a few buttons, saw everything worked perfectly, marked a project complete, and left two hours early?

What software testers actually do is craft a test plan that contains every scenario they can think of. Pretend you’re testing a new input box for a birthdate. Easy, right? Just enter a birthdate, and make sure it saves.

Easy, sure, if you know the exact input the system requires, and the program is properly coded. But what about the following scenarios? Here’s what I might test for a user born on February 1, 1982, with the last name of Smith.

• Can the user enter 2/1/1982, without two-digit months?

• Is the date saved as February 1 or January 2?

• Does 02/01/82 save as 1982 or 2082?

• What if the user enters today’s date?

• What if the user types Smith because they tabbed to the wrong field?

Software testers know the “wrong answers” aren’t always wrong

So maybe you can think of all of the birthday examples, or you’ve seen them all before. But you need to think beyond your experiences and learn how to find valid inputs the programmers may not have considered. You’ve tested the birthdate, and now you’re at the name field(s). Considering the followings names:

• e.e. cummings (all lowercase letters, punctuation in the name, no middle name)

• Michael D’Angelo (apostrophe, multiple uppercase letters, alphabetization)

• ‘Alim Ruhi Shil Chaira (apostrophe at start of name, possibility of two middle names or last name having two words)

• Madonna (one-word name)

• 岸田 文雄 (non-Latin characterset)

Testers also act as different users. Some users may have view-only permissions for a page, others can edit a page but need publishing approval from someone else, others could delete a page, and still others might not even be able to view a page. And those are only some of the options for a very basic operation of one webpage; to give you all of the testing scenarios in a large project, I’d need to write an entire book.

Software testers juggle a lot of projects at once

A good software tester needs to work well under pressure and juggle many projects. When preparing for a release, testers are testing multiple projects that are going back and forth between QA and programming as fixes are made. A lot of projects get to QA close to release time, and testers are making decisions as to which project to start on first to get everything done on time.

Besides testing, they can be working with the technical documentation team to get them information they need to document a project, answering questions from programmers about requested fixes, and coordinating user acceptance testing with end users.

It’s a lot less structured than you might imagine, and it requires a lot of flexibility.

Software testers need a lot of patience

I’ve heard it said programmers have to be very patient because they spend time debugging stuff like a case-sensitive typo causing their program to not compile. It’s true.

Now imagine how much patience QA testers need.

Testers will encounter programmers who send over projects with a lot of bugs, sometimes the same exact ones for every project. A common one I would encounter was programmers not initializing their variables. There were a few times in my career I thought if I saw one more project where I ran a search that should have returned no results but instead returned my previous results because variables weren’t cleared out, it was going to be the day I left for lunch and never came back. 

But it’s not just people that testers have to be patient with—it’s also the nature of the projects. You never know when a bug fix will break something else that was already working, so you have to be ready to test the same thing over and over again, knowing that you might find a new issue each time.

Software testers need to be good communicators

If it’s the seventeenth time a programmer hasn’t initialized their variables, you have my permission to suggest they add a Post-it note to their computer reminding them. But otherwise, testers need to be tactful in their feedback—nobody wants to hear that a project they worked hard on has issues. 

Being detailed and thorough in reports can help with this delivery. Example:

• Good feedback: “Entering a two-digit year in the birthdate field of the signup page of the member application form rev 2.3 results in a dialog box that states “invalid input” and erases all the data on the page.”

• Bad feedback: “The birthdate feature is still broken.”

Seriously, though, if a project is working really well and just needs a few minor fixes, also include a note with your feedback telling the programmer things are looking good on it. If there’s something you really like about how they designed a webpage or made it user-friendly, tell them! Don’t just be the bearer of bad news.

A background in programming can help

You don’t need to have in-depth programming skills to be a QA tester, but it sure does help. For example:

• Querying databases. Does the generated report match the data in the system? Do the search results seem valid?

• Script creation. Automated testing products do allow users to record test scripts, but if you can write or edit the script code yourself, you can customize the scripts for your situation.

Software testing isn’t a “lite” version of programming—it’s a completely different role and requires completely different skills. QA was a rewarding career choice for me, and if you have the skills I talked about here (and you like what you do!), it’s worth sticking around.