For years, developers have been making software that end users love. And yet, there's so much talk about agile this, and agile that, DevOps and a variety of other industry buzzwords that all seem to be pointing in the direction of improving the overall value of deliverables. If everything was OK then, what's so different now? The answer, in brevity, is everything. The expectations of users have shifted, technology has become more advanced, the number of applications has skyrocketed ("there's an app for that") and the competition is fiercer than ever before.
It is for this reason that so many development teams are searching far and wide for tools that will simplify the complexity of these processes. In a bid to do just this, many have turned their attention to software test automation. Testing is one of the most important aspects of any deliverable. It's basically how developers make sure that the thing they created actually does what it was supposed to be doing. With software test automation, this imperative initiative can be expedited and enhanced. This brings us to software test automation 101:
Developers need a way to perform repetitive test cases in order to ensure that there is less room for human error, and that QA talent is being leveraged economically. The last thing a startup developing a new app on limited seed money wants is to waste time paying their testing teams to do the same thing over and over again, when in theory, a solution exists that can accomplish the same thing at half the price and in half the time. This isn't to say that software automation testing tools are replacements for human expertise. However, it is an extraordinarily powerful supplement that is capable of reducing the time to market, while guaranteeing quality functionality.
What exactly is software test automation? TechTarget contributor Jennifer Lent sums it up as follows: "Automated software testing is an alternative to manual testing, where software tools, not human testers, execute pre-scripted tests on a software application before it is released into production."
This satisfies as a basic definition, but it's worth going a little bit more in depth. For starters, test automation is not a replacement for manual testing and should not be treated as such. There are certain scenarios in which manual tests make more sense, for example, with very specific user-experience functions that must be assessed based on, say, how intuitive they feel for users. It's difficult for automated test cases to achieve this.
Secondly, there are a variety of test management tools that QA teams could potentially use, and not all of them are made equally. Therefore, the "what" of test automation will hinge, at least to some extent on the value of the test management tool. For instance, testers will still need an organized, intuitive testing dashboard with extensive, real-time tracking capabilities. These features are essential for fostering greater collaboration among different teams. This is especially true if testers are working from different offices or even different parts of the country or world.
At what stage in software development should test automation be leveraged? With traditional waterfall models, testing marked the end of the line for a project, or at least, what developers really hoped would be the end of the line. The problem with this was that if there were serious flaws with the deliverable, it would have to go all the way back down the assembly line. The siloed nature of development simply wasn't conducive to swift remediation of issues, because teams were so removed from one another. Testers in particular seemed like the troll at the end of the bridge who was just looking for a reason to send a project back the way it came. In truth, they were just doing their job.
Now, however, "agile" and "continuous" processes are much more supportive of test management, and this is mainly because of the "when," aspect. By automating unit tests and regression tests from the onset, every time something is changed or a new iteration is unveiled, regression tests can immediately vet the alteration. There is no troll at the end of the bridge so to speak, but rather, a very intelligent guide that can provide affirmation for developers as they step from one phase of development to the next.
... And the How
In many ways, the how of software automation has sort of made the "when" moot, considering automated testing can occur on an as-needed basis. Nevertheless, there's still a bit more depth to exactly how software test automation can be used.
As already mentioned, one of the most practical use cases for automation integration is in unit and regression tests. The ability to catch defects with immediacy is a major boon to testing teams, and to the project in general. Furthermore, with the right test management software, many of these automated test cases can be saved and reused again for other projects if they are relevant. This is inherently conducive to agile software development and continuous delivery.
On that note, there are also ways to use automated testing to glean insight on what TechTarget contributor Nari Kannan refers to as "scenarios." Unlike plug-and-chug regression tests, these "scenarios" or "use cases" are a bit more exploratory, and enter more into the realm of what could be possible in terms of functionality. Agile testing methodologies help make this possible because they can be more quickly amended, and new tests can be easily scripted as needed or between iterations. This makes it much more manageable for testers to widen the berth of potential testing cases, and ultimately envision new, innovative test scenarios.
At the end of the day, software test automation is supposed to work for the user. By giving developers and testers more options, this is exactly what software test automation achieved, especially with a test management tool that supports agile testing methodologies.