Test Driven Development <ul><li>Reduce Development Cost </li></ul><ul><li>With Test Driven Development </li></ul><ul><li>J...
Test Driven Development <ul><li>The State of Software Development Today </li></ul>
Test Driven Development <ul><li>The Cost of Fixing Bugs Late in the Development Cycle </li></ul>
Test Driven Development <ul><li>The Search for Better Methodologies </li></ul><ul><li>The Classic Challenge: </li></ul><ul...
Test Driven Development <ul><li>TD ‘Design’ at the lowest </li></ul><ul><li>level: </li></ul><ul><li>A single atomic featu...
Test Driven Development <ul><li>TD ‘Design’: team units </li></ul>
Test Driven Development Beck & Astels 2003 <ul><li>TDD is a powerful way to produce well designed code with fewer defects ...
TDD using Unit Test  Framework NUnit for .NET <ul><li>Units are a piece of “isolatable functional code” > a Class or  Meth...
C# Example using NUnit Framework <ul><li>Task:  </li></ul><ul><li>Create an unbounded Stack which include Push, Pop & IsEm...
C# Example using NUnit Framework (continued) <ul><li>Test 2: Create a  Stack  & verify that  IsEmpty  is true </li></ul>Us...
TDD: Case Study - NetServ <ul><li>Netserv has successfully implemented the concept of SDUs with a few of our clients and c...
Scaling TDD  thru Agile Model  Driven Development AMDD <ul><ul><li>TDD is good at detailed specification, Validation & des...
The Other Dimension <ul><li>TD ‘Development’: </li></ul><ul><li>Driven by test </li></ul><ul><li>progress metrics </li></u...
TDD: Case Study - CTE <ul><li>A Project In Trouble : three years into a two year project, the first version had yet to be ...
TDD: Case Study - CTE
TDD: Case Study - CTE <ul><li>CTE took these steps to improve the delivery process, using metric-based testing data as the...
TDD: Case Study - CTE <ul><li>Lessons Learned </li></ul><ul><li>Synchronize your project plan and test management tools. <...
Finding the RIGHT Balance <ul><li>Increased Costs </li></ul><ul><li>Longer Projects </li></ul><ul><li>Higher Risk </li></u...
TDD: Case Study - CTE <ul><li>Employ management BASICS: </li></ul><ul><li>Business Acumen : all team members must have an ...
Test Driven Development <ul><li>Implementing TDD in Your Organization </li></ul><ul><li>Changing Relationships in Your Tea...
Test Driven Development <ul><li>Thanks for your attention!  </li></ul><ul><li>It’s time for your questions. </li></ul>
Upcoming SlideShare
Loading in...5
×

Reduce Development Cost with Test Driven Development

692

Published on

