Manual Test Cases Are the Baseline AI Agents Need
When the same process generates both implementation and its tests, a green pipeline only proves code and tests agree, not that the behavior is correct. The article argues for manual test cases as an independent behavioral baseline in agentic development. Written in Markdown or Gherkin, they capture business scenarios, preconditions, expected outcomes, and boundary conditions without depending on test framework internals. The proposed workflow splits responsibilities: a development agent implements, a dedicated automation agent turns approved cases into E2E checks, and a requirement-review agent blocks any test change not backed by an approved requirement. This helps avoid an implement-fail-fix-regression loop and keeps intent intact through rewrites and framework migrations. Useful for QA engineers, engineering managers, and anyone building agent-driven delivery pipelines. Note: the piece is published by Testomat.io, a test management vendor, and closes with a product pitch.
AI agents are changing the economics of software development. Source code can now be generated, refactored, and replaced faster than it can be reviewed. Automated tests are generated as side artifacts of the code production, which raises the question of testing AI-generated code before it reaches production. This acceleration is valuable. But it creates a new governance problem:
When the same development process produces both the implementation and the evidence that the implementation is correct, who independently verifies the intended behavior?
AI 智能体正在改变软件开发的成本结构。源代码的生成、重构和替换速度，已经快过人工评审的速度。自动化测试作为代码生产的附属产物被一并生成，这就引出一个问题：AI 生成的代码在进入生产之前，该如何测试？这种加速本身很有价值，但同时也带来一个新的治理难题：
当同一个开发流程既产出实现，又产出“实现是正确的”这一证据时，谁来独立核验预期行为？
Traditionally, automated tests were expected to act as an independent auditor of software. They described expected behavior and warned the team when an implementation violated it.
In an agentic workflow, that independence can quietly disappear. A development agent implements a feature, runs the test suite, encounters failures, and updates the tests until everything passes. The final result looks healthy: the code compiles, the pipeline is green, and the automated tests confirm what the system does. However, those tests may no longer verify what the system should do. They may simply document and reinforce what the latest implementation already does.
This is particularly dangerous when agents infer expected behavior from the source code itself. If the implementation contains a misunderstanding, the generated tests can reproduce the same misunderstanding. The test suite then becomes an artifact of the code rather than an independent source of verification. A passing test suite is valuable evidence. But only when its expectations come from a source that is independent of the implementation.
传统上，自动化测试被期望扮演软件的独立审计者：它们描述预期行为，并在实现背离预期时向团队发出警告。
在智能体工作流中，这种独立性可能悄悄消失。开发智能体实现一个功能、跑一遍测试套件、遇到失败就修改测试，直到全部通过。最终结果看起来很健康：代码编译通过、流水线绿色、自动化测试确认了系统的行为。但这些测试可能不再验证系统应该做什么，而只是记录并强化最新实现已有的行为。
当智能体从源代码本身推断预期行为时，这一点尤其危险。如果实现中包含一个误解，生成的测试会复现同样的误解。测试套件于是变成代码的派生物，而不是独立的验证来源。通过的测试套件是有价值的证据，但前提是它的预期来自独立于实现的来源。
Teams often notice this problem indirectly. A development agent starts spending ten or more minutes during every coding session to repair end-to-end tests. Assertions are rewritten, selectors are replaced, snapshots are regenerated, and expected results are adjusted. Tools for self-healing test automation absorb part of that work, but they repair the mechanics, not the expectation.
Some maintenance is legitimate. Interfaces change, workflows evolve, and automation must follow approved product decisions. However, persistent repair work is a warning signal. It may indicate the following:
Expected behavior is not clearly defined.
Tests are coupled too closely to implementation details.
Agents cannot distinguish an intentional product change from a regression.
Automated checks are being modified to accommodate the code.
The team lacks an independent behavioral baseline.
At this point, organizations usually make one of two choices. They either keep repairing an increasingly unstable E2E suite or reduce their reliance on E2E testing because it appears too expensive. Neither option addresses the underlying problem. The missing component is not more automation. It is a stable, reviewable definition of expected behavior.
团队往往间接地发现这个问题。开发智能体会在每次编码会话中花上十分钟甚至更久来修复端到端测试。断言被重写、选择器被替换、快照被重新生成、预期结果被调整。自愈式测试自动化工具能吸收其中一部分工作，但它们修复的是机制，不是预期。
有些维护是合理的。接口会变化、工作流会演进，自动化也必须跟随已批准的产品决策。然而，持续的修复工作是一种警告信号，可能意味着以下情况：
- 预期行为没有被清晰定义。
- 测试与实现细节耦合过紧。
- 智能体无法区分有意的产品变更与回归。
- 自动化检查正在被修改以迁就代码。
- 团队缺少独立的行为基线。
此时，组织通常会在两种选择间二选一：要么继续修复一套越来越不稳定的 E2E 套件，要么因为 E2E 看起来太昂贵而减少对它的依赖。两种选择都没有解决根本问题。缺失的不是更多自动化，而是一个稳定、可评审的预期行为定义。
Manual test cases can provide that definition.
In this context, “manual” does not necessarily mean that a person must execute every test by hand during every release. It means that the test case is expressed independently of automation code: in plain language, Markdown, Gherkin, or another format that product, engineering, and QA stakeholders can review. A useful manual test case describes:
The business scenario.
Relevant preconditions.
The user’s actions.
The expected outcome.
Important negative and boundary conditions.
The requirement or acceptance criterion it verifies.
Because these cases are readable without understanding the test framework, they create a shared contract among product managers, developers, QA engineers, and AI agents. They can be reviewed before implementation, validated with stakeholders, versioned alongside other delivery artifacts, and used as the input for automation.
Changing a Markdown scenario is also substantially cheaper than repeatedly debugging a complex E2E test. The team can settle the intended behavior first and update the automation only after the behavioral change has been approved.
手工测试用例正好能提供这个定义。
这里所说的“手工”，并不一定意味着每次发布都要由人逐条执行。它指的是测试用例独立于自动化代码来表达：用产品、工程和 QA 相关方都能评审的自然语言、Markdown、Gherkin 或其他格式。一份有用的手工测试用例应描述：
- 业务场景。
- 相关前置条件。
- 用户的操作。
- 预期结果。
- 重要的负向与边界条件。
- 它所验证的需求或验收标准。
因为这些用例不需要理解测试框架就能读懂，它们会在产品经理、开发者、QA 工程师和 AI 智能体之间形成一份共同契约。用例可以在实现之前被评审、与相关方确认、随其他交付物一起版本化，并作为自动化的输入。
修改一份 Markdown 场景，也比反复调试一个复杂的 E2E 测试便宜得多。团队可以先确定预期行为，只有在行为变更获批之后，再更新自动化。
A more reliable workflow separates implementation, behavioral specification, and automated verification. In practice, this means separate agents for writing cases and for automating them:
Requirements define the intended outcome. Product requirements and acceptance criteria explain why the change exists and what value it should deliver.
Manual test cases make the behavior concrete. QA translates the intent into reviewable scenarios, including negative paths, boundary conditions, permissions, data states, and regression risks.
The development agent implements the behavior. It may propose changes to the manual cases when it discovers ambiguity or a legitimate product impact, but it should not silently redefine them.
A dedicated automation agent implements the E2E checks. Its source of truth is the approved test case, not merely the current source code or rendered interface.
A requirement-review agent audits behavioral changes. When a manual case is changed, this agent checks whether the modification is supported by an approved requirement and whether it conflicts with existing behavior.
This separation prevents one agent from changing the implementation, redefining the expectation, and approving the result within the same feedback loop.
更可靠的工作流会把实现、行为规格和自动化验证分开。在实践中，这意味着写用例和做自动化由不同的智能体承担：
需求定义预期结果。产品需求和验收标准解释这次变更为什么存在、应带来什么价值。
手工测试用例让行为具体化。QA 把意图转成可评审的场景，包括负向路径、边界条件、权限、数据状态和回归风险。
开发智能体实现行为。它可以在发现歧义或合理的产品影响时，提出修改手工用例，但不应悄悄重定义它们。
专门的自动化智能体实现 E2E 检查。它的真相来源是已批准的测试用例，而不只是当前源码或渲染出来的界面。
需求评审智能体审计行为变更。当一条手工用例被修改时，它会检查该修改是否得到已批准需求的支持，以及是否与现有行为冲突。
这种分离可以防止同一个智能体在同一个反馈循环里，既修改实现、又重定义预期、再批准结果。
Manual test cases can serve as a clean, accessible source of truth. Both humans and AI agents can review a concise set of user scenarios much faster than they can interpret thousands of lines of application and automation code. Teams already work this way with an AI skill that drafts test cases from an approved template.
Together, these cases form a knowledge base of the behavior the organization expects to preserve. They describe critical user journeys, business rules, negative paths, permissions, data states, and expected outcomes independently of how the system currently implements them. They provide a clear answer to a fundamental question after every change:
Which user scenarios must continue to work?
For this reason, every meaningful feature addition should include corresponding manual test cases. A change is not fully specified until its expected behavior can be expressed as reviewable scenarios. These cases should be validated before the implementation becomes the new baseline and before automated E2E tests are generated or updated.
手工测试用例可以充当一个干净、易用的真相来源。人类和 AI 智能体审阅一组简洁的用户场景，远比解读数千行应用代码和自动化代码快。有些团队已经在这样工作：用一个 AI 技能根据已批准的模板起草测试用例。
这些用例汇集起来，就构成组织希望保留的行为知识库。它们独立于系统当前的实现方式，描述关键用户旅程、业务规则、负向路径、权限、数据状态和预期结果。每次变更之后，它们都能回答一个根本问题：
哪些用户场景必须继续工作？
正因如此，每个有意义的功能新增都应包含相应手工测试用例。一个变更要等到预期行为可以表达为可评审场景时，才算完整定义。这些用例应当在实现成为新基线之前、在生成或更新自动化 E2E 测试之前，先得到验证。
This creates a growing behavioral model of the product. When a new feature is proposed, its test cases can be compared with the existing knowledge base to identify:
Contradictions with established business rules.
Changes to previously supported behavior.
Overlapping or duplicate scenarios.
Missing negative and boundary conditions.
Effects on permissions, data integrity, and integrations.
Regression risks across related user journeys.
这就形成一个不断生长的产品行为模型。当新功能被提出时，可以把它的测试用例与现有知识库对比，以识别：
- 与既定业务规则的矛盾。
- 对先前支持行为的改变。
- 重叠或重复的场景。
- 缺失的负向与边界条件。
- 对权限、数据完整性和集成的影响。
- 相关用户旅程上的回归风险。
Manual test cases should remain stable enough to protect expected behavior, but they must not be treated as immutable. Products evolve, requirements change, and previously valid scenarios may need to be revised or retired. The important principle is to make these changes deliberate and traceable. You need to review them separately, so implementation never introduces them as a side effect.
This is where a requirement-review agent becomes valuable. When a development agent proposes adding, modifying, or removing a manual test case, the requirement agent can compare the proposal against:
Approved requirements and acceptance criteria.
Existing manual test cases.
Documented business rules.
Backward-compatibility expectations.
Contractual or regulatory obligations.
Previously accepted product behavior.
The agent should determine whether the proposed test change represents a legitimate product decision, a correction to an inaccurate case, or an attempt to accommodate a regression. If a new feature breaks an existing scenario, and an approved requirement fails to replace it, you need to block the change and ask for a review. The test case stays as it is, and so does the E2E automation.
手工测试用例应当保持足够的稳定，以保护预期行为，但不能被当作不可更改。产品会演进、需求会变化，先前有效的场景可能需要修改或退役。重要的原则是让这类变更变得有意识、可追溯。你需要单独评审它们，使实现永远不会把它们作为副作用引入。
这正是需求评审智能体的价值所在。当开发智能体提出新增、修改或删除一条手工测试用例时，需求智能体可以把提案与以下内容对照：
- 已批准的需求与验收标准。
- 现有手工测试用例。
- 文档化的业务规则。
- 向后兼容的预期。
- 合同或监管义务。
- 先前已接受的产品行为。
这个智能体应当判断：提议的测试变更代表合理的产品决策、对不准确用例的修正，还是为了迁就回归而做的调整。如果新功能破坏了一个现有场景，而没有已批准的需求来接替它，你就应当阻止变更并请求评审。测试用例保持原样，E2E 自动化也保持原样。
A proposed test-case change should therefore answer:
Which requirement authorizes this change?
Which new or modified user behavior does it describe?
Does it alter or remove previously supported behavior?
Which existing scenarios are affected?
What regression risks does it introduce?
Who must review and approve it?
Which automated tests should be created or updated afterward?
This workflow keeps responsibilities separate. The development agent may propose behavioral changes, but it should not be able to redefine expectations silently. The requirement agent audits those changes against the product’s accumulated knowledge base. Once the manual cases are approved, a dedicated automation agent can update the E2E suite from that validated specification.
The result is a governed source of truth that is more concise than source code, more accessible than automation, and more resistant to implementation-driven test drift. Manual test cases are allowed to evolve, but only when the expected product behavior has intentionally evolved with them.
因此，一个测试用例变更提案应当回答：
- 哪个需求授权了这次变更？
- 它描述了哪些新的或修改后的用户行为？
- 它是否改变或移除了先前支持的行为？
- 哪些现有场景会受影响？
- 会引入哪些回归风险？
- 需要由谁来评审和批准？
- 之后应创建或更新哪些自动化测试？
这个工作流让职责分开。开发智能体可以提出行为变更，但不能悄悄重定义预期。需求智能体依据产品积累的知识库审计这些变更。一旦手工用例获批，专门的自动化智能体就可以从这份已验证的规格出发，更新 E2E 套件。
结果是一个受治理的真相来源：它比源代码更简洁、比自动化更易访问、也更难被实现驱动的测试漂移带偏。手工测试用例允许演进，但只有在预期产品行为也与之同步、有意演进时才可以。
Source code is an authoritative description of what the system currently does. It is not, by itself, a sufficient description of what the system was intended to do.
In the agentic era, code is becoming cheaper to modify. That makes independent sources of intent even more important. Requirements and acceptance criteria define the expected behavior. Manual test cases that people review record the same intent and hold the source of truth. That source remains valid after implementation rewrites and framework migrations. It also holds through UI redesigns and a change of agents inside the organization.
These artifacts serve different purposes:
| Artifact | Primary question |
|---|---|
| Requirement | Why must this capability exist? |
| Acceptance criteria | What outcome must be satisfied? |
| Manual test case | How can the expected behavior be verified? |
| Automated test | Can that verification be executed consistently? |
| Source code | How is the behavior currently implemented? |
Treating source code as the only source of truth merges these separate questions into one artifact. That may be convenient, but it weakens independent verification.
源代码是系统“当前做什么”的权威描述，但它本身不足以描述系统“本来打算做什么”。
在智能体时代，代码的修改越来越便宜，独立的意图来源因此更加重要。需求和验收标准定义预期行为；由人评审的手工测试用例记录同样的意图，并掌握真相来源。这个来源在实现被重写、框架被迁移之后依然有效，在 UI 重新设计、组织更换智能体之后也依然成立。
这些工件各司其职：
| 工件 | 核心问题 |
|---|---|
| 需求 | 为什么这个能力必须存在？ |
| 验收标准 | 必须满足什么结果？ |
| 手工测试用例 | 预期行为如何被验证？ |
| 自动化测试 | 该验证能否被稳定地执行？ |
| 源代码 | 当前行为是如何实现的？ |
把源代码当作唯一真相来源，等于把这些原本分离的问题合并进一个工件。这也许方便，但会削弱独立验证。
Manual test cases are sometimes dismissed as expensive documentation. That assessment changes when they are considered part of an agentic control system. Well-maintained manual cases can reduce:
Repeated E2E repair work.
Accidental acceptance of regressions.
Ambiguity passed between product and engineering.
Test duplication generated by multiple agents.
Dependence on individual test-framework expertise.
The cost of replacing brittle automation.
The risk of an agent validating its own misunderstanding.
They also improve traceability, once coverage and requirement links sit in one dashboard. A CTO can see which requirements are protected. A manager can understand the impact of a proposed change. A QA engineer can identify missing negative and regression coverage. An automation agent can generate checks from an approved behavioral contract. The objective is not to maximize the number of manual tests. It is to establish enough independent behavioral coverage to prevent implementation-driven test drift.
手工测试用例有时被贬斥为昂贵的文档。一旦你把它们看作智能体控制系统的一部分，这个评价就会改变。维护良好的手工用例可以减少：
- 反复的 E2E 修复工作。
- 意外接受回归缺陷。
- 产品与工程之间传递的歧义。
- 多个智能体生成的重复测试。
- 对个人测试框架专长的依赖。
- 替换脆弱自动化的成本。
- 智能体验证自身误解的风险。
一旦覆盖率和需求链接出现在同一个仪表盘上，它们还能改善可追溯性。CTO 可以看到哪些需求受到了保护；经理可以理解一次变更的影响；QA 工程师可以发现缺失的负向与回归覆盖；自动化智能体可以从已批准的行为契约生成检查。目标不是最大化手工测试数量，而是建立足够的独立行为覆盖，防止实现驱动的测试漂移。
Agentic development produces code faster and cheaper, including automated test code. It does not automatically make either one correct. When the same process generates an implementation and continuously adjusts its tests, a green pipeline can lose its meaning. The organization risks entering an implement-fail-fix-regression loop in which agents spend increasing amounts of time reconciling code with tests that no longer represent independently approved expectations. Manual test cases provide a stable layer of behavioral intent. Combined with requirements, acceptance criteria, independent automation, and controlled approval of behavioral changes, they create a quality system that agents can accelerate without silently redefining.
As a Testomat.io team, we provide a Test Management System, ready for agentic development. We provide a knowledge base as test cases via our MCP server, and a practical set of agent skills that establishes QA process. We believe that the importance of QA is growing in agentic times. Firing a QA team to save money for tokens is a dead-end way. What is needed today is establishing an agentic-ready QA process, which can be controlled by professional QA personnel. And that’s why it’s the right time to do actual test case management. Something that you, your QA, and your agent can tell as a source of truth. In the agentic era, test cases are not a step backward from automation. They are the contract that keeps automation sane. Take the user journey your team is most afraid to break and store it in Testomat.io as an approved case your agents read through MCP: start for free or book a demo.
智能体开发会更快、更便宜地产出代码，包括自动化测试代码，但它不会自动让其中任何一种变得正确。当同一个流程生成实现并不断调整测试时，绿色流水线可能失去意义。组织面临的风险是陷入“实现—失败—修复—回归”的循环：智能体花越来越多的时间来调和代码与那些不再代表独立批准预期的测试。手工测试用例提供了稳定的一层行为意图。结合需求、验收标准、独立自动化和受控的行为变更审批，它们构成了一套质量体系，智能体可以在不悄悄重定义的前提下加速它。
作为 Testomat.io 团队，我们提供一套为智能体开发准备好的测试管理系统。我们通过 MCP 服务器把知识库以测试用例的形式提供给智能体，并提供一套建立 QA 流程的实用 Agent 技能。我们相信，在智能体时代，QA 的重要性正在提升。为了省 token 而裁掉 QA 团队是死路一条。今天真正需要的，是建立一个可以由专业 QA 人员掌控的、面向智能体的 QA 流程。这也是为什么现在正是认真做测试用例管理的时候——让您、您的 QA 和您的智能体都能把它当作真相来源。在智能体时代，测试用例不是自动化的倒退，而是让自动化保持理性的契约。拿团队最怕被破坏的那条用户旅程，存进 Testomat.io 作为已批准的用例，让你的智能体通过 MCP 读取它：立即免费开始，或预约演示。