qa-process-improvement
Skill5 starsChanged 9 months agoMITView on GitHub
Drive continuous improvement of QA processes through metrics analysis, retrospectives, best practice adoption, and team enablement. Focus on efficiency, effectiveness, and quality outcomes.
In this repository10 other files it gives its agents.
- browser-useSkill
- cicd-testing-integrationSkill
- defect-lifecycle-managerSkill
- find-skillsSkill
- multi-agent-orchestrationSkill
- skill-creatorSkill
- test-design-istqbSkill
- test-execution-managerSkill
- user-story-static-verifierSkill
- senior-qa-engineerSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use this skill when you need to:
- Distinctive: line 136
Test during development, not after
- Distinctive: line 154
Start with smoke tests, then expand
- Distinctive: line 199
Test data generation tools
- Distinctive: line 313
Test Management: Jira, TestRail, Zephyr
- Distinctive: line 314
Test Automation: Selenium, Playwright, Cypress
- Distinctive: line 337
Do they still make sense?
- Distinctive: line 340
Update or retire outdated docs
- Distinctive: line 380
Start with data, not opinions
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
QA Process Improvement
Expert skill for analyzing QA effectiveness and driving continuous improvement initiatives.
When to Use
Use this skill when you need to:
- Analyze QA process effectiveness
- Identify bottlenecks and inefficiencies
- Implement process improvements
- Adopt new tools and techniques
- Reduce test maintenance burden
- Improve team productivity
- Enhance quality outcomes
Improvement Framework
1. Measure Current State
Collect baseline metrics:
- Test coverage
- Defect detection rate
- Test execution time
- Automation coverage
- Defect escape rate
- Time to feedback
- Team velocity
2. Identify Problems
Common pain points:
- Tests take too long to run
- High maintenance burden
- Too many escaped defects
- Late defect discovery
- Manual repetitive work
- Unstable test environment
- Unclear requirements
3. Analyze Root Causes
Use techniques:
- 5 Whys
- Fishbone diagram
- Pareto analysis
- Process mapping
- Team retrospectives
4. Design Solutions
Improvement categories:
- Process changes
- Tool adoption
- Automation expansion
- Skill development
- Communication improvements
5. Implement & Measure
Track impact:
- Before/after metrics
- ROI calculation
- Team feedback
- Stakeholder satisfaction
Key Metrics for Improvement
Quality Metrics
Defect Detection Efficiency (DDE)
DDE = (Defects in QA) / (Defects in QA + Production) × 100%
Goal: > 90%Escaped Defect Rate
Rate = (Production defects) / (Total defects found)
Goal: < 5%Defect Removal Efficiency
Efficiency = (Defects removed in phase) / (Total defects) × 100%Efficiency Metrics
Test Automation Coverage
Coverage = (Automated tests) / (Total tests) × 100%
Goal: 70-80% for regression suiteTest Execution Time
Time = Total duration for test suite run
Track: Trend over time
Goal: Decreasing or stableTime to Market
Time from code commit to production deployment
Goal: Reduce cycle timeEffectiveness Metrics
First Time Pass Rate
Rate = (Builds passing tests first time) / (Total builds)
Goal: > 80%Test Flakiness Rate
Rate = (Flaky tests) / (Total automated tests)
Goal: < 2%Mean Time to Detect (MTTD) Defects
Average time from defect introduction to discovery
Goal: Shift left, detect earlierCommon Improvement Initiatives
1. Shift-Left Testing
Problem: Defects found late, expensive to fix
Solution:
- Involve QA in requirements review
- Test during development, not after
- Unit test coverage requirements
- Automate tests incrementally
- Continuous testing in CI/CD
Expected Impact:
- 50% reduction in defect fix cost
- Faster feedback to developers
- Earlier defect detection
2. Test Automation Expansion
Problem: Too much manual regression testing
Solution:
- Automate repetitive test cases
- Implement test automation framework
- Train team on automation tools
- Start with smoke tests, then expand
- Maintain automation suite health
Expected Impact:
- 70% reduction in regression time
- More time for exploratory testing
- Consistent test execution
3. Reduce Test Flakiness
Problem: Unreliable automated tests causing trust issues
Solution:
- Identify and quarantine flaky tests
- Root cause analysis for each
- Implement proper waits (not sleep)
- Ensure test independence
- Improve test data management
Expected Impact:
- < 2% flakiness rate
- Increased confidence in automation
- Reduced investigation time
4. Improve Test Environments
Problem: Environment instability blocking testing
Solution:
- Use containerization (Docker)
- Infrastructure as Code
- Self-service environment provisioning
- Automated environment setup
- Environment monitoring
Expected Impact:
- Reduced blocked testing time
- Faster environment recovery
- Consistent configurations
5. Enhance Test Data Management
Problem: Insufficient or outdated test data
Solution:
- Test data generation tools
- Data refresh automation
- Synthetic data creation
- Production data masking
- Data versioning
Expected Impact:
- Better test coverage
- Reduced data-related failures
- Compliance with privacy regulations
6. Optimize Test Execution
Problem: Tests take too long to run
Solution:
- Parallel test execution
- Selective test execution
- Test prioritization
- Remove obsolete tests
- Cache dependencies
Expected Impact:
- 50-70% reduction in execution time
- Faster feedback loops
- More frequent testing
Retrospective Framework
Sprint Retrospective Template
What Went Well:
1. [Positive outcome]
2. [Success to replicate]
What Didn't Go Well:
1. [Problem encountered]
2. [Pain point]
What We Learned:
1. [Insight gained]
2. [New understanding]
Action Items:
1. [Who] will [what] by [when]
2. [Who] will [what] by [when]
Follow-up from Last Retro:
- [Previous action]: [Status]Improvement Experimentation
Use hypothesis-driven improvements:
Hypothesis: If we [change X], then [metric Y] will improve by [Z]
Example:
If we parallelize our E2E tests across 4 machines,
then total execution time will reduce from 60min to <20min.
Experiment:
- Setup: Configure parallel execution
- Duration: 2 weeks
- Success criteria: <20min consistently
- Measure: Track daily execution times
Result: [Success / Partial / Failed]
Learning: [What we discovered]
Next: [Continue / Adjust / Abandon]Knowledge Sharing
Team Enablement
Training Topics:
- Test automation frameworks
- New tool adoption
- Testing techniques (ISTQB)
- Domain knowledge
- Best practices
Knowledge Transfer Methods:
- Lunch & learn sessions
- Pair testing
- Documentation wiki
- Code reviews
- Demo sessions
Communities of Practice
Establish:
- QA guild meetings (bi-weekly)
- Testing best practices repository
- Automation framework library
- Troubleshooting guides
- Lessons learned database
Tool Evaluation
When to Adopt New Tools
Evaluate based on:
- Problem Fit: Does it solve our specific pain?
- ROI: Cost vs benefit analysis
- Integration: Works with existing stack?
- Learning Curve: Can team adopt quickly?
- Support: Vendor support and community
- Scalability: Grows with our needs
Tool Categories for QA
- Test Management: Jira, TestRail, Zephyr
- Test Automation: Selenium, Playwright, Cypress
- API Testing: Postman, REST Assured, SoapUI
- Performance: JMeter, k6, Gatling
- CI/CD: Jenkins, GitHub Actions, GitLab CI
- Monitoring: Datadog, New Relic, Grafana
Process Documentation
Living Documentation
Maintain up-to-date:
- QA process flowcharts
- Test strategy document
- Automation framework guide
- Environment setup instructions
- Defect management workflow
- Release checklist
- Runbooks for common issues
Process Review
Quarterly reviews:
- Are documented processes followed?
- Do they still make sense?
- What's changed in our context?
- Where are inefficiencies?
- Update or retire outdated docs
Continuous Improvement Checklist
Monthly activities:
- ✓ Review and analyze key metrics
- ✓ Identify top 3 pain points
- ✓ Conduct retrospective
- ✓ Update action items
- ✓ Share learnings with team
Quarterly activities:
- ✓ Process health assessment
- ✓ Tool evaluation
- ✓ Skills gap analysis
- ✓ Roadmap planning
- ✓ Stakeholder feedback collection
Annually:
- ✓ QA strategy review
- ✓ Team maturity assessment
- ✓ Industry trends research
- ✓ Certification/training plan
- ✓ Long-term improvement roadmap
Success Indicators
You know improvement is working when:
- ✓ Defect escape rate decreasing
- ✓ Test automation coverage increasing
- ✓ Test execution time decreasing
- ✓ Team velocity stable or increasing
- ✓ Developer satisfaction with QA improving
- ✓ Production incidents decreasing
- ✓ Time to market decreasing
- ✓ Team morale improving
- ✓ Stakeholder confidence high
Best Practices
- Start with data, not opinions
- Focus on high-impact improvements
- Involve the whole team
- Experiment and iterate
- Celebrate successes
- Learn from failures
- Share knowledge broadly
- Measure everything
- Never stop improving
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

