QA Skill Library
Software testing skill library for testing types, workflows, and enhanced QA skills
Browse testing types, testing workflows, and plus skills to quickly find the right skill and start using it.
29 skills
Quick Start
- 1
Pick a skill
Choose the skill that best matches your current QA task.
- Use testing types for common tasks
- Use workflows for phase-based tasks
- Use plus skills for complex tasks
- 2
Prepare input
Provide context so the skill can generate actionable output.
- Include scope, environment, and timeline
- State expected output format
- Mark risk and priority in advance
- 3
Start using
Open the detail page and follow the guide and install section.
- Check scenario and audience first
- Use source links for quick jump
- Follow install steps directly
Skill Categories
Testing Types
Browse by testing capability.
Requirements & Strategy
-
requirements-analysis
Who should use: QAs and BAs who analyze requirements before case writing. Best used when: Requirements are ambiguous, changing, or risky and need testability assessment. How to use: Input requirement context, identify ambiguities and risks, then output clarifications and test direction.
View Details → -
test-strategy
Who should use: Test leads and senior QAs responsible for quality planning. Best used when: You need a risk-based testing plan for a feature set or release. How to use: Provide business goals and constraints, prioritize scope by risk, then define gates and execution plan.
View Details →
Case Design & Review
-
test-case-writing
Who should use: QAs who need executable and reviewable test cases. Best used when: Scope is clarified and the team needs concrete cases for execution. How to use: Start from requirements and risks, write atomic cases with data and expected results, then run a quality self-review.
View Details → -
test-case-reviewer
Who should use: Senior QAs reviewing case quality before execution. Best used when: Existing case sets are large and need quality, coverage, and maintainability review. How to use: Review traceability and scenario completeness, then output prioritized revision actions.
View Details →
Functional & Compatibility
-
functional-testing
Who should use: QAs validating business flow correctness end-to-end. Best used when: Core feature logic and state transitions need release confidence. How to use: Design main/edge/negative scenarios, execute with evidence, and summarize residual risk.
View Details → -
manual-testing
Who should use: Exploratory testers and QAs handling uncertain product behavior. Best used when: Automation is not ready or unknown risks need human exploration. How to use: Set an exploration charter, test with heuristics, and log reproducible findings.
View Details → -
mobile-testing
Who should use: Mobile QAs validating behavior across devices and OS versions. Best used when: Compatibility, lifecycle, network, and interaction risks must be checked on mobile. How to use: Build a device matrix, run key journeys under mobile-specific conditions, then report by device tier.
View Details →
API & Automation
-
api-testing
Who should use: API testers and backend-focused automation engineers. Best used when: API changes may impact contract, auth, payload, or integration behavior. How to use: Define API matrix, run contract and behavior checks, then report defects with reproducible evidence.
View Details → -
api-test-bruno
Who should use: API testers and backend-focused automation engineers. Best used when: API changes may impact contract, auth, payload, or integration behavior. How to use: Define API matrix, run contract and behavior checks, then report defects with reproducible evidence.
View Details → -
api-test-pytest
Who should use: API testers and backend-focused automation engineers. Best used when: API changes may impact contract, auth, payload, or integration behavior. How to use: Define API matrix, run contract and behavior checks, then report defects with reproducible evidence.
View Details → -
api-test-restassure
Who should use: API testers and backend-focused automation engineers. Best used when: API changes may impact contract, auth, payload, or integration behavior. How to use: Define API matrix, run contract and behavior checks, then report defects with reproducible evidence.
View Details → -
api-test-supertest
Who should use: API testers and backend-focused automation engineers. Best used when: API changes may impact contract, auth, payload, or integration behavior. How to use: Define API matrix, run contract and behavior checks, then report defects with reproducible evidence.
View Details → -
automation-testing
Who should use: Automation QAs and teams running CI/CD quality gates. Best used when: Manual regression is too costly and key flows need repeatable checks. How to use: Select stable high-value scenarios, automate in layers, and maintain suite health continuously.
View Details →
Quality Specialties
-
performance-testing
Who should use: Performance engineers and QAs handling capacity validation. Best used when: You need data-backed answers for latency, throughput, and bottleneck risk. How to use: Define SLO and workload model, execute phased load tests, then report bottlenecks and capacity thresholds.
View Details → -
performance-test-gatling
Who should use: Performance engineers and QAs handling capacity validation. Best used when: You need data-backed answers for latency, throughput, and bottleneck risk. How to use: Define SLO and workload model, execute phased load tests, then report bottlenecks and capacity thresholds.
View Details → -
performance-test-k6
Who should use: Performance engineers and QAs handling capacity validation. Best used when: You need data-backed answers for latency, throughput, and bottleneck risk. How to use: Define SLO and workload model, execute phased load tests, then report bottlenecks and capacity thresholds.
View Details → -
security-testing
Who should use: Security-minded QAs and teams validating sensitive flows. Best used when: Authentication, data protection, and abuse risks need verification. How to use: Map attack surface, test high-risk vectors, and provide risk-ranked findings with retest criteria.
View Details → -
accessibility-testing
Who should use: QAs and frontend teams responsible for inclusive user experience. Best used when: Key user flows must be validated for accessibility before release. How to use: Run semantic, keyboard, contrast, and assistive-tech checks, then prioritize fixes by user impact.
View Details →
Defect & Reporting
-
bug-reporting
Who should use: QAs who hand off defects to engineering and product. Best used when: Defects must be reproduced clearly for fast diagnosis and fix. How to use: Capture environment, steps, evidence, and impact, then track fix and retest to closure.
View Details → -
test-reporting
Who should use: QAs and leads responsible for quality communication. Best used when: Stakeholders need a decision-ready summary of test results and risks. How to use: Aggregate execution evidence, highlight blockers and trends, then provide clear next-step recommendations.
View Details → -
ai-assisted-testing
Who should use: QAs who use AI to accelerate analysis and test design. Best used when: You need faster QA drafts while preserving human quality control. How to use: Feed structured context, generate targeted outputs, then validate and refine before adoption.
View Details →
Testing Workflows
Browse by daily, sprint, and release workflows.
-
daily-testing-workflow
Who should use: QA coordinators, test leads, and cross-functional delivery teams. Best used when: You need daily task orchestration and blocker tracking rather than ad-hoc test execution. How to use: Set scope and timeline, run the workflow by phase, then output status, risks, and next actions.
View Details → -
discover-testing
Who should use: QA leads, PMs, and engineers who need to choose the right testing skill quickly. Best used when: A request is vague and you need a fast decision on which QA skill to run first. How to use: Describe the problem and constraints, let this skill route to the best next skill, then execute that selected skill.
View Details → -
sprint-testing-workflow
Who should use: QA coordinators, test leads, and cross-functional delivery teams. Best used when: You need sprint-level quality control and scope coordination rather than ad-hoc test execution. How to use: Set scope and timeline, run the workflow by phase, then output status, risks, and next actions.
View Details → -
release-testing-workflow
Who should use: QA coordinators, test leads, and cross-functional delivery teams. Best used when: You need release readiness checks and go/no-go coordination rather than ad-hoc test execution. How to use: Set scope and timeline, run the workflow by phase, then output status, risks, and next actions.
View Details →
Plus
Enhanced skills with deeper and more complete structure.
-
requirements-analysis-plus
Who should use: QAs and BAs who analyze requirements before case writing. Best used when: Requirements are ambiguous, changing, or risky and need testability assessment. How to use: Input requirement context, identify ambiguities and risks, then output clarifications and test direction.
View Details → -
test-case-reviewer-plus
Who should use: Senior QAs reviewing case quality before execution. Best used when: Existing case sets are large and need quality, coverage, and maintainability review. How to use: Review traceability and scenario completeness, then output prioritized revision actions.
View Details → -
test-strategy-plus
Who should use: Test leads and senior QAs responsible for quality planning. Best used when: You need a risk-based testing plan for a feature set or release. How to use: Provide business goals and constraints, prioritize scope by risk, then define gates and execution plan.
View Details → -
testcase-writer-plus
Who should use: QAs who need executable and reviewable test cases. Best used when: Scope is clarified and the team needs concrete cases for execution. How to use: Start from requirements and risks, write atomic cases with data and expected results, then run a quality self-review.
View Details →