Test Automation Predictions for 2021

Michael Battat’s “9 Test Automation Predictions for 2021” is a set of personal forecasts about how software teams might shift testing into development, builds, and visual validation. The central idea is earlier, faster feedback with more developer ownership. The article does not establish whether the predictions came true, so they should be read as forecasts, not as an outcome report.

Battat’s article page currently displays a November 7, 2022 date, even though its text is explicitly about predictions for 2021 and closes by asking readers to look ahead. The date and framing are worth keeping in view when citing it. [Battat’s article]

At a glance: the nine predictions

#	Prediction	Practical implication
1	Stand-alone QA faces pressure from integrated quality engineering.	Bring quality work closer to development to shorten feedback and find defects earlier.
2	Development teams take ownership of core test automation.	Developers write and maintain more of the automation, with JavaScript front-end testing and Cypress among the examples discussed.
3	Primary automation moves into the build.	Run core checks, including system and end-to-end tests, as part of build workflows.
4	Speed and coverage become the driving test metrics.	Optimize feedback time and parallel execution while removing redundant checks and examining untested code.
5	AI helps select tests to ensure coverage.	Use AI as an aid for generating test conditions, standardizing setup, finding untested code, and spotting duplication.
6	Visual AI page checks grow “10x.”	Visual validation gains attention. The figure is Battat’s forecast, not an audited market measurement.
7	Visual tests run on every check-in.	Move rendering and behavior checks earlier, into builds and merge workflows.
8	Visual tests run alongside unit tests.	Pair visual checks with small, fast tests as part of routine development feedback.
9	The gap between automation adopters and non-adopters grows.	Teams with modern automation may deliver faster, while teams without it face harder speed-versus-quality tradeoffs.

1. Quality engineering becomes more integrated

Battat anticipated challenges for stand-alone QA groups as teams integrated quality activities more closely with development. The reason in the article is practical: shorter feedback cycles help surface defects earlier, while the code and context are still familiar to the people changing them.

This prediction is about where quality work happens and who participates. It does not mean that specialist quality skills become unnecessary. It suggests that testing knowledge should inform design, implementation, and build decisions rather than arrive only at a later handoff.

2. Developers own more core automation

The forecast expected developers to take greater responsibility for core automation. Battat singled out JavaScript for front-end automation and anticipated Cypress gaining adoption alongside Selenium’s JavaScript bindings. These are examples from his prediction, not evidence that one tool universally replaced another.

In practice, developer ownership works best when teams agree on test boundaries, coding conventions, stable test data, and who maintains failures. A test suite that developers cannot run quickly or understand can become a bottleneck even if ownership has formally moved.

3. The build becomes the primary automation point

Battat predicted that core checks—including system and end-to-end tests—would move earlier into builds. The intended benefit is actionable feedback: a developer can investigate a failure soon after a change instead of discovering it much later.

That does not require every test to run on every commit. Teams can keep a fast set of high-value checks on the critical path and run broader or slower suites in parallel or at later stages. The prediction’s important criterion is when the result reaches the team, not simply whether a test exists in a pipeline.

4. Speed and coverage shape the test metric

The article argues that teams would prioritize quick feedback and parallel execution while reducing redundant tests and paying attention to unexercised code. Speed and coverage are related but different: a fast suite can miss important behavior, while a broad suite can be so slow that developers stop relying on it.

A useful way to evaluate a suite is to ask how long a developer waits for a trustworthy signal, which important behaviors it exercises, and whether each test adds distinct value. Coverage measurements can identify code that tests do not reach, but they do not by themselves prove that assertions check the right behavior.

5. AI assists with test selection and coverage

Battat forecast AI use for generating test conditions, standardizing setup, locating untested code, and finding redundant checks. The framing is assistance: AI could help teams decide what to test or produce candidate tests, while the team remains responsible for whether the test represents a real requirement.

For comparison, Forrester made a separate forecast in its Software Development Predictions 2021 webinar, originally broadcast January 11, 2021: “At least a third of test professionals will use machine learning to make test automation smarter.” This was a forecast, not a measured adoption statistic. The webinar page identifies Chris Gardner and Jeffrey Hammond as presenters. [Forrester webinar]

These two sources support a claim about what analysts and practitioners expected, not a claim about what adoption reached. They also do not specify one required AI architecture or product.

6. Visual AI checks were forecast to grow “10x”

Battat predicted a tenfold rise in pages checked using visual AI. He said the prediction drew on feedback from Applitools Visual AI customers and the company’s tracking of pages using visual AI. The article does not provide a period, baseline, or independently verifiable dataset, so “10x” should remain attributed to Battat as a forecast—not repeated as an industry statistic.

Visual testing checks rendered output, which can reveal layout or appearance changes that a functional assertion may not catch. It complements functional tests; it does not establish that a page’s underlying behavior is correct.

7. Visual checks move to every check-in

The prediction was that visual validation would shift earlier into code builds and merge workflows. Running a relevant visual check close to a change can help teams identify rendering regressions before they reach a later release stage.

For this to be useful, teams need a clear baseline policy, a way to review intentional changes, and a strategy for dynamic content. Otherwise, frequent checks can generate noisy differences that obscure meaningful ones.

8. Visual tests run with unit tests

