Step 1 – Be frustrated with the process heavy and skill-free testing done on most projects
Step 2 – View testing as a clerical process to be automated
Step 3 – Ignore the input of the skilled, competent test community about what testing actually is and their experience automating it
Step 4 – Invent TDD and Automated Unit Testing, a Real Good Thing
Step 5 – Extrapolate, by the same logic, that Acceptance Tests should be automated in the same fashion, even for GUIs
Step 6 – Try It
Step 7 – Fail
Step 8 – Repeat steps 6&7 if needed
Step 9 – Realize that some GUI-driving test automation makes sense in some cases, but it is, essentially, checking, not investigating
Step 10 – Ignore the testing community, who have been saying that for ten years
Step 11 – Declare myself an expert. Try to angle for a keynote at Agile 200X.
The steps above are actually a composite of a number of people and ideas. But just maybe enough of an approximation to post …
"The steps below are actually a composite of a number of people and ideas."
As are the steps above.
Can I be an expert too – oh wait – I can just declare it.
Except for 4 & 5, this could have happened in the 20th century too.
Other problem is that sometimes it's hard to find skilled competent testers – or I should say – it's hard to find truly skilled and competent testers among those who claim to be as such.
Oh – and also – http://blogs.msdn.com/alanpa/archive/2008/09/18/gui-schmooey.aspx