Test coverage for its own sake is dangerous. It leads to foolish technical choices.

If code offers business value, it's worth ensuring correctness with tests. If it's not worth doing correctly, just delete it.

What should you do with broken tests on an old project? Delete them. Probably.

In this episode, Daniel Bartholomae, CTO of Optilyz, "borrows my brain" for a consultatative discussion about how to improve the integration of QA in a growing startup with just two dev teams.

“We solve the problem of the ‘wall of confusion’ between dev and QA by enabling dev teams to do most testing on their own.”

The traditional Dev/QA dichotomy is analogous to the Dev/Ops dichotomy DevOps aims to solve. The same solution can work for both.

"Developers are optimistic, testers are pessimistic." I don't buy it.

"Testing" and "checking" are two different types of activities. They deserve a distinction.

When test writing is removed from code writing, there's no observed benefit in IT performance. Writing tests in a silo is an anti-pattern.

Is QA a separate stage in your software development pipeline? This is a "smell", an indicator of deeper problems.

CD leaves room for manual approvals, but once approved, all changes should be applied automatically.