Manual tester in the AI era: what do they do in 2026, what skills does the role need and what is its future?

The Tech Lead of a team building an online banking app gets a question from the board: “We bought an AI tool to generate tests — do we still need two manual testers?” The tool does work. Within a week it generated several hundred test cases from user stories and turned some of them into scripts. Three weeks later, during a manual exploratory session, one of the testers notices that a transfer amount with a decimal separator typed on a phone’s numeric keypad passes validation with a different amount than the one shown to the customer. None of the generated tests checked this, because no user story mentioned the numeric keypad.

This is not an argument against AI in testing. It describes how the manual tester’s role changed in 2026: less manual execution of scenarios that can be written down, more work where no scenario exists — exploration, usability, accessibility, domain knowledge and verifying what the machine generated.

We have already published general guides to the profession — who a software tester is and how to become one. Here we focus on one role and one question many Tech Leads ask today: what exactly does a manual tester do in a team that uses AI, what is it worth, and how do you build a QA team around the role that wastes neither people nor tools. Salary figures refer to the Polish market, where ARDURA builds most of its QA teams.

What does a manual tester actually do day to day in 2026?

A manual tester verifies software by using it the way a user would — without writing test code. That definition has not changed. What has changed is the mix of tasks in their week.

A few years ago, much of a manual tester’s work on a typical project consisted of running the same regression scenarios before every release: login, registration, cart, payment, report. In teams with reasonably mature automation and AI tools, the day-to-day scope looks different:

• Requirements analysis before implementation. The tester reads user stories and acceptance criteria before a developer starts and asks about edge cases. A defect found in requirements needs no code fix.
• Exploratory testing of new features. Time-boxed sessions guided by a charter (the session’s goal), without a script. This is the main source of defects nobody anticipated.
• Usability and consistency. Is the error message understandable, does the flow make sense to the customer, does the new feature behave consistently with the rest of the app?
• Accessibility testing. Checking the app with a screen reader, keyboard only, magnification and system settings — more on this below.
• Verifying AI output. Reviewing test cases and data generated by tools, and judging whether they cover risks rather than just the text of the requirements.
• Acceptance testing with the business. Joint sessions with the product owner or key users before release.
• Reporting and triage. Describing a defect so a developer can reproduce it, and assessing its business impact.

What does this look like in practice? Take a two-week sprint of a team building an online shop’s mobile app, with one manual tester. In the first days, the tester joins the refinement of three stories: a new payment method, a cart change and a loyalty programme. On payments, they ask what happens when the customer closes the app during bank authorisation — the requirements did not cover it, and handling it becomes a separate acceptance criterion. An AI tool drafts several dozen test cases, from which the tester removes duplicates and adds cases based on how customers really use the cart.

Mid-sprint, once the first version of the payment works in the test environment, the tester runs two one-hour exploratory sessions: one on interrupted transactions, one on weak signal and switching between Wi-Fi and mobile data. They find two defects no scenario anticipated. At the end of the sprint they check the new screen with a screen reader and enlarged text, and pick three recurring problems from the previous release’s production reports to hand over for automation. They do not run full regression by hand — automated tests do that on every change.

We covered the different types of manual testing in our article on types of manual software testing. The key shift here is emphasis: in 2026 a manual tester is less often a “manual script runner” and more often the person responsible for what scripts do not cover.

Which manual testing tasks is AI really taking over?

The scale of change is significant, but smaller than tool vendors’ marketing suggests. In the World Quality Report 2025-26 by Capgemini, Sogeti and OpenText, 89% of organisations are piloting or deploying generative AI–augmented workflows in quality engineering. Only 37% have them in production, however, and just 15% at enterprise scale. The most cited barriers are data privacy risks (67%), integration complexity (64%) and skills gaps (50%).

In teams where AI tools already run in production, five areas have changed most:

