DDT - Developer Driven Testing

There are no testers at TransferWise. Not a single-one.

This deliberate choice has been made already a long time ago and I believe it's a key element of our engineering culture: Engineers own the quality of the product. You could actually say we have a lot of Quality Engineers (QE), all of us are. We are responsible for the product at all levels, which also includes making sure the code we write fulfills its expectations.

Having lots of testers is an easy way to build a culture of engineers not caring about quality, because they know there is a tester that will check everything. What could go wrong?.. But this "throwing over the wall" mindset is not the way to build a high quality product orders of magnitude better than the competition, which we need to have to get NPS Driven Growth.

We are building a financial service, where bugs can have dramatic consequences for us and for our customers. Not having testers means that engineers naturally take the quality of what they do much more seriously. This results in a better product.

How do we do this in practice? Unsurprisingly, we invest a lot in automated testing and code reviews.

Automated tests are a no-brainer. People may say they have no time to write tests, but honestly in the vast majority of the cases that's nonsense. Writing an automated test doesn't take more time than executing the same actions manually tens of times. Even more true when you need to check error situation, which can be hard to reproduce manually.

Code reviews complement naturally automated testing. Some issues get better caught by tests, and others such as design or security issues by humans. Code reviews have also great benefits in ending up in more maintainable code, as the reviewer's natural tendency will be to see this code as something he himself may have to change one day. Of course, code reviews should cover also the tests themselves, since bad tests are as harmful as bad code-under-test. They may give unwarranted confidence or become a maintenance nightmare. Or the worst of all, be flaky tests (tests which fail sometimes only, usually because they are not well isolated from other tests).

Test-driven development (TDD) is used by some teams, although not by all. We don't really have much centrally mandated processes. It's up to the teams to figure out and decide what works best for them.

Of course, this approach is not without its challenges.

Not having people dedicated specifically to quality makes it harder to have a working feedback loop. Customer Support raises bugs that need attention, however teams don't all address them with the same diligence. Some teams struggle more than others to keep their defect backlog under control, a problem for which we haven't found an universal efficient solution.

Keeping a big test suite up-to-date is also challenging. While we are in the process of splitting up our monolithic application into micro-services, that main application still has a large code base, with suite of test as big.

When candidates hear about our approach to testing during an interview, reactions are usually either enthusiast or shocked. Enthusiast candidates tend to have experienced the limitations of human-based QA themselves and are excited to try the other approach. When the candidate is shocked and cannot believe it works, there is often a strong correlation with a lack of customer empathy: It usually means an engineer, who wants to focus on the code, not on the product. Not the people we want.

I find it quite sad that so few young graduates know anything about automated testing or have practiced code review during school assignments. It's such a crucial part of software development these days that it should really be part of university curriculum.

As with other parts of our culture, this is something we all buy into, up to our founders. Kristo wrote recently:

Kristo Käärmann: It is quite fascinating that we haven't even talked about QA for the last 2 years now (used to argue a bit in the beginning) -- think it has become so natural now that engineers and product own the quality of the product.

Nothing to add to this!