Most Bugs Start Before Coding

The bug wasn’t in the code

👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

---

I thought bugs came from bad code.

But I noticed that a lot of the bugs we were fixing in QA…
weren’t really coding bugs.

The implementation matched the ticket.
The unit tests passed.
The code review passed.

And somehow, the feature was “wrong behavior.”

Not because the code was broken.

But because people had imagined different things in their mind — usually in the same meeting where everyone thought they agreed.

That mismatch only shows up later.

QA raises issues.

The product owner says: “That’s not what I expected.”

Acceptance Testing Isn’t Really About Testing

Acceptance testing — or ATDD — isn’t just about “more tests.”

It’s about creating shared understanding before implementation starts.

It’s asking questions like:

• What should happen here?

• What does success actually look like?

• Can we describe this with real examples?

• What happens in edge cases?

That’s where a lot of bugs get prevented.

Not during coding.

During alignment.

⛔ Without Acceptance Testing

The developer gets a ticket: “Apply a 10% discount to orders over €100.”

The developer reads the ticket and assumes:

• discount applies before tax

• only for logged-in users

• applies to the entire cart total

QA, later on, tests and assumes:

• discount applies after tax

• also works for guest users

• applies per item, not cart total

The product owner expected:

• discount applies before tax

• only for logged-in users

• based on cart total

Same ticket. Three different interpretations.

And nobody realises until QA finds it — or worse, after release.

✅ With Acceptance Testing

Before coding starts, the team writes examples like:

• Given the customer is logged in, when the customer makes an order of €120, then a 10% discount is applied before tax

• Given the customer is logged in, when the customer makes an order of €80, no discount is applied

• Given a guest user, when the guest makes an order of €150, no discount is applied

Suddenly, there’s no room for interpretation.

Everyone is reacting to the same examples — not their own mental version of the feature.

That’s the shift.

Acceptance testing doesn’t add “more testing.”

It removes guessing before the code is even written.

Why Teams Skip This

Teams want to jump straight into implementation.

Writing code feels productive.

Clarifying expectations sometimes feels like “extra process.”

Until the feature comes back three times for rework.

Then suddenly those early conversations don’t seem so expensive anymore.

See It In Practice

I’m running a live, hands-on workshop where we build acceptance tests. We go from vague requirements → to concrete examples → to executable acceptance tests.

⚡In 4 hours, you’ll:

• Design acceptance tests using DSL + driver architecture

• Apply ATDD Cycle with AI to write an acceptance test and implement the change

• Learn how to introduce acceptance testing in your team

📅 May 25-26, 2:00-4:00 PM CET

Limited spots. Register now and get 100 EUR off with code DISCOUNT_100