I imagine that most of you have aleady heard of Test Driven Development (TDD) where the tests that software should pass are written BEFORE the software itself is written. The list of tests is essentially just a formalised way of listing success criteria (and indeed requirements) very precisely. More than precision, this approach gives you a very fast indication of your REAL progress, since the newly written code either passes or fails the tests*.
Test Driven Development is a software development approach usually associated with agile development methods such as those championed by the Agile Alliance. It is usually assumed that agile development requires a team to be collocated, working intensively and exclusively together, and so little attention has been paid to the role of these methods in outsourced development.
For better or for worse** however, many of us are on one side or the other of an outsourcing arrangement. I discovered in my work that using test driven development as a mechanism for both validation (are we building the right thing?) and verification (is it working?) can be hugely powerful.
There are a number of reasons for this:
- Well-written tests can explain requirements much more efficiently than traditional requirements documents. Even when there are misunderstandings, the SUM of the different tests specifies the right functionality.
- Tests are technical and so can overcome communication barriers with added precision. Even just not sitting next to your developers (or designers) can cause communication issues. When you add the moder-day reality of offshoring as well as outsourcing, this can be exacerbated.
- “The customer” (whoever they might be) can be involved in the creation of the test suite. This helps to ensure that the right functionality is being created in the first place since we can check that what the software does is what the customer desired/expected very easily.
- Showing the number of tests passed can be a much better indication of progress than the traditional “percentage of task complete” measure. You know exactly how much of the programme actually works at any given time.
- Tests can be automated. Then you essentially end up with an automatic checklist of desired behaviour, so that every time a change is made you can pinpoint other areas of the code that might have been affected and refactor quickly, rather than waiting for bug reports to come in from live use.
Hopefully as agile development methods become better and more widely adopted, an increased number of the firms providing outsourced development services will start to use them as standard. In the meantime, it can make a huge difference to your projects if you manage to introduce them ahead of the curve.
What have your experiences been with test driven development and outsourcing? Share in the comments.
* Provided your tests are well written, that is. Of course, writing good test cases is a skill all of its own!
** The pros and cons of outsourcing your development definitely deserves another post! Or arguably an entire book!
I think the focus on TDD is great. One note of caution though on talking about the customer creating the test suite. Unit tests are almost always purely a developer level practice, possibly with some enlightened QA staff. Customer level acceptence tests are another matter entirely.
Higher level functionality expressed as tests are typically concendered acceptence tests. You can do Acceptence Test Driven Development or Story Driven Development using tools like FIT/Fitnesse, but its really a different animal than tightly focused developer unit tests written as the code is being worked out.
Done right TDD is often much more about evolutionary design rather than testing. You might want to look into RSpec or JBehave for aspects of that.
Hi Ed. The approach I use tends to be blended — unit tests written by developers/QA, as you advocate, but with a suite of acceptance tests run regularly by business specialists. Even if they are running the tests manually, the time investment is worth it to get quick feedback on whether the enhancements being built are what is needed.
Obviously this approach is more usable when enhancing existing software, but I think functionality demos can be used when initially prototyping software to get the same sort of customer acceptance feedback.
i have read your article Really Nice one.because Now a days not only big companies like Adobe, Microsoft are doing software and product development in India at their development center. But now many other small to medium scale companies have started software and product development and started entering into outsourcing software product development. It is considered that, increase in business will be around 100% in offshore outsourcing product development.