by Kate Paulk

We've all heard it: you tell someone you test software and if you're not testing games, you'll get, "Oh, that must be so boring."

Well, no. It's not. Like any profession some parts are less interesting than others, but on the whole, testing is interesting and fun. Here are some of the reasons why.

1. No Two Days Are Ever The Same

I've been testing for 14 years, and I've yet to see two consecutive work days where I'm doing the same thing. Maybe I'm just lucky, but it's my experience that a tester who isn't stuck in an "any warm body can test" shop is going to be doing different things a lot - one day I might be spending most of my time exploring a new feature; the next I can be working to reproduce a customer-reported issue. In the last week, I've run and analyzed performance tests, explored new feature developments, worked with the product owner to find an acceptable, low-impact way to implement a stakeholder request, analyzed database records to help troubleshoot a problem, tested bug fixes, tested new report implementations… And that's just a partial list.

2. Constantly Learning The Craft

Testing is not one of those fields where you can learn everything. Or even a significant fraction of everything (or an insignificant fraction, come to think of it. What is a meaningful fraction of infinity?). Every project is different, even if you know the software you're working with very well. Every project brings new challenges and new information.

Some of the things I've learned in the last few months include better ways to look for security problems in code (and I'm not a security tester), how to set up and run a distributed load test (and how to interpret load test results), how to set up and run automated builds, how to use Powershell scriptlets to find information I need about a system… and more.

Some of the things I'm always working to improve are how to communicate better with my team so we don't wind up talking past each other, more effective ways to find the gaps between assumptions where bugs tend to lurk, better ways to document what I find, and better ways to test.

Two of the major enhancements I've worked on in the last year or so have brought new challenges: the big UI enhancement meant learning to be more efficient with cross-browser checks as well as cross-testing against the old code (and learning what could and couldn't be done with the new UI components - this in itself was a learning experience). The project to start unifying the multiple related applications we support meant learning some basic security testing techniques because unifying the applications also meant connecting different logins and different security systems. And how to build and run a distributed load test. And…

The principles of testing don't change but the context in which they're applied certainly does.

3. You Get To Let Your Inner Small Child Play

Remember when you were a kid and you'd build sandcastles at the beach? Half the fun was smashing the sandcastle when you were done and watching the way the sand scattered. Testers get to learn new and interesting ways to expose vulnerable parts of the application. Every day. All the time. We're always poking our fingers into dark places where assumptions don't match with reality and finding out what happens when we do something nobody expected.

The monkey test can be fun, too, throwing random stuff at a system to see what happens and clicking wildly at anything that looks like it might be possibly clickable. I've lost count of the number of double-click bugs I've found in websites where you get data corruption because you can click on something twice.

4. Your Inner Snark Gets A Totally Justified Outlet, Too

Most of us work in close collaboration with our developers, and we try really hard to maintain a good working relationship.  After all, we all have the same end goal of making our applications as good as possible.

That said, it's a human thing to take a certain amount of somewhat guilty pleasure when someone suffers for their misdeeds. The Germans even have a word for it: schadenfreude. For example, I had to deal with the fallout from a disastrous release pushed on the entire team by upper management setting a deadline and refusing to be moved despite being told it wasn't possible. There was definitely a good bit of schadenfreude in hearing about the avalanche of customer displeasure upper management received, despite the extra work and frustration the team suffered.

5. You Get To Do Detective Work

Any time you explore a new application or new functionality, you're acting as a detective. You know there are bugs hiding in there because any non-trivial software has bugs. You just have to find them, and that can be easier said than done.

Even before you look at the software, you're looking for clues about risks exposed by the new feature or application. You're reading user stories (or use cases, or functional specifications) and looking for the assumptions being made.  They are assumptions about how the system behaves, about how users will behave, about the interactions between features, even about how other teams will act.

Part of our role is to locate the risks of mismatched or incorrect assumptions and get everyone working from the same set of assumptions to minimize the likelihood that the risks exposed and implied by the documentation will become reality.

Then, when we test, we draw on our experience, our knowledge of the software, and our knowledge of the places bugs tend to hide. It's so satisfying when our intuition proves correct and we find them.

6. You Can Also Role Play

Okay, maybe your company would look askance at you changing costumes for your testing personas, but you have to admit, you can have a lot of fun playing "Evil Hacker Doodz" and trying to hack your company's software. Or playing the CEO's 3 year old granddaughter who's hitting the keys to watch stuff happening. Or….

The list of personas you can use for testing is endless. It only starts with the ones the software and documentation imply. Like the new user trying to register, or the administrator wanting to know how many orders were made in the last 7 days. Then there are the implied personas. The power user who's worked with the application for years and uses all the keyboard shortcuts; the long-term user with a touch screen who rarely looks at the screen because they know where all the features are and just automatically taps the right place until someone moves the hotspot for that function; the grandmother who's a bit intimidated by all this fancy computer stuff but really wants to buy her granddaughter that wonderful new product.

