qa-jd-author
Build-an-X workflow that authors a QA job description for a given role and seniority - responsibilities drawn from the ISTQB CTFL v4.0 split between the testing role (test analysis, design, implementation, execution) and the test management role (planning, monitoring and control, completion), a must-have versus nice-to-have skills split, and the screening signals a recruiter can apply to applications. The competency vocabulary matches `hiring-rubric-author`, so the JD a candidate reads and the rubric they are scored on describe the same role. Distinct from `interview-question-author` (first artifact of running the loop; this skill produces the artifact that opens the role), from `hiring-rubric-author` (scores candidates; this skill attracts them), and from `onboarding-plan-author` (post-hire ramp). Use when opening a QA / SDET / automation / test-lead / quality-manager requisition, before anything is posted - the JD is the upstream-most artifact of the hiring chain.
qa-jd-author
Overview
The JD is the first scoring instrument in the hiring chain, applied by candidates to themselves: a vague posting screens nobody, and an everything-list screens out exactly the people the team wants. This skill produces a JD whose responsibilities come from the role's actual test activities and whose skills section uses the same competency vocabulary the downstream hiring-rubric-author rubric will score - so the role a candidate applies to is the role the panel evaluates.
Two grounding sources. For what the role does: ISTQB CTFL v4.0 section 1.4.5 defines two principal roles in testing - the testing role, which "takes overall responsibility for the engineering (technical) aspect of testing" and is "mainly focused on the activities of test analysis, test design, test implementation and test execution", and the test management role, which "takes overall responsibility for the test process, test team and leadership of the test activities" and is "mainly focused on the activities of test planning, test monitoring and control and test completion". The same section notes one person may take on both roles at the same time (ISTQB CTFL Syllabus v4.0, §1.4.5; syllabus text verified 2026-06-10 from the published PDF). For how the document reads: Workable's JD guidance - clear, standard job titles (creative titles like "Rockstar Engineer" read as "unrealistic and potentially discriminatory"), 300 - 660 words total, bulleted duties that show a typical workday, and requirements split into must-have versus nice-to-have (Workable, "How to write a good job description", fetched 2026-06-10).
When to use
Do not use this skill to:
Step 1 - Capture the inputs
| Input | Notes |
|---|---|
| Role + seniority | Same axis the sibling skills use: manual QA / automation / SDET / test lead / quality manager × junior / mid / senior / staff+ |
| Role balance | Where this role sits between CTFL's testing role and test management role; a senior SDET is nearly all testing role, a test lead carries a documented share of the management role (CTFL §1.4.5) |
| Team context | Stack and toolchain, domain, test levels in scope, why the role is open (a capability-gap report from team-capability-gap-analyst in qa-team-management is the ideal version of this input) |
| Constraints | Location/remote, compensation-disclosure rules in the posting jurisdictions, non-negotiables |
Step 2 - Derive responsibilities from the role's test activities
Write 5 - 8 responsibility bullets, each traceable to a test activity, phrased as a typical-workday action (Workable's guidance: duties should show what a normal day looks like, not an aspirational mission). Map per role balance:
A role that is 100% one kind needs no bullets from the other; a mixed role states the split rather than hiding it ("~70% hands-on automation, ~30% process ownership").
Step 3 - Split skills into must-have vs nice-to-have
The split is the JD's main screening mechanism (Workable: be upfront about non-negotiables; separate must-have from nice-to-have so candidates self-assess accurately). Rules:
Step 4 - Define screening signals for the recruiter
The JD ships with a one-page screening note (internal, not posted): for each must-have, what in a CV or portfolio counts as signal vs noise. Example for "tooling depth, Playwright":
| Signal | Noise |
|---|---|
| Public repo or described project with Playwright specs they authored | "Playwright" in a skills word-cloud |
| Describes flake-debugging or CI-stabilization work | Lists every test tool released since 2015 |
| Automation framework decisions they can own ("migrated from X because...") | Certification list with no applied work |
This note is what keeps the recruiter's screen consistent with the panel's rubric - the same chain-of-custody idea the structured-interview triple applies after the screen.
Step 5 - Assemble and length-check the JD
Order: title, one-paragraph role summary (which includes why the role is open), responsibilities, must-haves, nice-to-haves, team and stack, process and timeline, compensation per jurisdiction rules. Target 300 - 660 words total per Workable's guidance; bulleted lists for mobile readability. Worked example (condensed):
# Senior QA Automation Engineer - Payments
We run weekly releases for a payments product used by 40k merchants. This role
is open because our capability review found one engineer covering performance
testing for the whole group; you will broaden and own that coverage. ~80%
hands-on engineering, ~20% strategy input for your area.
## What you will do
- Design and automate regression tests for payment-retry and reconciliation flows
(TypeScript + Playwright, k6 for load profiles).
- Extend the CI quality gates: flake quarantine, suite budget, pass-rate reporting.
- Run risk-based test analysis on new payment features with the product trio.
- Coach two mid-level engineers on test design through review.
## Must have
- Test analysis and design: you can derive tests from risks and requirements,
not only from acceptance criteria handed to you.
- Production-grade test code in TypeScript or a near language; you have owned
a suite others contribute to.
- Load or performance testing on at least one real system (k6, Gatling, or similar).
- Written communication: bug reports and strategy notes that stand alone.
## Nice to have
- Payments or other regulated-domain background; ISTQB CTAL-TA; CI ownership
(GitHub Actions); accessibility testing exposure.(~420 words in full form, inside the 300 - 660 band.)
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Unicorn JD (every tool, every level, "QA ninja") | Screens out honest strong candidates; Workable flags creative titles as unrealistic and potentially discriminatory | Standard title; 4 - 6 must-haves with the Step 3 reject-test |
| Years-of-experience as must-haves | Years measure exposure, not competence, and import bias | Phrase must-haves as capabilities with observable evidence |
| JD vocabulary differing from the rubric | Candidate applies to one role, gets scored on another; debriefs derail | Step 3 reuses hiring-rubric-author competency dimensions |
| Responsibilities copied from a template | The workday described matches no actual workday; early attrition follows | Step 2 derives bullets from the team's real test activities |
| Hiding the management share of a lead role | Candidates discover the meeting load after signing | State the split explicitly (Step 2) |
| Posting with no screening note | Recruiter invents their own filter; the funnel disconnects from the rubric | Step 4 note ships with the JD |