Table of content
Quality assurance
20 May 2026

Manual vs automated testing: when to use each (and when not to)

Quick summary

Manual and automated testing solve different problems, and the strongest QA strategies use both deliberately. According to McKinsey, top-performing organisations achieve 31 to 45 percent gains in software quality, but only when automation is paired with deliberate human oversight. Choosing between the two is less about preference and more about matching the method to the risk.

Introduction

Every software team eventually faces the same question: should this be tested by hand, or should it be automated? The debate is often framed as a binary, but the evidence tells a more nuanced story.

McKinsey's 2025 research found that more than 90 percent of software teams now use AI in development workflows, yet only the top quintile of organisations have translated that adoption into 31 to 45 percent gains in software quality (McKinsey, 2025). In other words, broad adoption has not produced broad results, and the difference often comes down to how testing is structured rather than which tools are used.

Manual and automated testing are not competitors. They are different tools that solve different problems, and the teams shipping reliable software know exactly when to reach for each. This article unpacks the strengths and weaknesses of both approaches, the situations where each performs best, and how to build a portfolio that fits the realities of modern software delivery.

What manual testing actually involves

Manual testing is the practice of a human exercising software, observing the outcomes, and applying judgement to determine whether the behaviour is correct. It covers scripted test cases, exploratory testing, usability evaluation, and the kind of intuitive "something feels off" detection that algorithms struggle to replicate.

Manual testing remains widely practised across the industry, and notably, its role is expanding rather than shrinking as AI enters the development lifecycle. Deloitte's research on quality engineering in the age of generative AI found that more than half of global respondents have already prioritised enhanced testing and validation protocols specifically to address AI-driven software quality needs (Deloitte, 2025).

The reason is intuitive: as AI generates more code faster, the human work shifts from writing tests to verifying that the system as a whole behaves correctly, particularly in areas where context and judgement matter. In Nordic, DACH, and Benelux markets, this human layer remains particularly relevant for usability and accessibility validation, where regulatory expectations under frameworks like the European Accessibility Act and consistently high cultural standards for user experience make machine-only evaluation insufficient.

Takeaway: Manual testing remains essential precisely because some aspects of software quality cannot be measured by a script.

What automated testing actually involves

Automated testing means writing code that exercises software and verifies the results without human intervention at runtime. It spans unit tests for individual functions, integration tests for component interactions, end-to-end tests for full user journeys, and performance tests that push systems beyond what any team of humans could simulate.

The economic and operational case is strong, and the motivations behind adoption point clearly to where automation creates value. According to Gartner, 60 percent of organisations cite improving product quality as a primary reason to automate, while 58 percent cite the need to increase deployment speed, with API testing (56 percent), integration testing (45 percent), and performance testing (40 percent) being the most commonly automated test types (Gartner, 2024).

These figures matter because they show automation succeeding precisely where repetition is highest and where human judgement adds the least value, exactly the conditions automation handles best. McKinsey's analysis of nearly 300 publicly traded companies puts a sharper number on the upside: top-quintile AI-driven software organisations achieve 16 to 30 percent improvements in productivity, time to market, and customer experience, alongside 31 to 45 percent gains in software quality (McKinsey, 2025). The decisive factor is not the tools themselves but the willingness to embed automation across the entire lifecycle rather than apply it as a single-stage intervention.

Takeaway: Automation transforms repetitive testing from a recurring cost into a one-time investment with compounding returns.

The case for manual testing

Manual testing carries real advantages that no degree of automation has eliminated.

Key strengths include:

  • Human judgement remains essential for usability, accessibility, and visual design questions

  • Setup is fast, requiring no frameworks, scripts, or infrastructure

  • Exploratory testing finds defects that scripted tests, by definition, were not designed to catch

  • It adapts instantly to UI changes, new features, and half-built prototypes

  • Upfront costs are low, making it suitable for early-stage products and short-lived features

The trade-offs are equally real, and they have become more visible as AI-assisted development changes the shape of the codebase. Deloitte's research highlights that as generative AI accelerates code production, developers must check far larger volumes of code for subtle issues that are harder to spot, making purely manual review increasingly unsustainable (Deloitte, 2025).

In practice, this means manual testing scales linearly while the code it needs to evaluate is now scaling exponentially, a mismatch that forces organisations to choose carefully where human attention adds the most value.

Takeaway: Manual testing is strongest at the start of the development cycle and during exploratory work, but it scales poorly under repetition.

The case for automated testing

Automation flips the economic and operational equation. Once written, a test suite that takes a human a full day can execute in minutes, and that scaling effect is precisely why automation is reshaping organisational performance.

McKinsey's 2025 State of AI survey of 1,993 organisations across 105 nations identifies software engineering as the function where AI-driven cost benefits are most commonly reported, ahead of marketing, IT, and customer operations (McKinsey, 2025). The pattern is consistent: where work is repeatable and outcomes are measurable, automation pays back faster.

Other strengths follow from the same foundation:

  • Deterministic, repeatable execution removes tester variability

  • Fast feedback catches regressions on every commit, not weeks later

  • Confidence to refactor, upgrade dependencies, and ship changes increases substantially

  • Well-written tests serve as living documentation of expected behaviour

  • AI-augmented testing capabilities continue to expand, with Gartner forecasting that 90 percent of enterprise software engineers will use AI code assistants by 2028 (Gartner, 2025)

The downsides are equally clear, and they explain why automation often disappoints in practice. Automation requires real engineering investment, both to build and to maintain. Tests break when applications change, and a neglected suite of false failures becomes worse than no suite at all.

McKinsey's research underscores the scale of the gap: only 5.5 percent of organisations report meaningful financial returns from their AI investments, with high performers distinguished not by their tools but by their willingness to fundamentally redesign workflows rather than bolt automation onto existing processes (McKinsey, 2025). The lesson is that automation rarely fails because the technology is inadequate; it fails because the organisation around it has not adapted.

