Claude Code + Skill: A Complete Walkthrough of Auto-Generating Functional Test Cases in 10 Minutes

Introduction: A Productivity Revolution for QA Engineers

Writing test cases by hand has long been one of the most time-consuming and tedious tasks in software testing. A product requirements document with nine chapters and dozens of functional requirements can take QA engineers days — or even weeks — to break down, extract test points, and turn into actionable test cases.

With Claude Code and its Skill mechanism, the entire process can be compressed to under ten minutes. Based on a hands-on demo by a Bilibili content creator, this article breaks down the complete workflow of this "one-command test case generation" approach and explores its potential impact on the testing industry.

Background: Claude Code and the Skill Mechanism

Claude Code is Anthropic's AI coding assistant built for developers. It runs directly in the terminal, executing code, reading and writing files, and calling external tools. Its Skill mechanism is essentially a packaged unit of "prompt templates + tool calls," allowing users to predefine the execution logic for specific tasks as reusable instruction modules. This closely mirrors the software engineering concept of function encapsulation — breaking complex tasks into single-responsibility subtasks and composing them to achieve higher-order goals. In the AI Agent space, this pattern is also known as Tool Chaining, and it's one of the core technical paradigms enabling LLM applications to move beyond one-off Q&A toward complex workflow automation.

The Core Approach: A Three-Stage Automated Pipeline

The key to this approach is simplicity for the user: just issue a single natural language command to Claude Code — "please use the Skills to generate test cases from the requirements document" — and the AI automatically parses the instruction, then sequentially invokes the corresponding Skill for each of three predefined stages.

The three stages are:

• Stage 1: Requirements Document Splitting (invokes the first Skill)
• Stage 2: Test Point Extraction (invokes the second Skill)
• Stage 3: Test Case Generation and Export (invokes the third Skill)

You might not immediately notice it, but every operational step is encapsulated as its own independent Skill. This modular design keeps the entire process clear and controllable, while making it easy to reuse and adjust. The requirements document in the demo has nine chapters, with chapters three through six containing the most critical functional requirements.

Stage 1: Verbatim Splitting and Requirements Review

In the first stage, the AI locates the requirements document and splits it verbatim by chapter. The design philosophy here is worth noting: splitting, not extracting — the AI neither adds nor removes requirements, preserving the full integrity of the original content, ultimately splitting the nine chapters into nine separate folders.

During the splitting process, the approach also includes a built-in AI auto-review mechanism that proactively flags unclear or ambiguous descriptions in the requirements document, surfacing potential risks early.

Technical Deep Dive: The "Reflection Loop" Behind AI Auto-Review

The "auto-review" mechanism mentioned repeatedly in this approach is essentially a set of review rules embedded in the Skill's prompt, instructing the large model to validate its own output from a "second perspective" while executing the primary task. In the AI field, this is known as Self-Critique or a Reflection Loop — a common strategy for improving LLM output quality. In the requirements review context specifically, the model scans each requirement against a set of predefined review dimensions (e.g., whether descriptions are unambiguous, conditions are complete, boundaries are clearly defined) and flags items that raise questions. The limitation of this mechanism is that its review depth is constrained by the quality of the prompt design and the model's understanding of the business domain — complex business logic still requires domain expert involvement.

Converting Images and Tables to Text

The most technically sophisticated step is the conversion of images and tables into text. Raw requirements often contain flowcharts, data tables, and other non-text content. The approach requires the AI to convert all of this into written descriptions. For the "Guest Browsing Flow" in chapter three, for example, the AI marks the original location (e.g., section 3.1), provides a module overview, and transcribes the image-based flow into readable text.

For requirements that contain tables — like the product detail section in chapter four — the AI similarly converts tables into prose and supplements them with dimensions such as access roles, page information, conditional exceptions, edge cases, and acceptance criteria.

Why Does Text Conversion Matter So Much?

Converting visual, non-structured content like flowcharts and tables in requirements documents into plain text is a technically underrated value point in this approach. Current mainstream large language models (including Claude) still rely primarily on text as their reasoning substrate when handling multimodal inputs. Converting flowcharts into step-by-step textual descriptions and tables into key-value pairs or lists significantly improves the model's comprehension accuracy and reduces reasoning errors caused by "visual ambiguity." The conversion process itself also serves as a "structured review" of the requirements, helping to surface logical gaps that might be obscured by visual presentation in the original document. In the broader document processing space, this "multimodal-to-text" preprocessing strategy is increasingly becoming a standard step in building RAG (Retrieval-Augmented Generation) systems.

