QA skills matrix template
| Skill | 0 Not started | 1 Aware | 2 Working | 3 Strong | 4 Lead |
|---|---|---|---|---|---|
| Manual test design | Has not written test cases | Understands basic test cases | Writes clear test cases for common flows | Designs risk-based coverage across features | Coaches others and reviews test strategy |
| API testing | Has not tested APIs | Understands requests and responses | Tests status codes, payloads, auth, and errors | Designs API coverage across workflows and environments | Coaches others and connects API testing to automation and release risk |
| AI testing | Has not tested AI features | Understands hallucination and prompt sensitivity | Tests common prompt and output risks | Designs AI risk coverage for product features | Coaches teams on AI test strategy and escalation paths |
| Test automation | Has not written automated tests | Understands what automation can and cannot do | Automates stable checks with support | Maintains suites and investigates flaky failures | Guides automation strategy and review practices |
| DevOps testing | Has not worked with pipelines | Understands CI/CD basics | Uses pipeline results and environment notes | Connects test feedback to release risk | Coaches teams on QA feedback loops |
What a QA skills matrix is
A skills matrix is a table that shows what a team can do today and where it needs growth. It can cover manual test design, API testing, automation, AI testing, DevOps testing, security, performance, usability, and domain knowledge.
In practice
A lead maps manual testing, API testing, automation, AI testing, and release-risk skills before planning a quarter of work.
What helps: The matrix shows team coverage and gaps tied to product needs.
What gets missed: The table becomes a generic list of names and scores with no link to delivery risk.
Why managers use it
Managers use a skills matrix to plan training, reduce single points of failure, pair people for coaching, and make hiring needs clearer. It helps answer practical questions like who can review API coverage or who can guide chatbot testing.
Better vs weaker evidence
A QA manager sees that only one tester can review API coverage before that tester goes on leave.
Stronger evidence
The matrix turns the gap into a backup plan, pairing plan, or training target.
Thin evidence
The gap is discovered during release week when nobody else can review the risky change.
How to rate skills without embarrassing people
Make the matrix about team coverage, not public ranking. Let people self assess, then discuss examples privately. Use observed work and peer review. Avoid turning a 0 into shame. Everyone has 0s somewhere.
In practice
A manager asks testers to self-assess privately and then reviews examples such as test cases, bug reports, and API checks.
What helps: Ratings are discussed as coaching data with evidence behind them.
What gets missed: Scores are announced in a meeting and people stop admitting what they need to learn.
Skill levels
- 0 Not started: No meaningful exposure yet.
- 1 Aware: Understands the basic idea and terms.
- 2 Working: Can apply the skill with normal support.
- 3 Strong: Can handle varied work and explain tradeoffs.
- 4 Lead: Coaches others and shapes strategy.
In practice
The team defines level 2 API testing as checking status codes and auth with support, while level 4 means coaching others on coverage strategy.
What helps: Each level describes observable behavior and examples.
What gets missed: Levels are treated as vague labels that mean different things to every manager.
Manual testing row
Manual test design should cover test cases, exploratory testing, risk analysis, bug reports, regression planning, and acceptance criteria review. A strong tester designs coverage across features, not only individual screens.
Better vs weaker evidence
Two testers both write test cases, but one covers common flows while the other designs risk-based coverage across refunds, permissions, and regression impact.
Stronger evidence
Level 2 and level 3 are separated by observed scope, risk thinking, and independence.
Thin evidence
Ratings are assigned from job title instead of actual testing artifacts.
For entry-level skill definitions, use How to Become a QA Tester.
API testing row
API testing should cover requests, responses, status codes, payload validation, authentication, authorization, errors, environments, and data cleanup. Strong API testers connect endpoint behavior to product workflows.
Better vs weaker evidence
The UI looks right while the API response leaks an internal account flag.
Stronger evidence
The tester checks status, body fields, auth rules, and cleanup.
Thin evidence
The test stops at a green response code and misses the unsafe data.
API growth plans should point testers toward API Testing for QA Testers.
Test automation row
Automation should cover selecting good candidates, writing maintainable tests, reviewing failures, managing data, and understanding pipeline feedback. Strong automation skill includes knowing what not to automate.
Practice lens
A manager rates two testers at level 2 working but realizes one can write a stable Playwright test from scratch while the other can only update an existing test. The matrix gets refined with examples instead of just labels.
Useful evidence: Each level on the matrix is anchored to specific observable work: can write, can extend, and can review.
Thin evidence: Ratings are assigned from intuition and two testers rated the same level have wildly different actual ability.
AI testing row
AI testing should cover hallucinations, prompt sensitivity, output quality, privacy, bias, safety, monitoring, and escalation. Strong AI testing skill includes explaining uncertainty and risk clearly.
Better vs weaker evidence
A new chatbot feature needs privacy testing and the matrix shows who has practiced prompt variation, leakage checks, and escalation review.
Stronger evidence
The team picks a lead and a learner before testing starts.
Thin evidence
The AI work is assigned randomly and privacy checks are discovered late.
For AI practice, pair the matrix with the AI Testing Checklist.
DevOps testing row
DevOps testing should cover CI/CD feedback, smoke tests, environments, test data, release risk, logs, and production signals. Strong contributors help the team trust the pipeline.
What to save
- Situation: A checkout change reaches release planning before anyone asks about expired coupons or refund paths.
- Evidence: QA raises the risk during refinement and ties it to acceptance criteria.
- Easy miss: Testing starts after merge and the team learns about the gap under release pressure.
Security testing row
Security testing for QA teams often starts with basic access control, sensitive data handling, session behavior, input validation, and safe error messages. For API-heavy teams, the OWASP API Security Top 10 gives leads a useful checklist of risk areas to discuss. Specialist security work may require dedicated expertise.
In practice
A payment feature is shipping and the team maps who can review basic access control, session behavior, and safe error messages.
What helps: The matrix identifies who can run QA-level security checks and when a specialist is needed.
What gets missed: Everyone assumes someone else checked permissions until a defect appears in review.
Performance testing row
Performance skill can start with noticing slow flows, measuring response times, and understanding load basics. Stronger skill includes test design, bottleneck investigation, and realistic workload modeling.
Better vs weaker evidence
A peak season launch is coming and the matrix shows nobody can run even a basic load check or interpret response-time results.
Stronger evidence
The manager creates a small training plan before the risk becomes urgent.
Thin evidence
The team waits until traffic increases and learns it has no performance evidence.
Usability testing row
Usability testing covers clarity, flow, accessibility basics, error recovery, form behavior, and user friction. QA teams often find practical usability problems during exploratory testing.
Better vs weaker evidence
During sprint review, exploratory testing finds an error message that tells users payment failed but not whether they were charged.
Stronger evidence
The matrix captures practical usability observation as a skill the team can coach.
Thin evidence
The team treats usability as design-only work and misses recoverability problems.
For team planning around accessibility and AI risk, the W3C accessibility principles and NIST AI RMF give leads shared language.
How to turn the matrix into a training plan
Pick two or three team gaps per quarter. Pair a stronger tester with someone learning. Assign a practice project, review artifacts, and decide what proof shows progress. Keep the plan small enough to finish.
In practice
A team chooses API cleanup, AI privacy prompts, and release-risk notes as the quarter’s three practical training targets.
What helps: Each gap gets a coach, a practice task, and an artifact to review.
What gets missed: The matrix is updated once and never turns into work anyone can practice.
How to avoid using it badly
- Do not use the matrix as a public scoreboard. A public scoreboard makes people protect their image instead of sharing gaps. Use the matrix for coaching and coverage planning, with sensitive individual detail handled carefully.
- Do not treat credentials as the only proof. Credentials are useful signals, but they are not the whole skill story. Combine them with observed work, peer review, practice artifacts, and product results.
- Do not rate people without examples. Ratings without examples become opinions. Tie each level to real artifacts, such as a reviewed API checklist, a stable smoke test, or a risk note from a release.
- Do not pretend every skill needs a 4. Not every tester needs to lead every skill. A healthy team has coverage across people, with clear backups for the skills the product needs most.
- Do not ignore the work the product actually needs. A matrix that ignores product needs becomes busywork. Prioritize skills tied to the roadmap, current defects, release risk, and the team’s actual delivery bottlenecks.
What to save
- Situation: A manager shares that the team needs more API and AI coverage without posting individual scores in a public channel.
- Evidence: The matrix is used for coaching, pairing, and planning at the team level.
- Easy miss: Individual ratings are published as a scoreboard and people start hiding skill gaps.
Map your matrix to AT*SQA credentials
A skills matrix is most useful when each skill has a verifiable proof point. AT*SQA micro-credentials map cleanly onto matrix rows: Test Automation, API Testing, AI for Testers, DevOps Testing, Performance Testing, Cybersecurity Testing, and Testing Essentials, with most exams at $39 (API Testing $49), two open-notes attempts each, valid for a year.
For team upskilling, AT*SQA’s AT*Learn training subscriptions start at $39 for a year of access and give consistent material across the team.
As team members earn credentials, each one appears on the Official U.S. List of Certified and Credentialed Software Testers and adds Testing Tiers points, giving you an external, verifiable record of team capability rather than a self-assessed spreadsheet. Complete an AT*SkillStack and the full certification is awarded at no additional cost, so a column of micro-credentials rolls up into a recognized certification.
FAQ
Questions testers ask
Should every tester aim for level 4 in every skill?
No. Teams need balanced coverage. Some people will lead in API testing while others lead in exploratory testing or release risk.
Can credentials be part of a skills matrix?
Yes, as one signal. Include observed work, peer review, practice projects, and coaching too.
How often should the matrix be updated?
Quarterly is often enough for planning. Update sooner if the team changes or a major product need appears.
Should the matrix be public?
Team level gaps can be discussed openly. Individual ratings should be handled with care and context.
How do I introduce a QA skills matrix without making the team defensive?
Explain that the matrix is for coverage and training, not public ranking. Let testers self-assess, then review examples privately. Start with team gaps before talking about individual ratings.
What skills should a QA skills matrix include?
Include the skills your product actually needs: manual test design, API testing, automation, AI testing, DevOps testing, security basics, performance awareness, usability, accessibility, and domain knowledge. Do not copy a generic matrix if it ignores your release risks.
How do I validate someone’s skill level fairly?
Use observed work, peer review, practice artifacts, and coaching conversations. Credentials can be one signal, but they should not be the only measure. Ask for examples of test cases, bug reports, automation changes, or risk analysis.
How often should a QA team update its skills matrix?
Quarterly works for many teams because it lines up with training planning. Update sooner after major hiring, turnover, product shifts, or a new risk area such as AI features. Keep the process lightweight.
How do I turn a QA skills matrix into a training plan?
Pick two or three gaps that matter to upcoming work, then assign practice projects, pairing, review sessions, and optional credentials. Make the next step concrete. A matrix without action is just a table.