Keep Testing Weird

I’m at SauceCon 2019 in Austin, Texas which is a test automation conference put on by my employer, Sauce Labs.

The theme for the conference is “Keep Testin’ Weird” — a play on the city’s slogan “Keep Austin Weird”.

So I thought to myself, what’s weird about testing? It didn’t take long to come up with a long list. Testing is weird, and I’d love to hear all the weird stories everyone else has about testing.

Besides all the weird things that happen while testing — testing itself is pretty weird.

If you’re a software tester, you realize this the moment you’re asked to describe what you do for a living that it’s not like other professions. Personally, I’ve taken to just telling people “I work with computers” — and see how far down the rabbit hole they actually want to go. Which is a weird thing to do, but I guess I’m a little weird myself.

You kinda have to be weird to go into testing — or at least to stay at it very long. And not just because of all the weird stuff you encounter.

First of all, I don’t know anyone who ever deliberately went into testing. At least not until recently. It wasn’t really a known career path, and even for those who knew about it, testing wasn’t really highly regarded.

The act of testing itself is kinda weird. You’re not actually creating anything, but you have to be creative to be an effective tester. In fact, one of the qualities that make someone a good tester is that they like to break things. Testing is destructive — you have to destroy the product to save it. The greatest delight of a true tester is to find a truly catastrophic bug that is triggered in a really weird way.

You have to be a bit off to take pleasure in telling people that for all their hard work, it’s still not right. Testing is critical. Your job is to be, not just the bearer of bad news, but to actively go out looking for it, and since you have to justify your job, hoping to find it.

You have to be a bit immune to social criticism to be able to do so day after day. That means you probably don’t mind being weird.

Finding bugs is hard, especially when you’re handed this black box and you’re not only supposed to figure out how it works, but how it doesn’t. It takes a certain kind of perverse creativity to even come up with ways to test things effectively.

When you report a bug that can only happen under strange esoteric circumstances, it’s often dismissed as irrelevant and how that would never happen under real world conditions. But the real world is weird, and it’s just those types of weird issues that developers and designers don’t anticipate, that happen in production, and cut across layers to expose fundamental flaws or weaknesses in systems.

That you need to justify testing is really weird. Testing improves quality, and quality is the primary source of value, but testing isn’t considered valuable. Testing is often left out or cut short. And always being under-budgeted and under-resourced with inadequate time.

Testers have to have a varied skillset. You have to test things that you don’t understand. And you’re expected to find bugs and verify requirements. Without knowing the code, without understanding the requirements, and in many cases, without the practical experience of being an end user of the product you’re testing.

You’re not a developer, but you have to understand code. You’re not a product designer, but you have to understand the design and requirements in more depth than perhaps anyone else. You’re probably going to need to know not only how to test software, but how to build and deploy it.

How do you know when your job as a tester is done? Have you ever tried to define done? There’s development done, feature complete, deployed… But then there’s monitoring and maintenance, bug fixing and new features. Maybe you’re only really “done” when software has been deprecated and abandoned.

Is testing ever done? At some point you just have to draw a line and call it good enough. You can’t prove a negative, but your job is to declare a negative — this works with no issues — with a certain degree of certainty.

Test automation is weird. Writing automated tests while software is under development is like building the train as it’s running down the track, while the track is being laid — and testing that it works while it’s doing so.

Automation is meant to do the same thing over and over again, but why is it that test automation is so much harder to maintain than production code?

Automation code is throwaway code, but one of the greatest values comes when you can change the production code out from underneath it and the automation still passes — which means that the software isn’t broken. So you write test code to find bugs, but it actively prevents bugs from happening. That’s weird.

There is a lot more weirdness around testing and test automation but like any good tester knows, when you’re writing or speaking, you have to know when to stop, so I’ll end it here.

But I want to hear from you all. I’d like to ask you to share your thoughts and experiences about why testing is weird, what weirdness have you seen while testing, and what can we all do to keep testing weird?