http://debianws.lexgopc.com/wiki143/index.php?action=history&feed=atom&title=Tester-driven_developmentTester-driven development - Revision history2026-10-26T06:14:33ZRevision history for this page on the wikiMediaWiki 1.43.1http://debianws.lexgopc.com/wiki143/index.php?title=Tester-driven_development&diff=7645297&oldid=previmported>Bearian: Deprod; add {{inline |date=March 2025}}2025-03-29T18:18:49Z<p>Deprod; add {{inline |date=March 2025}}</p>
<p><b>New page</b></p><div><br />
{{Short description|Software development process}}<br />
{{one source |date=March 2024}}<br />
{{inline |date=March 2025}}<br />
In [[software engineering]], '''tester-driven development''', or '''bug-driven development''', is an [[anti-pattern]] where the [[requirement]]s are determined by [[bug report]]s or [[Software test|test]] results rather than, for example, the value or cost of a [[Software feature|feature]]. The concept is generally invoked facetiously, and comes with the implication that high volumes of computer code are written with little regard for [[unit testing]] by the programmers.<br />
<br />
The term itself is a tongue-in-cheek reference to [[test-driven development]], a widely used methodology in [[Agile software development|agile software practices]]. In test-driven development tests are used to drive the implementation towards fulfilling the requirements. Tester-driven development instead shortcuts the process by removing the determination of requirements and letting the testers (or the [[quality assurance|QA team]]) drive what they think the software should be through the testing (or QA) process.<ref>{{cite book |last1=Ali |first1=Junade |title=Mastering PHP Design Patterns |date=2016 |publisher=Packt Publishing |isbn=9781785883422 |page=62 |url=https://books.google.com/books?id=DIFcDgAAQBAJ&q=%22tester+driven%22+%22bug+driven%22&pg=PA62}}</ref><br />
<br />
[[Software project|Project]]s that are developed using this anti-pattern often suffer from being extremely late. Another common problem is poor [[code quality]].<br />
<br />
Common causes for projects ending up being run this way are often: <br />
<br />
*The testing phase started too early;<br />
*Incomplete requirements;<br />
*Inexperienced testers;<br />
*Inexperienced developers;<br />
*Poor [[project management]].<br />
<br />
Things get worse when the testers realize 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.<br />
<br />
== See also ==<br />
*[[Extreme programming]]<br />
*[[Extreme programming practices]]<br />
*[[Feature creep]]<br />
*[[Requirements management]]<br />
*[[Software prototyping]] – creating prototypes of software applications to get feedback from users early in a project<br />
<br />
==References==<br />
{{reflist}}<br />
<br />
[[Category:Software development process]]<br />
[[Category:Anti-patterns]]<br />
<br />
<br />
{{Software-eng-stub}}</div>imported>Bearian