1. Test case drafts. A language model turns a user story into a list of scenarios in seconds, work that used to take the tester an hour. The draft needs review, but the work shifts from writing to editing.
2. Test data. Generating realistic data — addresses, correctly formatted account numbers, sets of edge cases — is no longer manual work.
3. Regression of repetitive paths. Tools that execute a browser test from a natural-language description take over some scenarios a person used to click through because coded automation was too expensive.
4. Visual comparisons. Detecting unexpected interface changes between versions.
5. Summarising and grouping reports. Merging duplicate bugs, summarising logs, suggesting reproduction steps.

What these tasks share is that the expected result can be described in advance. If you know what should happen, a machine can check it faster and more cheaply than a person. We discuss where the line between automation and manual work runs in our article on automated vs manual testing in 2026.

What will AI not take over in testing, and why?

The reverse principle defines what stays with people: where the expected result cannot be described in advance, judgement is needed. In practice, that means four areas.

Exploratory testing. A tester who notices during a session that an amount field behaves differently on a phone’s numeric keypad is not executing a scenario — they are creating one on the spot, based on what they just saw. A model generating tests from requirements reproduces knowledge written in the requirements. An exploratory tester looks for knowledge that is not there. We describe the technique in our article on exploratory testing and the concept in the glossary.

Domain knowledge. A tester on a banking project knows that instant transfers have different limits from standard ones and that bookings on non-working days follow different rules. A tester on a medical project knows that a drug dose in the wrong units is not a “validation error” but a threat to life. This knowledge is rarely fully documented, so a tool has nowhere to get it from.

User experience. A form can pass every functional test and still be confusing. Judging whether “Operation failed (code 4012)” is acceptable to a bank customer requires empathy and context, not a comparison with an expected result.

Accountability. “This defect blocks the release” is a decision with business consequences. Someone has to make it and own it. In regulated industries — finance, healthcare — that accountability is formally required.

Two new areas have grown fastest in the past two years: accessibility testing and testing AI systems themselves.

Why has accessibility testing become manual testers’ work since June 2025?

On 28 June 2025 the European Accessibility Act (EAA) became applicable across the EU; in Poland it was implemented by an act of 26 April 2024. It covers e-commerce, consumer banking services, telecommunications, e-books and parts of transport services, among others. Microenterprises providing services are exempt. Penalties vary by member state; in Poland administrative fines can reach ten times the average wage, capped at 10% of turnover, and are preceded by a request to fix the non-compliance.

The technical reference is the EN 301 549 standard, whose current version refers to WCAG 2.1 at level AA. The next version is expected to incorporate WCAG 2.2, published by W3C in 2023.

Why is this a job for a manual tester rather than a tool? Because automated tools find only part of the problems. The UK Government Digital Service ran an audit in which it deliberately introduced 142 accessibility barriers into one page and tested it with 13 automated tools. The best tool found 40% of the barriers, the weakest 13%. All of them missed issues such as reading order, missing visible focus indicators and meaning conveyed by colour alone.

The practical implication is simple: an automated scan in the pipeline is necessary but not sufficient. The rest is checked by a person — going through customer journeys with the keyboard only, with a screen reader (NVDA, VoiceOver, TalkBack), at 200% zoom and with system contrast settings. Most manual testers have had to learn this in the past two years, and it is one of the most sought-after specialisations in teams building consumer apps. Our article on getting started with WCAG accessibility testing is a good introduction.

Where should a manual tester start if the team is only now introducing accessibility testing? In our experience, six simple checks on key journeys — registration, login, search, cart and payment — find the most problems:

1. Keyboard only. Can you complete the whole journey with Tab, is the order logical, and is there no focus trap?
2. Visible focus. Is it always clear which element is active?
3. Screen reader. Do buttons and fields have understandable names, and are error messages announced when they appear?
4. 200% zoom and text resizing. Does content not overlap or disappear off screen?
5. Colour alone. Is an invalid field marked by more than a red border?
6. Time limits. Does the payment session not expire without warning and a way to extend it?

These checks do not replace a full WCAG audit, but in a few hours they show where the biggest barriers are and whether the team needs a specialist.

How do you test AI-based features when their results are not deterministic?

More and more apps include features built on language models: an assistant in a banking app, document summarisation, reply suggestions for agents, natural-language search. Testing them changes the tester’s work more than using AI for testing does.

