I had an amusing experience a few weeks ago. A colleague of mine was explaining how he was automating a regression test set and how it greatly enhanced their testing experience. I believed him, because I know he’s a professional worker with good testing and automating skills.
But I wanted to tease him a bit, as I’ve learned that he sometimes mixes up terminology and definitions.

I asked him: Today, I asked for an extract of a certain table from our database. I visualized it in excel, added some formulas and conditional markup. Next, I sorted on that markup and data errors were immediatley visible.

Was that automated testing or manual testing?

To many people, it’s a confusing question. Hell, it’s even confusing for me.
A better name might be “tool-enabled-checking/testing”. But this doesn’t clarify whether my example is testing or checking.

I noticed that we, testers, see checking and testing as surrogate terminology for automation and manual. This is not completely true, it’s too easy. There’s bound to be a gray area. A twilight zone where testing overflows in checks.

One tests a theory. My theory was that the table I selected might contain errors. I devised a formula in which I could show these mistakes. This is where theoretical testing flows over into the actual checking. The moment I start working in the excel sheet I’m beginning my practical checks. But checking is still a subset of testing. Be they tool-enabled or not, checking has to be done to either, prove or falsify your theories.

There’s a funny ebb and flow kind of feeling to testing and checking as they tend to alternate. While exploring your product you come across new ideas constantly. Further exploring ideas in depth or jumping to the next idea or even exploring ideas within ideas makes the whole concept extremely fluid.

Black on white, in the given example one goes into checking as soon as you start comparing your data to it’s expected result. But while you are doing it, you’re still testing. There is much verification, validation and checking in testing, but it’s the testing itself that’s interesting and which can result in infinitely more important paths to follow.

Be wary, that the above mentioned explainability heuristic does not hold into account false positives and negatives, human epiphanies (oh! That looks weird, let’s take a closer look) and more human errors by the analyst, developer, tester or anyone else whose had a say. It serves to show that “automated” is not the same as checking. It can be used to explain that automated checks are a subset of all possible checks and that all possible checks are a subset of Testing.

We’ve all been done a terrible wrong.

I wasn’t born at the time, but it must’ve been somewhere in the 60’s, when the first ‘software tester’ was named as such.
How did this came about? I can only imagine.
As so many innovations it was probably a scheme to make money where there wasn’t initially any.

From the first tester on, us professionals were branded “Tester” and no finer name exists. Because Testing is such a broad an interesting concept, that it’s really more of an aspiration, a goal than a thing you can fully master.

BUT! Somehow, through time, in people’s perception, the word “testing” degraded. Is it because it is associated with unwelcome surprises? Is it because everyone sometimes does it and can do it? Or maybe testing doesn’t invoke much imagination, digressing in a ‘checking culture’?

Testing is in the same league as “Playing”. A child can play with blocks and dolls, a group can perform a play at a theater. Everyone can do some form of playing. Sure, not everyone can play the piano. Everyone can learn though, if they are willing. Learning, just as testing and playing, is key.
This is an important similarity I would like to make.

Learning and Testing

One can not test, if you are not willing to learn. One can not learn if you don’t test.
They are not exactly the same, but they are immensely congruent.

Testing and learning have virtually the same process.
The chart in this post visualizes Kolb’s Learning Cycle and is part of every teacher’s education.
Everyone, while learning, is considered to go through each of the four stages.
You can begin at any stage, but will eventually complete the cycle. You’ll also spend more time on one or two of the stages as that will be your personal preferred learning style.

I’m more of a do-er, focusing on Concrete Experience. This is how a typical test cycle usually goes for me:

1. Get hands-on experience with the product;
2. While or afterwards create some kind of mindmap of what I experienced;
3. Analyze where and how I could important defects fast;
4. Go back and find those buggers..

See how Testing and Learning go entwined? We could be named ‘Software learner’ or ‘Software player’ just as well. However, neither of those evoke any more awe than ‘tester’ in the general perception.
Personally, while I can’t effectively master testing as a whole, I can learn about it and hope that one day, I’ll be truly worthy of the name “Tester”.

We’ve all been done a terrible wrong.
We’ve been given a job title we can’t possibly fulfill.

“Even if you’re not a teacher, be a teacher”
-Tim Minchin

Teaching, Learning, Mentoring, Listening, Coaching, Advising.
These continuous verb forms are ingrained into the testing field so heavily, it feels as if it is the single most valuable skill a tester should have.

A willingness to learn and to question, is perhaps more valuable than the cliché ‘attention to detail’ which you find on the top of 90% of testing vacancies. This latter has shifted a bit though, to automation.

As a youth, I aimed to become a teacher of English and Informatics to educate teenagers. During the few years I spent training to become a classic teacher, I found myself growing ever so bitter against the current school system. After a few years that kept me tormented over either “pursuing that certificate and walking between the lines” and “Quitting, but facing a life of uncertainty”, I passed a milestone. That milestone being a second consecutive fail.

It felt as if I had lost everything, but freed me up to take matters into my own hands.
That’s when I came into testing.
Where I felt imprisoned in the academic world, I found a second wind in the private business.

Freed from curricula and exams, you can pursue just about anything. Drop it, leave it some months and pick it up again, however you like.

I believe I’ve gotten in contact with many more intelligent people, who are willing to share knowledge, learned more and studied more in a year of working, than my 4 years of higher education.

The choices trap

There are many people who face a lifetime of possibilities. I believe it is a sickness of today, that we raise our children to always keep our options open. I believe in shutting doors. We can’t progress if we can’t find peace in choosing.

A few months ago, a friend asked me to contact his sister, who found herself in the same situation I was in. I haven’t ever seen her, but since last December we had regular contact through mails and skype. I sent her books, gave her exercises and followed her progression, giving feedback on anything she sent my way.

She’s been working as a test consultant for a month now. I was ecstatic! It felt good to give back.

Per Sholas, Speak Easy, Weekend Testing, uTest, Software Testing Club… Are organizations that are focused on teaching and learning both, specifically for software testing.

Whether you find yourself in the same situation, you can reach out and you will be helped. It helps when you try to produce literate sentences and expect only as much time from others, as you put in yourself.

If you wish to enter the Testing craft, but doubt you’ll like it/have the qualifications/need help with a job interview, don’t hesitate to contact me.
You don’t need paper to prove your intelligence, you need only demonstrate it.