Several years ago in one of his early insightful blog posts, Pradeep Soundarajan said this:
“The test doesn’t find the bug. A human finds the bug, and the test plays a role in helping the human find it.”
More recently, Pradeep said this:
Instead of saying, “It is programmed”, we say, “It is automated”. A world of a difference.
It occurred to me instantly that it could make a world of difference, so I played with the idea in my head.
Automated checks? “Programmed checks.”
Automated testing? “Programmed testing.”
Automated tester? “Programmed tester.”
Automated test suite? “Programmed test suite.”
Let’s automate to do all the testing? “Let’s write programs to do all the testing.”
Testing will be faster and cheaper if we automate. “Testing will be faster and cheaper if we write programs.”
Automation will replace human testers. “Writing programs will replace human testers.”
To me, the substitutions all generated a different perspective and a different feeling from the originals. When we don’t think about it too carefully, “automation” just happens; machines “do” automation. But when we speak of programming, our knowledge and experience remind us that we need people do programming, and that good programming can be hard, and that good programming requires skill. And even good programming is vulnerable to errors and other problems.
So by all means, let’s use hardware and software tools skillfully to help us investigate the software we’re building. Let’s write and develop and maintain programs that afford deeper or faster insight into our products (that is, our other programs) and their behaviour. Let’s use and build tools that make data generation, visualisation, analysis, recording, and reporting easier.
Let’s not be dazzled by writing programs that simply get the machinery to press its own buttons; let’s talk about how we might use our tools to help us reveal problems and risks that really matter to us and to our clients.
And let’s consider the value and the cost and the risk associated with writing more programs when we’re already rationally uncertain about the programs we’ve got.
[…] s/automation/programming/ Written by: Michael Bolton […]
[…] s/automation/programming/. A nice reality check from a tester on automation. Obviously I think testing with programs is a great idea, but it’s worth bearing in mind. The linked It’s a “tester” who finds a bug, even with the robust Google Search is also worth reading […]
The word “Human Testers” sounds a bit odd, as testers will be always human. “Human Checker” sounds not bad though.
I totally agree with whatever is mentioned in this blog..And everything cannot be automated.And it should not be automated.. automation can never completely take over manual testing.. So it is highly important there is a good balance in what and how much we automate..
So now the programmer found the defect while writing a program to exercise the code. Hmmm… sounds good but I think it might alienate even more testers if you start calling them programmers or developers. But I fully agree that they are!
Michael replies: Some testers are programmers. Some testers are not programmers. Either way, it’s okay.
The other positive side effect would be that we might get the tool support to actually do our job and that we start applying proper development practices to what we do and are not accepting hacky tester stuff.
Tool support is a good thing. I’m curious what you mean by “proper development practices” and “hacky tester stuff”, though.
Such a simple thing to do and such a deep reaching mind shift. Somehow I always knew that but Only this post opened my eyes to the reach of that statement and I had a *duh* moment.
I suspect Oliver is referring to things such as: not having code reviewed by peers, having significant code (e.g. a framework) that has no testing or checks for itself, lack of consideration for “releases”/versioning/usage of the code that they wrote by others, “it’s just test code”, stop learning about a language after they’ve gotten the syntax.
I’ve seen many testers (at varying levels of experience/years) seemingly not take the code that they wrote seriously and do things that many testers (including some of them) have complained that their “bad” developers do.
Michael replies: That happens. It’s okay to write throwaway code if you’re going to throw it away. It’s okay not to take code seriously if you intend not to take it seriously. But if you want to be a pro about things, be a pro.
I like the term “Automation in testing”.
Test automation sounds like programming automation.
What a nonsense?! Where you saw that a program written automatically?
It is written with tools which automate routine, like syntax checkers, auto completion, static analysis, automated build etc.
[…] reflect for a moment on why we write automated tests. In another excellent blog post, s/automation/programming/, Michael Bolton […]