From Functional Testing to AI: Building the Right Foundation for Test Automation

As AI speeds up software delivery, technology leaders and quality engineering teams face an important question: do we have the right quality foundation underneath the automation and AI we are introducing?

That matters as most organizations expand functional test automation and begin adopting AI in software testing. The objective is to understand business risk and establish meaningful coverage, then decide where automation and AI can provide the greatest value.

These ideas were explored in ImpactQA’s webinar, “AI Won’t Fix Bad Testing: Building the Right Functional Testing Foundation Before You Automate,” held on September 24, 2026.

This article covers the progression from functional testing to sustainable automation, quality engineering, and AI-plus-human testing stemming from the webinar.

Watch the webinar: AI Won’t Fix Bad Testing: Building the Right Functional Testing Foundation Before You Automate

Why a Strong Functional Testing Foundation Comes First

AI is helping engineering teams generate code faster and increasingly test software faster. But faster delivery does not automatically mean lower quality risk.

As the speed and volume of change increase, organizations also have more scenarios, integrations, data combinations, and edge cases to validate. The more important aspect is whether increased testing capacity is improving confidence in the things that matter most.

AI can help identify coverage gaps, assess risk, prioritize scenarios, generate tests, and analyze failures. Business priorities, acceptable risk, and the final release decision, however, continue to require clear human ownership.

This is why the quality foundation matters. A strong foundation gives AI direction. Automation provides repeatability and scale. AI can add intelligence and amplify that capability, while people provide context, judgment, governance, and accountability.

1. Test Design and Meaningful Functional Testing Coverage

The first area is whether the right business scenarios are being tested.

A strong functional testing approach needs to consider negative paths, integrations, boundaries, and critical business journeys. The emphasis is on meaningful coverage rather than simply increasing the number of test cases.

In one print and text product engagement, the product was continuously evolving while the existing regression approach remained heavily focused on a defined regression model. As the product became more complex, the quality scope also needed to evolve.

The existing test landscape had gaps, so a broader functional regression test foundation was established, with approximately 700 additional test cases covering edge and integration scenarios.

The important shift was in the way automation was viewed. Instead of asking how many more tests could be automated, the focus moved to whether the business and customer journeys that mattered most were actually covered.

2. Test Data for Realistic Business Conditions

The second area is test data.

Do teams have the data needed to validate realistic business conditions and combinations?

An insurance assessment highlighted the importance of this area. Multiple data combinations and test-complexity gaps were identified, with approximately 40,000 additional datasets helping expand coverage of critical business scenarios. Coverage moved from approximately 20% to 100% after missing test-data combinations were identified.

Before automating more, organizations need to understand where coverage is missing and where data combinations are creating complexity.

3. Test Environments and Testing Confidence

The third area is the test environment.

Can the team trust that the environment and configuration reflect the conditions in which the software will operate?

Environment instability can affect automation results and create noise. QA environments also need to reflect production conditions closely enough to support meaningful testing. At scale, this connects directly with test-data strategy, including data seeding, dynamic data generation, APIs, CSV-based data, and masked or synthesized production data.

4. Shared Quality Ownership

The fourth area is ownership.

Business and product define the outcomes that matter. Engineering builds testable software and owns unit and component quality. QA brings risk-based validation, integration testing, exploratory testing, and quality intelligence. DevOps embeds quality into delivery pipelines.

This creates a shift from QA owning quality toward the organization owning quality, with QA providing the expertise required to manage quality risk.

Measuring Business Risk Beyond Automation Volume

Once the functional testing foundation is established, the next question is where automation should actually be applied.

More automation does not automatically mean more quality.

Consider two organizations. Organization A has automated 80% of its regression suite. Organization B has automated 50%. If Organization B’s automated tests protect revenue-critical and business-critical customer journeys while Organization A has automated mostly stable, low-risk scenarios, automation percentage alone cannot explain which organization has stronger business-risk coverage.

The focus therefore needs to shift from how much has been automated to how much business risk is actually covered.

Measuring Quality Beyond Automation Percentage

Quality can be viewed through three layers.

1. Business outcome: Are critical customer, revenue, or compliance workflows protected? Are defects escaping into production?
2. Quality effectiveness: How early are defects detected? What level of defect leakage exists? How reliable is the automation?
3. Engineering efficiency: How much time does testing take? How much effort goes into automation maintenance and investigating false failures?

Automation coverage remains useful, but it needs context. At the same time, business risk needs to be reduced at a sustainable engineering cost.

Using Business Impact and Likelihood of Failure

A practical framework is to map areas against business impact and likelihood of failure.

• High-impact, high-likelihood areas receive prioritized testing, automation, monitoring, and engineering attention.
• High-impact, low-likelihood areas require deeper validation and stronger controls.
• Low-impact, high-likelihood scenarios can be automated where repetition creates efficiency.
• Low-impact, low-likelihood areas may not justify significant investment.