A classic test assumes the system gives the same result for the same input and the tester compares it with the expected one. A language model may answer the same question in several ways, each of which may be correct — or merely sound correct. The tester therefore does not compare output with a template but assesses it against criteria:

• Factual correctness. Does the assistant’s answer about a transfer limit match the terms? Does the summary add facts not in the document?
• Behavioural boundaries. Does the assistant decline investment advice when it should? Can it be coaxed into revealing another customer’s data or its system instructions?
• Consistency. Does it answer consistently when the same question is asked three ways?
• Tone and accessibility. Is the answer clear, polite and readable for a screen reader?

For example, an insurance app team introduces an assistant that answers questions about policy coverage. The manual tester prepares several dozen questions in three groups: questions answered in the policy terms (the assistant must answer correctly and cite the source), questions the documents do not answer (it must admit it does not know rather than guess), and questions it must not answer (legal advice, another customer’s data). Each question is asked several times and in several phrasings, and answers are rated against criteria agreed with the product owner. The set later becomes the basis for automated evaluation whenever the model or system instructions change.

Creative attempts to “break” the assistant — unusual phrasing, questions combining two topics, manipulation attempts — are largely exploratory testing in a new medium. Automation can check thousands of answers against simple rules, but the rules and edge cases are defined by someone who understands the domain.

How does a manual tester verify AI output in a QA team?

The other side of the same change: if AI generates test cases, data and scripts, someone has to check that it does so well. In many teams this falls to the manual tester, who knows the product and its risks best.

Our projects show four typical problems with AI tool output in testing that a person catches:

• Covering text instead of risk. Generated cases mirror what the story says. If the story omits an edge case, so do the tests — and the result looks complete because there are many of them.
• Guessed expected results. A model fills gaps with whatever sounds plausible. A test that checks for “a success message” can lock in wrong behaviour.
• Duplicates and inflated numbers. Fifty variants of one scenario with different data make an impressive count and little value.
• Unrealistic test data. Account numbers that pass format validation but match no real production case, and no data with the problematic characters the system actually trips on.

A sensible division of work is therefore: AI drafts, the manual tester edits — removing duplicates, adding cases based on domain knowledge and risk, correcting expected results — and only then does the team decide what to automate. In the World Quality Report 2025-26, generative AI was the top-ranked skill for quality engineers (63%), just ahead of core quality engineering skills (60%). The two do not compete; the second is a precondition for using the first sensibly.

What skills does a manual tester role require in 2026?

Manual tester job ads in 2026 differ from those of a few years ago less in the names of requirements than in their weight. From the perspective of a Tech Lead hiring or developing a team, skills fall into three layers.

Foundation — unchanged. Test design techniques (equivalence partitioning, boundary values, decision tables, state transitions), solid bug reporting, understanding the development lifecycle and Scrum, basic test management. This is the scope of the ISTQB Foundation Level, still the most common formal requirement.

Technical layer — increasingly important. A manual tester who does not write test code still needs:

• browser developer tools (console, network, local storage),
• API testing in Postman or a similar tool,
• basic SQL to check what was actually saved,
• reading logs and basic monitoring,
• working with AI tools — writing prompts, assessing output, understanding limitations.

Specialist layer — the source of value. Domain knowledge (finance, insurance, healthcare, logistics), WCAG accessibility, exploratory testing as a deliberate technique rather than “clicking without a script”, testing AI systems. This is where a manual tester differs from a tool and from a course graduate.

Soft skills matter more in this role than in many technical ones: asking questions at the requirements stage, describing a problem clearly to a developer, and talking to the business about risk without jargon.

For a Tech Lead, the practical consequence is a change in how the team’s training budget is spent. An automation course for every manual tester is not always the best choice. A few days of accessibility training, an exploratory testing workshop with charters, or joint sessions with a business analyst to learn the client’s processes often pay back more. It also helps to agree simple rules for AI tools: what data may be entered, who reviews generated tests, and when output needs human approval. Data privacy was the most cited barrier to scaling AI in QA in the World Quality Report.

How much does a manual tester earn in 2026, and why is there a gap with automation testers?

