| Introduction |
The test driven development is an approach that focus on capturing the details from the analysis of the User Story in a acceptance test instead of in a functional specification. The acceptance test becomes input to the design and coding of the solution and the user acceptance test.
The necessary development activities depend on a risk assessment of the planned solution.
A simple straight forward solution might only need the writing and review of the test case, coding, and the final run of the user acceptance test before being complete.
A complex solution might require one or more of the activities: writing and review of the test case, design, design review, code, code review, unit test, integration test and acceptance test before it is complete – ‘Done’. |
| Which Tasks Should be Considered in Test Driven Development? |
Test driven development focus capturing the result of the analysis of the requirement in a detailed test case reflecting what is the intended use, then iteratively develop the solution with reference to the test case identifying the tasks needed to develop the solution
| Task |
Description |
| Select a User Story for implementation in the Sprint |
Verify the selected User Story is sufficient specific to be implemented – if there is any uncertainties, consult the Product Owner about the interpretation, eventually arrange a meeting with the requester of the User Story to get a proper understanding.
|
| Create a User Acceptance Test for the User Story |
Based on the User Story an acceptance test case is specified for the successful transformation of the User Story into a ‘Done’ solution.
The test case shall be sufficient detailed to verify the intended use of the solution, e.g. it should mention all data field the user expect to see during use, which fields are optional, any specific type of calculation, etc.
When the test case is finished, the Product Owner or the end-user shall verify the test case is complete and correct – it might be signed, if it is a regulated requirement. |
| Consider a Technical Design |
Based on the User Story and the User Acceptance Test the developper decide if a Technical Design is required, there is usually two reasons for a design:
- It might carry a risk to the proper function of the solution if there is no design, e.g. the solution involve multiple database tables, complicated real-time performance or critical functionality, or other non-trivial design decisions
- It might carry a risk to the effective and efficient maintenance of the solution, you cannot rely on the same person who did the code is also available for maintaining it.
The Technical Design doesn’t need to be finished in all details. When sufficient details for starting code is described, an interim version is stored in the document management system (before starting the first code iteration).For design of a regulatory critical User Story, a comment shall be made by a peer that have checked the design. The comment shall briefly note the the most important specific thing checked, e.g. “The design correctly uses the table “KNB4 Customer payment history” for retrieving data for this report.
For a regulatory critical Technical Design a formal review at the end of design should be considered. |
| Create and Verify Code |
Code is developed based in the following input:
- User Story.
- User Acceptance Test.
- if created, the Technical Design, eventually in an interim version.
During development of the code, some design considerations might be necessary. The Technical Design is then (re)opened and the changes needed to continue implementation is made and a new interim version is stored in the document management system. (see activity above).
The Agile development method involve a high degree of experimenting with the best solution to the User Story, it therefore often involve some kind of “back tracking” when an original promissing solution later appears less promissing. Change management and the use of a tool to keep track of intermediate solutions or versions is strongly recommended as a way get back to a useful version of the code and branch therefrom. |
| Considered informal testing |
Other types of verification and validation activities than the already planned User Acceptance Test might have been decided during the Sprint Planning or is decided based on a risk assessment of the intermediate solution created in the Sprint e.g.
- Technical design walk-through or review, usually relevant if e.g. the design is critical, complex or differ from the design methods the team usually uses, etc.
- code walk-through or review, usually relevant if the code is critical, complex, difficult to test (code include many branches), etc.
- Unit test, usually always considered a good choice, might be a simple test after a proper code review has been performed. Remember: functional test, positive test, negative test, and other relevant types of unit tests.
- Integration test, usually relevant if the code has many dependencies, e.g. many interfaces, call many non-library functions, etc.
For a regulatory critical User Stories some form of documentation of the “informal” testing should be considered. |
| Perform User Acceptance Test |
The User Acceptance Test is performed as often as required, as a way for the person who perform the coding to verify the completeness of the developed code (see illustration above). These interim test do not need to be documented.
The type of needed documentation for the final successful test execution will be stated in the definition of ‘Done’ for the User Story. |
| Perform Change Management |
In the rare case a User Story cannot be implemented in its current form, and it might be necessary to change it if a solution shall be found. This change is handled under change management involving the Development Team and the Product Owner. The Product Owner might involve stakeholder from Business in the decision to change a User Story. |
| Delivery of a ‘Done’ User Story |
The deliverables from the development, User Acceptance Test, other types of tests, Technical Design, Code and Test Execution should be documented and kept under document control.
This is especially important for the implementation of User Stories related to regulated tasks. |
|
