Then you have testers, but you may not have much independent testing.
Developers should absolutely help testers understand what changed, where risky code sits and what deserves attention. The problem starts when the person who built the feature also defines the entire test approach for proving it works. If you want us to review whether your team is providing real challenge, we can.
Who decides what deserves testing?
If the answer is always the developer, the tester is functioning mainly as an execution layer. They may still catch defects, but you are losing the value of another person approaching the product with different assumptions.
Good testers use developer input, product knowledge, architecture, past defects, user behaviour and plain curiosity. They do not need to prove independence by ignoring developers. They need enough ownership to say, “you told me this is safe; I still want to look here.”
Give testers room to follow what they find
A developer may reasonably say, “I changed this calculation, so check these three cases.” The tester should do that. But if one of those cases exposes strange behaviour elsewhere, they need permission and time to follow it. That is exactly the distinction behind whether developers testing their own code makes independent testers unnecessary.
Over-scripted teams often stop exactly where the interesting testing begins because the investigation is not in the estimate. That is where experience earns its keep: noticing something feels wrong and digging long enough to understand why.
Testing is not the whole of quality assurance
A tester who only sees tickets will naturally test tickets. A tester who understands the service can ask whether a technically correct change creates a terrible user outcome, breaks another journey or exposes a risk nobody wrote into the acceptance criteria.
For smaller operators, this is the useful distinction between testing and broader quality assurance. Testing examines the product. Quality assurance also asks whether the way you build, review, integrate and release it is giving you enough confidence. You do not need a giant QA department. You do need somebody thinking beyond “did the button do what the ticket said?”
The answer is not to build a wall between developers and testers. Independence means independent judgement, not separate seating plans and ceremonial handovers.
Developers should still be heavily involved
Independent judgement does not mean throwing work over a wall. Developers often know where a change is technically risky, which assumptions were made and what nearby code could be affected. Ignoring that knowledge in the name of independence would be daft.
The useful model is collaboration without surrendering judgement. Let developers point at the danger. Let testers decide how far to chase it, what else it might affect and what additional questions the implementation has created.
If you want us to look at how your team chooses coverage and whether testers are adding genuine challenge, speak to us. We can tell you where developer-led testing is sensible and where it has quietly turned the test function into a very expensive pair of hands.