- Women in Testing Newsletter
- Posts
- The Cost of “It Works for Us”
The Cost of “It Works for Us”
by Hanisha Arora
Most of the time when you raise an issue with developers, you get a familiar reply:
“It works for us.”
“We’ve always done it this way.”
And sure - it does work for them.
But that’s not the same as working well. Or working for everyone.
Because when something “just works” for the people who built it, it usually means nobody else can verify, control, or question it.
That’s where testable design comes in.
What Testable Design Actually Means
Testable design isn’t about writing more tests.
It’s about building in a way that makes testing possible, fast, and meaningful.
A design is testable when:
You can verify behavior without touching production data.
You can isolate components without needing the whole system.
You can observe what’s happening under the hood.
You can change inputs and expect predictable outputs.
When none of this is easy, testing becomes expensive - and feedback slows down. The product still “works,” but it stops evolving safely.
When teams say “it works for us,” what they often mean is:
It works on our setup.
It works with our data.
It works with our assumptions.
That mindset builds invisible dependencies - on people, configurations, and habits. The product looks stable, but is actually fragile.
You can’t test it without replicating someone else’s mental model.
An untestable design is a dependency trap. It ties knowledge to individuals instead of systems
How to Design for Testability
Here’s what testable design looks like in practice.
You can use this as a checklist when reviewing your next feature or API.
1. Make behavior observable
Add logs, metrics, or state outputs that help see what’s going on.
If you can’t tell what a system is doing, you can’t test it effectively.
2. Keep boundaries clear
Each module or service should do one thing, expose what it does, and hide what it shouldn’t.
If testers (or automated tests) need to jump through layers to reach a function, it’s not testable - it’s tangled.
3. Inject, don’t hardcode
If your code depends on a specific file, URL, or time, allow that to be injected.
It makes testing easy and production safer.
Design for substitution - fake dependencies should work like real ones.
4. Separate data from behavior
Don’t bake test data or configurations into logic.
Keep them external and swappable. It helps testers validate different scenarios without changing the code.
5. Think about reversibility
A good design lets you undo things easily - reset a state, clear a queue, roll back a transaction.
If testing something leaves behind a mess, people will test less.
Testability isn’t the tester’s job alone.
It’s a design quality - just like performance or usability.
When teams build with testability in mind, feedback loops shorten.
You spot problems earlier, fix them faster, and gain trust in your system.
Testers don’t slow down development. Untestable design does.
Before You Ship
The next time you’re about to say “it works for us,” ask:
Can someone else validate it without me?
Can we see what happens when it fails?
Can we isolate and test just this part?
If the answer is no, you’re not done designing - you’re just done coding.
Final Thought
Good design isn’t about adding tests.
It’s about making things testable by design - so the whole team can see, question, and trust how the product behaves.
Because “it works for us” is never enough.
It should work for everyone who has to build, test, or use it.
Hanisha Arora is a Growth Hacker Lead focused on advocating for products and building better systems. She works where technicalities meet product thinking. Hanisha writes about testing, systems, and the tiny human errors that turn into product lessons.
Reply