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.

About these ads

One thought on “Selecting a testing approach?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s