Postmortem: So you want to be a Tester?

postmortem, career, testing, and quality
a movie still from Bean, 1997
Bean, 1997

I got a comment from Reichart Von Wolfsheild about my recent post, a couple of weeks ago:

  1. Write a follow up to this that gives REAL WORLD examples (perhaps several) of each of your points. Post Mortems.

  2. Look back at other systems (i.e. Six Sigma) and why and how they failed, and for that matter, what we carry forward from them. If a given system is so good, why does any company fail to use it? (…)

From this feedback I started writing drafts for two new posts.

Like with most of the things I start: I got distracted and lost interest. One thing kept creeping back into my mind:

what if I tried to do a postmortem of one of my own early systems / proposals from years ago?

I started going through my old blog posts, and one of them peeked my interest: my “So you want to be a Tester?” post from Mid-April 2018.

What was the blog post about?

I wrote the original post years ago, after some folks reached out to me for advice on how to get into the Testing craft.

In it I attempt to give folks six key pieces of advice:

At the end I wrap up with the same thoughts folks might find in a lot of my writings and those of other context-driven testers:

You don’t add quality, assure anything, break stuff, create (or prevent) bugs. There’s only one truth: You hunt for (meaningful) bugs.

What helped

Looking back at the post, most points were helpful, but not applicable for everyone.

It did help that I had an internship at one point doing Testing/Test Engineering work. I met people that I remember to this day. I learned a lot. The pay was a third of Portugal’s minimum wage at the time. Would I recommend folks to take that kind of internship nowadays? Nope, and screw companies that do that. It was a start. It served as a means to an end.

Investing in any sort of programming skills was on target. The market might have had a lot of demand for non-coding testers 7 years ago. There has been a total shift since then. Tech orgs everywhere have been scrambling to find test engineers.

Likewise, Investing in knowledge transfer to others in a 1-to-many setup was on target. Leaning towards meaningful and accessible documentation and note-taking is a win-win stance, and hasn’t failed me once. Alternatively: the few cases where I relied first (and only) on implicit 1-to-1 synchronous knowledge transfer almost always resulted in chaos and added stress.

Studying testing and test engineering, and practicing meaningful testing, should have been the first things to invest way back in 2015.

I only started to invest in these a few years after that. The turning point was after taking my first Rapid Software Testing course. It propelled my will to be a better tester and helped my credibility and self-confidence a lot over time. Until then, some people would tell me I was incompetent, and they were right at the time.

The last piece of advice on expecting to deal with unfairness applies to this day. The hardships and pain points might change. The things that cause unfairness might change. The people we deal with will change. Sometimes we’ll need to outsmart assholes. Sometimes we’re the asshole and we don’t recognize it.

What failed or was missing

For all the success, help and good intentions and the ideas of my old post, there was also lot of failure. There are things that I didn’t understand and wasn’t prepared for. There are things that I missed.

1) People’s influence in our path is always underestimated

To quote one of the sayings of the late Jerry Weinberg:

No matter what the problem is, it’s always a people problem.

This is one key idea that I completely failed to tackle in the original post.

The people, systems and rules we surround ourselves with always affect us. They may predict how good a Tester we grow into. They can influence how satisfied we’ll feel over time.

We can take:

And we would still barely scratch the surface of the actual impact people have on our craftsmanship. This is something I didn’t account for in my post.

Every problem and crossroads we face spawns from people, both ourselves and others. For example:

2) Take into account work/employment context

Like to the point above, our workplace surroundings and employment affect our path.

The mood of early 2010s pre-unicorn Portuguese “tech” companies was weird. To paint a picture:

“Dress the shirt”“We are looking for Junior Rockstar Ninjas with 100 years XP in jQuery”“Strategic government co-paid 12 month IEFP tactical internships”“Unpaid internships for the exposure and skillz”“We need to be more Agile”“MORE AGILE!” … …

Some companies portrayed themselves as traditional, slowly adding commodities and easing rules. Others picked up on the idea of turning the workplace into a kindergarten for adults:

We are young and rebel. Our office has trinkets, food, games, drinks, commodities, skateboard back-flip lessons, etc.. We are structureless and leaderless. Read our cool office culture values and manifesto! Come build epic shit with us.

Both types of companies would encourage: Crunch; Being idealistic; Acquiring more responsibilities for the same pay; Paying back “freedoms and commodities” through blind/aggressive loyalty; …

The above would trickle down to Testers in weirder ways. In most places both Testers and Test engineers were (and some still are) viewed as second-class citizens, e.g. inept for being “proper” programmers and/or lacking management and product skills to change from an individual contributor path to a management path.

All of this which brings me to my first amendment to the original post:

Force yourself to undergo different contexts and environments.

In other words:

If possible search for a job in another geographical market. Don’t keep shooting towards your local market. Try to be a tester/test engineer in different countries, be it working remotely or through relocating.

In my personal case, having had the chance to work with people from completely different cultures and countries had many great benefits. Too many to list on this post.

3) Don’t fall into someone else’s school of testing tribalism

Don’t go into holy wars. Don’t waste time debating and campaigning for the software testing beliefs of others. In the limit: start your own tribe, create your own space. This is a new addition to the original post.

If there’s any beliefs, models or systems we should defend, and perfect through time, it’s the ones we, and those close to us, adopt as our own.

Things we should always do, regardless of our internal models:

4) Specialize in something sooner

I didn’t account in my old post for the fact that different people want different end-goals within the Testing craft itself, not even taking into account folks that want to use Testing as a means to jumping to another craft, which I think is fair.

There are a ton of paths one can take as a tester:

Each of these paths is important. Each is complex in its own right, and has its own learning paths. I didn’t account for these paths years ago in my old post. Bits of it might have helped beginner testers, but would serve little purpose for folks sitting at crossroads, not sure in what to specialize in.

5) Don’t wait around for change to happen

Some folks will tell others:

Don’t throw yourself blindly at your passion and dreams.

Others will say the opposite. I say: do what you can, but don’t wait around. Don’t deposit your full trust in waiting around for others to do what is right for you in the long-term.

I lost count of the number of fellow testers and friends that are just waiting.

Here’s the thing though: Avoiding to make decisions, is a decision in itself.

This attitude, of not trying to be clear about what we want, and then not pursuing or at least not trying to find out, is something we should avoid, sooner rather than later.

Wrapping up

There’s more stuff I would like to go over, but this postmortem is long as it is, so I’ll just scribble what’s on my mind, and who knows, maybe in the future I’ll go in detail in some of these points. Here’s a few practical points I missed from the original:


If you read this far, thank you. Feel free to reach out to me with comments, ideas, grammar errors, and suggestions via any of my social media. Until next time, stay safe, take care! If you are up for it, you can also buy me a coffee ☕