A very common mistake that Agile teams make is when they try to design the software in their planning sessions.

I can kind of understand the temptation. The developers don't really know what's going to be involved in implementing each story, and the project manager wants accurate-ish estimates. So they dig a little deeper. And the danger is that they'll dig too deep, and then keep digging, leading to a monumental design effort lasting hours - or even days.

1. Test-driven Development is:

* Write a failing test
* Write the code to pass the test
* Refactor to remove duplication

If you write the code first, that is not TDD (I mean, really! The clue's in the name...)

If you write a stub and then write tests against it, that is Stub-driven Testing, not Test-driven Development.

If you w

Any curious tester can find a number of published heuristic documents out there on the web (James Bach, Elisabeth Hendrickson)‘Heuristics’ appear regularly on blog posts. (Mike Kelly, Ainars Galvans, Scott Barber, David Gilbert)In this post I aim to show you an easy way of identifying new test ideas without recourse to heuristics, on a case [...]