Talking testing, automation... and anything else.


When To Automate

?There’s a veritable plethora of blogs, articles and papers, listing the mistakes commonly made when creating functional/ui automation… and many of these, themselves, contain common mistakes. Here’s one I recently found…

From an article “Five Common Mistakes and Their Solutions” by Artem Nahornyy:

Starting at the Wrong Time
It is a common mistake to begin test automation development too early, because the benefits almost never justify the losses of efforts for redevelopment of test automation scripts after the functionality of the application changes until the end of iteration…

Solution
During the development phase, members of a quality assurance (QA) team should spend more time creating detailed manual test cases suitable for the test automation…

Mr. Nahornyy argues that automating too early can waste efforts due to change, but the same argument can be made against his solution. Changes can also lead to waste when writing detailed manual test cases, early in development.

My advice is to start automating as soon as you can. For example, you might write automation code when devs are writing app code. Start with a failing test, and flesh out any page objects needed (or create them if they don’t exist). Then create any methods and/or data needed by the tests. This will save time later for manual/exploratory testing, when the code is complete.

Even better is if you can get access to the code in progress. Maybe by accessing your dev’s machine, or working from a branch, etc… Then you can start hooking up selectors in your page objects and perhaps even running code. More importantly, you can sniff out early bugs in the html/css/javascript, or even in the ui. This is also the perfect time to ask for css changes to solidify page object selectors. Eg. add a css id to an element to save you from using a more brittle solution. It’s WAY easier to get a dev to add an id while they’re still in the code, rather than later down the line.

Truth is, I would generally argue that it’s a mistake to automate too late, rather than too early. The ability to run even the simplest automated tests during a release can add real value. Kicking the can down the road with automation might at best, bloat your backlog, and at worst, never come to be.

Plusone Linkedin Facebook Twitter Digg Email

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.