How I Set Up Claude Code as My Testing Toolkit: Issue Fixes, PR Reviews, and Skills for Test Case Generation

A developer detailed how they set up Claude Code as a testing toolkit for issue fixes, PR reviews, and test case generation. They emphasized creating custom agents with concrete coding rules, using the /init command to generate CLAUDE.md, and implementing security hooks to restrict access to .env files. The developer also shared their preference for critical user journey test cases over granular tests and described a user story for an admin server registration feature.

I believe AI will be another service like the internet or a cell phone, and it's important to use it correctly by adding the right context, being aware of token usage, and following your own process. For this reason some months ago I finished different courses about how to use Claude: I checked the Addy Osmani Agent skills repo https://github.com/addyosmani/agent-skills and checked his courses on linkedin. And I am taking the Mosh Hamedani course Claude Code for Professional Developers https://codewithmosh.com/p/claude-code and finished other claude skills course. Also, in one of the jobs, I used skills developed by other QAs. I initially struggled with complex queries and generating API automation test cases due to the complexity of the user stories. But after some feedback from the agents and the user stories were clearer and with more context, like including the legacy stored procedure or checking the PR code, I got better results using the skills with GitHub copilot. It's better to create your own agents with your rules and process. You need a framework with concrete coding rules and conventions, for your test cases. For example, for test cases, I prefer critical user journeys with detailed steps and assertions in bullet points, rather than 10 tests that test a small part of the real user flow. For automation frameworks, I like to follow these rules: Once you have the structure of your framework, it is important to generate CLAUDE.md using the /init command. This command will analyze the structure of your repo and create a file with the main structure and commands to run and execute the tests of your project, and each time you request something, Claude will read this file. You need to check the generated file and ensure that includes all the info. With Claude, you can define The .env file, usually contains all the passwords. For security, it's better that the agent can't access it. The course Claude Code in Action https://anthropic.skilljar.com/claude-code-in-action includes an example that restricts access with JavaScript, but for practice I also created a hook to prevent access with a Python script. To create the hook: 1 Create the scripts with the rule or command that you want to execute. I created a hooks folder with: 2 Add the hook in the .claude/settings.json file. type: command command: "node ./hooks/read hook.js" statusMessage: "Checking file access..." { "permissions": { "allow": "mcp playwright", "Bash playwright-cli ", "Bash npx tsc --noEmit " , "deny": }, "hooks": { "PreToolUse": { "matcher": "Read|Edit", "hooks": { "type": "command", "command": "node ./hooks/read hook.js", "statusMessage": "Checking file access..." } }, "PostToolUse": } } If you request access you will see an error I created the user story and a Figma design. I added only one screenshot without any interaction. But usually Figma designs are like this, which include the web and mobile versions also other Figma designs include interaction I am not a fan of BDD, so I didn't follow the BDD syntax for the user story. I've worked with and without BDD. Description: The admin user needs to register the different servers used to connect to the ERP to see some reports from the Firebird database. Server Fields Id - Server ID numeric auto-increment Key – Server key unique identifier Name – Server name URL – URL to connect to the ERP API Active – Whether the server is enabled Scope: view the registered servers, search by name or key, add, edit, delete, and mark a server active/inactive. In the attached file, you can find translations for English, Japanese, Spanish, and German. Acceptance Criteria Servers grid Add / Edit Delete / Active state Navigation While I was testing, I found some gaps in my user story and Figma design, like the missing confirmation before deleting a server and the missing empty state. So I requested Claude to add a comment. It's important to review the user stories and create test cases at the start of the sprint to prevent gaps before the developer starts coding so the developer can generate unit tests and know the test cases can prevent bugs. I prefer creating small skills for specific tasks rather than a general skill. For manual test cases I created these skills: First you need to add the Azure DevOps MCP on Claude with an Entra Id account. And add your Azure DevOps Project I created an entra Id user mcp azure@abi1521hotmail.onmicrosoft.com mailto:mcp azure@abi1521hotmail.onmicrosoft.com , because you need to access with your Entra ID account instead of your personal email. claude mcp add azure-devops \ -- npx -y @azure-devops/mcp your organization \ --authentication interactive \ --tenant your tenant id 1 Inside the .claude folder, create a skills folder 2 Add a folder with the name of the skill, e.g., read-testcase 3 Add a SKILL.md file 4 Add a references folder optional if you want to include a file with some references; for example, for the manual test skill, I created one file for API tests and another for E2E tests 5 Add a scripts folder optional : Executable actions for a specific task. The structure of the SKILLmd file is: I usually add some description about the role of the skill for example I want to create update the test cases for a user story or for playwright code, sometimes the code already exists but the manual tests are outdated. --- name: manual-tests description: Create and update manual Test Cases in Azure DevOps from a user story — API, E2E/UI, and performance types and wire them into a Test Plan/Suite. Use to write, generate, revise, or refresh manual test cases, e.g. "create test cases for story 123", "turn this Playwright spec into ADO test cases", "update test case 456 steps", "create test cases from this Figma design". allowed-tools: - Read, mcp azure-devops core list projects, mcp azure-devops wit get work item, mcp azure-devops wit update work item, mcp azure-devops testplan list test plans, mcp azure-devops testplan create test plan, mcp azure-devops testplan list test suites, mcp azure-devops testplan create test suite, mcp azure-devops testplan create test case, mcp azure-devops testplan add test cases to suite, mcp azure-devops testplan update test case steps, mcp claude-in-chrome tabs context mcp, mcp claude-in-chrome tabs create mcp, mcp claude-in-chrome navigate, mcp claude-in-chrome computer, mcp claude-in-chrome read page --- Act as a manual tester: turn a user story or an automated test / feature description into well-structured manual Test Case work items in Azure DevOps, and keep existing ones current when the story changes. Test cases come in three flavours — API, E2E/UI, and Performance — each with its own step template see references/ . For the steps that I usually follow: Step 1: Verify the MCP is available and Test Plan Id Before anything else, confirm the Azure DevOps MCP is connected e.g. attempt a small read like mcp azure-devops testplan list test plans . If it is not available, stop and show: Azure DevOps MCP is not set up. Configure it in .mcp.json set your org and set AZURE DEVOPS TOKEN in your shell, then restart Claude Code and try again. Determine the target project — never hardcode it: use the project the user named; otherwise propose the .mcp.json default --project arg and confirm before writing; if neither is clear, list projects with mcp azure-devops core list projects and ask. testplan and wit tools require an explicit project arg on every call, so resolve it once up front and reuse it. If a single request spans projects e.g. a story in one project, test cases destined for another , confirm each. Determine the destination Plan/Suite — ask the user whether cases go into an existing Plan/Suite or a new one, if they haven't said: - Existing — mcp azure-devops testplan list test plans project to find the named plan; mcp azure-devops testplan list test suites project, planId to find the named suite, or use the root suite parentSuite empty/itself if they don't want a sub-suite. - New — create the plan with mcp azure-devops testplan create test plan project, name, iteration — default to the project root iteration unless they name a sprint , then the suite with mcp azure-devops testplan create test suite project, planId, parentSuiteId = root suite id, name . Confirm both names before creating. Capture planId and suiteId — needed later when the cases are created and added to the suite. Find the test case update mode — if the user gave a test case ID, use it directly; if they gave a story ID and asked to refresh its cases, fetch the story with mcp azure-devops wit get work item expand: "all" and follow its Microsoft.VSTS.Common.TestedBy links to the linked test cases. Checklist Run through this silently before presenting the draft/diff for approval, and once more before any write call — it's a final gate, not documentation. - Mode create vs. update chosen; for updates, current steps read fresh before drafting changes - Test type chosen and the matching references/ .md template followed - Steps derived from real source story fields / actual spec file / stated facts — zero invented endpoints, fields, or thresholds - Figma link in the story spotted and the design opened and inspected before drafting E2E create mode ; design-quoted text marked High confidence - Open doubts unspecified texts, behaviors, edge cases batched and asked before drafting; assumptions only after the user deferred or couldn't answer - No extra | inside any action/expected-result text — | is the tool-input delimiter Step 5 , not part of the preview's → format - No assertion-only "Observe/Inspect/Verify" steps; multi-assertion expected results written as bullets steps XML via wit update work item - Journeys are positive-scenario only, negative scenarios split into their own parameterized cases; cleanup postcondition present when the case creates data - Destination plan + suite resolved plan/suite created on request when none exists — create mode - Draft create or before→after diff update presented and user approved before any write I created other skills to create the automated playwright tests some of the skills are: I'm still working on that but you can see the repo with the skills: https://github.com/apis3445/TestingDojo https://github.com/apis3445/TestingDojo You can include a .yml file to allow Claude to tag your GitHub issues or to review your PR automatically. You need to One disadvantage I encountered is that when I was trying to use the .yml to review the PR, if you change the .yml for the code review, you will get an error that the file needs to be the same as the main branch, but you can add a comment @claude https://dev.to/claude review to get the PR review comment. The PR review is part of your Claude usage. In my experience at one of my jobs, some suggestions weren't good. The review suggested changing code that will be fixed in other user stories, or that flagged code as incorrect due to a lack of context, even though the context was in the PR description. You can reply with suggestions, for example: @claude https://dev.to/claude , I fixed it, and Claude will check again. But I prefer Qodo https://www.qodo.ai , which is focused on PR review. You can see both PR reviews here: https://github.com/apis3445/TestingDojo/pull/15 https://github.com/apis3445/TestingDojo/pull/15 Now the disadvantage that I found: You can use the mcp context7 to get up-to-date docs for AI agents and for example for angular, google added claude skills but there is still a gap to LLM don't write deprecated code. Create skill or automate your flows require continuous feedback so it's important that improve the skills and be aware of the token usage. Thanks for reading so don't hesitate to ask questions or share your feedback. If this helped you, feel free to share it with the community.