Quality assurance is the discipline of making release confidence mechanical: the tests, environments and pipelines that catch defects before a customer does. The craft is being reshaped by generative AI faster than almost any other engineering function. The 17th World Quality Report, based on more than 2,000 senior executives across 22 countries, finds 89% of organisations piloting or deploying GenAI-augmented quality workflows, with 37% in production, while only 15% have scaled it enterprise-wide and the rate of non-adopters has actually risen from 4% to 11%. Automation coverage still averages only a third of test cases, and 60% of organisations struggle with secure, scalable test data. The function is also small on the ground: QA or test developers are just 0.8% of survey respondents, which makes every quality hire a scarce one.
Challenges in Quality Assurance Recruiting
Software testing that only arrives after the feature
The structural problem in most QA organisations is timing, and it shapes the candidate pool. Shift-left remains the dominant approach in quality engineering, the World Quality Report notes, with shift-right practices gaining traction as teams try to learn from production. The surrounding evidence says quality is organisational, not individual: JetBrains finds developers rate non-technical factors like collaboration and communication as critical to performance at least as often as technical ones, and the quality function is where that reality bites first. An engineer who has only ever tested a finished feature has practised one quarter of the discipline: the part where the defects are found after the expensive decisions are locked. The stronger profile has worked the full span, from reviewing requirements and designing test strategy through the unit testing, integration testing, system testing ladder to analysing production telemetry. Interview for the moment they entered: what was the earliest stage they influenced, which requirement did they prevent from being built, what production signal did they turn into a test case. Candidates who have only lived at the end of the pipeline describe the discipline they were handed, not the one they practise.
Test automation stuck at a third of the coverage
Automation is the quality function's reputation problem. The World Quality Report finds organisations automating only about a third of their test cases on average, with 60% struggling over test data and 58% over adopting AI-powered tools, so the gap is structural, not motivational. The hiring consequence: "test automation" on a CV covers an enormous range, from a Selenium script that clicks through a login to a pipeline that runs thousands of tests in parallel with quarantine rules and flake budgets. Depth shows in the failure stories: the suite that took two hours and how it shrank, the flaky test that hid a real regression, the retry logic that taught the team to ignore red. Ask about the test pyramid versus what they actually run; engineers who have owned a suite can recite the ratio and defend it, and engineers who have only written tests quote the textbook.
Integration testing against environments nobody can stand up
Integration testing is where quality work fails first, because it needs environments that are the hardest thing the organisation has to build. The data confirms the pain: 95% of organisations now use generative AI to create test data, yet only 10% have embedded it through the full lifecycle, and synthetic data has jumped from 14% to 25% of test data while ownership stays fragmented. The candidate who has run integration testing at scale talks about environment orchestration as the actual job: seeding, state reset between runs, service stubs versus real dependencies, the database schema version that broke the suite. The candidate who has only run integration tests on their laptop talks about assertion libraries. The screening question is blunt: what did the environment cost, in time or money, and what did you do when two teams needed the same environment on the same morning. Real answers are war stories; the rest are vocabulary.
Performance testing is a load model, not a tool run
Anyone can run a load tool; almost nobody models the load. Performance testing done properly starts before the tool: the transaction mix, the ramp pattern, the think times, the difference between peak and sustained, the client-side bottleneck versus the server-side one. The World Quality Report shows the gap on the other end of the lifecycle: 94% of organisations review production data, but nearly half struggle to turn those insights into test strategy, which is the same skill in reverse. Hiring should chase the model, not the tool. Ask what traffic they modelled and how they validated the model against production before trusting the results. Ask what a load test cannot catch and what caught it instead. The candidate who answers with percentiles, degradation points and the defect that escaped anyway has done performance testing; the candidate who answers with JMeter configuration has attended it.
Quality engineering under the GenAI divide
The function is splitting between organisations that scaled AI-assisted quality and everyone else, and the split runs through individual CVs too. Only 15% have enterprise-wide deployment; 43% remain experimental; productivity gains average 19% but a third see little effect; and the top barriers are integration complexity at 64%, data privacy at 67%, and hallucination and reliability concerns at 60%. Quality engineering under these conditions means judging generated output: which generated test is wrong in a way that matters, which boundary case the generator skipped, which flaky test should not be retried into silence. Thoughtworks' Radar Vol 34 puts mutation testing on its radar as a feedback control for AI-assisted code, which is the QA-flavoured version of the same skill. Interview for the review direction: hand them a generated test suite and ask what it misses. The candidate who finds the missing boundary is the one whose judgment the AI divide did not dissolve.
Regression testing evidence a green pipeline cannot fake
Every QA CV says regression testing, and the claim is nearly free because the pipeline proves nothing about who caused it to pass. Verification has to separate the people who own the feedback from the people who observed it. Walk one release: which tests ran, which were skipped and why, what broke in production that the suite missed, and what changed in the suite afterwards. Ask what they would delete from the suite they inherited and what deleting it would risk. Mutation testing is the sharpest probe available: ask what percentage of deliberately injected faults their suite would kill, because the discipline's entire point is confidence, and confidence is only measurable against known faults. The cost of a weak hire here lands in the release pipeline: a regression suite nobody trusts, a performance test that passes while production degrades, and flaky tests that teach every engineer to ignore red. Quality assurance fails quietly, and the organisation discovers the failure in front of a customer, which is the reason the interview has to fail candidates loudly instead.
References
- World Quality Report 2025-26 — Capgemini. (accessed 2026-09-28)
- World Quality Report 2025-26: Adapting to Emerging Worlds — OpenText. (accessed 2026-09-28)
- Technology Radar Vol 34 — Thoughtworks. (accessed 2026-09-28)
- 2025 Stack Overflow Developer Survey: Developers — Stack Overflow. (accessed 2026-09-28)
- The State of Developer Ecosystem 2025: Coding in the Age of AI — JetBrains. (accessed 2026-09-28)