Planning, planning and more planning
Lots of questions are usually asked about automation, its bonuses, and abilities, etc. That is indeed an interesting topic that requires something more than a mere blog post. It’s just impossible to fit in all the answers into something that is containing less than several thousand pages of boring yet meaningful words and letters. Let’s just try and understand whether we need automation anyway, what’s it good for and how to apply it properly. We will be doing some preparations before the preparations for testing.
Why should I even bother automating?
You shouldn’t, unless the activity is of profit to you, your team, your project and your company. Unlike many managers believe it is not some all-solving panacea that may heal any place that is aching despite on the project itself. It’s just that most top managers are certain that with the amount of money they’ve spent on automation it has to cure cancer on its minimum of potential. And that is, indeed, a false misbelief. So when will automation work out?
- Regression is the perfect domain for automation. It always was and always will be. Just imagine all the work you’ve already done with your project. And you are now with some new functional or new bug fixes or whatever. Adding those may cause new bugs to emerge in the previously written code. Sure you can test all that manually but that is just an activity that reduces the effectiveness of testing. It’s not the quality of software I am talking about, it’s the spent time, resources and the cost of those activities your company is paying for.
- So you are into a mobile application test. Lots of users will be using it at the very same time. How can one man test such mobile app’s potential? If you are to create lots of users with your own hands that will take ages. Or you can just automate your load testing.
- An application has a constantly shifting code. The GUI is pretty much the same all the time yet there are lots of functional changes thus more testing rework. GUI stable? Automate!
What may go wrong?
As mentioned above automation is no panacea and has some risks involved you are to consider before even beginning with your preparations.
- Do you have any coding skills? Because you’ll need those for automation purposes. If you are not feeling too confident with programing I’d rather you to forget about automation until you are educated to the proper level. Lots of books and tutorials are out there for you to gain necessary knowledge.
- Automation costs are high! If you are simply wishing to reduce the cost you are spending on manual testers that won’t work out. At all. Tools, trainings, maintenance costs are high and simply getting rid of manual testers from the team won’t work as well. Automation is not something you can replace testers with. And it never was despite all the blubbering the sales guy is telling. Sure you can save some money on cheaper tools and scripts yet the quality of software will be injured. And what is the point of the entire activity with such an outcome?
- UI is not to be automated. Until it’s not entirely fixed at the very least. There will be extra script maintenance cost charged with any chance in UI. Thus be warned.
- If you are not into agile I’d also rather you not to automate straight from the early development. That may be expensive as well.
- 100% automation? Yeah, right, and a castle with a dragon-riding pony-princess who’s nephew is a charming leprechaun as an addition. Get real. Performance testing, Regression testing, Stress testing, sure. You will get near 95% automation with those if lucky. Yet there are areas that are automation no-no’s, like UI, documentation, compatibility, etc.
- And, of course there is no need of automating tests you will be running only once or twice.
Now, that everything is considered and you are sure you want some automation goodness, you feel you are ready, you may begin with the actual preparations.