Bloggo back to the blog
Magic Bullet – Completely Automate the Testing Effort-->
This is a follow-up blog post on Test automation for the blog entry by Sanju Pillai here titled ” Effective Planning, Right Expectations, Skilled Resources are Key Indicators for Test Automation Success” I second his views.
It’s very unfortunate that many see test automation as a “magic bullet” that solves all testing problems, and it will always be ready (updated) whenever there is a change in the software that needs to be tested.
Many who suggest test automation aren’t clear about their expectations from it, it makes me chuckle when someone says “completely automate the testing”.
What is Test Automation Exactly?
1. Piece of software program you have written that will do the repitative task on the software that need to be tested, either only one or billion times
2. Piece of software program you have written will listen and monitors across the system for any changes ever since the software to be tested is installed and operational.
3. Piece of software program you have written that will simulate virtual users or concurrent usage on the software to be tested.
Above specified are mainly automation activity, apart from that there are many minor activities carried out, eg: inserting values to the db or text field or stimulating test data etc.
What software you can automate?
If the software is very well (at least reasonably) documented for the requirements, designs and workings and that software has underwent a good round of testings (unit test ,integration test and system test)
Why only the above specified softwares?
1. Because, if you dont have proper requirements, design and working of the software documented, we cannot instruct the “test automation tool”, as you might know they don’t have common sense like we humans do(!!) They might not be sure which is okay and which isn’t okay, so to instruct the “test automation tool” we need clear documents.
2. If the software never under went (and passed) unit test, integration test and system test, which literally means the software is near dead, what is the point in trying to kill the software to be tested with “test automation tool” if it’s already dead?
I have also explained what kind of softwares can’t be automated above, but there is other kinds of software available too, which will have all proper documents, undergo very good rounds of testing, but the changes to the software will happen very frequently, to keep this software automated we need to keep updating the test automation tools regularly, that is code maintenance, somebody need to be dedicated for this effort.
Between, I am against commercial test automation tools, more on that topic later :)