This is the second of a couple of “The core of X” -articles that give you -my- ideas on what I think of X. The attempt is to cut away all that surrounds the term and show its core for what it truly is. The essence of it all.
Take from it what you will, love it or leave it. In any case, I would invite you to share what goes around in your head and what you feel while reading. Feel free to correct me or engage in discussion. We’re here to learn.

There’s Always Testing

Independent Test Teams, Dogfooding, Bugbashes, agile Testers, Test Jumpers,… or testing by any other name. There’s always some testing going on in a software project. It might even not be called testing, but it’s there.
It’s in those moments of critical thinking just before someone says “hey now, wouldn’t that shortcut our registration process?” or “Woah, I never thought about it in that way.”

When one ‘thing’: a piece of code, a requirement, a document,… is changed and passed from one person to another: that’s an opportunity for doing testing.
This isn’t always done by a professional tester. Au contraire.
Whether it’s a formalized or accidental process, there’s people jumping in and out of “The Testing Role”. Adding value because of it.

“Everyone tests, but it’s a skill not many professionals care to practice.”

The Core of the Testing Role = Mindset + Skills + Attitude

Be you a tester, developer, analyst, schoolboy or astronaut, to take up the Testing Role effectively, you need to be aware of these three different aspects.

Mindset

Most professionals are focused on Building. Adding, accelerating, stabilizing and all that improvement goodness. At one point or another, these professionals will need to test each other’s improvements. Having that builder’s mindset while doing so is a lousy way to go about it. It’s the equivalent of a mom cheering on her son on the football field:

You want to see them succeed. Confirmation bias and inattentional blindness play their part: Your feedback will be limited.

A tester’s mindset is often seen as a negative or destructive way of thinking. It’s focused on Risk. What can go wrong? How can this be abused? What haven’t we thought of?

It’s about thinking differently. It’s about being engaged with the product with the intent of finding problems.

Getting that mindset consistently right is probably the most important part of this role, yet also the easiest to discard. The path of least resistance doesn’t lead here. It goes everywhere but here, with a rather sharp turn.

It’s a Skill

There’s a lot of different skills involved in testing.

• Critical thinking
• Systems thinking
• Modeling
• Risk Analysis
• Quick learning
• One’s own expectations management
• Inter- and intrapersonal skills.
• Technical insight
• …

Just like any other craft, it might look easy for the unwitting and unpracticed. To become a master though, it takes hours, days of mindful practice.

Attitude

Attitude, to me, is the defining characteristic for a tester.

• It makes you speak up in planning meetings to go against popular opinion.
• It has you fighting for a bugfix you think is important.
• It gives you fresh ideas to go through the same high-risk functionality over and over.
• It helps you be different in a world where sameness is worshiped.

Just like Mindset, which is about thinking differently, Attitude is too easily dismissed as part of the Testing Role. Being adamant about quality can be perceived as difficult or not-a-team-player behaviour. I’ve worked with many people who don’t want to bother learning about testing for those exact reasons. It doesn’t make you popular.

Recap

Anyone can take up the Testing Role. Whatever else you do, it takes these three things to be successful at it:

Mindset – Thinking differently when looking at solutions and problems.
Skills – Have the tools to analyse, find, plan for and report risks and issues.
Attitude – The resolve to be consistently different and defend underrepresented notions.

Doing that context switch isn’t easy, isn’t evident and takes practice.
While many people do this role & mindset switch daily, most of the time it is lacking. Practice, investigate and learn how to do it well.

This is the first of a couple of “The core of X” -articles that give you -my- ideas on what I think of X. Take from it what you will, love it or take offence. In any case, I would love to hear about what goes around in your head and what you feel while reading. Feel free to correct me or engage in discussion. We’re here to learn.

First things first: Language. For this blogpost, when I say Automation I mean a set of Anti-regression checks. Whether they’re on the Unit, Integration, API, UI,… any level, they’re all the same here. There’s usefulness in dividing them by purpose, use or whatever, but it’s not here. I use ‘checks’ where you may expect ‘tests’. That’s fine. The important thing is the point, all else is for a different time.
Behold, das Point:

The core purpose of Automation is NOT about
finding bugs, saving time, getting to market faster or bringing value faster.
It’s about
Stability and Reliability.

Now don’t get me wrong. The red stuff is greatly helped by what’s in green, but it is not and should not be the main focus.

Should your project not care about Stability and Reliability and only about going to market faster or saving time, you can just as well not write any checks.
If you want to find as many bugs as possible, automation is a rather inefficient way of looking for them.

Your checks are about minimizing the risk that comes from working with multiple people on the same thing. Because… inevitably, someone will make an error. That’s human nature. Ideally, you want your Regression Harness (or Automation Check Suite) to warn you of that error. This way, when a team has a good set of checks, it’ll keep a personal “oopsie-doozie” from becoming a whole-team “WHO THE HELL BROKE OUR STUFF AGAIN?!”.

When you engage in any form of automated checking, know that your focus should be on Reliability and Stability. It will lead you down the good path. The one of continuous integration, saving time, having to do less firefighting and having more control as a team.

I’ve seen people talk about metrics of automation and mention: number of bugs found, time saved, number of deploys per day, number of checks ran,…
These are rather unhelpful.
As a Team member, when it comes to metrics, I’d love to outweigh:

Time lost fighting instability + Energy wasted on firefighting + motivation loss while investigating problems + friction between team members
VS.
Time invested in building a regression harness + problems still occurring after the effort + Effect on team-cohesion and sense of purpose.

Hard to do, right? Though it could be better worded, that’s the only metric that counts for me.
(Though I might be interested in the other metrics sometimes, those moments are rather circumstantial)
Notice, though, the difference of mindset of investigating problems as individuals and building a solution as a team.

But… where does Testing fit into that strategy? In my opinion: Not necessarily.

While Testing can certainly help come up with interesting ideas on improving your check harness, it doesn’t have to be part of it. However:

The information that Testing provides from looking for unexpected, extreme and abusing behaviour can greatly support your automation.

I do believe that Testers should make the occasional step into this territory, just as much as I encourage anyone to make frequent and valuable role-switches. Yet the main focus of the Tester role is on providing valuable information that might have been overlooked, the team was unprotected against or misunderstood.
Make no mistake, if your product is rather complex there’ll be things missed, erred and overlooked.

Also… I’ve yet to meet a tester who didn’t think her project or business is simple.

TL;DR:  Regression checking automation is about Stability and Reliability. When done well and consciously, the result can evolve to be: Less bugs, time saved firefighting & problem-solving, going to market faster and adding value faster. A Tester isn’t necessarily an agent in this process, but the information she provides can be invaluable.

We all need stability. Sometimes more than other times.