The Tesults web app is designed for desktop browsers. Sign up and configure your project on a laptop or desktop. Use the iOS app or Android app to view results on the go.

Semi automation and software testing

The middle way

blog-title-image

When there are test cases that can not be totally automated it is often possible to use semi automation to help development teams save time on testing.

What is semi automation?

Semi automation involves automating part of a test case only and then utilizing a manual process to complete the test case. Automation may be applied at the beginning of the test, at the end or somewhere in-between. Often, automation is used early in a test process to generate some sort of data output that a human tester can then examine and assign a pass or fail outcome.

UI verification example

As an example, suppose a team has an application with a web front-end. The front-end must be responsive for different screen and browser widths. The Bootstrap framework is a popular example of having a grid system that adjusts content layout based on up to five different width intervals. The development team may want to test that the content on every page looks great for all five supported width ranges across all the browsers the product supports. At the same time the organization may have a visual design guideline that also needs to be considered and the application should be checked to ensure it is adhering to this.

To perform this set of tests a manual tester would have to adjust the width of the browser to a specific size and then open every page in the application (including modal views) and check everything appears correct. Then they would need to adjust the width again and do the same again, opening every page of the application, repeated five times in total. That is not all. Suppose the application supports Chrome, Firefox, Safari, Edge and Opera. The tester must now repeat all of the above again in each browser. In total that is 5 browsers x 5 widths x number of pages that must be checked. Assuming it’s a small application with only 10 pages, that is still 250 different views that must be navigated to and examined on every release. The navigation alone would take a significant amount of time. Full automation of this is difficult to achieve due to the visual subjectiveness of assigning a pass or fail result. However, assuming a test harness has been created for driving the browsers with Selenium, automating everything but the verification itself is possible. By automating changing the width, navigating to every page, with every browser and taking a screen capture of each window, these images can then all be submitted to a human test team for manual verification. Flicking through a set of images in succession is much better than having to performing hundreds or thousands of actions to get at these views and then perform verification. This sort of semi automation is a great first step at saving test time and allowing faster releases on every iteration. The semi automation can be adjusted later to make it more automated as required. To add further automation to the image example, consider that image comparison software can be used to test whether an existing screen capture has already been verified by a human in the past. If it has, then a pass or fail outcome can automatically be assigned without having to submit the image to a human tester. This procedure provides a massive return on investment for regression testing.

How Tesults facilitates semi automation

When writing semi automated tests that require human verification to confirm a pass or fail result, such as in the UI verification example, the semi automated test result should be set to the ‘unknown’ result outcome rather than a ‘pass’ or ‘fail’ result when the automated results upload takes place. The results will then appear on Tesults as unknown results and human testers can examine each test case. If there are screen captures that require examining this is a fast process because Tesults displays images inline for each test case. The supplemental results view even provides all images for a test run in a carousel that can be quickly examined. After checking the images the human tester can then edit the test case result outcomes to assign a pass or fail result.


Edit:



Completed:


Once this process is finished the human tester can optionally choose to trigger a notification by email or to a Slack channel to make the rest of the team aware of the completed test run.

A middle way

Semi automation offers a sensible and pragmatic middle way between manual and automated testing in cases where full automation is not possible or the potential return on investment for a highly complex automation system is poor. Rather than the binary options of automating or not automating, semi automation offers degrees of automation that can have a significant impact on test efficiency.



By Ajeet Dhaliwal

Test automation reporting and failure intelligence

Consolidated test reporting for engineering teams. Store, track, and understand test results across every run and system.

Latest Posts

Why Cypress Tests Pass Locally but Fail in CI
Why Cypress Tests Pass Locally but Fail in CI
The environment differences that cause Cypress failures in CI, and how to tell a real bug from an environment flake
How to Track Test Pass Rate Over Time
How to Track Test Pass Rate Over Time
Why a single run cannot tell you if your test suite is getting healthier or worse, and how to track pass rate as a trend across runs so you can see the direction
How to Report WebdriverIO Test Results to a Dashboard
How to Report WebdriverIO Test Results to a Dashboard
Send WebdriverIO results somewhere durable and team-visible using the Tesults service, with the wdio.conf.js setup, enhanced reporting, and parallel run consolidation
How to Report Cypress Test Results to a Dashboard
How to Report Cypress Test Results to a Dashboard
Send Cypress results somewhere durable and team-visible using the Cypress Module API, with screenshots and videos attached and runs consolidated across CI
Why Playwright Tests Pass Locally but Fail in CI
Why Playwright Tests Pass Locally but Fail in CI
The real reasons Playwright tests go green on your machine and red in CI, how to debug each one, and how to tell a genuine failure from an environment flake
How to Detect and Handle Flaky Tests
How to Detect and Handle Flaky Tests
What makes a test flaky, how to detect flaky tests automatically instead of by memory, and how to handle them without disabling coverage
How to Report Vitest Test Results to a Dashboard
How to Report Vitest Test Results to a Dashboard
Send Vitest results somewhere durable and team-visible, with the setup details specific to Vitest, so multiple test jobs consolidate into one history you can act on
How to Report Go Test Results to a Dashboard
How to Report Go Test Results to a Dashboard
Go has no reporter plugin, so reporting go test results means parsing go test -json and uploading the cases yourself. Here is the whole pattern.
How to Report Jest Test Results to a Dashboard
How to Report Jest Test Results to a Dashboard
How to send Jest results somewhere they are kept, viewable by the team, and comparable across runs, without giving up the default reporter
How to View Playwright Test Results in CI
How to View Playwright Test Results in CI
How to get Playwright results out of the CI console and into a durable dashboard, including parallel shards, screenshots, and retained history
What Is a Test Results Dashboard and When Do You Need One
What Is a Test Results Dashboard and When Do You Need One
What a test results dashboard actually does, how it differs from your CI logs and your test framework report, and the point at which a team starts needing one
Diagnosing CI Failures Automatically With an AI Failure Diagnosis API
Diagnosing CI Failures Automatically With an AI Failure Diagnosis API
How to turn a red build into a root cause, a regression list, and a deploy gate without a human reading the logs