Comments on: Measuring test effort

By: Ask for forgiveness, not for permission at Mark Needham

Ask for forgiveness, not for permission at Mark Needham — Fri, 04 Jun 2010 21:04:18 +0000

[...] My colleague Kristan Vingrys came up with a matrix which showed the risks of not testing various features and then let the client decide whether they wanted to take that risk. Alex wrote more about this at the time. [...]

By: TDD: Does it make you slower? at Mark Needham

TDD: Does it make you slower? at Mark Needham — Wed, 24 Dec 2008 23:44:13 +0000

[...] The TDD approach to doing this encourages early testing whereas the traditional approach is to do a lot of the testing at the end. The problem with the latter approach is that any bugs are being discovered quite a long time after the code was written which means it will take much longer to try and identify where they came from. Alex has a nice post showing the risks we assume when deciding to cut back on testing effort. [...]

By: Kamil

Kamil — Sun, 20 Jul 2008 17:25:55 +0000

Isn’t it wise in face of delay you drop practices you are learning and are not master of yet in order to deliver quicker? Resume learning on a next interation/project.

By: Alexandre Martins

Alexandre Martins — Fri, 18 Jul 2008 12:24:22 +0000

Yes Josh, in the short term the delivery is gonna be faster, if cutting off test effort, but in long term, as bugs start popping out, more time will be needed to fix them.

By: JoshG

JoshG — Fri, 18 Jul 2008 08:33:12 +0000

I would echo Senhor Shoe’s thoughts. Also, looking at the matrix and thinking about the other important dimension – time – I would expect that in general, a lack of tests would increase the likelihood of negative impact as time went by.

So it might be reasonable to cut some corners on tests, refactorings, and general cleanliness in the last mad dash to a release, but those things really need to be addressed immediately for long-term benefit and easier implementation of future business value.

If such decisions about cutting down on testing is made, it’s important to immediately start reporting changes in things like defects and rework time, to highlight the cost of _not_ taking the time to write software properly.

By: Fabio Nascimento

Fabio Nascimento — Thu, 17 Jul 2008 20:16:23 +0000

Sinto que cada vez mais devo me posicionar com relação a lutar para que os testes sejam colocados em todos os cronogramas.

By: Phillip Calçado

Phillip Calçado — Thu, 17 Jul 2008 14:20:28 +0000

There is some amount of test that just can’t be negotiated. That’s the minimum level of what you, as a professional, require to say that something is done. For most agile teams this will include unit and integration testing, for non-agile teams maybe unit testing and manual testing is enough.

The business has the right to reduce effort in software quality and focus on delivery but this can’t affect whatever you require to say something is done.

cheers