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 and checked his courses on linkedin.
And I am taking the Mosh Hamedani course Claude Code for Professional Developers 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 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:
-
Create the scripts with the rule or command that you want to execute. I created a hooks folder with:
-
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, 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
-
Inside the .claude folder, create a skills folder
-
Add a folder with the name of the skill, e.g., read-testcase
-
Add a SKILL.md file
-
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
-
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:
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
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 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, I fixed it, and Claude will check again.
But I prefer Qodo, which is focused on PR review. You can see both PR reviews here: 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.