I quite often tell clients that their approach to test automation is not sustainable, this got me thinking, does test automation always have to be sustainable and reusable?
This all depends on the goal you’re trying to meet I guess. If your goal is set for long-term cost efficiency, shorten the timelines on regression testing and through that get to a more rapid release cycle, yes you will need to be focussed on the re-usability of your automation suite.
However there are plenty of instances where you want to automate something to make life easier right here, right now. Most testers, I hope, know the feeling of having to go through tedious, repetitive work, setting up data for a test, going through the login flow of an application to get to the feature you want to test etc. For actions like that, you can very well use automation. In fact, you can quite often use the most simple form of automation, record/playback without having to adjust your scripts for maintainability or re-usability.
Tools like Selenium IDE and AutoIt are excellent for making life easy right here, right now when you need to quickly automate something to make life easy. Funnily enough a lot of testers either do not realize these tools can be used to make life easier. When talking with colleagues about test automation they quite often think of big test automation packages, like QTP or Rational Robot. Sometimes they ask how much you need to know of software development and writing code to automate things. And most of these conversations I let myself be sucked into the tool talks and indeed talk about the difficulties of setting up a test automation framework.
In future conversations I am going to try to explain my colleagues and fellow testers that automation does not need to be a big operation, it doesn’t need to be reusable and maintainable, at least, depending on your goals. As long as your goal is to make life easy here and now, there is no need to build something awesome.
For a lot of things, a simple script, either hand written or simply recorded, can be more than enough to get to your goal, when done with your tasks you can then throw them away, but preferably be a bit smart about it and just dump it somewhere in a repository, you might have to do this task again.
“…it doesn’t need to be reusable and maintainable, at least, depending on your goals”
And that is the key thing about any type of of automation, it depends on your goals with it. That is where 99% of people get lost in the woods, they “loose the forest for the trees” as the saying goes.
I’ll definitely be checking on your posts, very interested in your views/take on this one.
It’s funny to see that within “regular” software development a lot of attention is given to preventing over-engineering of things. In Test automation development however it seems to be the norm to heavily over engineer things.
I like your ideas, but I would like to add to them. If you DO have an ‘over-engineered’ automatic test (to use your words), where you have made an analysis of the system and implemented test-functions for the different actions in the system and possibly enumerations for the different objects, it will be very easy to create ad-hoc tests for a number of things, as you need them.
Well stated. Good analysis and identification of goals prior to test automation design and implementation are important.
Here here. AutoIt has saved me more time than I realize. Heck – batch files, VB scripts, VBA, and Windowss “send to” feature have as well.