Takeaway: Automation rewards investment over time, but only when paired with the discipline to keep the suite healthy.

When to use each approach

Rather than choosing sides, the practical question is which kind of testing the situation calls for.

Reach for manual testing when:

  • The feature is new, changing weekly, or still in design iteration

  • Usability, accessibility, or visual quality is the focus

  • Exploratory work is needed to find unknown defects

  • The cost of automation exceeds its value, such as for short-lived campaign pages

  • The behaviour is genuinely hard to automate, including complex visual rendering or hardware interactions

  • A quick smoke check before release is the goal

Reach for automated testing when:

  • The behaviour is stable and will be tested repeatedly

  • The functionality is critical, such as authentication, payments, or compliance flows

  • The test sits at the unit or API level, where automation is cheapest

  • Performance, load, or stress testing is required at a scale humans cannot match

  • Long-lived code needs protection against regression

  • The expected outcome is deterministic and clearly defined

Takeaway: The right choice is rarely manual or automated; it is the cheapest reliable method for managing the specific risk at hand.

Regional and regulatory context

European software teams operate under conditions that increasingly shape testing strategy. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, introduces mandatory cybersecurity requirements covering the planning, design, development, and maintenance of products with digital elements across the EU market, with full obligations applying from 11 December 2027 and reporting requirements from 11 September 2026 (European Commission, 2024).

The directive matters for testing strategy because it requires manufacturers to demonstrate, not just claim, that security has been engineered into the product, and that evidence has to be reproducible across the product lifecycle.

The penalties make the point clear. EY notes that non-compliance can result in fines of up to €15 million or 2.5 percent of worldwide annual turnover (EY, 2025). For most organisations, exposure at that level cannot be managed through manual sampling alone; it requires the kind of repeatable, automated verification that produces an audit trail.

At the same time, regulators continue to expect human review of risk assessments and incident response, which means pure automation also falls short of what compliance requires. For Nordic, DACH, and Benelux teams, this regulatory layer compounds existing standards. ISO/IEC 27001 governs information security management, ISO 26262 sets functional safety requirements for automotive software, and EU MDR governs medical device software.

Each one demands documented, traceable testing evidence, and each one is most efficiently met by a hybrid approach that automates the repeatable evidence trail while keeping humans in the loop for interpretation and judgement.

Takeaway: European regulatory pressure is steadily raising the floor for what counts as adequate QA.

Building a portfolio that fits

Mature teams build a layered approach rather than choosing one method.

A typical layered model includes:

  • Unit tests running on every commit

  • Integration tests running on every pull request

  • End-to-end automation guarding critical user journeys

  • Manual exploratory testing before each release

  • Usability testing whenever new flows ship

The right proportions shift with context. A high-frequency trading platform leans heavily on automation. A design-led consumer app keeps significant manual capacity. A pre-product-market-fit startup may skip most automation entirely until the product stops changing weekly.

McKinsey's findings reinforce why this layered approach outperforms either extreme: high-performing organisations are nearly three times more likely than peers to have fundamentally redesigned workflows around automation, rather than treating it as a bolt-on enhancement (McKinsey, 2025). The implication is that the testing portfolio is not just a technical choice but an organisational one, and treating it as such is what separates teams that capture the value of automation from those that simply spend on it.

Takeaway: A balanced portfolio is consistently more effective than either extreme.

Conclusion

Automation does not replace manual testing, and manual testing is not a relic. They cover different blind spots in different ways. Teams that treat them as substitutes, either automating everything or refusing to invest in tooling, consistently ship lower-quality software than teams that use both with intent.

The path forward is to match the method to the risk, revisit the mix as the product matures, and treat the testing portfolio as a strategic asset rather than a cost centre. In a European market shaped by the Cyber Resilience Act, ISO compliance expectations, accelerating release cycles, and rising customer expectations, that discipline is what separates resilient software from fragile software.

FAQ

Is automated testing replacing manual testing?

No. Deloitte's quality engineering research shows that more than half of global organisations have actually increased their investment in testing and validation protocols in response to AI-driven development, not reduced it. Automation handles repetition and scale; manual testing handles judgement and exploration.

What percentage of testing should be automated?

There is no universal answer. The right proportion depends on product maturity, risk profile, and regulatory environment, with most mature organisations operating a hybrid model.

Which tests should never be automated?

Usability, accessibility evaluation, exploratory testing, and assessments requiring human judgement about user experience are typically best kept manual. Features that change weekly are also poor automation candidates.

Is automated testing more cost-effective than manual testing?

Over time, yes, for stable and frequently repeated tests. McKinsey reports that top-performing organisations achieve 31 to 45 percent gains in software quality by embedding automation across the development lifecycle, but upfront and maintenance costs mean automation is not always cheaper for short-lived or rapidly changing features.

How does EU regulation affect testing strategy?

The EU Cyber Resilience Act, effective in full from 11 December 2027, requires manufacturers of products with digital elements to implement security testing, document vulnerabilities, and maintain coordinated disclosure across the product lifecycle, with penalties of up to €15 million or 2.5 percent of global turnover.

Sources
About Author Wirtek is a Danish tech company with 25 years of experience, specialising in three core domains: energy, connectivity & automation and digital engineering. We build, connect and operate digital solutions through software development, Internet of Things (IoT), quality assurance and ready-made products. Founded as a Nokia spin-off, we combine deep know-how with EU compliance to partner with companies on their journey to modernise systems and extend capabilities while reducing risk. Since 2022, we have focused strongly on shaping solutions that power the sustainability transition.

Got a project in mind?

Talk to an expert