The most complete data for Poland comes from Bulldogjob’s IT Community Survey 2025, which reports employment contract salaries as net take-home pay and B2B as net on the invoice. Manual testers made up 34% of respondents in testing.

Role	Employment — average (net)	Employment — median	Senior employment — average	B2B — average (net on invoice)
Manual tester	PLN 6,635	PLN 6,020	PLN 9,044	PLN 12,942
QA	PLN 8,513	PLN 8,000	PLN 10,850	PLN 17,801
Automation tester	PLN 9,538	PLN 9,000	PLN 12,592	PLN 19,396

An automation tester earns on average about 44% more than a manual tester on an employment contract and about 50% more on B2B. In absolute terms, that is about PLN 34,800 a year net on employment and about PLN 77,400 a year on B2B. Among seniors on employment contracts the gap is about 39%. The report also notes that manual testers’ pay plateaus after about ten years, while automation specialists and leaders keep growing.

Read these figures with care. First, “manual tester” is a broad category — from someone following scripts to an accessibility specialist at a bank. Second, the gap reflects a difference in scope, not just in title: a manual tester who has mastered accessibility, APIs and domain knowledge competes for different rates than someone running regression only. Current rates for QA roles in staff augmentation are in our overview of QA rates in Poland for 2026.

The takeaway for a Tech Lead: if the team pays a manual tester to run regression by hand that could be automated, it wastes both money and the person’s potential. If it pays them for exploration, accessibility and domain knowledge, the rate is usually below the value they deliver.

What does a manual tester’s career path look like in the AI era?

The “manual tester → automation tester” path still exists and is the simplest route to higher pay. It is not the only one. Our view of the market points to four directions that give a manual tester a real edge in 2026:

1. Domain specialist. A tester who knows banking, insurance or healthcare processes at a business analyst level is hard to replace and often moves on to analyst or product owner roles.
2. Accessibility specialist. Since the EAA, demand for people who can audit against WCAG and EN 301 549 and test with assistive technologies has clearly grown.
3. AI systems tester. Assessing model answer quality, robustness testing against manipulation, building question sets and evaluation criteria. Exploratory testing experience is directly useful here.
4. Automation. The classic path to a QA engineer and automation tester role, easier today because AI tools lower the barrier to writing test code.

A fifth direction, test lead or QA lead, suits those who enjoy coordinating work and discussing risk with the business.

ISTQB certifications provide formal support. Foundation Level remains the base. In July 2025 the ISTQB General Assembly approved the specialist certification Testing with Generative AI (CT-GenAI), covering practical use of language models in testing, prompting and risk management. Version 1.1 of the syllabus followed in April 2026. Foundation Level is a prerequisite for the exam. For testing AI systems there is a separate Certified Tester AI Testing (CT-AI).

How should a Tech Lead structure a team with manual testers?

The most common mistake we see is treating manual testers as a “buffer” before release: developers hand over a feature at the end of the sprint, the tester has two days to check everything, and regression is manual because automation is lacking. In that setup AI can indeed replace part of the work — but only because it was work a person should not have been doing.

What works is a model in which the manual tester is part of the team from the start of work on a feature:

• Before implementation, they join story refinement and write acceptance criteria with the product owner and developer.
• During implementation, they run short exploratory sessions on early builds rather than waiting for “done”.
• Before release, they own exploration, accessibility and business acceptance — not manual regression.
• After release, they analyse production reports and turn recurring issues into automation candidates.

Regression should be automated as far as possible — by developers, an automation tester or with AI tools. The manual tester decides what is worth automating, because they know best which paths break most often.

Proportions depend on the product, but our experience suggests three principles:

• A consumer product with many user journeys, regulations and accessibility requirements needs more manual work than an integration system without a user interface.
• A team shipping AI-based features needs at least one person who systematically assesses their output — rarely a job for that feature’s developer.
• One manual tester shared across several teams will slide back into the “release buffer” role, because there will be time for nothing else.

If you lack a specific skill for a limited time — an accessibility audit ahead of EAA obligations, domain testing for a product launch — you do not always need a permanent hire. With testing services, a specialist can join your team for the duration of a project.

