urn:lsid:ibm.com:blogs:entries-59010112-9143-447a-ba21-e36e0f009a6bAgility@Scale: Strategies for Scaling Agile Software Development - Tags - specification Agility@Scale: Strategies for Scaling Agile Software Development03022015-01-19T21:45:56-05:00IBM Connections - Blogsurn:lsid:ibm.com:blogs:entry-83c83a74-54ac-4051-8f20-e3fb3f725716Tragic Mistakes When Adopting TDDScottAmbler120000HESDactivefalseComment EntriesLikestrue2010-01-25T17:00:57-05:002012-01-19T12:10:07-05:00My January 2010 DDJ Agile Update, <a href="http://www.ddj.com/architect/222301633?cid=Ambysoft">Tragic Mistakes When Adopting Test Driven Development (TDD)</a> , is now online. In the article I summarize what I consider to be common, and tragic, mistakes that I'm seeing organizations make when they attempt to adopt TDD.<br /><br />These mistakes include:<br /><ul sizcache="25" sizset="120"><li>Not providing sufficient training, education, and mentoring</li><li>Not supporting pair programming</li><li sizcache="25" sizset="120">Not reducing the creation of non-executable <a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/detailed/speculations">detailed speculations</a> early in the project</li><li>Not reducing the confirmatory testing being done by their independent QA/testing team</li><li sizcache="25" sizset="121">Completely reducing initial <a href="http://www.agilemodeling.com/essays/initialRequirementsModeling.htm">requirements envisioning</a> and <a href="http://www.agilemodeling.com/essays/initialArchitectureModeling.htm">architecture envisioning</a></li><li sizcache="25" sizset="123">Completely reducing <a href="http://www.ambysoft.com/essays/agileTesting.html#IndependentParallelTesting">parallel independent testing</a></li></ul><br />The article also goes into potential benefits of TDD as well as potential challenges that you're face when adopting it.<br />My January 2010 DDJ Agile Update, Tragic Mistakes When Adopting Test Driven Development (TDD) , is now online. In the article I summarize what I consider to be common, and tragic, mistakes that I'm seeing organizations make when they attempt to adopt TDD....005922urn:lsid:ibm.com:blogs:entries-59010112-9143-447a-ba21-e36e0f009a6bAgility@Scale: Strategies for Scaling Agile Software Development2015-01-19T21:45:56-05:00urn:lsid:ibm.com:blogs:entry-0b01577b-8e85-4183-a42f-fd78f648b1c7Scaling Test Driven Development (TDD)ScottAmbler120000HESDactivefalseComment Entriesapplication/atom+xml;type=entryLikestrue2008-01-11T11:13:07-05:002012-01-19T17:39:00-05:00Test-driven development (TDD) is a common agile programming technique which has both specification and validation aspects. With TDD, you specify your software in detail on a just-in-time (JIT) basis via executable tests that are run in a regression manner to confirm that the system works to your current understanding of what your stakeholders require.<br/><br/>TDD is the combination of test-first development (TFD) and refactoring. With TFD, you write a single test (at either the requirements level with customer/acceptance tests or the design level with developer tests) and then you write just enough software to fulfill that test. Refactoring is a technique where you make a small change to your existing code to improve its design without changing its semantics. <br/><br/>TDD offers several benefits:1. It enables you to take small, safe steps during development, increasing programmer productivity.2. It increases quality. Agile developers are doing more testing, and doing it more often, than ever before. We're also fixing the problems that we find right on the spot.3. It helps to push validation activities early in the lifecycle, decreasing the average cost to fix defects (which rises exponentially the longer it takes you to detect them).4. Through single sourcing information, by treating tests as both specifications and as tests, we reduce the work required, increasing productivity.5. We leave behind valuable, up-to-date, detailed specifications for the people who come after us. Have you ever met a maintenance programmer who wouldn't want a full regression test suite for the code that they're working with?<br/><br/>But TDD isn't perfect. Although TDD is great at specifying code at a fine-grain level, tests simply don't scale to address higher level business process and architectural issues. Agile Model Driven Development (AMDD) enables you to scale TDD through initial envisioning of the requirements and architecture as well as just-in-time (JIT) modeling at the beginning and during construction iterations. To scale requirements-level TDD, you must recognize that customer tests are very good at specifying the details, but not so good at providing overall context. High-level business process models, conceptual domain models, and use cases are good at doing so, and these work products are often created as part of your initial requirements envisioning and iteration modeling activities. Similarly, to scale design-level TDD you must recognize that developer tests are very finely grained but once again do not provide overall context. High-level architecture sketches created during envisioning activities help set your initial technical direction. During each construction iteration, you'll do more detailed design modeling to think through critical issues before you implement them via TDD. <br/><br/>You also need to scale the validation aspects of TDD. TDD is in effect an approach to confirmatory testing where you validate the system to the level of your understanding of the requirements. The fundamental challenge with confirmatory testing, and hence TDD, is that it assumes that stakeholders actually know and can describe their requirements. Therefore you need to add investigative testing practices which explore issues that your stakeholders may not have thought of, such as usability issues, system integration issues, production performance issues, security issues, and a multitude of others. <br/><br/>For further reading, I suggest:1. My article "Introduction to TFD/TDD" at http://www.agiledata.org/essays/tdd.html which overviews TDD.2. My February 2008 column in Dr. Dobb's Journal entitled "Scaling TDD" at http://www.ddj.com/architect/205207998 which explores this issue in detail. 3. Andrew Glover's article "In pursuit of code quality: Adventures in behavior-driven development" at http://www.ibm.com/developerworks/java/library/j-cq09187/ which describes a new-and-improved take on TDD called BDD.<div>Test-driven development (TDD) is a common agile programming technique which has both specification and validation aspects. With TDD, you specify your software in detail on a just-in-time (JIT) basis via executable tests that are run in a regression manner to confirm that the system works to your current understanding of what your stakeholders require.<br /><br />TDD is the combination of test-first development (TFD) and refactoring. With TFD, you write a single test and then you write just enough software to fulfill that test. Refactoring is a technique where you make a small change to your existing code to improve its design without changing its semantics. When you do this at the requirements level with customer/acceptance tests it is called Acceptance Test Driven Development (ATDD) or Behavior Driven Development (BDD). At this design level with developer tests it's generally referred to as TDD. <br /><br />TDD offers several benefits:</div><ol><li>It enables you to take small, safe steps during development, increasing programmer productivity.</li><li>It increases quality. Agile developers are doing more testing, and doing it more often, than ever before. We're also fixing the problems that we find right on the spot.</li><li>It helps to push validation activities early in the lifecycle, decreasing the average cost to fix defects (which rises exponentially the longer it takes you to detect them).</li><li>Through single sourcing information, by treating tests as both specifications and as tests, we reduce the work required, increasing productivity.</li><li>We leave behind valuable, up-to-date, detailed specifications for the people who come after us. Have you ever met a maintenance programmer who wouldn't want a full regression test suite for the code that they're working with?<br /></li></ol><div>But TDD isn't perfect. Although TDD is great at specifying code at a fine-grain level, tests simply don't scale to address higher level business process and architectural issues. <a href="http://www.agilemodeling.com/essays/amdd.htm">Agile Model Driven Development (AMDD)</a> enables you to scale TDD through initial <a href="http://www.agilemodeling.com/essays/initialRequirementsModeling.htm">requirements envisioning </a>and <a href="http://www.agilemodeling.com/essays/initialArchitectureModeling.htm">architecture envisioning </a>as well as just-in-time (JIT) modeling at the beginning and during construction iterations. To scale requirements-level TDD, you must recognize that customer tests are very good at specifying the details, but not so good at providing overall context. High-level business process models, conceptual domain models, and use cases are good at doing so, and these work products are often created as part of your initial requirements envisioning and iteration modeling activities. Similarly, to scale design-level TDD you must recognize that developer tests are very finely grained but once again do not provide overall context. High-level architecture sketches created during envisioning activities help set your initial technical direction. During each construction iteration, you'll do more detailed design modeling to think through critical issues before you implement them via TDD. <br /><br />You also need to scale the validation aspects of TDD. TDD is in effect an approach to confirmatory testing where you validate the system to the level of your understanding of the requirements. The fundamental challenge with confirmatory testing, and hence TDD, is that it assumes that stakeholders actually know and can describe their requirements. Therefore you need to add investigative testing practices which explore issues that your stakeholders may not have thought of, such as usability issues, system integration issues, production performance issues, security issues, and a multitude of others. This is often done by a <a href="http://www.ambysoft.com/essays/agileTesting.html#IndependentParallelTesting">parallel independent test team</a>.<br /><br />For further reading, I suggest:</div><ol><li>My article &quot;<a href="http://www.agiledata.org/essays/tdd.html">Introduction to TFD/TDD</a>&quot; which overviews TDD.</li><li>My article <a href="http://www.ambysoft.com/essays/agileTesting.html">Agile Testing and Quality Strategies </a>which describes a collection of agile practices.</li><li>My February 2008 column in Dr. Dobb's Journal entitled &quot;<a href="http://www.ddj.com/architect/205207998 ">Scaling TDD</a>&quot; which explores this issue in detail. </li><li>Andrew Glover's article &quot;<a href="http://www.ibm.com/developerworks/java/library/j-cq09187/ ">In pursuit of code quality: Adventures in behavior-driven development</a>&quot; which describes a new-and-improved take on TDD called BDD. </li></ol>Test-driven development (TDD) is a common agile programming technique which has both specification and validation aspects. With TDD, you specify your software in detail on a just-in-time (JIT) basis via executable tests that are run in a regression manner to...037216urn:lsid:ibm.com:blogs:entries-59010112-9143-447a-ba21-e36e0f009a6bAgility@Scale: Strategies for Scaling Agile Software Development2015-01-19T21:45:56-05:00