Team handshake

How to make the most of your test automation team

As the use of agile and DevOps practices and methodologies spreads among software companies and IT organizations, so does the need for test automation. Automating tests is a superb way to be more efficient, deliver code faster, and preserve precious technical resources for more challenging exploratory and manual testing needs. And you can automate a large portion of tests in applications today.

But here’s the rub: Test automation requires having people with particular technical skills—software developers or those who know how to write code. A test automation script is essentially a piece of code that tests another piece of code. In most organizations, talented developers are stretched pretty thin. With discipline and commitment,  developers can write good unit tests and provide good code coverage, but when it comes to identifying and writing more complex integration tests and acceptance tests, a much larger commitment of time and effort is required.

So, when push comes to shove, you can’t get to the level of test automation that you might like if your developers are too busy to take on the extra load.

Another issue with the technicalities of test automation is that non-developers, such as product managers, testers, and analysts, are in the dark as to the content and outcomes of those tests. With test automation, the test is now stored as source code in a repository such as GitHub. One can see a report showing that 15 .java files failed tests, but the report offers no context as to the actual functionality that failed. This results in mistrust and confusion by other team members when trying to troubleshoot and improve the application.

The result can be team members worrying that critical issues are being overlooked or test coverage is not complete. This can create a divide between developers and everyone else, when the whole point of DevOps is to integrate teams and tasks to streamline development.

Which mobile tests should you automate?

Bridging the skills gap with test automation

To maximize automated tests in your organization, you’ve got to find ways to put nontechnical employees to work. This will expand an organization’s ability to automate tests and also provide additional value, since these individuals have deep product knowledge and a closer alignment to the business. Here are two tactics to consider:

1. Recording tools

Test recording tools, of which there are many, allow a nontechnical person to record test-related activity in the system for developers to access later. This saves time, since the developer now only has to write the automation scripts from the recording. The recording consists of screenshots and user input, describing what steps should constitute a particular test. Some tools even help generate the automation by capturing not only screenshots but also the underlying application objects and interactions required for test automation. All of this speeds up the process and allows testers, analysts, and other people who don’t possess coding skills to assist with test automation. Teams can also use these tools to convert manual testing into automated tests. While a tester is conducting a manual test, the recording can be running in the background to document the actions and create a test script.

2. Behavior-driven development (BDD)

Another useful tactic for expanding test automation across the organization is to employ BDD. This methodology can align application requirements with business/user needs. It starts by documenting the behavior that is desired, such as helping the user complete a registration process in minimal steps. That desired behavior is then translated into specs using a BDD language such as Gherkin. The documented behavior not only defines the feature for the developer, but it also defines the required test. BDD syntaxes, such as Gherkin and SpecFlow, are easily accessible by nontechnical users, such as business analysts. Those individuals can now specify developer requirements and help accelerate the development of automated testing scripts at the same time.

Another powerful advantage of BDD is that it allows functional experts to specify code and testing requirements, saving automated testers valuable time. As well, using BDD for automated testing provides much better traceability. Within the system, you can view a Java file that might contain a Cucumber automated test and see annotations about the related functionality. That way, when you get reports, you can correlate test results to specs; you know exactly what feature or function failed. Business analysts and the QA team can finally identify exactly what the automated tests covered and gain a clear understanding of the results and correlated risks.

Sometimes, BDD is used in concert with test-driven development (TDD), which requires that the user scenario/test is written before the developer writes a line of code. Therefore, the developer is writing code to meet that test requirement from the outset. And he or she can write the automated test before writing the actual code.

Get beyond falsehoods of automation

DevOps relies on frequent collaboration and cross-functional skills and roles. There are still some people who believe that with the advent of DevOps and its focus on heavy automation, QA people are no longer needed. But this is faulty thinking. The QA team exists to ensure that the application is of the highest quality and aligned with business goals before being released to users. Automation is important to a certain point, but critical thinkers who understand the business and the user community will always be fundamental to DevOps success.

Therefore, we must always be thinking about how to link automation with business acumen. Test automation is one area where we can improve the process to enable people outside of development to add value. Recording tools and BDD are two very accessible methods for achieving these goals today. Furthermore, adopting both of these tactics together can deliver even greater benefits to any DevOps team.

Which mobile tests should you automate?
Topics: Quality