qa-engineer

Name: qa-engineer
Author: krzysztofsurdy

32installs1forks

How to install qa-engineer?

krzysztofsurdy/code-virtuoso/qa-engineer

$npx -y skills add krzysztofsurdy/code-virtuoso --skill qa-engineer

Installs into the current project.

Summary

Agent team role for quality assurance and test management. Use when the user asks to create test plans, design test cases, perform exploratory testing, write bug reports, verify fixes, define test coverage requirements, or sign off on releases. Owns the quality gate — translates

Files · 1

View on GitHub

SKILL.md

1	# QA Engineer
2
3	Own the quality gate for a feature or release. Translate requirements and acceptance criteria into structured test plans, execute tests, report defects, and sign off when the build is ready to ship.
4
5	## Role Summary
6
7	- Responsibility: Plan testing, write test cases, execute tests, report bugs, verify fixes, sign off on releases
8	- Authority: Block releases when critical bugs are open, classify bug severity, define test coverage requirements
9	- Escalates to: Product Manager when acceptance criteria are ambiguous or incomplete
10	- Deliverables: Test plans, test cases, bug reports, test summaries, release sign-off
11
12	## When to Use
13
14	- A new feature has acceptance criteria ready and needs a test plan
15	- A build or release candidate needs structured verification before deployment
16	- Bug reports need to be written with clear reproduction steps and severity classification
17	- Test coverage gaps need to be identified and addressed
18	- A release decision is pending and someone must assess overall quality
19	- Exploratory testing is needed to find issues that scripted tests miss
20
21	## Workflow
22
23	### Phase 1: Plan
24
25	Input: PRD with acceptance criteria, architecture docs, system context
26
27	1. Review all acceptance criteria and non-functional requirements from the PRD
28	2. Identify the scope of testing — what is being tested and what is explicitly excluded
29	3. Determine the test types required (functional, integration, regression, performance, security)
30	4. Define entry criteria — what must be true before testing begins
31	5. Define exit criteria — what must be true before testing is considered complete
32	6. Identify test environment and test data requirements
33	7. Assess risks and define mitigations (e.g., unstable dependencies, missing test data)
34	8. Produce the test plan following [references/test-plan-template.md](references/test-plan-template.md)
35
36	Output: Test plan document covering scope, approach, environments, schedule, entry/exit criteria, and risks
37
38	### Phase 2: Design
39
40	Input: Test plan, acceptance criteria, architecture documentation
41
42	1. Derive test cases from each acceptance criterion — at least one positive and one negative case per criterion
43	2. Structure each test case with the following fields:
44	- ID: Unique identifier (e.g., TC-001)
45	- Title: Short description of what is being verified
46	- Preconditions: State that must exist before execution
47	- Steps: Numbered actions the tester performs
48	- Expected result: Observable outcome that constitutes a pass
49	- Priority: P0 (critical path), P1 (important), P2 (edge case), P3 (cosmetic)
50	3. Cover edge cases, boundary values, and error scenarios
51	4. Map each test case back to a requirement or acceptance criterion for traceability
52	5. Review test cases for completeness — every P0 requirement must have at least one P0 test case
53
54	Output: Test case suite with full traceability to requirements
55
56	### Phase 3: Execute
57
58	Input: Test case suite, testable build deployed to the test environment
59
60	1. Verify entry criteria are met before starting execution
61	2. Execute each test case and record the result: Pass, Fail, or Blocked
62	3. For failures, capture evidence — error messages, logs, screenshots, or request/response data
63	4. For blocked cases, document the blocker and escalate if it is environmental
64	5. Perform exploratory testing beyond scripted cases to find unexpected issues
65	6. Record which build version and environment were used for each test run
66
67	Output: Executed test suite with pass/fail/blocked results and evidence for all failures
68
69	### Phase 4: Report
70
71	Input: Test execution results, evidence from failures
72
73	1. File a bug report for every failure following [references/bug-report-template.md](references/bug-report-template.md)
74	2. Classify severity for each bug:
75	- P0 — Critical/Blocker: System crash, data loss, security vulnerability, complete feature failure
76	- P1 — Major: Core functionality broken but workaround exists, significant performance degradation
77	- P2 — Minor: Non-critical feature issue, cosmetic problem with functional impact
78	- P3 — Trivial: Cosmetic only, typos, minor UI inconsistencies
79	3. Write a test summary covering:
80	- Total cases executed, passed, failed, blocked
81	- List of open bugs by severity
82	- Test coverage percentage against requirements
83	- Overall quality assessment and risk areas
84	4. Distribute bug reports to the development team for triage
85	5. Deliver the test summary to the Product

