So you think you know automation? Part One

I stepped into a briar patch today.

The Michael Bolton (@michaelbolton) kind of patch. No you sillies, not the singer but a philosopher disguised as a canadian tester. Early this afternoon, I've unwittingly butted into his conversation with Adam Yuret (@AdamYuret) regarding Automated Checks, aka Automated tests to the uninitiated. I'll leave it up to you to find out why things of this nature should be called checks and not tests.

Here are some of Michael's points regarding the value Automated Checks;

1. at least THESE examples appear to work to some degree.
2. We found a bunch of interesting problems when we developed these automated checks.
3. These automated checks, on first principles, will probably make it easier to perform other automated checks.
4. These automated checks, on first principles, will probably make it easier to explore the application with automation's help.
5. The automated checks helped us to identify problems with load, performance, and stress that would have been hard otherwise.
6. These automated checks will help us to identify at least some unexpected and unwelcome changes.
7. These automated checks (since they come with logging) may assist with debugging and with retesting, should they expose bugs.
8. These checks provide coverage of stuff that with my Big Brain and Clumsy Fingers I would consider tedious, trivial, and awful.
9. These automated checks, like all forms of testing, provide partial answers that might be useful.

CHALLENGE: The skillful tester NOW presents a counterargument for every single one of those heuristics. Over to you. :)

The "skillful tester" in me agreed to his 8th point and argued that;

PA:  The moment a person starts considering something as tedious, trivial and awful, that person has least slowed down learning.
MB: What if that person uses boredom as a heuristic trigger to do something more valuable?
PA: But the I'm stuck heuristic is different from boredom. Boredom comes because you just can't think of anything better to do.
MB: I would argue that boredom is an important variety of "I'm stuck."
PA: Besides, to me, boredom is an effect and not a cause.

And much to my surprise, Michael issued to me a secondary challenge.

I'd recommend that you practice thinking more expansively (and critically) on this subject. You're right; what might *also* be right?

So looking into that earlier statement, "These checks provide coverage of stuff that with my Big Brain and Clumsy Fingers I would consider tedious, trivial, and awful.".

So what is this stuff that Michael is talking about? And what of coverage? Why does my brain have to be big? Do I understand why fingers can be clumsy? And what does the brain and fingers have to do with being the tasks I deem tedious, trivial or awful?

Now, for more serious questions, as a tester, how does automated checks bring value to my work? will it make testing my products more efficient, even make it better? or is it just throw away work? How do these checks bring value to my team? how about to my organization? What is it really that I have that require automation? What is it that I need that call for automation? Is it a far stretch to employ it? Will it require a culture change within the entire organization that I'm working for? Do I even understand it's purpose?

I dare say that if you are automating checks for the sake of your laziness and misunderstanding of your product, then don't. Automation is not just a programmatic conversion of your manual tests. Your manual tests that you deem tedious at this point in time will probably give new insight of the product under test the next time around. However you approach your product at this point in time will definitely be different as time progresses since you would have better understanding of the product (I hope) and can find other ways or paths to take which could lead you further in your exploration.

That is enough for now. Time to get some feedback.