A recipient-preview rule changes, but the regression suite still checks the earlier behavior. An AI agent may choose a different route through the editor and expose a useful question. Neither a familiar script nor a new interaction sequence can establish correctness without an applicable expectation.
For a QA lead, the useful comparison is between repeatable checks of reviewed obligations and bounded exploration that helps decide what to investigate next. AI exploratory testing and scripted testing can share the same requirements, data and execution tools. They differ in how much of the next interaction is decided during the run, and in the evidence needed to review that decision.
Human exploratory testing combines learning about a product, designing tests and executing them in a closely connected cycle. A tester uses an observation to form a question and choose a further experiment. A charter provides direction without specifying every interaction. Curiosity, domain knowledge and interpretation remain important; exploration does not mean random clicking.
An AI-driven exploration loop can follow a related control pattern: receive a goal and current application observations, choose an available action, let a tool execute it, then use the returned state to choose what happens next. Browser Use's bu-2-0 model card describes this separation between model action selection and library execution. It is one documented implementation, not proof that every product marketed as an AI tester works identically.
Here, runtime adaptation means changing the next interaction in response to available observations. It does not imply that the model trains its weights during the session or acquires a human tester's judgment. The loop can only reason over the context and tools it receives, and its choices must stay inside the authorized scope.
A scripted test has reviewed instructions and expectations established before the execution being evaluated. It can contain conditionals, loops, parameterized data and negative cases. A branch written in advance is still predefined even when the branch taken depends on runtime state.
Playwright's documentation, for example, supports test-level and project-level parameterization as well as explicit assertions. Retrying an assertion until a stated condition is met changes when observations are sampled; it does not invent a new business expectation. Scripts are therefore useful for repeatedly checking known rules, including complicated rules, provided their inputs and assertions stay aligned with the current requirement.
AI authorship does not decide which category a test belongs to. An AI-generated script that a person reviews and then executes with fixed checks can be scripted regression testing. Conversely, a human can direct exploratory work through an automated interaction tool.
A test oracle is the basis for deciding whether an observed result is acceptable. It may include an approved requirement, a reviewed invariant or another justified comparison. The agent's ability to select a new interaction does not establish that its interpretation of the result is correct.
A disabled control might implement the intended rule. A surprising checkbox state might expose a missing requirement rather than a defect. Keep the observation, the expected behavior and the proposed interpretation separate. A confident explanation without a test basis remains a hypothesis.
The following packet holds the comparison constant. It supplies both approaches with the same initial state, inputs, changed behavior and unknowns. Every sequence discussed afterward is an author-written design illustration, not a record of testing.
Fictional packet INV-4 v2, unexecuted: The workflow is the recipient step of a draft invitation. Both approaches receive the same packet and begin with the synthetic draft recipient editor@example.test, recipient class Internal, an unchecked external-recipient acknowledgement, and no generated preview. Internal and External are supplied fixture classifications, not a rule inferred from the email domain. No account, browser, model, environment or application run has been provisioned or approved.
Requirement INV-4 v2 A: The earlier workflow allowed preview for either recipient class without acknowledgement. The changed workflow requires acknowledgement only for an External recipient. With External selected and acknowledgement unchecked, Preview must be disabled and no preview may be generated. With External selected and acknowledgement checked, Preview must be enabled; requesting Preview must produce a preview containing the selected recipient and an External marker. With Internal selected, Preview must be enabled without acknowledgement; requesting Preview must produce a preview containing the selected recipient and no External marker.
Allowed-input proposal INV-4 v2 B: Both approaches may use only editor@example.test with class Internal and partner@example.test with class External, edit between those recipients, toggle acknowledgement, request Preview when enabled, and reset to the stated initial state. This is a proposed allowlist for a future authorized exercise, not a grant of access. Sending invitations, changing permissions, visiting other destinations and using real recipient data are excluded.
Unknowns INV-4 v2 C: The packet does not specify whether acknowledgement persists when switching from External back to Internal and then to External, nor the wording of any notice or the timing of UI updates. No expected checkbox state, notice text or response-time threshold may be inferred for that sequence. The selected-class rules in A still apply after a switch; the missing persistence rule must remain an open question rather than an asserted defect.
Review boundary INV-4 v2 D: All interaction sequences and evidence examples below are author-written possibilities, not observed agent decisions, application logs or test results. Both approaches remain NOT RUN, with actual validation Blocked pending an authorized environment, approved access and human review of the test basis and unresolved expectations. A candidate finding would require review against this packet and separately authorized reproduction before defect acceptance or promotion to a reviewed regression check.
The known branch checks below each start from the shared state or its stated reset, so an earlier preview is not silently carried into another case. These are check designs, not runnable code or approved executions.
Comparison Point | Predefined Scripted Checks | Possible Adaptive Exploration | Evidence and Limit |
|---|---|---|---|
Shared starting state | Use editor@example.test, Internal, acknowledgement unchecked, no preview. | Use the identical initial state and INV-4 v2 packet. | Both NOT RUN; actual validation Blocked. |
Internal branch | Assert Preview enabled; request it; check selected recipient and no External marker. | May inspect the same branch before choosing an allowed follow-up. | Requirement A supplies these expectations, not an observed result. |
External without acknowledgement | Change to partner@example.test, External, acknowledgement unchecked; check Preview disabled and no preview generated. | May examine this changed branch after observing the supplied editor state. | Both disablement and absent preview are required; neither is measured here. |
External with acknowledgement | Check acknowledgement; assert Preview enabled; request it; check selected recipient and External marker. | May choose this follow-up after inspecting the unchecked branch. | Expected outcomes are fixed by A even when interaction choice adapts. |
Return and switch again | Add a reviewed sequence only with explicit expectations; retain unknown checkbox persistence. | May ask about persistence after an allowed return to Internal and back to External. | Persistence, notice wording and UI timing remain Unspecified; no bug is established. |
Retained record if later run | Reviewed script version, inputs, assertions, environment and actual run artifacts. | Ordered actions, observations, decision context, state, configuration and open questions. | Proposed records only; no traces, screenshots or Pass/Fail results exist for this example. |
The scripted approach can encode the changed External branch directly: start from reset, select the supplied External recipient, check both disablement and absence of a generated preview, then acknowledge and check the enabled-preview outcomes. Checking only the control's enabled state would omit the required preview content. Checking only an External marker would omit the selected recipient. The requirement contains several obligations even though the workflow looks small.
The possible exploratory approach can use its current observations to choose among allowed follow-ups. After inspecting the External branch, it might choose the return-to-Internal transition and then switch to External again because persistence could affect later behavior. That is a proposed decision pattern, not a claim that an agent took those actions or discovered a problem.
The persistence question has no approved answer in the packet. An agent must not turn an unchecked or retained acknowledgement into a failure merely because it expected another state. It can preserve the question while still checking the selected-class rules that are specified. Notice wording and timing also remain unknown; no convenient message or timeout should be invented to make the example look complete.
A script can include the same transition once its intended checks are reviewed. Exploration's contribution is choosing an informative follow-up during the session, not possessing exclusive access to unusual paths. Neither the existing script nor the possible exploration plan establishes exhaustive coverage of the editor.
A useful record lets another reviewer separate what was attempted, what was observed and why it might matter. The following are proposed evidence conventions for a future authorized run. They are not artifacts produced by the fictional example.
Retain the reviewed script version, the applicable requirement version, input data, configuration, relevant starting-state snapshot and assertions. If execution occurs, attach the actual attempt identity, result and supporting runner artifacts. A saved script without a run is a test definition, not evidence that the application passed it.
A passing assertion has a bounded meaning: its stated condition was satisfied under that attempt's conditions. It does not establish that every requirement was represented, that a stale assertion is correct or that other interaction sequences are safe. Review the assertions after the behavior changes instead of preserving the earlier expectation to keep a suite green.
Retain an ordered action-and-observation record, the charter, allowed scope, starting and relevant intermediate state, configuration, and model and tool versions where available. Link candidate findings to the exact observations that motivated them. Record open questions and explain why a follow-up was selected when that decision context is available; do not invent a rationale after the fact.
Keep references to actual screenshots, snapshots or tool outputs only when they exist. A written statement that Preview looked wrong is weaker than a retained observation tied to the recipient class, acknowledgement state and requirement. Even a captured image is an observation, not automatic proof of a defect or its root cause.
Reproduction can depend on application state, data, tool behavior, configuration and changing external conditions as well as model choice. Retaining a seed or version helps describe an attempt but does not guarantee an identical future path. Missing evidence should remain missing, with its consequence stated, rather than being reconstructed as a plausible trace.
More actions or screenshots do not establish more requirements coverage. Map the evidence back to specific obligations and mark those not checked. The same discipline applies to scripts: a large suite can repeatedly verify a narrow or outdated set of expectations.
Exploration and script authoring can be connected stages. BrowserStack's current Test Companion overview describes application exploration and automation-script authoring as distinct capabilities. Playwright's official agent documentation similarly separates a planner that explores and produces a plan from a generator that produces test files. These are documented vendor capabilities, not measured defect-detection quality or proof of availability in any particular tenant.
For the fictional editor, a future observation that contradicts a known rule would become a candidate finding. Review the applicable packet, the actual state and the captured behavior first. If the issue concerns persistence, obtain the missing expectation rather than declaring a bug. If a known-rule contradiction remains plausible, arrange reproduction under a separate authorized scope and preserve that attempt separately.
Only after review should a team accept a defect or promote a stable, explicit check into its regression baseline. Review any AI-authored assertions against the clarified requirement; do not copy an agent's preferred behavior into the expected result merely because the agent proposed it. Adding a check, approving its meaning and executing it are separate actions with separate evidence.
For a future pilot, propose an isolated synthetic recipient editor and name a human owner for the test basis and findings review. Confirm the environment, permitted tools, data handling and allowed interactions before enabling either approach. Stop on an unexpected destination, an action outside the allowlist, uncertain side effects or an inability to retain the evidence needed for review. Do not extend the exercise to sending invitations or changing access.
These controls are recommendations, not accepted assignments or access approvals. The example remains NOT RUN and actual validation remains Blocked until those prerequisites and unresolved expectations are addressed. No model, application, browser or reproduction testing was performed for this comparison.
Use scripted regression to repeat reviewed obligations, and use bounded exploration to pursue additional questions within the same authorized boundary. Keep the expected behavior stable while the interaction choice adapts, preserve unknowns, and let human review decide what becomes an accepted defect or a durable regression check.
Two reports can describe the same symptom while disagreeing about where the failure occurs. If a reviewer accepts a duplicate suggestion because the titles…
A checkout test times out while waiting for an order confirmation. The runner reports an assertion failure, the application records a failed request, and…
A refund story has a linked test called “Refund Permissions.” Its steps check the user's role before the first submission. The current acceptance criteria…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
