An Alternative Approach to Automated Testing
By Ray Claridge
So you know you want to introduce automation into your regression suite, but not sure where to start? You could go down the traditional route and automate each module. But what if the software's an existing product and there's hundreds of modules already in place?.
It would take an awful long time (and cost) before you've caught up with the code. Mention this to stakeholders/managers and you could be derailed before you've even started.
I've recently heard of an alternative approach that sounds quite interesting and it wouldn't take too much effort to get automation up and running.
Let me explain - Instead of trying to automate each module, you start with automating defect fixes. The idea is that after a defect has been fixed a verified as working correctly, a small automated script is written to cover the functionality. Over a period of time, the suite slowly starts to build up into a regression pack. At fist the coverage is low just as with it would be following a traditional approach. However, as you're testing bug fixes, these tend to be around the most problematic areas of the code. Also by automating bug fixes, you can easily find problems when software code has regressed.
As time goes by, you could start to look at introducing a more module like traditional approach. But as a starting point, I think this could be the answer to introducing automation with quick results.
Ray
Great alternative. This is something we were looking at last year but ended up opting down the traditional route
I followed this approach on my last project and found it very effective. Do you ever go to testing meet ups in London?
Yes, I think it is an easy way to get into automation early
Good idea. We are trying to automate our software product and it is taking its time, dragging the development, even. Let me try this approach.
Wow. Very nice post. Thank you for sharing your views. I trust this can certainly help in Software Test Automation.
Thank you for sharing this post. I liked the idea and approach. I am interested to know if this alternative approach for software test automation can bring the same value for any financial or banking specific testing project or may have some risk factors?
I started employing this same concept durring a recent project. An additional bonus is that bugs are essentially stories... and could be looked upon as TDD for test development :)
Thanks for great explanation.
Thanks for the tip! Just the right time I found this since the team is starting to look at automation. I'm going to pitch this in during our discussion :)
It seems as a simple explanation - but it really powerful idea that address both the immediate and long-term needs.. Good contribution really :-)