Postmortem: So you want to be a Tester?
I got a comment from Reichart Von Wolfsheild about my recent post, a couple of weeks ago:
Write a follow up to this that gives REAL WORLD examples (perhaps several) of each of your points. Post Mortems.
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:
- Find a Software Testing job. Doesn’t matter if it’s at a crappy company. You can change companies later. The end goal is to put oneself in the path.
- Sharpen coding skills so we have better prospects. This was (and is) a given, that being a technical/coding tester pays better in the long term.
- Avoid waste time helping folks, or getting help, on a 1-to-1 basis. If we need help or are helping people, we should do it on to a 1-to-many setup. Learn to leverage tools like StackOverflow, search engines, blog posts, etc.
- Study testing. Get a hold of the community, the concepts, the different schools of testing, the tools, …
- Test stuff. Be very deliberate and practical when studying testing: through actual testing. Few professional Testers do.
- Nothing is going to be easy. Folks will ignore us. We will feel like we are the bottleneck. We’ll have to deal with toxic people and workplaces. We’ll not get proper recognition, …
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:
- Any testing frameworks we work with,
- Any rules and guiding principles that orient our testing,
- The tech stack of the product we are testing,
- Any number of esoteric programming languages and libraries we might dominate,
- Any amount of technical resources
- …
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:
- Dealing with all sorts of virtual constructs that come with working with others.
- Withstanding blind and incompetent leadership.
- Doing a poor job as a leader ourselves.
- Conflicts of power and interest.
- Discrepancies in expectations.
- Becoming overconfident to the point of missing bugs.
- …
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:
- Try to be a decent person,
- Try to be a craftsman tester and
- Let our own work and actions speak for themselves.
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:
- You can become an expert non-technical tester, that can steer testing efforts on any kind of system
- You can become an expert technical/coding tester, that steer test engineering efforts in projects
- You can become a tool builder, enabling and supercharging any kind of technical and non-technical folks in their different test missions
- You can switch from the individual contributor path over to the test manager path, and steer and guide testers and test engineers, and handle the logistical side of building good test teams
- You might want to do a bit of everything and wear more than one hat in teams and projects that don’t require a lot of people
- You might want to become a teacher or a consultant, helping folks improve their testing techniques …
- …
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.
- Waiting for a company where they will finally have an excuse to put on a different hat.
- Waiting for some promises that their current company did. Next quarter they can spend a percentage of time wearing a different hat, as long as it doesn’t impact wearing the current hat.
- Waiting for a better time to learn about how to do some specific kind of testing, because they heard it’s complicated.
- …
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:
- Focus on enabling other testers, through better and more accessible tools is one of the most impactful things we can do throughout our career, more so than trying to change the guiding principles imposed by other testers in an organization.
- In hardcore scenarios: Nimbleness and being extremely comfortable in confusion and failing is a bit more useful over memorizing a ton of technical knowledge.
- Don’t over-romanticize business relationships. A job is just a job. Most companies can’t afford to care about people, so they play a game where they say they do.
- Learn to let go and step away from situations that are destroying you and/or others, or where you are being taken advantage of. This is easier said than done, and I guess it’s something that time helps sharpen a bit.
- …
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 ☕