A collaboration between NetServ Applications and Celtic Testing Experts on Test Driven Development and Design. This presentation demonstrates how an organization can reduce development cost by implementing TDD.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
692
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Reduce Development Cost with Test Driven Development

  1. 1. Test Driven Development <ul><li>Reduce Development Cost </li></ul><ul><li>With Test Driven Development </li></ul><ul><li>J. Hank Rainwater, CTO of CTE </li></ul><ul><li>Noel Kierans, CEO of CTE </li></ul><ul><li>Sam Murthy Bharath, CEO of NetServ </li></ul>
  2. 2. Test Driven Development <ul><li>The State of Software Development Today </li></ul>
  3. 3. Test Driven Development <ul><li>The Cost of Fixing Bugs Late in the Development Cycle </li></ul>
  4. 4. Test Driven Development <ul><li>The Search for Better Methodologies </li></ul><ul><li>The Classic Challenge: </li></ul><ul><li>A Better Way: TDD </li></ul><ul><li>TDD = Test Driven Design: improvements at the smallest level of construction </li></ul><ul><li>TDD = Test Driven Development: improvements in the overall delivery process </li></ul>
  5. 5. Test Driven Development <ul><li>TD ‘Design’ at the lowest </li></ul><ul><li>level: </li></ul><ul><li>A single atomic feature </li></ul><ul><li>Negative Test </li></ul><ul><li>Code Construction </li></ul><ul><li>Positive Test </li></ul><ul><li>Refactoring </li></ul>
  6. 6. Test Driven Development <ul><li>TD ‘Design’: team units </li></ul>
  7. 7. Test Driven Development Beck & Astels 2003 <ul><li>TDD is a powerful way to produce well designed code with fewer defects </li></ul><ul><li>The best way to write a code is to shape it from the beginning with Tests </li></ul><ul><li>Fewer defects, lesser debugging, more confidence, better design & higher productivity </li></ul><ul><li>TDD Goal > think of the design before you develop leading to “clean code that works ” </li></ul><ul><li>Step A : Test First Design (TFD) </li></ul><ul><ul><li>Create a Test Case and Create a code small enough code to fail the test </li></ul></ul><ul><ul><li>Next you run the test to ensure it fails </li></ul></ul><ul><ul><li>Update the functional code to make it pass the test case </li></ul></ul><ul><ul><li>If it fails update/fix the code to pass the tests </li></ul></ul><ul><li>Step B : Refactoring </li></ul><ul><ul><li>Refactor any duplication out of design turning TFD into TDD </li></ul></ul><ul><ul><li>TDD = TFD + Refactoring </li></ul></ul>
  8. 8. TDD using Unit Test Framework NUnit for .NET <ul><li>Units are a piece of “isolatable functional code” > a Class or Method </li></ul><ul><li>Unit Tests are “programs written to run in batches and test classes” </li></ul><ul><li>UTFs help developers test using their development language and IDE </li></ul><ul><li>Traditional UTFs used “ Derived Classes ” to develop test classes </li></ul><ul><li>NUnit uses a concept of “ Attributes ” which are highly scalable </li></ul><ul><li>NUnit uses a Test Runner application to do Unit Testing </li></ul><ul><li>Test Runner runs tests identifying the NUnit “attributes” in the code </li></ul><ul><li>NUnit provides the following attributes </li></ul><ul><ul><li>Test Fixture Attribute indicates a class contains Test Methods </li></ul></ul><ul><ul><li>Test Attribute indicates a method is a test method to be run by TestRunner </li></ul></ul><ul><ul><li>Setup & Teardown helps create setups before and after each tests </li></ul></ul><ul><ul><li>Expected Exception helps create a try..catch statement to catch test exception </li></ul></ul><ul><ul><li>Ignore helps ignore a test temporarily if need arises </li></ul></ul><ul><ul><li>Assertion Class helps actually test what has happened is what you wanted to happen </li></ul></ul><ul><li>NUnit has a GUI / Console app to run against Test Assemblies </li></ul><ul><li>Test Assembly is a class library that contains Test Fixtures </li></ul><ul><li>Test Fixtures contains Test Attributes </li></ul>
  9. 9. C# Example using NUnit Framework <ul><li>Task: </li></ul><ul><li>Create an unbounded Stack which include Push, Pop & IsEmpty operations </li></ul><ul><li>Create a Test List: </li></ul><ul><ul><li>Create a Stack & verify that IsEmpty is true </li></ul></ul><ul><ul><li>Push a single object on the stack & verify that IsEmpty is true </li></ul></ul><ul><ul><li>Push a single object, Pop the object & verify that IsEmpty is true </li></ul></ul><ul><ul><li>Push a single object, remembering what it is; Pop the object & verify they are equal </li></ul></ul><ul><ul><li>Push three objects, remembering what it is; Pop each one, and verify they are removed in the correct order </li></ul></ul><ul><ul><li>Pop a stack that has no elements </li></ul></ul><ul><ul><li>Push a single object and then Call Top. Verify that IsEmty is False </li></ul></ul><ul><ul><li>Call Top on a Stack with no elements </li></ul></ul><ul><li>Run Tests: </li></ul><ul><ul><li>Test 1: Create a Stack & verify that IsEmpty is true </li></ul></ul>Using System; Using Nunit.Framework; [TestFixture] Public class StackFixture { [Test] Public void Empty() { Stack stack = new Stack() Asser.IsTrue(stack.isEmpty); } Test fails to compile Stack missing public class Stack { private bool isEmpty = true; public bool isEmpty { get { return isEmpty; } } Code compiles Runs in NUnit Green Bar Displays
  10. 10. C# Example using NUnit Framework (continued) <ul><li>Test 2: Create a Stack & verify that IsEmpty is true </li></ul>Using System; Using Nunit.Framework; [TestFixture] Public class StackFixture { [Test] Public void PushOne() { Stack stack = new Stack(); stack.Push(“first element”); Assert.IsTrue(stack.IsEmpty, “ After Push, IsEmpty should be false); } Public void Push(object element) { } Using System; Using Nunit.Framework; [TestFixture] Public class StackFixture { [Test] Public void PushOne() { Stack stack = new Stack(); stack.Push(“first element”); Assert.IsTrue(stack.IsEmpty, “ After Push, IsEmpty should be false); } Public void Push(object element) { isEmpty = false; } Failure: StackFixture.PushOne: “ After Push, IsEmpty should be false” Everything OK
  11. 11. TDD: Case Study - NetServ <ul><li>Netserv has successfully implemented the concept of SDUs with a few of our clients and currently have 1 to 6 SDUs working per client locations </li></ul><ul><li>The SDUs have Project/QA Lead at the client location </li></ul><ul><li>Regular SCRUM Sessions between SDUs and Project Leads </li></ul><ul><li>Creates a seamless pipeline from the SDUs to the Stakeholders </li></ul><ul><li>QA/Project lead with the SDU Testers execute any Blackbox/Regression/Integration Testing </li></ul><ul><li>Result </li></ul><ul><ul><li>24 Hour throughput </li></ul></ul><ul><ul><li>Well documented and tracked process </li></ul></ul><ul><ul><li>Continuous Whitebox and Regression Testing </li></ul></ul><ul><ul><li>Well designed code with very fewer defects </li></ul></ul><ul><ul><li>Cost effective Development Solution </li></ul></ul><ul><ul><li>Good Balance between Onshore team , Offshore team and Stakeholders </li></ul></ul>
  12. 12. Scaling TDD thru Agile Model Driven Development AMDD <ul><ul><li>TDD is good at detailed specification, Validation & design </li></ul></ul><ul><ul><li>TDD is not good thru bigger issues like overall design, UI design </li></ul></ul><ul><ul><li>AMDD addresses the scaling issues which TDD does not </li></ul></ul>Initial requirements Envisioning Initial Architecture Envisioning Iteration2:Development Iteration 1:Development Model Storming Iteration Modeling TDD Iteration 0: Development AMDD & TDD
  13. 13. The Other Dimension <ul><li>TD ‘Development’: </li></ul><ul><li>Driven by test </li></ul><ul><li>progress metrics </li></ul><ul><li>2. Managed by </li></ul><ul><li>discipline where </li></ul><ul><li>metrics provide </li></ul><ul><li>evidence for </li></ul><ul><li>action </li></ul><ul><li>Test progress is an aggregation of many factors </li></ul>
  14. 14. TDD: Case Study - CTE <ul><li>A Project In Trouble : three years into a two year project, the first version had yet to be delivered. Public promises had been made but a delivery date wasn’t in sight. </li></ul><ul><li>Corporate Culture : the bureaucratic viscosity of the organization hampered agile processes. </li></ul><ul><li>An Aggressive Timeline : key project milestones were sometimes established based on corporate needs and public promises rather than estimates derived from actual development progress. </li></ul>
  15. 15. TDD: Case Study - CTE
  16. 16. TDD: Case Study - CTE <ul><li>CTE took these steps to improve the delivery process, using metric-based testing data as the evidence to drive change: </li></ul><ul><li>Realigned tasks and personnel to better fit skills and depth of experience. </li></ul><ul><li>Held daily team meetings with QA staff to coordinate testing efforts. Often these were of the ‘scrum’ variety and often held standing. </li></ul><ul><li>Mentored staff as needed to increase motivation and effectiveness. </li></ul><ul><li>Generated daily metrics and weekly reports for all teams that informed leadership decisions. </li></ul><ul><li>Reviewed test scripts and execution plans with QA and development staff at regular intervals. </li></ul><ul><li>Coordinated daily conference calls with off-shore developers and performed triage on project priorities. </li></ul><ul><li>Implemented best practices with test management tools. </li></ul>
  17. 17. TDD: Case Study - CTE <ul><li>Lessons Learned </li></ul><ul><li>Synchronize your project plan and test management tools. </li></ul><ul><li>Keep the progress data up-to-date </li></ul><ul><li>Take action when the data indicates problems </li></ul>
  18. 18. Finding the RIGHT Balance <ul><li>Increased Costs </li></ul><ul><li>Longer Projects </li></ul><ul><li>Higher Risk </li></ul><ul><li>Lower ROI </li></ul><ul><li>Costs are LEAN </li></ul><ul><li>Shorter Projects </li></ul><ul><li>Reduce Risk </li></ul><ul><li>Optimize ROI </li></ul>
  19. 19. TDD: Case Study - CTE <ul><li>Employ management BASICS: </li></ul><ul><li>Business Acumen : all team members must have an understanding of the business processes that they are attempting to test. Knowledge of the context of the problems software is designed to solve is essential and will require mentoring and directed assignments. </li></ul><ul><li>Strategy : TDD offers a new strategy. The tactics that lead to the strategic benefits will be unique in your organization but embracing the vision of improvement will motivate team members and leaders alike to make the sometimes painful changes required. </li></ul><ul><li>Innovation : trying something new can be part of strategy but it must be justified by the standards and constraints of the corporate development ecosystem. With TDD you are using an innovative strategy but as you put it into practice, don’t be afraid to tweak it as needed as you learn what works best for your teams. Just don’t stray from the core principle of writing tests before writing code! </li></ul><ul><li>Common Sense : without being redundant, common sense often means using basic management practices such as never expecting what you don’t inspect and holding personnel accountable for their performance. The whole concept of a SDU practicing TDD is based on accountability in a small group – something much easier to manage than large and disconnected teams where finger pointing can take precedence over problem solving. </li></ul>
  20. 20. Test Driven Development <ul><li>Implementing TDD in Your Organization </li></ul><ul><li>Changing Relationships in Your Team </li></ul><ul><li>Developers, testers and users have different perspectives </li></ul><ul><li>Be aware of typical misconceptions </li></ul><ul><li>TDD = >Agile => Lean => $avings at the bottom line </li></ul>
  21. 21. Test Driven Development <ul><li>Thanks for your attention! </li></ul><ul><li>It’s time for your questions. </li></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×