Battat described customers running visual validation alongside standard unit tests and predicted broader adoption of visual unit testing. The idea is to make visual feedback part of the routine developer loop, as familiar as other fast checks.

“Alongside” need not mean that every visual comparison has the same runtime or isolation as a unit test. A team can group checks by speed and scope, keep the smallest useful visual checks close to the commit, and run wider browser coverage separately.

9. Automation adopters pull further ahead

Battat expected the distance between teams using modern automation and teams that were not to grow. In his framing, automation adopters could deliver faster, while teams without it would face more difficult tradeoffs between speed and quality.

This is a prediction about compounding workflow advantages, not a quantified comparison of team performance. It is also not proof that automation alone causes delivery speed: test reliability, maintainability, architecture, and the ability to act on feedback all matter.

What connects the predictions

Three themes tie the forecasts together:

1. Shift feedback earlier. Integrate testing with development, builds, check-ins, and unit-test workflows.
2. Make feedback useful at speed. Improve parallel execution and coverage while reducing duplicated or noisy checks.
3. Expand what automation can inspect. Use AI as an aid to coverage and selection, and add visual validation alongside functional checks.

Together, these themes describe a direction for test workflows. They do not prove that every team should run every kind of check at every stage. A team still has to choose the right balance of runtime, coverage, and maintenance for its product.

How to assess a test automation workflow using these ideas

The predictions suggest practical questions for reviewing a pipeline. They are evaluation criteria implied by Battat’s article, not a formal benchmark.

1. Measure feedback time. Record how long the developer waits for the first useful result and for the full suite.
2. Check coverage gaps. Identify important paths or code that current tests do not exercise, then decide whether tests are warranted.
3. Look for redundant checks. Find tests that duplicate the same signal without catching distinct failures.
4. Review integration points. Determine which checks run on commits, builds, merges, and later release stages.
5. Separate test purposes. Know which checks validate behavior and which inspect rendered appearance.
6. Evaluate AI suggestions as proposals. Review generated conditions and selected tests against actual requirements and failure modes.
7. Track trust, not just volume. Investigate flaky failures and false alarms; a large suite that teams routinely ignore is not effective feedback.

What the sources do not establish

• They do not establish which of Battat’s nine predictions came true.
• They do not establish that the predictions represented industry consensus.
• They do not independently verify the “10x” visual AI forecast.
• Forrester’s “at least a third” statement is a forecast, not a measured adoption result.
• They do not provide comparative benchmark results for frameworks, services, or team delivery performance.

A retrospective assessment would need separate evidence gathered after 2021, such as comparable adoption data, test-workflow studies, or measured outcomes. The cited material alone cannot answer that historical question.

Or skip the browser setup

If your visual checks need clean website screenshots, ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. See the API documentation for parameters and setup.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

• Cookie banners are accepted and removed before capture; 60+ known consent platforms, newsletter popups, and chat widgets can be removed, with each step configurable.
• Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing; response headers report the page verdict and billing status.
• An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.
• The free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 screenshots; every feature is available on every plan.

Sign up for 1,000 free screenshots a month, with no card required.

Troubleshooting visual capture in automation

Symptom	Likely cause	Practical fix
Visual output differs between runs	Dynamic content, animation, time-dependent data, or inconsistent viewport and device scale.	Stabilize test data and capture settings; wait for a meaningful page condition; disable or account for animations where appropriate.
A page looks blank in the capture	The page has not rendered yet, navigation failed, or a bot check is blocking access.	Check the response and browser logs, wait for a stable selector, and verify the URL is reachable in the same environment.
Lazy-loaded images are missing	The capture happened before scrolling or image loading completed.	Use a full-page capture mode that loads lazy images, or scroll the relevant content into view and wait for it.
Tests are slow after adding visual checks	Too many broad captures run serially in the critical path.	Prioritize representative pages, parallelize independent checks, and move lower-priority coverage to a later stage.
Frequent failures are not actionable	Flaky checks, stale baselines, or intentional changes are not reviewed consistently.	Assign ownership for baseline updates, separate infrastructure errors from visual differences, and remove checks that provide no distinct signal.

Performance, reliability, and cost considerations

• Runtime: Browser startup, page load, image loading, and comparison work all contribute to feedback time. Keep the commit-level suite focused and parallelize independent pages where the environment permits.
• Reliability: Treat flaky tests as a product-quality issue in the test system. Use stable data and conditions, retain enough diagnostics to explain a failure, and make ownership for failures clear.
• Coverage: More screenshots or tests do not automatically mean better coverage. Select cases that exercise distinct states, layouts, and behaviors.
• Cost: The cited prediction sources do not provide pricing or cost benchmarks. When evaluating a hosted service, compare the pricing model, included usage, concurrency, and the cost of retries and failed captures using current vendor documentation.

FAQ

Were these predictions written as a consensus forecast?

No. Battat labels them as his personal predictions. The article should not be presented as a consensus study.

Did Forrester say that a third of test professionals already used machine learning?

No. The webinar takeaway forecast that at least a third would use machine learning; it is not a measured result.

Does visual testing replace functional testing?

No. Visual checks inspect rendered output, while functional checks validate behavior. The predictions discuss bringing these signals into the development workflow.

Can the sources show whether the forecasts came true?

No. The available sources describe the forecasts but do not provide an outcome audit.