Reading Time: 5 minutes

In case I never stated it clearly enough on the pages of my blog, because I am normally saying this when I speak at  conferences – I absolutely disagree with the existence and the usefulness of the term “manual testing”. I truly believe testing has never been manual, nor it will ever become. I am ready to go further – I will challenge anyone defending the usefulness of the term manual testing to share why does he or she thinks manual testing actually helps describing testing better. Here are my thoughts.

Hand diagram - manual testing
Free licence image from

What’s the problem with manual testing?

The first problem I see with the term is that testing was never manual. Testing was never an activity which included executing action in repeatable, excluding thinking, simplistic manner just like someone working on a production line where same actions are performed over and over and over again. Testing is referred to as “manual testing” mainly from tool vendors who want to make it look dumb, so they can sell you tools to make it easier (both claims are lies), people who are not involved in testing or people who don’t really care what they talk.

The other problem that I see related to this is people trying to “fit” in the description “manual testing” and trying to perform testing in a unified unnecessarily formal way so they fit into the label they were given. I think I wrote something about it in the article The non-manual, unautomated tester, not too long ago.

Why “manual testing” is invalid term?

Testing can never be simply manual. The reason for this is – it includes way too much thinking and brain work. If I have to paraphrase a famous saying – if 100 “monkeys” tap on keyboards and click around your product for 100 years, they won’t produce high quality testing service, no matter what low-cost, outsourcing companies claim.

See also  State of testing 2016 survey is LIVE

Testing includes a lot of thinking and brain work, such as, but not limited to:

  • Modeling – the ability to “imagine” what the product is like and how its inner workings are arranged
  • Critical thinking – the ability to construct theories about the product and challenge them to prove them wrong.
  • Social knowledge – software is not simply code, it’s something serving to human beings as a bridge, so it has to work in specific social context.
  • Risk mitigation – thinking about what can fuck up, before it’s too late.
  • Cognitive psychology knowledge – knowing your own thinking patterns and how they can fool you, knowledge of bias.
  • Metacognition – or thinking about your thinking, playing the spectator role on your own approach strategy or thinking, so you evaluate the efficiency of your own methods.
  • Logic – being able to derive conclusions from clues using deductive, inductive and abductive reasoning.
  • Epistemology – explaining yourself – how to you know what you know, how are you sure a statement about software is true, how do you know software has to work in a certain way?
  • Creative thinking – the ability to produce new ways and strategies to expose problems

Now, don’t worry, you mostly use these without even knowing they are called like this or that they exist. Terms are put there just to help explain what we do.
Note: If you want a deeper dive in these, please refer to the “What software testing is…” series on my blog. I know they are not complete, but they will be, soon.

What I really want to emphasize here is sort of black swan conclusion – the fact that you never seen black swan doesn’t mean there are no black swans, therefore the fact that the mass of testing resources don’t speak about thinking in testing, doesn’t necessarily mean there’s no thinking in testing or that we can label it “manual testing”.

See also  QAshido – The path of the tester. Virtue # 1 - Technical skills.

So, testing is an activity related to thinking and cognition, if you want to refer to a body part to describe it, call it “brainial testing”. Sounds ridiculous, isn’t it? Now revisit the term “manual testing” and tell me how does that make any sense, ffs!?

Why people like the term “manual testing”?

If I have to be brutally honest, I will cite this article from Scott Berkun:

People love easy, binary models for things and take pride in basing our primitive notions on the pretense of science.

And this is why the manual/automation bullshit lived for so long, for the only reason that testers prefer to have the simple, but wrong binary division, instead of diving into thinking and come up with a better answer.

What people really mean when saying “manual testing”?

According to my observations, when most testers speak of “manual testing” they normally mean “testing performed in a non-programmatic way” or in other words – testing in which we don’t write code to perform the testing, but do it ourselves. Anyway that doesn’t turn testing into manual activity, so I’d suggest to repair this “defect” and call it “human testing”, rather than manual. I think it gives a little bit more clarity to the term and what is involved in it.

Calling “manual testing” exploratory, doesn’t really help.

This is something that I mostly see among people involved in coded testing e.g. automators, but I see it spreading.

Whenever someone is showing the automation pyramid (which I will address in my Hindsight automation lessons, soon) they normally show that “cloud” on the top and refer to it as “exploratory testing”. When I go to conferences and see companies present, they again speak of testing being “executed” with this percent of automation and this percent of exploratory.

See also  Learning Linux as a tester.

Well, I guess the community finally got it when we react in an allergic-like manner to the term “manual testing”, so they probably decided to call it exploratory, so it sound “cooler”. Well, this doesn’t really help, when they mean the same old characteristics they meant for “manual testing”. On the opposite, this in fact distorts the meaning of the term exploratory testing, giving it attributes it was never meant to have.

As a conclusion…

What I very often see is that the term “manual testing” is normally used as sort of self-explanatory theorem to derive conclusions (mostly wrong) about testing. Just like, testing is manual therefore it’s easy or testing is manual, therefore we can make it more efficient with automation. This all show a shallow understanding about testing and the software domain in general.

What “manual testing” really  turned into is a synonym of “very low quality, low expertise human checking”. And I am ready to bet that no sane tester really wants to be labeled this way.

So my call for action is – stop calling testing “manual”, it is not manual, never was and it won’t become.

To those who disagree with me – my challenge is open – in the comments, give me your best argument why the term “manual testing” is useful on describing the testing role?

Aside from that, any comments, shares and retweets are highly appreciated. Thanks for reading! 😉


Senior software testing engineer at Experience in mobile, automation, usability and exploratory testing. Rebel-driven tester, interested in the scientific part of testing and the thinking involved. Testing troll for life. Retired gamer and a beer lover. Martial arts practitioner.

More Posts - Website

Follow Me:
TwitterFacebookLinkedInGoogle Plus