QA Engineer Job Description: Template and Hiring Guide

Last updated: August 19, 2026

Most QA job descriptions attract the wrong candidates for one of two reasons. Either they are too vague and every applicant self-qualifies, or they are too prescriptive and require combinations of tools that don’t exist in the same candidate profile. Both failures waste sourcing time and produce a shortlist that requires extensive rescreening.

This guide breaks down every section of a QA engineer job description, explains what to include and why, identifies what to cut, and ends with a complete ready-to-use template sized for nearshore hiring from Costa Rica.

Why Most QA Job Descriptions Attract the Wrong Candidates

The problem starts in the first paragraph. Hiring managers who haven’t written a QA JD before often copy-paste from a generic template, add their specific tool names, and post. The result is a description that every QA candidate in the applicant pool can technically claim to meet while the actual role requires specific depth that the JD never clearly communicates.

Automation roles described as manual testing roles. If your role requires writing and maintaining a Cypress test suite, your JD needs to say: “Write and maintain automated test scripts in Cypress.” Not “experience with automated testing preferred.” The second phrasing attracts candidates who have run automated test suites without writing them, candidates who learned automation briefly in a bootcamp, and candidates who use “automated” to mean automated regression execution rather than script authoring.

Skill lists that contradict each other. A JD that requires “5 years of Selenium experience, Cypress, Playwright, Appium, k6, and ISTQB Advanced certification” describes three different senior QA specializations in one role. A Selenium specialist with Java background is a different hiring pool from a Cypress-focused front-end QA engineer. When you combine skills from different specializations, you either get no qualified candidates or candidates who list tools they have surface-level exposure to because the JD told them to.

Vague soft skill requirements that everyone claims. “Detail-oriented,” “quality mindset,” “passionate about quality,” and “strong communication skills” appear in approximately 90% of QA job descriptions and provide zero filtering signal. Every candidate reads these and self-approves. They also push down the character count, so the actual technical requirements that matter get less emphasis.

Writing the Responsibilities Section Correctly

The responsibilities section should describe what the QA engineer will do in a typical two-week sprint, not a comprehensive list of everything QA engineers everywhere do. Every item should be specific enough that a candidate can assess whether they have done that specific thing before.

Strong responsibilities section (automation-focused role):

• Write and maintain end-to-end test scripts in Cypress against our web application’s critical user journeys
• Design test plans from product requirements documents, identifying positive paths, negative paths, edge cases, and boundary conditions
• Integrate test runs into CI/CD pipeline via GitHub Actions and surface failures before merge to main
• Execute regression suite before each release and document results in TestRail
• Write clear, reproducible bug reports in Jira including severity, environment, reproduction steps, and expected behavior
• Participate in sprint ceremonies including planning, standups, and retrospectives in English
• Collaborate with developers to review requirements for testability before implementation begins

Compare that to a weak responsibilities list that reads like a job category rather than a specific role: “Ensure software quality,” “Perform testing activities,” “Collaborate with cross-functional teams,” “Identify defects and verify fixes.” These descriptions could apply to any QA role at any company in any technology context. They provide no filtering value.

Notice that the strong version tells a candidate exactly what framework they’ll use, what CI/CD system they’ll integrate with, what project management tools they’ll work in, and what the collaboration requirements are. A candidate reading this knows immediately whether they have done this work before.

Required Skills and Tool Specifications

The required skills section is where most JDs lose specificity. The goal is to list the tools the engineer will use weekly, organized by function, with the depth level specified where it matters.

Test design and execution: Name the test case management tool (TestRail, Zephyr, Xray, spreadsheet-based) and the bug tracking tool (Jira, Linear, Azure DevOps). Candidates need to know the workflow context, not just that you use a bug tracker.

Automation framework: Be specific. “Cypress 13+” is more precise than “JavaScript-based automation experience.” If you need someone who can write page object models and handle complex async waits, say so. “Experience writing and maintaining Cypress test suites with page object model structure” tells the candidate exactly what level of depth you’re looking for.

API testing: Postman for manual API exploration and REST Assured for automated API testing are different skill profiles. If your QA engineer needs both, list both. If they only need one, list one and don’t pad the JD with the other.

CI/CD integration: Name your actual CI/CD system. GitHub Actions, Jenkins, CircleCI, and GitLab CI all require slightly different configuration knowledge. A candidate who knows Jenkins deeply may need 2 to 3 days to get productive with GitHub Actions. That’s not a deal-breaker, but it’s worth noting in the JD.

English proficiency: For nearshore roles, specify the required English level explicitly. “B2 English (upper-intermediate) required: ability to write clear bug reports, participate in English-language sprint ceremonies, and communicate directly with US-based product and engineering teams.” This is not implied by listing that the role is remote or nearshore. State it directly.

Nice-to-Have vs. Required: Drawing the Line Correctly

