Tools are devices to
- Amplify force or speed, like a pry bar or bicycle
- Give capabilities that humans don’t have, like a network sniffer or a magnetic compass
It has been said (not by me) that “test automation” happens any time one applies a tool (for example, Selenium and the coding to drive it) to what would otherwise be a manual test. IMO to spread this idea is a minor crime against the QA role, because if people believe that idea, they are doomed to the potentially huge opportunity cost of doing quality automation poorly because they won’t understand that do to it well requires an understanding of how it delivers very different value than manual testing.
Quality automation is no more a “tool” for software teams than accounting is a “tool” for the success of business.
I’m passionate about this topic because:
First, we all deserve better quality software, especially as software becomes more important to our lives every year.
Second, we software quality practitioners can do better:
There are many very smart people with great intentions doing good work applying automation to software quality management. Call those people set A. There are also many very smart people making expensive mistakes in this work, as they follow conventional practices; call this set B. Define set C as the intersection of sets A and B. Set C is most people doing software quality management with automation.
The good people of set C will benefit from a better understanding of what they’re doing; they’ll be more productive for the software business’ quality management, they’ll be able to articulate their value more clearly (when asking for an adequate budget or a pay raise, for example), and they will earn the esteem of their peers.
If you agree or disagree and can reason it out in writing, comment somewhere or shoot me an email from the Services page on this site.