Why Human Validation is always needed (in discussion)
This is the discussion slowly going on Justin Dessonville’s blog post. With the arguments taken from famous “Testing vs. Checking” article by Michael Bolton it once again reminds me of Luddites.
The Luddites were a social movement of British textile artisans in the early nineteenth century who protested—often by destroying mechanized looms—against the changes produced by the Industrial Revolution, which they felt were leaving them without work and changing their entire way of life.
Nowadays, automatic checks are everywhere – from electrical safety devices to jet airplane automatic control systems. Could you imagine manually checking wiring every time you want to turn on the light? And it’s not even possible to perform a manual start-up check for a jet airplane because all the units a sealed off.
So how it works? – Humans stand at the top of the pyramid “checking – validation – judgment – decision” and look at the big picture. Make decisions. Give directions.
How it is implemented?
1. Automatic checking elements are part of the device. They are built-in.
2. A device along with the primary function provides an output allowing examine and check its state.
3. Atomic pieces of information are gathered and reconciled. Checking becomes validation.
At this point it becomes high level enough to report to a human being.
So maybe it’s an opportunity to stop “checking out the details” and start seeing forest?
4 responses to "Why Human Validation is always needed (in discussion)"
I agree with you and know that automation definitely has its place in all systems and architectures. However, the implementation of automation is the core issue here. Not everything can be automated nor manual.
“Start seeing forest” is exactly where the solution is. However the forest in question needs to be surveyed completely before the details can be checked/tested/validated effectively and accurately. Too many times are ‘automation specialists’ thrown into the mix of a project and asked to automate it when really they should be given at least 2 development cycles to see the points at which a testing routine can be automated, where they should stay manual, and where they should be a combination of both.
True, 2 cycles is hard for anyone to swallow with a new employee sitting idle (blame my mind at 1:30 in the morning for that idea). There are common pitfalls that can be identified/corrected quickly. However I think that as an automation tester getting your hands dirty in manual test land for a bit wouldn’t be the worst thing when you’re starting out at a new job or after a year of being focused on automation.
Hi Justin,
Thanks for commenting back.
Yes, I agree, integration is one of the major problems in test automation. I wrote about that in the following posts:
http://automation-beyond.com/2009/09/15/test-automation-problems-5a/
http://automation-beyond.com/2009/09/15/test-automation-problems-5b/
However I can’t see what company would have a luxury giving 2 development cycles to observe in idleness. In my opinion, based on a few years of successful automation practice for enterprise scale projects, professional approach combined with managerial support brings a significant payback already by the end of first 6 months (assuming establishing automation from nothing). And the more mature automation professional is engaged the more powerful and robust will be coverage.
The key organizational points are support, feedback, and Agile automation development cycle (a product development cycle might be Waterfall).
The key technical points are rapid, thorough, and robust automation which is very well affordable with hybrid keyword/data driven framework.
Thanks.
I would even say that you didn’t emphasize manual testing strong enough. ANY automation candidate test case should be thoroughly investigated MANUALLY by an automation developer first in order to design right automated testing flow. If new defects are exposed during that exploratory testing an automation developer should be able to track and report them.
In my belief, again, practically confirmed, QA Automation without hands-on experience in manual testing is neither efficient nor successful.
Thanks.