The nice-to-have section creates a filtering problem when it contains skills that are actually required and when it contains so many items that candidates ignore it entirely.

A clean rule: anything that will affect your hiring decision goes in “Required.” Anything that would make two otherwise equally qualified candidates differentiate goes in “Nice to Have.” If you won’t hire someone without ISTQB certification, it’s required. If you’d prefer ISTQB but would hire a strong candidate without it, it’s nice to have.

Common items that belong in Required, not Nice-to-Have:

• Specific automation framework experience (if the role is automation-focused)
• English proficiency level (for nearshore roles with live collaboration)
• Experience with your specific testing methodology (BDD, TDD, risk-based testing)
• CI/CD integration experience (if the role owns test pipeline integration)

Items that genuinely belong in Nice-to-Have:

• ISTQB Foundation or Advanced certification (genuinely adds value but isn’t a hiring gate)
• Experience with a second automation framework (Playwright if you use Cypress primarily)
• Performance testing experience with k6 or JMeter (if QA primarily owns functional testing)
• Accessibility testing experience (WCAG, axe-core) for teams that plan to expand into this area
• Mobile testing with Appium (if mobile testing is occasional, not primary)

Writing Seniority-Level Variations That Actually Filter

The same QA engineer JD does not scale across seniority levels. A junior QA engineer JD that requires “5+ years of experience” will generate zero qualified applicants. A senior QA engineer JD that uses junior-level responsibility descriptions will attract mid-level candidates who believe they can grow into the role. Write separate JDs for each seniority level, or write a base JD with clearly marked seniority tiers.

Junior QA engineer (1 to 3 years): Responsibilities focus on execution under guidance. They write test cases from specifications provided by a senior QA or PM, execute manual regression suites, and are learning to write automation scripts. Required skills are narrow: the specific testing tools the team uses, English at B2 level, and demonstrated ability to write clear bug reports. Do not require automation framework mastery at this level; require the ability to follow an established automation pattern.

Mid-level QA engineer (3 to 6 years): Independently designs test plans from requirements, writes automation scripts without scaffolding, identifies edge cases proactively, and participates in requirements review before development begins. Required skills include the automation framework at a working level (not just conceptual familiarity), bug tracking tools, and CI/CD integration experience. Can mentor junior QA engineers on test case writing.

Senior QA engineer (6+ years): Owns test strategy for the team or product area, makes framework selection decisions, sets up test infrastructure from scratch, defines release readiness criteria, and leads QA retrospectives. Required skills include deep expertise in at least one automation framework, experience building test suites from zero, and demonstrated ability to influence engineering process decisions. At this level, ISTQB Advanced or equivalent demonstrated methodology depth is reasonable to require.

What to Cut from Your QA Job Description

Cutting is as important as writing. A bloated JD with 25 required skills, five nice-to-haves, and three paragraphs of company culture description performs worse than a focused JD with 8 precise requirements and a clear compensation range.

Cut: “Attention to detail.” Every QA candidate claims this. It signals nothing. Replace it with a specific responsibility that demonstrates the type of detail work required: “Write test cases covering edge cases and boundary conditions without explicit specification guidance.”

Cut: “Quality mindset” and “passion for quality.” These phrases are meaningless without context. A candidate who has spent three years writing automation scripts for a fintech platform has a quality mindset that looks nothing like a candidate who has spent three years doing exploratory testing on a consumer mobile app. Neither is wrong, but they are different.

Cut: “Rockstar,” “ninja,” or “guru.” These terms actively filter out experienced senior engineers who read them as signals of an immature hiring process. They attract recent bootcamp graduates who respond to marketing language.

Cut: Tool lists longer than 8 items in Required. If you have 15 tools in your required skills list, you are describing a team of QA engineers, not a single hire. Pick the 5 to 8 tools the engineer will use in every sprint and move everything else to Nice-to-Have or remove it entirely.

Cut: Vague experience duration requirements. “5+ years of QA experience” is not meaningful. A candidate with 5 years of manual testing who pivoted to automation 6 months ago is not the same as a candidate with 5 years of automation engineering. Replace duration requirements with output requirements: “Demonstrated ability to build a Cypress test suite from scratch, including page object structure, test data management, and CI/CD integration.”

Complete QA Engineer Job Description Template

The following template is ready to copy, customize, and post. Replace bracketed items with your specifics. This template is sized for a mid-level nearshore QA engineer with Cypress automation focus.

Customize the bracketed sections for your stack. If your role is junior, remove the CI/CD integration requirement from Required and move it to Nice-to-Have. If your role is senior, add framework selection and test infrastructure setup to Responsibilities.

Frequently Asked Questions

Disclosure: Kore BPO is a nearshore and offshore staffing agency. This article reflects our direct experience placing QA engineers from Costa Rica with US engineering teams.