Test automation: the secrets and how to use them Solidify

Test automation: the secrets and how to use them

Published February 08, 2017

In 1913 Henry Ford created the world’s first assembly line production and, together with his engineers, took the first step towards car production automation. This was something nobody had seen before. Using sophisticated machines to produce large quantities of car parts and various methods for assembling these, Ford contributed to the industrial revolution and has taken his place in the history books. A lot the philosophy lives on in modern day software test automation. Automation as a concept has existed for a long time and is today a hotter topic than ever. You probably want what everyone else does – that software testing should be quikc and without flaws. But what happens when the complexity increases and tests take longer and longer to both set up and to execute? The discussion regarding automated testing has likely come up in almost every software develoment project. Despite test automation having come far from the old <a href="https://msdn.microsoft.com/library/dd286714%28v=vs.120%29.aspx?f=255&MSPPError=-2147217396">Record and Playback</a>, many still have questions about it. Below you will find some of the secrets behind successful test automation that can help you in your work towards a more automated test environment. <h2>Avoid only testing through the user interface</h2> Only testing through the user interface is slow. It might even be extremely slow. It might work just fine for the first few weeks, when testing only takes five or six minutes to perform. However, those minutes can quickly become one or two hours. Before you can say “unit test”, your testers now run the automated testing through the user interface at 5 in the afternoon and have the results the morning after. In case the testing runs into problems early, the results might be useless. This leads to further testing being needed – which only leads to more time. When developers are waiting for test feedback, they initiate something else and sooner or later someone makes a UI change, rendering all tests worthless. In addition, test automation is increasingly difficult in this type of scenario. By extending your automation to also include unit tests (especially important if you have very modular code), <a href="https://en.wikipedia.org/wiki/Test-driven_development">Test Driven Development (TDD)</a>, <a href="https://en.wikipedia.org/wiki/Functional_testing">Functional Testing</a> or similar methodologies, you can both complement and speed up your regular testing. With a mix of internal code testing and UI testing, the overall process becomes a lot more manageable. <figure id="attachment_3694" class="thumbnail wp-caption aligncenter style="width: 581px"><img class="wp-image-3694 size-full" src="http://solidify.se/wp-content/uploads/2017/02/is_it_worth_the_time.png" alt="Time for test automation" width="571" height="464" /><figcaption class="caption wp-caption-text">XKCD: Efficiency</figcaption></figure> <h2>Remember your pipeline</h2> Testing includes more than just the execution and reporting of the tests themselves. You need to set up the right environment, decide on a testing strategy, use the correct test data and design, not to mention the test setup. If you don’t keep all this in mind, your test automation will only simplify a small part of the process. If you create automated tests that then needs to be executed manually, those manual additions will end up being more destructive than constructive. You should instead start with a few simple tests that run end-to-end, through your integration server and on every build. When that’s in place, you can extend the test with new scripts. Unfortunately, 100% test automation is impossible to do right away. That’s why it’s important to realize that if you forget your pipeline, you might find yourself using tests that’s both hard to use and to maintain. Begin with automating the most important examples and work your way up from there. <h2>Test automation from day one</h2> <blockquote>Make sure the application works, and we’ll move on to automation later.</blockquote> A common misunderstanding is that automation cannot be made before the application is ready to run. The fact is that a strategy that involves early automation can lead to faster delivery, and overall better testing. To define a good strategy for test automation, you need to agree with developers, testers and product owners what needs do be done to minimize the number of deployment failures. <a href="http://blog.gdinwiddie.com/">George Dinwiddie</a>, agile coach, popularized the term <a href="https://www.infoq.com/interviews/george-dinwiddie-three-amigos">The Three Amigos</a> for this type of work. The three amigos are referencing the developer, the tester and the analyst and another name for the concept is <a href="http://testobsessed.com/2008/12/acceptance-test-driven-development-atdd-an-overview/">Acceptance Test-Driven Development</a>.     These are just a few of the things to remember then thinking about test automation. What type of tests do you use or want to know more about? Let us know in the comments!