Top 10 Blogs of 2015: Test automation – Don’t try to build Rome in a day
Dec 24, 2015
This blog was originally published on 26th Janurary 2015
Test automation is often perceived as ‘expensive’, ‘costly’ or ‘difficult’… but it shouldn’t be. There is a lot of automation software that is easy to learn, cheap or even free to use.
Nowadays, organizations are working more and more Agile, often through Scrum – which means that the rate of deployments are going up and so is the frequency of Regression Testing. In the first two or three sprints, it’s rather easy to keep up with the delivery rate of new features. This is because the product is still relatively small, and there isn’t much requirement for Regression Testing.
However, after the third or fourth sprint, the product takes more shape. By this time, the features become more mature, comprehensive and elaborate, thereby demanding extensive period of Regression Testing.
The Regression set gets bigger and bigger and the time spent on Regression Testing increases almost exponentially, resulting in a longer waiting period on the feature to be completed; thus, increasing the time-to-market. This could be solved by automating the (regression) tests. In my opinion, this is the obvious choice… but it isn’t for all businesses! Often times, companies spend prolonged period rationalizing the pros and cons of Test Automation. So, my suggestion would be… just do it instead of speculating too much!
Start doing !
As stated above, this is something I hear way too much. Using of tools are ‘expensive’, ‘costly’ or ‘difficult’. I think differently, there are many tools that are easy to use , cheap or even free to use.
For example Selenium is a free-to-use tool, which one can download as an add-on for Firefox. It’s a very easy record and playback tool for websites and one can start using it within minutes. So, apply, engage and implement. When working on a product that involves websites, the testers should download Selenium or another similar free tools the moment they start on a sprint. Why? It’s because the team starts learning right away.
There are other free or cheap tools, each meant to achieve its specific goal:
For example
Type | Name |
Unit test | JUnit, Mockito, Easymock |
Performance | JMeter, LoadUI |
User interface / Web | Selenium IDE, Firebug,Firepath |
Security | ZAP, Webscarab, Burp Suite |
Services | SoapUI, CURL |
There are tools that one can use for functions other than Testing. Following is a list of some that I know:
Type | Name |
ALM | Trac, Jira, Bugzilla |
SCM | SVN |
Build tools | Maven, ANT, Gradle |
Continous integration | Hudson, Jenkins, Bamboo |
Analyses | SonarCube, Findbugs |
Deployment | Hudson, Jenkins, LiquiBase |
Usually, the tool(s) used by teams differ and I feel, they should have the freedom of selection.
Learn
In my Testing career, I found that the “old school” testers are habituated to Manual Testing and have challenge embracing Automation. So, if the learning curve starts with Automation, it will get too difficult for such Testers and they might lose interest and be inclined to go back to their comfort zone i.e. Manual Testing.
Therefore, start with tools that are cheap and easy to use. Due to the low costs, the team will be able to switch between tools more easily and they won’t need programming skills or even a training to start working on it. Give the team room to explore, fail, experiment and learn, so they can make a better choice of tools that are really beneficial. Thus, making Automation more cost-efficient. This is a long term thinking game.
“Don’t make the mistake to start with an expensive suite of tools. You probably don’t even need all its features, but you surely will pay for it.”
Share & Grow
When using tools and test execution gets automated, people get the hang of it. They will have a better understanding of Automation and will create new ways to improve existing test cases or even see new opportunities for the use of better or other test tools. Make use of this. Let teams and people share their knowledge with others. If they like their tools, they’ll probably want to talk about it, tell other people and teams how good their tools work. Support this and let them share their knowledge, encouraging peer-to-peer learning.
So, start small and simple, apply, engage, learn and share. Don’t try to build Rome in a day!