Offshore Outsourcing and the Value of Test-Driven Development

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
Difficulties finding a time to communicate
Lag between time zones
Meeting tight deadlines with this lag

Issues
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
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
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
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
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
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
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

http://www.slideshare.net	19
http://www.incredibleslideshows.com	10
http://lanyrd.com	5
http://all-for-women.com	4
http://www.linkedin.com	2
http://database.cd	1

Offshore Outsourcing and the Value of Test-Driven Development

by Guy Rintoul

Accessibility

Categories

Upload Details

Usage Rights

6 Embeds 41

Statistics