The reason for this text conversion is straightforward: large models understand and reason over plain text with far greater clarity and accuracy.

Stage 2: Intelligent Test Point Extraction

The second stage focuses on extracting test points from the split requirements. This is where the approach's "intelligence" shines — the AI automatically skips non-requirements content. In the demo, chapters one and two are just documentation introductions and overviews rather than actual functional requirements, so they are automatically excluded from the test point extraction.

Every test point is output in a unified structured (JSON) format containing the following fields:

• Module and chapter it belongs to
• Test point title (e.g., "Verify the normal flow for guests accessing the mall homepage")
• Status, steps, and expected results
• Priority
• Testing design method used

The Engineering Value of Structured Output

Outputting test points in JSON format is far more than a technical detail — it's a critical step toward production-ready implementation. JSON (JavaScript Object Notation), as a lightweight data exchange format, is both machine-readable and structurally clear. It can directly interface with the API import endpoints of mainstream test management platforms like Jira, TestRail, and Zentao. This means AI-generated test points can theoretically flow seamlessly into existing development workflows without requiring manual re-entry. Structured output also provides the foundation for downstream statistical analysis — for example, counting cases by priority or assessing coverage by module — data that has real value for test planning and quality measurement.

End-to-End Automated Quality Review

Critically, all test points undergo automatic review after generation. This means every transformation step from requirements to test points has a quality checkpoint built in, rather than producing output in one shot with no subsequent validation.

Stage 3: Production-Ready Test Case Generation

The third stage invokes the export Skill to convert test points into final test cases, organized by chapter. From the moment the instruction is issued to the completion of case generation, the entire process takes under ten minutes.

The first page of the output is a summary table showing how many cases each chapter contains, followed by specific cases for each feature. Take chapter three's "Guest Browsing" feature as an example — for this single feature alone, the AI generated eight test cases: covering guest access to the homepage, category browsing, search functionality, and product details, all the way to scenarios involving shopping cart actions, favoriting, and login prompts triggered during checkout. The coverage is remarkably comprehensive.

Every test case includes complete fields: title, test type, priority, preconditions, test data, execution steps, and expected results. It also reserves an additional column for manual review and notes the corresponding source test point, enabling full traceability.

Traceability and the Engineering Foundation for AI-Human Collaboration

Retaining a "source test point" field in each case and reserving a "manual review column" reflects the core principle of Traceability in test engineering. Traceability requires that test cases can be traced upward to specific requirements items and downward to defect records. It's a key component of testing standards like ISO 29119 and a prerequisite for software quality certifications such as CMMI and functional safety standard ISO 26262. In an AI-assisted collaboration model, this traceability design carries additional significance: it gives human reviewers a contextual anchor for "auditing AI output," enabling engineers to quickly determine whether a given test case accurately covers the intended requirement rather than having to re-read everything from scratch. This is precisely the engineering foundation that makes the "AI generation + human review" collaboration model viable in practice.

According to the presenter's assessment, these cases have reached a "production-ready level" — in terms of rigor and executability, they are on par with or even exceed some manually written versions.

Efficiency Assessment and a Grounded Perspective

The presenter emphasized that compared to writing cases by hand, the efficiency gain from this approach is "definitely more than double" — the entire process takes just ten minutes, while the equivalent manual effort could take days.

From a technical standpoint, the value of this approach lies not only in speed, but also in its process design:

1. Modular Skill encapsulation: Each stage has a single responsibility, making it easy to maintain and reuse;
2. Verbatim splitting + text conversion: Preserves the authenticity of requirements to the greatest extent;
3. Multi-stage auto-review: Quality checks are built into every step, not bolted on afterward;
4. Manual review column + source traceability: AI and humans collaborate rather than one simply replacing the other.

Of course, a grounded assessment is also necessary. The final quality of the test cases remains highly dependent on how well-written the original requirements document is. For ambiguous requirements, the AI can only flag issues — it cannot fill in gaps out of thin air. Furthermore, the "production-ready" judgment comes from a single demo scenario; real-world production environments will require large-scale validation across actual projects to confirm stability and edge case coverage.

Conclusion

The combination of Claude Code and Skill points clearly toward a direction for testing work: shifting from handwritten cases to an AI generation + human review collaboration model. It's not about fully replacing QA engineers — it's about freeing engineers from repetitive case writing so they can focus on higher-value work like requirements review, boundary analysis, and quality assurance. For testing teams, understanding and adopting these kinds of AI tool chains early will become a key lever for building team competitiveness.