Injecting "7 Ruthless QA Personas" into Claude Code to Plug Test Case Blind Spots

Claude Code is an agentic coding system from Anthropic that reads your codebase, makes changes across files, runs tests, and delivers committed code. The official documentation states “If you can describe it, you can build it.”

📑Table of Contents

Background and Challenges in Test Case Creation with Claude Code
Definition and Roles of the Seven Ruthless QA Personas
Skill Separation Between New-Feature and Migration Tracks
25-Column CSV Specification and ISO/IEC 25010 Quality Characteristics
Real-World Pipeline and Results
Summary and Future Outlook
Comparison Table: New-Feature Track vs Migration Track

Background and Challenges in Test Case Creation with Claude Code

AI-generated test cases tend to bias toward happy paths. Edge cases, database consistency, malicious inputs, and regression scenarios are often overlooked, leading to coverage gaps discovered late in the process. In practice, relying solely on AI output has resulted in significant defects found downstream.

To address this, we embed seven “ruthless QA personas” as a custom skill in Claude Code. This approach, detailed in a Zenn article (https://zenn.dev/nexta_/articles/be13a2395a5d2a), systematically eliminates blind spots.

Definition and Roles of the Seven Ruthless QA Personas

Seven personas are defined and prefixed in every prompt. Each provides at least one destructive viewpoint:

P1 Novice User: flags intuitive mistakes and empty submissions
P2 Veteran Field Operator: anticipates keyboard edge cases
P3 Malicious Actor: probes boundary values and unauthorized access
P4 Data Integrity Auditor: checks DB table state consistency
P5 Migration Specialist: validates legacy data integrity
P6 Regression Guardian: watches for breakage of existing features
P7 Specification Skeptic: highlights implementation-spec mismatches

This multi-angle structure counters happy-path bias effectively.

Skill Separation Between New-Feature and Migration Tracks

The new-feature track takes PBI and source code as input, emphasizing P3 and P4. The migration track uses existing help center content and design patterns, centering P5 and P7. Because the origins of specifications differ, a single skill causes the output focus to drift; separation maintains consistency.

25-Column CSV Specification and ISO/IEC 25010 Quality Characteristics

Output is a 25-column CSV covering requirement ID, description, Test Basis, evidence, and all eight ISO/IEC 25010 characteristics (functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability). Explicitly recording primary sources in Test Basis prevents bias.

Real-World Pipeline and Results

Commands such as /test-case-creation PBI-XXX and /migration-test-creation are used in daily operations. In a real migration project, over 200 test cases were generated, dramatically reducing missed perspectives. Post-generation manual review ensures final quality.

Summary and Future Outlook

Fixing the seven ruthless QA personas in Claude Code improves test coverage. Future work includes expanding the persona set and broadening automation scope. See the Zenn article and Anthropic official site (https://www.anthropic.com/product/claude-code) for details.

Frequently Asked Questions (FAQ)

Q: Why are seven personas necessary?

AI tends to focus on normal cases, missing database integrity, regression, and malicious scenarios. Fixed ruthless personas ensure comprehensive coverage.

Q: Why separate skills for new features versus migration?

The specification sources (PBI + code vs. help + patterns) differ, so success criteria and primary personas vary. A single skill causes output drift.

Q: Why 25 columns in the CSV?

To cover everything from requirement ID to evidence, explicitly record Test Basis, and embed all eight ISO 25010 characteristics, making bias visible.

Q: How are the personas embedded into the skill?

Prefix every prompt with: “You are seven ruthless QAs who do not trust that things are working. From each persona’s perspective, attempt to break at least one thing.”

Q: Is there a track record of creating over 200 test cases in the migration track?

Yes, in a contracted migration project we generated over 200 test cases this way and significantly reduced coverage gaps.

Comparison Table: New-Feature Track vs Migration Track

Item	New-Feature Track	Migration Track
Specification Source	Issue (PBI) + source code	Existing help center + design patterns
Success Criterion	Meets requirements	Behaves per specification
Primary Personas	P1–P7 (esp. P3 malice, P4 data integrity)	P5 migration + P7 specification skeptic
Output	Test case CSV	Test case CSV + coverage table + config pattern table
Input Example	/test-case-creation PBI-XXX	/migration-test-creation (help URL)

Sources: Zenn article (https://zenn.dev/nexta_/articles/be13a2395a5d2a) and Anthropic official documentation.

Related articles:

Author

krona23

Over 20 years in the IT industry, serving as Division Head and CTO at multiple companies running large-scale web services in Japan. Experienced across Windows, iOS, Android, and web development. Currently focused on AI-native transformation. At DevGENT, sharing practical guides on AI code editors, automation tools, and LLMs in three languages.

DevGENT about →

📚 Read Next