Many times while examining existing automation scripts, it is amazing to note how much some of the automation code tries to accomplish. In a recent engagement, while examining automation code of a product with rich browser-based GUI, the automated script was found to have checks for wide range of conditions viz., data boundaries, default values of inputs, control enabling/disabling, control properties, and of course the functional behavior. One can visualize the various conditions to check and the associated long code that is rich in potentially uncovering a variety of issues. The developer of the script is proud of how much he/she has packed into the script whilst I am smiling and cringing inwardly. The “richness” is the problem.
So as a script developer, what do I have to do? Given scenarios to automate, assess the “fitness of automation” of the these. (In HBT (Hypothesis Based Testing), this is called “Fitness for Automation” with scenarios being “level-ized”. This helps in making the scenario “chewable” by the “automation”.)
Read the article written by T Ashok Founder & CEO of STAG Software (published in the Jan 2012 issue of Tea-Time with Testers, ezine) below that highlights that a scenario with a clear goal results in a “singular purpose” script and satisfies the key “single entry-single exit” criteria.
We would like to hear from you, so leave us a comment.
