How to find a QA engineer.

Quality engineering split into two roles that share a label. One is a software engineering job: building test frameworks, writing maintainable automation, integrating with CI pipelines. The other is testing work that may involve little or no code. Both are advertised as QA.

The distinction matters because automation succeeds or fails on code quality. A recorded script suite becomes unmaintainable within months; a well-designed framework survives years of product change. Screening on which tools someone has used rather than how they write code is why so many automation investments quietly get abandoned.

Job titles worth searching

Grouped by what the person actually does, because searching all48 at once produces a result set you cannot triage. Decide which group you need first — that decision does more for the search than any string below.

Where QA engineers actually are

GitHub answers the question that matters most for automation roles. A published test framework shows structure, abstraction, and whether someone writes code that will survive product change — which is the difference between automation that pays off and a suite that gets deleted in eighteen months.

Testing has an unusually strong craft culture in writing and conferences. TestBash, Agile Testing Days, and EuroSTAR are practitioner-led rather than vendor-driven, and the context-driven testing community writes extensively about heuristics and strategy. People engaged with that literature think about quality strategically, which is what senior roles actually need.

The most under-searched pool is manual testers who have begun learning automation independently. They combine domain knowledge of what should be tested with growing ability to automate it, and in a complex product that combination is often more useful than an automation engineer who does not understand the domain. They are also far less contested.

Boolean search strings

Written to be pasted as-is. Each one is built around an intent rather than a platform, since the useful question is what you are trying to find, not which site you happen to be on.

site:linkedin.com/in/ ("SDET" OR "QA engineer" OR "test automation") (Selenium OR Cypress OR Playwright OR "API testing") "{city}"

site:github.com ("playwright" OR "cypress" OR "selenium" OR "pytest") ("framework" OR "page object" OR "fixtures") -tutorial -awesome

("SDET" OR "software engineer in test") ("Java" OR "Python" OR "TypeScript") ("CI/CD" OR "pipeline" OR "framework design") -jobs -course

("performance testing" OR "load testing" OR "JMeter" OR "k6" OR "Gatling") ("bottleneck" OR "throughput" OR "latency") -jobs -course

("exploratory testing" OR "testing strategy" OR "test heuristics" OR "context-driven") ("wrote" OR "blog" OR "how we") -jobs -course

("speaker" OR "workshop") ("TestBash" OR "Agile Testing Days" OR "SeleniumConf" OR "EuroSTAR") 2024..2026 -jobs

("validation engineer" OR "GxP" OR "CSV" OR "IQ OQ PQ" OR "21 CFR Part 11") ("testing" OR "qualification") -jobs

("manual tester" OR "QA analyst") ("learning automation" OR "transitioning" OR "Selenium" OR "self-taught") -jobs -course

Mistakes that cost the most time

1. Advertising for a QA engineer when you need an SDET

   SDET is a software engineering role that focuses on testing — building frameworks, writing maintainable code, integrating with CI pipelines. Many QA candidates cannot do this, and advertising it as QA attracts people who will fail the technical screen. Naming it SDET and testing coding ability properly saves everyone time.

2. Treating automation as a tool skill

   Automation succeeds or fails on code quality. A recorded script suite becomes unmaintainable within months, while a well-designed framework survives years of product change. Screening on framework names rather than on code quality selects for the wrong thing, and the cost appears eighteen months later as an abandoned test suite.

3. Dismissing manual testing entirely

   Skilled exploratory testers find classes of problem that scripted automation cannot, particularly around usability, edge cases, and unexpected user behaviour. Domain-expert testers in complex products are genuinely hard to replace. Treating manual testing as obsolete discards real capability, though the role should evolve rather than stay static.

4. Ignoring the shift-left change

   Many organisations have moved testing into engineering teams, with quality engineers enabling developers to test well rather than running a separate QA gate. Candidates from traditional siloed QA functions may struggle in that model, and candidates used to it will be frustrated by a gatekeeping role. Describe which model actually operates.

5. Confusing performance and security testing with functional QA

   These are separate disciplines. Performance testing requires understanding system behaviour under load; security testing requires offensive knowledge. A strong functional tester does not automatically have either. Roles needing them should say so, since a general QA advert will not attract those specialists.

6. Overlooking manual testers who are learning automation

   Testers with deep domain knowledge who have started learning automation on their own time combine two valuable things: understanding what should be tested and growing ability to automate it. They are considerably less contested than experienced automation engineers and often more useful in a complex product.

Common questions

What job titles should I search for when hiring a QA engineer?

Depends heavily on whether the role is automation-focused. For automation, search SDET, Software Development Engineer in Test, Test Automation Engineer, and QA Automation Developer — these people frequently avoid the plain 'QA Tester' label. For specialised testing, Performance Test Engineer, Security Test Engineer, and Accessibility Tester describe separate disciplines. Manual and exploratory roles use Manual Tester, Exploratory Tester, and UAT Coordinator. In regulated industries, Validation Engineer and GxP Validation Specialist identify an entirely different population.

What is the difference between a QA engineer and an SDET?

An SDET is a software engineer whose focus is testing — building test frameworks, writing maintainable automation code, and integrating testing into CI pipelines. The role requires genuine programming ability comparable to a developer's. A QA engineer may be automation-capable or primarily manual, and the title spans a wide range of technical depth. The practical consequence is that advertising an SDET role as QA attracts many candidates who will fail a coding screen, wasting time on both sides. If the role needs framework development, name it accordingly.

Is manual testing still worth hiring for?

Yes, though the role has changed. Skilled exploratory testers find classes of problem that scripted automation cannot — usability issues, unexpected user behaviour, and edge cases nobody thought to script. In complex domains, a tester who deeply understands the product and its users catches things no automated suite will. What has genuinely declined is repetitive scripted manual regression testing, which automation handles better and more cheaply. The strongest manual testers have moved toward exploratory work and quality strategy rather than test execution.

How do I evaluate test automation skill?

By looking at code rather than tool names. Automation succeeds or fails on maintainability: a recorded script suite becomes unusable within months as the product changes, while a well-designed framework survives years. Published test frameworks on GitHub show structure, abstraction, and whether someone thinks like an engineer. In interview, asking how they would structure tests for a changing product, or how they handle flaky tests, distinguishes framework designers from script recorders far better than asking which tools they have used.

Where can I find QA engineers outside LinkedIn?

GitHub is the strongest source for automation roles, since published test frameworks demonstrate code quality directly. The testing community has an unusually strong writing and conference culture — TestBash, Agile Testing Days, and EuroSTAR are practitioner-led events whose speaker lists identify people serious about the craft, and the context-driven testing community writes extensively about heuristics and strategy. An underused pool is manual testers with deep domain knowledge who are learning automation independently.