4

My question is a sort of inverse of this one, where the OP asks whether a client may expect software tests as automatic deliverable in a software project. To me, that would imply a knowledgeable customer who knows that tests represent a percentage development cost that can help insulate against the surprise costs of regressions later on.

I'm looking to get started as a freelance developer, and I foresee the opposite problem. I think writing good software (unit/functional/etc) tests takes time, and since this is a substantial fraction of time spent it must be billed for. If we say that it takes 20% of a project's billable hours, clients may see this as an avoidable expense and ask for it to be removed from the schedule of work. For the freelance engineer, this may result in a loss of quality and a lower level of deployment confidence (neither of which are great if the freelancer is hired as a maintainer over the long term).

This answer suggests that the day rate should be high enough to effectively throw writing tests in for free. However, this may make estimates look uncompetitive, and I'd rather have the client know exactly what they're getting for their money. Thus, is it worth persuading clients of the value of this deliverable?

Community
  • 1
halfer
  • 298
  • 2
  • 12
  • I put test calculation in the estimation, just below of the QA estimation. Most clients don't want to pay for it (99%). – Peter MV Jul 22 '15 at 10:12
  • Another thing to bang your head over is whether they're willing to pay for you to document your own code... – user45623 Jul 24 '15 at 03:40
  • @user45623: I always comment code, which is the first form of documentation. I'd keep at least some minimal other docs, like some simple tech specs or install docs, as items of work rolled into the base cost. – halfer Jul 24 '15 at 08:56

2 Answers2

5

Unless your client is high-profile and huge, or the software is mission-critical, you're going to have a hard time justifying the extra time taken for tests to clients.

Most clients tend to think that writing tests just takes longer (your average time taken to do something is at least 50% more), and clients don't value the return on investment given by unit/functional/behavioral tests, because "Why do you need to write more code while I'm paying you?".

Since tests benefit both of you (not having to rewrite something is always a plus), try and show that you can directly test that your deliverables do exactly what the client asked for, and attack it from that angle.

Try not to have tests as a separate billable, but keep them part of the time/effort estimate for the project. If you separate them out, clients can and almost certainly will see that billable item as optional and try to eliminate it.

When billing hourly, use experience you have writing tests and factor in how long that will take. A good rule of thumb when starting out is estimate how long you think it would take, then triple that. As you gain experience, and you know your capabilities, you can start estimating more precisely.

If billing per-project, factor the time taken to test into the costs of the project, and make it non-negotiable and part of the software deliverables.

If you really need to itemise things, only itemise the acceptance tests (that is, behavioral tests; BDD). All other testing is a core part of software development (as in, test-driven development) and you should not give the client any choice about this.

Amelia
  • 1,227
  • 1
  • 11
  • 31
  • I expect you're right, that 50% is probably a better estimate (my working approach is more thorough than fast anyway). I wonder whether, as I am getting started, a set of partial tests is a good place to start - for example that all web screens actually display. Not completely robust, but better than nothing. Anyway thanks, good advice. – halfer Jul 22 '15 at 08:31
  • @halfer the best tests to convince clients with are behavioral tests - cucumber/behat, etc, because they literally write the tests for you and you prove your software passes those tests. – Amelia Jul 22 '15 at 08:48
  • I'll look into that, thanks. I currently just use PHPUnit driving Selenium/PhantomJS etc, but setting up the correct fixtures for each scenario tends in my experience to be rather slow. #morestufftolearn :-) – halfer Jul 22 '15 at 09:06
  • 1
    Definitely wouldn't include testing a s a line item billable. You don't bill them for source code repository setup and other key parts of a solid development process, you bill them for quality results. The testing you should be discussing with them is acceptance testing to provide a means for both sides to agree in advance on completion criteria. – cdkMoose Jul 22 '15 at 19:07
  • @cdkMoose: well, repo configuration is such a trivial task that it is clearly not worth itemising. I put software testing at 20% of time spent, but Amelia is probably correct that it is more than that. Whilst I don't disagree with the above advice, I can't think of a better example category of work that takes so much time and yet ought not be itemised. – halfer Jul 23 '15 at 11:21
  • @halfer see the edit I just made. – Amelia Jul 23 '15 at 12:00
2

I typically work on small-to-medium scale projects with clients that have zero-to-moderate experience in having software developed. In nearly every project I've ever worked on, we've almost immediately settled into a flow where I send the client regular prototype builds, and they report back with their opinions as well as any bugs they have spotted. This lets me focus on features and often cuts down on costs. I've gotten so used to this that I don't even think to address the subject of testing.

Most small clients, even those new to the industry, understand that bugs are a fact of development and don't mind helping track them down. Additionally, a client with a limited timeframe or budget is likely going to be more than willing to take on some of the testing to speed things up or reduce expenses.

Even though it's how I've ended up operating, I wouldn't recommend jumping into a project without discussing the subject with clients. You might just ask whether they'd prefer to do some of the testing themselves to save time/costs or to have you set up more expensive unit tests to be more thorough.

Of course, you need to use common sense depending on the project and the client. An enterprise-level client is probably going to expect you to do through testing. Any time you're doing critical calculations (e.g. scientific, financial, etc) where mistakes might not be obvious, unit tests are key.

user45623
  • 1,670
  • 1
  • 9
  • 17
  • I much appreciate your answer, but I don't think manual testing is sufficient, unless we're talking about an app of fairly trivial complexity. Perhaps I've just been unlucky with the sprawling, legacy codebases I've been landed with, but many a time I've adjusted something of horrendous complexity and it's inexplicably caused a bug or regression elsewhere. Even after pushing it to a staging server and getting a customer nod! – halfer Jul 23 '15 at 20:09
  • My half-way house may be to write browser tests for just the display of all screens, and to hold off unit testing. This will catch a proportion of problems - it isn't really good enough, in my view, but at least it'll only account for a small fraction of billable time. For longer projects perhaps I can build on top of that. – halfer Jul 23 '15 at 20:12
  • 1
    You wrote that I'm looking to get started as a freelance developer and implied that you don't expect your clients to be knowledgeable, so I got the impression that you wouldn't be jumping straight into sprawling legacy codebases. I wrote from the assumption your projects would be started from scratch. Of course, the nature of testing that is or isn't required will depend on the type of software you're building. – user45623 Jul 24 '15 at 01:19
  • I should think clients exist that are not particularly knowledgeable and have legacy codebases. I'd certainly prefer to do greenfield development, but I may need to take what I am given in the early days. And, to be fair, I'd prefer to add some form of tests to everything. – halfer Jul 24 '15 at 08:54