• Save
Offshore Outsourcing and the Value of Test-Driven Development
Upcoming SlideShare
Loading in...5
×
 

Offshore Outsourcing and the Value of Test-Driven Development

on

  • 19,212 views

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

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

Statistics

Views

Total Views
19,212
Views on SlideShare
19,163
Embed Views
49

Actions

Likes
11
Downloads
0
Comments
0

9 Embeds 49

http://www.slideshare.net 19
http://www.incredibleslideshows.com 10
http://lanyrd.com 7
http://all-for-women.com 4
https://twitter.com 4
http://www.linkedin.com 2
http://database.cd 1
http://pmomale-mn1 1
http://pmomale-ld1 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Offshore Outsourcing and the Value of Test-Driven Development Offshore Outsourcing and the Value of Test-Driven Development Presentation Transcript

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