How to provide Product Owner with estimates for unit testing?

Question

"How long does it take his developer to write a unit test?" This is exactly the question the project owners keep asking me. The question is not actually how long it takes to write the unit test, but actually what does TDD or in particular the writing of unit test bring me in the later course of development.

I always answer "That depends, some don't last very long", but as a test manager I can't give an exact specification. I always advise to use timeboxes in sprint planning.

But I am unfortunately over-questioned with this question, because the PO´s really want to have this as a calculable unit.

So how do you calculate at least a rough estimate of how long it would take per task or per sprint to write a unit test?

How do you calculate the size, and which time units ?

Answer 1

I would argue that the question will not give any meaningful information and that you should make a stand if you are questioned in your practices as a professional.

I will start by the question itself:

Uncle Bob's Three Rules of TDD:

1 - You are not allowed to write any production code unless it is to make a failing unit test pass.

2 -You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.

3 - You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

These rules imply that you will be "trapped" in a loop of:

1 - Writing a little piece of test (maybe simply a MyObject obj = new MyObject()) which will break, because you don't have the class MyObject.

2 - Then you create a class called MyObject, making all tests pass

3 - Then you write some more testing:

Assert.equals(obj.name, null, "Default name is not null")

4 - Then you create an attribute called name that is always null, making all tests pass

5 - Then you write more testing....

Each of these steps are seconds long, you keep jumping frenetically between test and production code. The act of writing tests is embedded in the act of writing production code, and vice-versa.

So, how long did it take to write this unit test? Maybe you can have a text editor plugin that tracks the time you passed writing in files in the test folder. Is this information useful? Probably not.

Maybe your PO will ask:

But we want to know if TDD has a positive ROI...

The reason we don't question doctors why they spend time cleaning their hands 10 times, with 10 strokes on each side of each finger and under the nails, it's because they are professionals (literally they do). They take responsibility on their craft.

Accountants use double entry bookkeping, which is basically the process of TDD: Making a smallest step on the assets column, then making the equivalent on the liabilities column, and checking everything is OK.

TDD is a software craftsmanship practice, it is done because it is necessary to produce high quality software, which allows changes and improvements with security that quality is not denigrated.

If the PO don't value this and prefers to deal (financially) with the consequences of badly designed software, no problem, but he/she will have a hard time dealing with professionals that value high quality of their craft.

Answer 2

As with application code, attempting time estimation at a low level such as hours, days or weeks is not only an exercise in frustration (and much wasted effort) but will inevitably lead to (as we have learned) low quality. Quality ends up being optional and the first thing that can be cut.

The seminal book 'The Inmates are running the asylum' first revealed this to me and much has been written by other authors in this vein in the 20 years since.

It makes sense that the company needs to know when things are done so that they can plan the many other activities that relate. So "1st quarter we will have a new version" is good. However once you start down the path of 'x change takes take y time and will require z people' it gets messy. Fast. See "The mythical man month". As it says: "9 women can't make one baby in one month". Note: the new version should be released in tiny amounts, not all at once (otherwise I would seem to be recommending waterfall).

The problem is that the folks you are dealing with don't know / see / realize / understand this. So any attempts to 'explain it' to them, especially on the fly, will likely backfire and put their backs up and increase resistance. They expect a date and also think expecting a date is reasonable. Attempt to discredit this will increase resistance in the moment and over the longer term.

This requires high level leadership to give clear direction.

Once this is done you can refer to the direction given by leadership as defense of your efforts. That is pretty much the only way I know to make progress in these situations. Make sure it's not

"You and your opinion trying to convince them"

and make sure it is

"Following the company direction and goals for higher quality, move faster and make more money (or whatever)"

You might also consider the answer being that is is something that cannot be determined in isolation. The question, if asked, should be 'how long to write the application code (which MUST include the accompanying tests).

A typical release process may have many stages:

• enter story
• assign story
• work on code and tests for story
• perform code review on new code
• release tests to staging environment
• perform integrated testing
• perform UI testing
• perform performance testing
• perform usability testing

Trying to estimate all these part is a huge amount of effort (and not agile at all btw).

What you really care about it the lags beyween activities. If you actually add the actual time to code, test, etc. you might get 12 hours of work. The problem tends to be that becuase of all te handoffs and process 12 hours takes 2 weeks. or longer. The solution to this? More process? More estimating? No. I recommend:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

https://agilemanifesto.org/https://agilemanifesto.org/

If all this fails: New Job For You

Answer 3

The other answers have given you some good reasons why the metrics you are being asked for are not particularly useful. What you need is to have metrics that are useful to give the POs. To get them, you will probably need to do some data hunting and some talking to everyone involved.

The kinds of things you are looking for are (with all of these you're looking for averages, and doing everything you can to filter out exceptional situations):

• how long it typically takes your developers to produce a working, unit-tested segment of code - say, a slice of functionality being worked on in an iteration.
• how many issues your testers typically have with the working, unit-tested code, and how long it takes to get the unit-tested fixes through.
• how many problems customers typically report once the unit-tested and tester-tested software is released. For this information you'll likely need to filter actual problems from feature requests disguised as problems, misunderstandings, customers being hypercritical and reporting things they've been happy with for years, and so on. You're specifically looking for problems with the changes you've introduced, not anywhere else.
• how long it typically takes for the same team to write the same type of functionality without unit tests (Depending on the complexity of the software, this could be anything from much less to much more).
• how many problems the testers have with the software that doesn't have unit tests and how long it takes to get the problems fixed. (For anything complicated this measurement is likely to be much worse).
• How many problems customers report with the new functionality (which is also likely to be much worse).
• How many potential problems have been caught by running tests as part of the build processed (and then fixed right away instead of getting to customers)

What you want is your numbers to tell a story, preferably the story you want them to tell. The time a unit test takes to write (which can be under a minute) does not tell a story - it just looks like a potentially removable "cost" when really it's insurance.

The real value of time spent on unit tests (and integration tests and other automated tests) is the assurance that this change did not break that feature. When I was working with software that had very little unit testing, the sections with unit test and integration test coverage were much more robust than the sections of the application that couldn't be unit tested - and those parts that had reasonable UI layer automation were more stable than the features that didn't. This is the story your numbers need to tell, and the story your numbers should (and probably will) tell if you've got the raw data available.