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)

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

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

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

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

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)

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)

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

“ 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

“ 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

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

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

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

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

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

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

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

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