Getting started with test automation: It’s not just about the tools

Making a test automation culture work well does depend upon alignment between people, process, and technology

12 run diagnostic test

Whether you call it test automation, automated testing, or something else, using software tools to help speed up the execution of software testing is an essential element of successful software development. There are various reasons for this: It’s faster and gives QA time to verify the quality of the application it is testing in a more meaningful way. According to Capgemini’s World Quality Report, 60 percent of IT executives say that test automation increases the ability to detect software defects. Test automation may even save money, even though your organization may initially have to purchase additional technologies and deliver training to make it happen.

Of course, as with most changes in technology, automating testing processes doesn’t make everything easier overnight. First, there are expectations to manage. Full automation is not ever possible, or even desirable—but it does allow your testers to focus on higher-priority areas, like using exploratory testing to test the application’s business logic. And even if you take advantage of every automation opportunity, bugs will still make an appearance—they always do. Can you think of a single product or application that Apple or Microsoft has released that has been completely bug-free? These companies have developers and testers dedicated to every nook and cranny of the applications they release. And bugs still get through.

Not to sound trite but making a test automation culture work well does depend on alignment between people, process, and technology. Let’s look at these three areas:

1. People

You’ve heard plenty about the challenges in finding quality IT people; the same goes for software testers, particularly those with enough technical chops to do test automation. These people are often called test engineers and for good reason: They need some coding experience to write automated tests. While you might consider retraining a developer who wants a career change, it’s likely that you’ll need to look elsewhere. Graduates of technical trade schools, or people who have engineering or science degrees or at least some previous coding experience, are good candidates. Another option is to seek out people with experience working on an internal IT or software vendor help desk. That experience gives individuals an understanding of user issues and how software works. Anyone with an analytical mindset, an interest in troubleshooting and an aptitude for learning could undertake the training necessary to be a great test engineer.

Here’s something else to consider: Some roles require more technical prowess than others. You should have a test automation lead running the show. That person needs a deep understanding of how all the components of the application fit together and, of course, programming knowledge. Ideally, the automation lead will have experience in both an object-oriented programming language such as Java or C# and a scripting language such as Python. Other team members can be less technical out of the gate, yet willing to learn how to use the organization’s language of choice.

If you have the luxury of a large QA organization, it’s entirely possible to move a manual tester into automated testing. This can be a fun career change for testers who have been performing rote tasks for many years. Writing test cases entails creativity and problem solving, and that can be extremely rewarding.

You will need a dose of patience in getting people trained. This can happen with online courses, yet it will take a few months for someone to become reasonably proficient in a language. Factor in that transition time and investment when planning how to build out your test automation team.

2. Process

Getting started in test automation is like drinking from the firehose and requires significant change management. You’ll need to get people on board and figure out how to institute a new mindset around QA. Then you’ll need to figure out how to introduce new workflows. Begin by identifying the different areas of testing you want to tackle first, such as functional and API, security, regression, integration, or load tests. Ideally, unit testing has already been automated by the dev team, but if not, that should be the first area you tackle. Next, analyze your test cases and give each one a risk score, so that you can figure out which to automate first.

Along the path of adopting test automation, you’ll have to assure others who may question the amount of money needed for training and tools. Initially, test cycles will also take longer as everyone is getting up to speed; slower release cycles will make everyone cranky, but this is a short-term issue. Increasing test automation does speed up production cycles and produce higher quality products—and the results are often almost immediate. The second that an automated test finds a bug, money has been saved.

Achieving buy-in from product managers, business managers, and executives is easier when you have metrics to show indicating how test automation is positive for the business. Some persuasive comparison metrics of the before-and-after testing process include number of defects and severity of defects.

3. Tools

Finally, you’ll need to compare your QA goals to the plethora of tools available today and determine which will help you achieve your goals and work best with your existing tech stack. Your QA group will need to select your automation tools; Postman and JMeter are popular choices for API and load testing. Then you’ll need to decide on a programming language and select your frameworks. Some, like Cucumber, will require a process change, while others may be easier to pick up and start using right away. Some of these tools are free (open source), while others will be easier to use with more features and a higher price tag. Consider too that certain types of projects (like websites) will match up best with certain languages and thereby, associated tools. For instance, the frameworks used with Java are typically JUnit or TestNG.

You may want to choose a language that’s popular with developers, in which case you’ll use the optimal framework and tool set for that language. There are many decisions to make, so take the time to choose the right tool set for the job and for your organization. When in doubt, use popular technologies like Cucumber because they have established communities and resources for getting your questions answered quickly and authoritatively.

Finally, when moving to test automation, the company’s sector and customer base can dictate strategy. The complexity and user impact of defects necessitate that QA think carefully about how much testing to conduct; automating most of these tests can help teams from drowning in environments with heavy requirements. For instance, in a health care organization, a software defect could harm a patient. In finance, a critical defect could result in customers being unable to check accounts or, worse, experience data leaks, resulting in a drastic loss of trust and loyalty. By comparison, a bug in an application such as Skype or Netflix will be annoying to users yet won’t likely bring a company to its knees.

If your organization is not already doing some form of test automation, it’s a smart idea to designate someone on the QA team as your automation champion. Starting early with test automation training and tools is an excellent way to motivate your team and be ready for whatever comes next.

Copyright © 2018 IDG Communications, Inc.

How to choose a low-code development platform