How can you tell a team is wasting a manual tester’s potential?

The manual tester role is far more often misused than redundant. Six warning signs worth checking:

1. The tester runs the same set of scenarios by hand before every release. That is regression to automate; their time is needed elsewhere.
2. The tester gets a feature only after implementation ends. Requirements defects then surface as code defects and cost far more to fix.
3. Nobody runs exploratory sessions. All tests come from scripts, so the team finds only the defects it predicted.
4. Accessibility is checked only by an automated scan. Given the GDS audit results, most barriers stay undetected.
5. AI tool output goes into the test repository unreviewed. The number of tests grows; trust in them does not.
6. The tester has no contact with users or the business. Without it they cannot build domain knowledge, their main advantage over a tool.

Each of these can be fixed without changing the team — by changing the process. That is why “do we still need manual testers?” is better replaced by “what are we paying them for?”

How should you hire a manual tester in 2026, and what should you ask in the interview?

A manual tester job description copied from an ad of a few years ago attracts candidates for work that no longer exists in a well-run team: executing regression scripts by hand. If you want someone for exploration, accessibility and business collaboration, say so and test for it.

Our experience recruiting QA specialists points to four elements that work:

• An exploratory task instead of a knowledge quiz. Give the candidate 30 minutes on a real app — even a public shop website — and ask for session notes. How they choose areas, form hypotheses and describe what they saw matters more than the number of defects.
• A bug report to improve. Show a poorly written report and ask them to fix it. In five minutes you see whether they understand what a developer needs.
• A discussion of generated tests. Show a dozen AI-generated test cases for one story and ask what is missing, redundant or wrong. A candidate who simply accepts the list will not verify it on the job.
• An accessibility question. Do not expect knowledge of all of WCAG. Check whether they know how to complete a form with the keyboard only and what a screen reader user should hear.

We cover the wider hiring process in our article on how to hire a QA developer in 2026. In the EU, pay transparency rules are also making salary ranges in job ads standard — in Poland they have been mandatory since 24 December 2025 — and the table above helps set ranges that match the scope of the role rather than its title.

How do you assess the maturity of the manual tester role in your team?

The model below helps a Tech Lead assess where the manual tester role stands in their team and what to change to get more value from it:

Area	Level 1: script runner	Level 2: tester in the team	Level 3: owner of quality risks
When involved	After implementation	At sprint start	During requirements refinement
Regression	Run by hand	Partly automated	Automated; tester decides what to automate
Exploratory testing	None or ad hoc	Sessions for larger features	Charter-based sessions for every risky feature
Accessibility	Not checked	Automated scan	Scan plus assistive technology testing against WCAG
AI tools	Unused or unreviewed	Test and data drafts	Drafts edited by the tester, review rules
AI-based features	Tested like any feature	Manual spot checks	Question sets, evaluation criteria, robustness tests
Domain knowledge	From documentation	From the product owner	From users and production data
Growth	No plan	Foundation Level	Specialisation path: domain, accessibility, AI or automation

The key takeaways:

1. AI takes over tasks whose result can be described in advance. Test drafts, data, repetitive regression and visual comparisons are now tool work.
2. People stay where judgement is needed: exploration, usability, domain knowledge and accountability for release decisions.
3. Accessibility and AI features are two new areas of manual work. Automated tools find at best 40% of accessibility barriers, and model answers must be assessed against criteria, not templates.
4. The pay gap with automation testers is 44–50%, but it follows the scope of work, not the job title. Specialisation narrows it.
5. The manual tester role is more often misused than redundant. Before cutting it, check whether the team pays for work a machine should be doing.

At ARDURA Consulting we have been building and supporting QA teams for clients in Poland, Europe, the Middle East and the USA for more than ten years — from manual and exploratory testing, through accessibility audits, to automation. We help Tech Leads split work between people and tools so that testers focus on what machines cannot do.

If you want to assess how you use testers in your team, or need a manual, accessibility or AI testing specialist for a project, talk to our team. More about our approach to quality is on our testing services page.