When the client won't pay for testing

If an agency or project manager ever tells you, “the client won’t pay for testing.” This comment is a process smell, a surefire sign of communication and project management issues.

Testing is part of building a feature and should be included in the cost. It is not an optional add-on. If the client is asking about testing, it must be listed as a separate line item in an estimate or invoice. Writing tests for features is part of a feature. Include them as part pricing said feature.

Keep the customer out of the kitchen

Does your client understand the implications of not writing tests? If not, why are they making that decision?

Why is the client even aware of testing? Are you showing too much of how the sausage is made?

Imagine ordering food at a restaurant, walking into the kitchen. Then imagine asking the chef why you are paying for him to wash __his__ hands, and you could skip that step and lower the price of the meal. No good chef would acquiesce to that.

You can collaborate with clients without letting them get too close. There’s a reason many bike shops have a pricing policy of “double if you watch, triple if you help.” 

Collaborate with clients on what you both want to achieve together, not how you do your work.  Drive conversations towards outcomes, not inputs.

Writing tests is cheaper than skipping them

Presumably, the client wants to save money. However, testing done right helps you move faster, not slower. The alternative to an hour spent writing unit tests is not one less billable hour. It is more time spent manually testing and debugging. Those hours may come later, but eventually, a project without tests will move slower.

The comparison isn’t “X hours spent writing tests vs. not” it’s “X hours spent writing tests vs. Y hours spent manually testing, going back and forth on bugs, tracking down regressions, etc.”

What if you’re building an “MVP”?

If you are building a true MVP, and one that you are planning to throw away when you are ready to create the “real” project, then you could make a test for not including automated testing. However, in my experience, this isn’t how it works in practice. If someone hires developers and money is changing hands, they likely are expecting a “real” product.

To them, “MVP” means “the first version we can use as a foundation for our product.” 

In that case, you shouldn’t be building a foundation on shaky grounds. Those versions need tests. 

What if you inherit a code base with no tests?

Firstly, god bless you. Secondly, if you know that adding tests will make your work on the project better, add it and throw it in with another feature. Typically a new product will include some hours for setup and learning the platform. You can install testing tools as part of this process, then add tests as you fix bugs and add features.

Adding tests to existing functionality is a case here where it has limited value and can take a large number of hours. In these cases, a conversation with the client makes sense, and the best way forward is situation-dependent.

What should you do instead?

Remember that you’re the expert, and you have a responsibility to practice your craft to the best of your ability. That sometimes means protecting the client from themselves.

If you’re required to report the time or cost of features, include testing with those features. If you need to install something new, roll it up with something else. Focus your client conversations more on goals, metrics, and outcomes and less about the nuts and bolts of how you do your job. The client will get a better quality product for less cost, and both of you can focus on achieving goals instead of getting bogged down in invoice minutia.