Your SlideShare is downloading. ×
Offshore Outsourcing and the Value of Test-Driven Development
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Offshore Outsourcing and the Value of Test-Driven Development


Published on

By Guy Rintoul ( for BarCampLondon2 (17-18 Feb 07) ... liable to slight alteration

By Guy Rintoul ( for BarCampLondon2 (17-18 Feb 07) ... liable to slight alteration

Published in: Business, Technology

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Offshore Outsourcing and the Value of Test-Driven Development Guy Rintoul
  • 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)
  • 3. Issues
    • Language barriers
      • Often based in India, Poland etc.
      • Communicating ideas effectively
      • Don’t necessarily speak “business” English
  • 4. Issues
    • Working across time zones
      • Difficulties finding a time to communicate
      • Lag between time zones
      • Meeting tight deadlines with this lag
  • 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
  • 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
  • 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)
  • 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)
  • 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.”
  • 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.”
    • Test-driven_development
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 19. Offshore Outsourcing and the Value of Test-Driven Development Guy Rintoul