Ask Your Dev Team about their testing strategy
Not all tests are created equal. Learn how to evaluate your developer's testing strategy and why test coverage alone doesn't mean your software is reliable.
“Do you write tests?” is a good starting question. But the answer you’re looking for goes deeper than “yes.”
Types of tests
There are several types of software tests, and they serve different purposes:
- Unit tests: Test small, isolated pieces of code. Think of a single function that calculates a price. A unit test makes sure that function returns the right number every time.
- Integration tests: Test how multiple pieces work together. Your checkout flow might involve a pricing function, a payment gateway, and a database. Integration tests make sure those pieces talk to each other correctly.
- End-to-end (E2E) tests: Simulate a real user interacting with your application from start to finish. These are the closest thing to having a human click through every screen and verify that everything works.
Each type catches different problems. A developer with only unit tests might miss bugs that happen when systems interact. A developer with only E2E tests might struggle to pinpoint where something broke.
Coverage isn’t the point
You might hear developers talk about “test coverage,” a percentage that represents how much of the codebase is covered by tests. Sounds like a useful metric, right?
Not really. A developer can hit 90% coverage by writing meaningless tests that technically touch every line of code but don’t actually verify anything important. Coverage tells you how much code was executed during testing, not how much was validated.
Tests for the sake of tests aren’t valuable. What matters is whether the tests are checking the things that matter to your business.
What to ask
- “What’s your testing strategy?” You’re looking for a clear, articulate answer. They should be able to tell you which types of tests they write, what libraries or tools they use, and why.
- “What do you prioritize testing?” The best answer focuses on the paths and workflows your users rely on most. Payment flows, authentication, data integrity, anything where a bug costs real money or trust.
- “How do tests prevent regressions?” A regression is when something that used to work stops working because of a new change. Tests are your safety net here. Every time new code is added, existing tests should run to confirm nothing broke.
If a developer can’t articulate what they test and why, that’s a red flag. You’re not looking for a textbook answer. You’re looking for someone who has thought about it.
A note on QA
Testing strategy and quality assurance (QA) are related but different conversations. Automated tests run in code. QA can involve manual testing, dedicated testers, and structured processes for validating work before it reaches your users. We’ll cover the difference between automated and manual QA in a future issue.
Expect better. Build better.