Best practices, Automation Trends
Which Test Cases Should You Not Automate in 2026
Introduction
Test cases that depend on subjective human judgment, target features still in active development, or involve complex, data-heavy validation are generally poor automation candidates. They need a person's judgment, not a script, at least until the process stabilizes. The right automation strategy targets repeatable, high-volume, stable work instead, and layers in business context for anything that's genuinely business-critical.
Test automation adoption keeps climbing across every major industry, and 2026 has added a new layer to that shift: AI-driven and agentic testing tools are moving from experimental to standard practice. Teams are no longer asking whether to automate. They're asking what to automate, and how to keep that automation from becoming its own maintenance problem.
Key takeaways
Automation should target repeatable, high-volume, stable work. Anything that depends on human judgment, is still under active development, or only runs a handful of times is usually a poor automation candidate.
Business-critical functions still need automation, just not generic scripted checks. They need automation that understands the process it's protecting, with subject matter expertise built into how it's validated.
Self-healing automation reduces the maintenance burden that UI changes create, but it doesn't replace the human judgment needed to confirm something looks and feels right.
Over-automating is its own risk. Partially built scripts, low-value coverage, and flaky tests quietly erode the ROI that automation was supposed to deliver.
No-code platforms let business analysts and functional consultants build and maintain the right tests directly, without waiting on developer availability.
Businesses use automation to move faster, but speed alone has never been the real prize. The organizations getting the most from automation are the ones connecting it to something bigger: whether the business itself keeps working through every release.
A robust test automation strategy isn't about the maximum number of test cases you can automate. It's about choosing the right test cases to automate and balancing them against manual testing. That's why it's crucial to understand which test cases can or cannot be automated. For teams running ERP systems like Dynamics 365, SAP, or Oracle, that distinction matters even more: the cost of automating the wrong thing, or failing to automate the right one, shows up as risk to a business process, not just a line in a test report.
What goals should test automation fulfill?
Before we jump into specific test cases, let's discuss what test automation does.
Many teams still treat automation as a replacement for human testers. It isn't. Automation handles the repeatable, high-volume work. People still own the judgment calls: exploratory testing, usability, and the calls that require business context automation can't supply. With no-code platforms, that human role increasingly includes business analysts and functional consultants, not just QA engineers.
Automating test cases should be prioritized based on:
- How long will it take to write the script?
- Will the test be reused multiple times?
- How crucial is the feature being tested for the application?
- Does the test involve a lot of data entry and manipulation?
- How many configurations need to be tested?
- How long will the test run?
- Does the test require visual confirmation?
- How soon are the test results and feedback required?
These are some factors that need consideration before creating a testing strategy. Based on those factors, here's the list of tests that you should not automate.
Which test cases should you not automate
Subjective validation
Subjective validation covers anything that depends on human judgment rather than a pass or fail rule: wording, tone, visual polish, or whether something simply feels right to a user. It's best performed manually. A person can spot and flag an issue in seconds, where scripting the same judgment call would take longer to build than it's worth. In an SAP or D365 upgrade, that might mean checking whether a redesigned approval screen still feels intuitive to the AP clerk who uses it daily.
New functionalities
Applications and software that are still under development will often require many changes in the underlying code. In such a scenario, every time the code is changed, the automated test script will need to be altered too. This alone makes test automation time-consuming and tedious.
Business-critical functionalities
Business-critical functions deserve the opposite of a hands-off approach. They need automation that understands what it's protecting, not automation for its own sake. Generic scripted checks miss the process context. An Oracle order-to-cash workflow or an SAP Concur approval chain are good examples: get the validation wrong and the business feels it immediately. Business-Aware AI validates these functions with the operational and compliance context that subject matter experts bring, so critical processes get consistent, repeatable coverage instead of being left to manual review alone.
User experience
UI tests are generally hard to automate. The scripts are complicated and require several changes to run successfully. Moreover, the human eye is best suited to test UI features such as resolution, formatting, etc. Self-healing automation reduces some of this friction by adapting to UI changes automatically, but visual judgment, whether something looks right to a person, still belongs to a human reviewer.
Complex functionalities
Some features of the application under test will have complex pathways. For instance, tests that require data modification and manipulation downstream are best suited for manual testing. A multi-step Dynamics 365 configuration change with downstream financial postings is a good example: too many moving parts and dependencies for a generic script to trace reliably. No automation script can do justice to these test cases.
Quality control
The final quality checks run on the software or application should also be left for manual testers. Automated tests are best suited to test for results that are predictable and fixed. Additionally, no automation solution can give the kind of feedback that a human tester can.
Automating the wrong things carries its own risk
There's a cost to automating the wrong things too. Every test case you automate that shouldn't be automated becomes something to maintain, not just something to run. Partially built scripts that never made it to production, automation covering low-risk paths while high-risk ones stay manual, and flaky tests nobody trusts anymore all quietly drain the ROI that automation was supposed to deliver. The fix isn't more automation. It's automating the right things, keeping that automation healthy over time, and knowing which processes actually carry business risk if they break.
Automation shortens the development lifecycle, but only when it's applied selectively. Automating everything on principle backfires. It adds maintenance cost without adding confidence.
For the tests that do belong in your automation suite, the platform matters. Avo Assure is no-code and works across web, ERP, and enterprise applications, so business analysts and functional consultants can build and maintain tests without developer support. Beyond execution, Avo Assure's Business-Aware, Accountable AI connects that automation to the business processes it's protecting, showing not just whether a test passed, but whether the business process it validates is still sound going into the next release, the kind of quality intelligence a pass-or-fail count alone can't give you.
In practice, that's the difference between a testing tool and a business process assurance platform: not just faster execution, but confidence that the business itself is ready for release.
If you want to see how Avo Assure helps you automate the right things and stay confident about the rest, book a demo with us today.
Frequent Asked Questions
What test cases should not be automated?
Subjective validation, features still in...
Subjective validation, features still in active development, and final quality control checks are generally poor automation candidates. Each depends on human judgment that a script cannot reliably replicate.
Should business-critical processes be automated or tested manually?
Neither on its own is...
Neither on its own is enough. Business-critical processes need automation built with business context, understanding what the process does and why it matters, rather than generic scripted checks or manual review alone.
Why are UI tests hard to automate?
UI tests break easily because...
UI tests break easily because interfaces change often, and small layout or element changes can invalidate a script. Self-healing automation reduces this maintenance burden by adapting to UI changes automatically, though visual judgment still benefits from human review.
Can business analysts build automated tests without a developer?
Yes, on a no-code platform...
Yes, on a no-code platform. Business analysts and functional consultants can build and maintain automated tests directly, which matters for ERP environments like Dynamics 365, SAP, and Oracle where functional knowledge often sits outside the QA team.
Is it possible to over-automate testing?
Yes. Automating tests that do not...
Yes. Automating tests that do not need it adds ongoing maintenance cost without adding confidence. Partially built scripts, low-value coverage, and flaky tests all reduce the return automation is supposed to deliver.
How does AI change what should be automated in 2026?
AI-assisted and agentic testing...
AI-assisted and agentic testing tools are shifting from experimental to standard practice in 2026, particularly for self-healing scripts and test maintenance. That shift changes how much upkeep automation requires, but it does not change the underlying principle: automation still works best on repeatable, stable, high-volume tests, and human judgment still owns the rest.