Offshore Outsourcing and the Value of Test-Driven Development

Slide 1: Offshore Outsourcing and the Value of Test- Driven Development Guy Rintoul guyrintoul.com

Slide 2: Key Issues Language barriers • Working across time zones • Communicating context of development • Communicating business need • Accuracy of specification • Robustness of test scenarios •  Value of Test-Driven Development (TDD)

Slide 3: Issues Language barriers Often based in India, Poland etc. • Communicating ideas effectively • Don’t necessarily speak “business” English •

Slide 4: Issues Working across time zones Difficulties finding a time to communicate • Lag between time zones • Meeting tight deadlines with this lag •

Slide 5: Issues Communicating context of development Don’t have in-depth knowledge of business • Don’t see rest of system or process • Even systems developers do see may be seen • out of context – simply as code Don’t know how that code is used •

Slide 6: Issues Communicating business needs Need to communicate what needs to be done • with code, not what business needs Solution which may do what is asked for the • individual piece of code may not fit in with business as a whole

Slide 7: Issues Accuracy of specification Need to communicate needs accurately • Specify precisely – which code, what changes, • exact timescale etc. Specification is a contract • Developers work for third party, and aim to • achieve best result with minimal cost (though obviously this is a generalisation)

Slide 8: Issues Robustness of test scenarios Need to test specification • Need to be thorough and precise • Need to clearly draw together business context • and specification Need to be measurable (pass/fail) •

Slide 9: What is TDD? “Test-driven design (TDD) (Beck 2003; Astels 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.” http://www.agiledata.org/essays/tdd.html

Slide 10: What is TDD? “Test-driven development requires that an automated unit test, defining requirements of the code, is written before each aspect of the code itself. These tests contain assertions that are either true or false. Running the tests gives rapid confirmation of correct behaviour as the code evolves and is refactored.” http://en.wikipedia.org/wiki/ Test-driven_development

Slide 11: What is TDD? In a nutshell… From specification, write tests that must be • satisfied for solution to be correct Develop and continuously test solution as • pass/fail, refactor code/tests as necessary Code evolves to meet tests and thus • specification, rather than being fully developed then needing correction

Slide 12: TDD Solution Language barriers Communicate effectively as far as possible • Negate need for understanding “business” • English – develop and test code not whole system business process Misunderstandings clear through failing tests, • and correct solution – whether or not “business English” is required to understand reasoning – is apparent from expected test results

Slide 13: TDD Solution Working across time zones Allows work to be carried out even if contact in • different time zone is unavailable – can work independently and flexibly, clarifying failed tests when both available Development can continue through lag time •

Slide 14: TDD Solution Communicating context of development TDD makes knowledge of business irrelevant • Ignores context – concentrates on which code • needs changing Developer uses tests to indicate if code correct • Test may pass but need to be refined – customer • can redefine test and code can be altered if necessary

Slide 15: TDD Solution Communicating business needs No need to specify if solution is stand-alone or • part of wider process Developer need not understand business need, • but rather applicable parts of code Business need independent of solution – if • solution meets test results, need is met

Slide 16: TDD Solution Accuracy of specification Communicate concisely – specify code, tests, • specification etc. Ensure requirements can only be interpreted one • way, in order to meet tests and thus spec If specification tight and specific, solution is • correct regardless of developers’ interests

Slide 17: TDD Solution Robustness of test scenarios Robust and precise test scenarios required • Tests should only be interpretable one way • Solution draws together business and • specification, but make solution required only a knowledge of code not business Clear pass/fail measurements provide clear test • of whether solution meets tests and thus spec

Slide 18: TDD Summary Tests throughout provide constant measure of • whether solution is meeting specification No requirement for developer to understand • “business English”, process or context Developer must simply understand code • Rigorous elimination of superfluous information • TDD provides clear pass/fail results, and clear • indication of whether code satisfied the solution Without TDD, opportunity exists for solution to be • widely different from requirements Eliminates common problems of development •

Slide 19: Offshore Outsourcing and the Value of Test- Driven Development Guy Rintoul guyrintoul.com