Automate Your Tests
Learning Objectives
After completing this unit, you’ll be able to:
- Explain the differences between manual and automated testing.
- Explain the benefits and limitations of automated testing.
- Identify contexts that are ideal for automated testing.
This module was produced in collaboration with Provar. Learn more about partner content on Trailhead.
Explore the Differences Between Manual and Automated Testing
Provar lets us know quality assurance in software involves running a variety of tests. All tests are executed in one of two ways: manually or through automation. Manual testing means a person performs the testing; automated means software is used to perform or support test activities. In both scenarios, people write the test scripts, which are similar to instructions for how to test. However, who or what executes the scripts changes.
Some teams begin with manual testing on their quality journey. As they mature, though, they often find manual testing alone can’t meet all of their needs. This is where test automation comes in.
Explore Benefits of Test Automation
Testing is about more than finding bugs; it’s also about uncovering information that can impact larger business decisions. More on that later.
Test automation is an increasingly important step in getting that information. Flip through the cards below to see how automating tests helps teams.
Automate the Right Tests
Automated tests have immense value, but that doesn’t mean every test should or even can be automated. There are several factors to consider when deciding which tests to prioritize for automation. Automation can free up resources, but it can’t make them limitless!
Create a test strategy to help teams strike the right balance between manual and automated. Check out the table for questions on automating tests and how their answers help teams choose the right features to test with automation.
| Question to Ask | Answer to Consider |
|---|---|
|
How often do tests on this feature fail? |
Features that have a higher rate of bugs (found through manual testing) make sense for automation because there is a greater chance of finding issues through testing. |
|
How often is this feature used? |
Features that are used more often are going to be a higher priority for automation. Conversely, if a feature is rarely used, it will likely not be a candidate for automation. |
|
How severe is the impact on users if it does not work? |
If a bug is going to cause a large disruption for end users, then that feature is worth considering for automation. |
|
Which features matter most to the end user? |
Figuring out which features are most important to the end user helps teams understand which types of tests need to be at the top of the list for automation. |
There are more factors to consider, including the test case, the effort to build the test, and how often it will be run. Let’s take regression testing as an example.
Teams run regression tests to check that adding new code doesn’t break existing code or functionality. That means these tests are run each time there is a change to the code base. This can wind up being a lot of testing!
On top of that, software becomes more mature as more code is added to it, creating the need for more regression tests. Because they’re built to test a specific set of functionality that needs to be tested often, regression tests are prime candidates for automation.
Ultimately, teams need to know that their tests are addressing their biggest risks, not just providing the broadest coverage. Test coverage can be a helpful metric, but it needs a purpose. A high rate of test coverage over nonessential features can create a misleading picture of quality for a team.
Use Manual Testing with a Purpose
Let’s look at when manual testing is a better fit.
Limited Testing
While test automation can save time and resources in the long run, it does not serve the same purpose for test scripts that are only meant to be run once or twice. It takes work to set up the automated tests, so it’s best to save that work for tests that will be repeated over a period of time. The longer and more frequent a test is run, the better a candidate it is for automation. For those with a shorter time frame, stick with manual testing.
Exploratory Testing
Not every test can be automated, and exploratory testing is one of them because it requires human thinking. In exploratory testing, engineers use their knowledge, creativity, and analysis to uncover unknowns in the product. Once some of these unknowns are found, teams can decide if they need to be monitored with automation.
Usability Testing
The ultimate goal is quality for the end users, and for them that means the product works and it’s easy to use. Usability testing checks just that, to make sure the product and its features are user-friendly to a target audience. To obtain this feedback, a group of representative users answers questions that a tool cannot: How intuitive is the navigation? Does it look aesthetically pleasing? Are there broken links? And so on.
Sum It Up
Test automation is a tool for teams to level up their quality efforts, but that doesn’t mean manual testing should be left behind. Balance the two with intention and strategically decide which tests, for which purpose, will best support your testing strategy.