Tester Driven Development
From Wikipedia, the free encyclopedia
 |
This article does not cite any references or sources. (December 2006) Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed. |
| This article may not meet the notability guideline for neologisms. If you are familiar with the subject matter, please expand or rewrite the article to establish its notability. The best way to address this concern is to reference published, third-party sources about the subject. If notability cannot be established, the article is more likely to be considered for redirection, merge or ultimately deletion, per Wikipedia:Guide to deletion. This article has been tagged since November 2007. |
| Software development process | |
| Activities and steps | |
|---|---|
| Requirements · Architecture Design · Implementation Testing · Deployment |
|
| Models | |
| Agile · Cleanroom · Iterative · RAD RUP · Spiral · Waterfall · XP · Scrum |
|
| Supporting disciplines | |
| Configuration management Documentation Quality assurance (SQA) Project management User experience design |
|
Tester driven development is an Anti-pattern in software development. It should not be confused with Test Driven Development. It refers to any software development project where the Software testing phase is too long. The testing phase is so long that the requirements may change radically during software testing. New or changed requirements often appear as bug reports. Bug tracking software usually lacks support for handling requirements. As a result of this nobody really knows what the system requirements are.
Projects that are developed using this anti-pattern often suffer from being extremely late. Another common problem is poor code quality.
Common causes for projects ending up being run this way are often:
- The testing phase started too early;
- Incomplete requirements;
- Inexperienced testers;
- Inexperienced developers;
- Poor project management.
Things get worse when the testers realise that they don't know what the requirements are and therefore don't know how to test any particular code changes. The onus then falls on the developers of individual changes to write their own test cases and they are happy to do so because their own tests normally pass and their performance measurements improve. Project leaders are also delighted by the rapid reduction in the number of open change requests.
