Selecting a testing approach?

We’re approaching OOW rapidly, and we’re discussing the different topics that can be adressed during the ADF EMG Sessions.

One of the topics I would like to start discussing in this group, is the testing strategies that are used at the different project sites.

In most projects we’re now trying to introduce Test Driven Development, to make sure that all functionality that is integrated within the project lifecycle is thouroughly tested before releasing the code into the release management lifecycle.

What does it mean Test Driven Development :
Each new feature begins with writing a test, which will inevitably fail because it is written before the feature has been implemented. To write a test, the developer must clearly understand the feature’s specification and requirements. This could also imply a variant, or modification of an existing test.
This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.

At our current ADF project most developers we’re already acquanted with Unit-testing code and had no difficulties with the TDD-approach.

The benefits for the project:
1) Better communication and collaboration between the business analyst, product owner and development team
2) Code was much more failproof and the team could easily delegate tasks amongst each other. E.g. one developer wrote the tests and the other member of the team implemented the functionality.

Limitations:
1) When deadlines and production dates are approaching, it’s hard to keep the team focussed on this approach. It’s in everyone’s mindset that refactoring test cases and creating new ones, will take up time that is limited, instead of just writing the code, or changing it and pushing it through release management
2) The tests themselves become overhead for the maintenance part of the project.
3) Test cases aren’t bullet-proof, if the code and test cases don’t cover the functional requirements, it won’t be shown in the testing results. As well functional and business validation is needed before you can be sure the implemented functionality is bullet-proof.