How I reported 37% of my team's bugs over 4 years in ERP QA Automation (it wasn't luck)

César Beas Suárez — Thu, 19 Feb 2026 17:50:08 +0000

In 4 years doing QA Automation for an enterprise ERP, I reported approximately +450 bugs — roughly 37% of all bugs found by a team of 4-5 people.

It wasn't talent. It was a system.

Here's the approach I used, with concrete technical examples.

The context: an ERP where bugs cost real money

This isn't a web app with a "deploy and fix" cycle. An ERP handles invoicing, purchases, stock, accounting — operations that affect real businesses with real money. A bug in an invoice calculation can mean fiscal problems for a client. A stock bug can mean wrong inventory for months.

The cost of a missed bug here isn't a bad UX — it's a financial loss for the end user.

This changes how you think about testing.

The mindset shift: hunter, not executor

Most QA engineers run tests. They follow happy paths, mark them green, and move on. I decided to think differently:

Instead of asking "does this feature work?", I started asking "where is this most likely to break, and what's the business cost if it does?"

This led me to three key decisions:

1. Prioritize by business risk, not by module assignment

While others distributed work evenly across modules, I focused on the highest-risk areas:

Invoicing (electronic invoicing, credit invoices, fiscal validation)
Sales circuits (quotes → orders → delivery notes → invoices)
Purchase circuits (purchase orders → receipts → purchase invoices)
Accounting operations (current accounts, payment plans)

These modules have the highest density of business rules and the most complex edge cases. One bug here equals ten bugs in a settings screen.

2. Design edge cases, not just happy paths

For every feature, I asked:

What happens with negative quantities?
What happens when a referenced document is deleted mid-process?
What if the user changes the tax condition after creating a document?
What happens with rounding on multi-line invoices with mixed tax rates?
What if the date crosses midnight during an automated test run?

Example: I discovered that our automated tests were producing false negatives because execution started before midnight and finished after — the system date changed mid-run, causing date validation failures. The fix: calculating expected execution time and scheduling runs to avoid the boundary.

3. Optimize the framework, not just the tests

I didn't just write tests — I improved the infrastructure:

Optimized Fn_ValidarGrilla (grid validation function): reduced execution from 6 to 4 hours (33% improvement) by fixing how it iterated through grid cells
Created Fn_BuscarEnCombo: a universal function to search combo boxes that replaced dozens of module-specific implementations
Built a shared repository for validation Excel files — eliminating manual sync errors that caused false failures across test machines
Implemented QRes.exe for standardized screen resolution — test machines had different resolutions causing element location failures

Each of these wasn't just a "nice to have" — they unblocked the entire team.

The uncomfortable truth: 21% cancellation rate

Not everything was perfect. Approximately 21% of my reported bugs were cancelled — meaning they weren't actually bugs, or couldn't be reproduced, or were duplicates.

But here's what matters: each cancellation taught me something. Every cancelled bug meant I needed to:

Improve my test data
Refine my expected results
Add better validations to the framework
Understand the business rule more deeply

The cancellation rate went down over time as my system improved.

When I stopped automating (on purpose)

One of my most impactful decisions was choosing to test manually during critical release periods.

When the team was pushing a major version and development velocity was high, automated tests couldn't keep up with the changes. Instead of fighting the tool, I switched to exploratory manual testing for 2.5 weeks, reporting 3-4 urgent bugs daily that were reaching clients.

Knowing when to drop the tool is as important as knowing how to use it.

The system, summarized

1. PRIORITIZE   → Target high-risk business modules
2. THINK        → Design edge cases before writing any test
3. OPTIMIZE     → Fix infrastructure problems that multiply impact
4. ADAPT        → Switch methods when the context demands it
5. LEARN        → Use every failure (cancelled bugs, false negatives) 
                   as feedback to improve the system

The real impact

The real impact wasn't the number. It was reducing the bugs that reached clients. Every bug caught in QA is a bug that doesn't become a support ticket, a fiscal problem, or a broken business process.

Quality testing isn't about finding bugs. It's about thinking strategically about where to look.

I wrote a more detailed version (in Spanish) on my blog: cesarbeassuarez.dev

I'm building my QA automation lab in public — frameworks, decisions, and learnings documented as they happen. Follow the process if you're interested.

If your QA strategy is based on coverage percentages instead of business risk, you're optimizing the wrong metric.

Building my QA automation lab in public

César Beas Suárez — Tue, 06 Jan 2026 22:22:48 +0000

I’m a QA Automation Engineer from Argentina.

I started building a personal QA automation lab and decided to document the process in public.

I’m writing short logs about automation, testing, and building things slowly.

Full notes and context live here:
https://cesarbeassuarez.dev

DEV Community: César Beas Suárez