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


Acceptance tests are not just *more* tests.