I’m like a test unitarian. Unit tests? Great. Integration tests? Awesome. End to end tests? If you’re into that kind of thing, go for it. Coverage of lines of code doesn’t matter. Coverage of critical business functions does. I think TDD can be a cult, but writing software that way for a little bit is a good training...
If you can measure regressions in some way it would help to quantify the scale of the problem and also give the team something to visibly work towards.
For example: number of automated error reports (tracking like Sentry), number of issues/bug tickets created manually or number of PRs that are associated with fixing regressions (tagged after the fact).
Watching these numbers go down is satisfying.
The other thing I’d do is try to improve the tooling around testing to reduce friction when writing tests.
Are there no consequences for shipping buggy things though? No grumpy customers or internal users? I take pride in stuff that works well first time.
How do you get your team to write tests?
I’m like a test unitarian. Unit tests? Great. Integration tests? Awesome. End to end tests? If you’re into that kind of thing, go for it. Coverage of lines of code doesn’t matter. Coverage of critical business functions does. I think TDD can be a cult, but writing software that way for a little bit is a good training...
OC Bed kitty in her natural habicat