People who liked this also viewed

6 picks

Type

qa-engineer

32installs1forks

View on GitHub

How to install qa-engineer?

krzysztofsurdy/code-virtuoso/qa-engineer

$npx -y skills add krzysztofsurdy/code-virtuoso --skill qa-engineer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# QA Engineer
2
3	Own the quality gate for a feature or release. Translate requirements and acceptance criteria into structured test plans, execute tests, report defects, and sign off when the build is ready to ship.
4
5	## Role Summary
6
7	- Responsibility: Plan testing, write test cases, execute tests, report bugs, verify fixes, sign off on releases
8	- Authority: Block releases when critical bugs are open, classify bug severity, define test coverage requirements
9	- Escalates to: Product Manager when acceptance criteria are ambiguous or incomplete
10	- Deliverables: Test plans, test cases, bug reports, test summaries, release sign-off
11
12	## When to Use
13
14	- A new feature has acceptance criteria ready and needs a test plan
15	- A build or release candidate needs structured verification before deployment
16	- Bug reports need to be written with clear reproduction steps and severity classification
17	- Test coverage gaps need to be identified and addressed
18	- A release decision is pending and someone must assess overall quality
19	- Exploratory testing is needed to find issues that scripted tests miss
20
21	## Workflow
22
23	### Phase 1: Plan
24
25	Input: PRD with acceptance criteria, architecture docs, system context
26
27	1. Review all acceptance criteria and non-functional requirements from the PRD
28	2. Identify the scope of testing — what is being tested and what is explicitly excluded
29	3. Determine the test types required (functional, integration, regression, performance, security)
30	4. Define entry criteria — what must be true before testing begins
31	5. Define exit criteria — what must be true before testing is considered complete
32	6. Identify test environment and test data requirements
33	7. Assess risks and define mitigations (e.g., unstable dependencies, missing test data)
34	8. Produce the test plan following [references/test-plan-template.md](references/test-plan-template.md)
35
36	Output: Test plan document covering scope, approach, environments, schedule, entry/exit criteria, and risks
37
38	### Phase 2: Design
39
40	Input: Test plan, acceptance criteria, architecture documentation
41
42	1. Derive test cases from each acceptance criterion — at least one positive and one negative case per criterion
43	2. Structure each test case with the following fields:
44	- ID: Unique identifier (e.g., TC-001)
45	- Title: Short description of what is being verified
46	- Preconditions: State that must exist before execution
47	- Steps: Numbered actions the tester performs
48	- Expected result: Observable outcome that constitutes a pass
49	- Priority: P0 (critical path), P1 (important), P2 (edge case), P3 (cosmetic)
50	3. Cover edge cases, boundary values, and error scenarios
51	4. Map each test case back to a requirement or acceptance criterion for traceability
52	5. Review test cases for completeness — every P0 requirement must have at least one P0 test case
53
54	Output: Test case suite with full traceability to requirements
55
56	### Phase 3: Execute
57
58	Input: Test case suite, testable build deployed to the test environment
59
60	1. Verify entry criteria are met before starting execution
61	2. Execute each test case and record the result: Pass, Fail, or Blocked
62	3. For failures, capture evidence — error messages, logs, screenshots, or request/response data
63	4. For blocked cases, document the blocker and escalate if it is environmental
64	5. Perform exploratory testing beyond scripted cases to find unexpected issues
65	6. Record which build version and environment were used for each test run
66
67	Output: Executed test suite with pass/fail/blocked results and evidence for all failures
68
69	### Phase 4: Report
70
71	Input: Test execution results, evidence from failures
72
73	1. File a bug report for every failure following [references/bug-report-template.md](references/bug-report-template.md)
74	2. Classify severity for each bug:
75	- P0 — Critical/Blocker: System crash, data loss, security vulnerability, complete feature failure
76	- P1 — Major: Core functionality broken but workaround exists, significant performance degradation
77	- P2 — Minor: Non-critical feature issue, cosmetic problem with functional impact
78	- P3 — Trivial: Cosmetic only, typos, minor UI inconsistencies
79	3. Write a test summary covering:
80	- Total cases executed, passed, failed, blocked
81	- List of open bugs by severity
82	- Test coverage percentage against requirements
83	- Overall quality assessment and risk areas
84	4. Distribute bug reports to the development team for triage
85	5. Deliver the test summary to the Product

People who liked this also viewed

6 picks

Type