Personas are wonderful. They help extend the scope of our testing, and they're as flexible and extensive as our imagination allows.

7. When Errors Rise

Errors will happen - it's what comes after that can be fun. First up is reproducing the error, then tracking and collecting the evidence it leaves behind. That can involve logs, databases, screenshots, videos… If you can refine the steps to reproduce, you'll do that, too - and this is just the beginning. At this stage you're the ranger in your adventuring party, following the trail to the dragon… ahem… bug.

Of course, it takes a team to kill a dragon. A tester's role is like the ranger in the gaming party: we track it down and lead the rest of the team to its lair, where the paladins and barbarians (and whatever other fighting types are on the team) do their part to put an end to the dragon-bug. The wizard protects the team while they fight and the healer cleans up any damage. Once the dragon-bug is dead, the whole team shares the spoils.

Yes, the analogy is a little strained, but the point is that it takes the whole team to track down and fix problems. Our part is finding them - which usually involves making them happen, sometimes a lot of times before we have the evidence we need to help our developers find the cause of the problem.

This means that yes, it's totally fine for testers to be happy when we do something that sends the software in testing into fits. After all, it's our job to find places where the software doesn't work so well. Finding some and making your test system spawn endless errors is more or less expected.

8. Research Is Fun

It's not just looking for reasons why you're seeing something your developers can't reproduce, it's learning more about the software you test and the reasons why your developers made the choices they made. It’s about learning more, period.

Just as an example, some of the things I've found myself researching in the last few days include bugs reported against Firefox, Chrome, Internet Explorer, and Safari; accepted security practises on allowing users to save passwords in their browsers; ways to configure Microsoft's load tests to emulate a user load of several thousand users per hour; Windows XP support for specific encryption algorithms; how many users of our software still use Windows XP as part of a proposal to formally cut off support;  and that's just a small sampling.

I've also found myself researching various settings for Microsoft's Internet Information Services; how to get a snapshot of IIS configuration to compare server configurations; how to poll a massive directory, so big that just browsing it or using an unfiltered file listing from a command prompt will crash the server; ways to write better queries to pull the data I need from the database; not to mention a once-a-quarter survey of said data to determine which operating systems and browsers our users prefer, and collating that information into a nice simple report.

Learning all of these different things are fun, and you never know when you'll need to start researching an idea, issue, or statistic.

9. It Matters To Everyone Involved

You're working behind the scenes to improve people's lives. No matter what kind of software is being tested, every problem that gets fixed before the changes go live has an effect on your customers. Sometimes the effect is that they don't get irritated by game-breaking bugs so your employer earns more. Sometimes it's preventing an issue  that could kill someone like in the case of medical device software, or aviation software.

10. We're Good-Guy Ninjas

Seriously. We're doing skilled work that's only visible if something goes wrong. Our contribution to software in an ideal world is completely hidden. Unnoticeable. Nobody is ever going to talk about how well that application was tested, only how well it was written.

We did that. Our work to find as many missed assumptions and issues as we can before the software goes live means that our customers have a better experience when they first use that application. There are fewer bugs escaping because different perspectives which look at a feature are more likely to catch an issue. The defects that are released are better documented. We've prioritized the things we found and advocated for those that need to be fixed before release. All of this exploration and communication is invisible to our customers, but the improved experience they get as a result is invaluable.

Testers are the conscience of a company, helping them to produce better software. Maybe it's not always comfortable when the conscience is speaking, but it's always worth listening. Every tester I've met takes a lot of satisfaction from knowing their contribution exists even if it's invisible to their organization or the public.

No, Testing Isn't Boring

There are aspects of testing that can be tedious and repetitious, but mostly it's interesting and fulfilling. There are dedicated testing communities like those here at the Ministry of Testing and its sister sites The Dojo and The Club. There are informational forums like SQA Stack Exchange, Slack channels like Testers.io and the Ministry's channel. There are several conferences such as TestBash, tester Meetups and more. If you're looking for some support and help to learn, these many communities, conferences, and meetups are the perfect place to start.

References

Software Testing - It's just so dull (James Willett's blog)

Do test engineers easily become bored (Quora question)

The Plague of Boredom (Google Testing Blog)

Software Testers - Invisible Ghosts in the Code

About Kate Paulk

Kate refers to herself as a chaos magnet, because if software is going to go wrong, it will go wrong for her. She stumbles over edge cases without trying, accidentally summons demonic entities, and is a shameless geek girl of the science fiction and fantasy variety, with a strange sense of humor. In what she ironically refers to as her free time, she writes. Novels, short stories, and more recently, articles for the Dojo.