Rahul Parwal and Rosie Sherry discuss how quality professionals can navigate AI adoption, avoid the noise, and find where human skill still matters most.

The inputs, values, and system state used to execute a test case and verify that software behaves as expected. Test data spans a wide range of forms: valid inputs that exercise the happy path, invalid or boundary inputs that probe edge cases, and pre-existing system state such as user accounts, tokens, or database records that a test depends on. In automated testing, managing test data carefully is critical: each test should operate against a known, isolated set of data, use explicit fixtures or seeded records rather than shared or assumed state, and clean up after itself to avoid polluting subsequent runs. AI-generated automation scripts frequently omit proper test data setup and teardown, making this one of the key areas a human engineer must review and strengthen before the code is considered framework-ready.

A gradual, often unnoticed divergence between the configuration of different environments (such as development, staging, and production) that causes tests to behave differently depending on where they run. Config drift is one of the common causes of environment-related test failures, and a key cluster to look for when triaging automated test results. It can manifest as a service that behaves differently in CI than locally, a feature flag set differently across environments, or a third-party dependency pointing to a different endpoint.

The practice of framing instructions or context given to an AI tool in a way that shapes the quality and relevance of its output. In a testing context, how a requirement or instruction is written for an AI tool significantly affects what test cases or automation code it generates. Rather than simply asking an AI to write test cases, effective prompting names the risks to surface, specifies the types of tests needed (positive, negative, boundary), and provides enough context about the system under test for the AI to produce targeted, useful output. Poor prompting produces plentiful but shallow results; well-structured prompting produces focused, risk-aware coverage.

The externally visible outcome of a system action that a test can verify, as distinct from internal implementation details. In test automation, assertions should check observable behaviour rather than internal state: for example, checking that a specific error message appears on screen, or that a button becomes visible after a reset, rather than checking a variable value inside the code. AI-generated assertions sometimes check implementation details that are brittle or invisible to the user, so reviewing whether each assertion targets a genuine observable outcome is one of the key disciplines when reviewing AI-produced automation code.

Test data that is explicitly inserted into a system or database before a test runs, in order to establish a known, controlled state for the test to operate against. Seeding ensures tests are repeatable and do not rely on pre-existing or shared data that may change between runs. For example, a login test might seed a user account with a specific username and password before executing, then clean up that account afterwards. Seeded data is a key discipline in robust test automation and something AI-generated scripts frequently omit, requiring a human to add it.

A judgement about whether a piece of software is sufficiently tested, stable, and low-risk to be deployed to users. Release readiness takes into account test coverage, outstanding defects, severity of known issues, risk exposure, and stakeholder confidence. It is one of the decisions that is often explicitly identified as remaining human responsibility and not something that should be delegated to AI, because it requires contextual knowledge of the business, the users, and the acceptable risk threshold that an AI tool cannot reliably supply.

The deliberate management of the data used in automated tests, including how it is created, seeded, isolated per test, and cleaned up after execution. Good test data control ensures that each test runs against a known, predictable state and does not depend on or pollute shared data. Approaches include explicit fixtures (pre-defined data sets loaded before a test), seeded data (data inserted directly into a database or system before the test runs), and cleanup passes (removing test-generated data after execution). AI-generated automation code often lacks proper test data control, making it one of the key areas a tester must review and strengthen before committing scripts to a CI/CD pipeline.

The practice of using AI to generate the initial structural skeleton of an automation script, including imports, class setup, basic test structure, and placeholder steps, as a starting point for a tester or engineer to build upon. Scaffolding produces a draft that handles the repetitive boilerplate of automation code quickly, but it is not production-ready. The engineer still needs to apply the correct locator strategy, add meaningful assertions, manage test data, and integrate the scaffold into the existing automation framework and CI/CD pipeline. Think of it as the rough framing of a house: structurally present, but not finished or safe to move into yet.

A specific type of self-healing behaviour in which an automated test tool detects that a UI element can no longer be found using an existing locator and attempts to identify a replacement locator that points to the equivalent element. Unlike broader self-healing (which may alter assertions or test logic), selector repair is narrowly scoped to fixing broken element references caused by DOM or UI changes. It is generally considered a lower-risk form of self-healing when done transparently, but should still require human review rather than being applied automatically and silently.

In the context of AI-powered tools, the consumption of tokens (the units by which large language models process and generate text) as a measure of how much compute a given interaction or workflow requires. Token usage has a direct cost implication: the more complex the prompt, the longer the context, and the more requests made, the higher the token consumption and associated cost. For teams integrating AI into testing workflows at scale, token usage becomes a practical constraint that affects how often the AI can be called, how much context can be included, and ultimately the economics of using AI tooling long-term. Rate limits on tokens per minute can also affect throughput when many tests are run in parallel.

The primary, expected flow through a feature or user journey, where all inputs are valid and everything works as intended. Testing the happy path confirms that the core functionality works under normal conditions, but it represents only a fraction of the scenarios a tester should cover. A skilled tester uses the happy path as a baseline and then designs additional tests for invalid inputs, edge cases, boundary conditions, and failure states. AI tools can help extend coverage beyond the happy path quickly, but they depend on the tester having already understood the happy path before evaluating what the AI produces.