The goal is to direct engineering effort toward the areas where it can reduce the most business risk.

How Test Automation Grows Into Quality Engineering

Automation at scale introduces another question: can the organization sustain it?

A telecom expense management procurement platform had a large and growing regression suite that needed to be scaled without creating a significant maintenance problem. Approximately 7,000-plus test cases were automated in the first year.

The larger consideration was the evolution of the framework itself. Scalability, maintainability, and execution efficiency became important as automation expanded.

Application changes can break locators. Test-data changes can create failures. Environment instability can create noise. Timing dependencies can lead to intermittent results. Teams can eventually spend engineering capacity determining whether a failure represents a real defect or a broken test.

The goal is therefore maximum useful automation at a sustainable cost.

Framework architecture, test-data management, environment design, and maintainability all become increasingly important as the suite grows.

Moving From Test Automation to Quality Engineering

This sustainability challenge requires a broader view of quality.

Traditional QA generally focuses on validation toward the end of the delivery lifecycle. Quality engineering looks across requirements, testability, automation, environments, CI/CD, observability, and production feedback.

The objective is to make the organization better at preventing, detecting, and responding to quality risks.

Quality is moved upstream by making it a shared responsibility across business, product, development, QA, and DevOps.

A testing CoE can establish governance, standards, tools, and reusable QA practices. QA engineering champions can bring domain and specialist expertise across automation, performance, security, and other testing areas. A core-flex model can combine a stable core team with specialist capabilities deployed when needed.

Testing can also be integrated into delivery pipelines through continuous quality gates between development, QA, staging, and production.

Where AI Fits Into Test Automation

With the foundation and automation strategy in place, AI can support multiple stages of the testing lifecycle.

• AI can generate test scenarios and automation, analyze failures, identify potential coverage gaps, generate test data, and help maintain scripts. It can increasingly reason across large volumes of requirements, code, test results, and defects.
• AI can identify scenarios that may have been missed. People validate which scenarios represent meaningful business risk.
• AI can generate hundreds of tests. People ensure those tests create value.
• AI can assess failures and recommend what should be tested next. People remain accountable for how the information is used and for the quality decision.

When AI Becomes the Test Author

With AI in test automation, AI is increasingly writing the tests themselves. It can generate hundreds or thousands of test scenarios quickly, and those scenarios may still be shallow, redundant, or focused on the wrong areas. As our speaker put it:

“Generating a test is not the same as generating a valuable test.”

The quality of an AI-generated recommendation depends on business context, data, risk criteria, and governance. That is why AI test automation output still needs to be evaluated using the same risk-based approach applied to other testing activities.

One speaker framed it this way: 1,000 generated tests ≠ 1,000 valuable tests.

The role of the quality professional also shifts. AI can take on more generation, analysis, and repetitive work, while quality professionals increasingly focus on understanding business risk, validating AI recommendations, asking the right questions, and providing governance.

“The role shifts rather than disappears. AI scales the work. Humans validate the value.”

A Four-Stage Path to AI-Augmented Quality Engineering

The progression can be viewed across four stages:

Five Questions to Ask Before Scaling AI Testing

Before introducing AI more broadly, five questions can help teams assess their current quality foundation:

• Do we know which business journeys represent our highest quality risks?
• Does our automation protect those journeys, or are we primarily measuring automation volume?
• Can our team trust the data, environment, and results behind our testing?
• Is quality truly shared across product, engineering, QA, DevOps, and the business?
• If AI doubles our testing capacity tomorrow, would our quality foundation and governance be ready for it?

These questions bring the full progression together: functional testing establishes coverage, automation provides repeatability and scale, quality engineering broadens quality responsibility, and AI adds intelligence and acceleration.

Final Say

“Better testing is about understanding the risks, focusing the investment, and continuously improving quality.”

The journey from functional testing to automation, quality engineering, and AI-assisted testing starts with the right foundation. Meaningful coverage, reliable test data and environments, clear ownership, and a risk-based approach create the base on which automation can scale.

From there, automation brings repeatability and scale, quality engineering extends quality across the delivery lifecycle, and AI adds intelligence and acceleration. The role of people remains central in providing business context, judgment, governance, and accountability.

ImpactQA’s test automation services have evolved along this journey—from traditional automation and API testing to Playwright MCP, AI-assisted automation with Playwright MCP and TOSCA, and Falcon, our AI-driven autonomous solution. These capabilities are being applied across enterprise environments including SAP S/4HANA, Oracle EBS, and cloud platforms.

The technology will continue to evolve. The foundation determines how effectively it delivers value.

Frequently Asked Questions (FAQs)

Share this post

Related Posts

Our Case Studies