Test-Driven Equals Quality-Driven. Develop ATDD Skills.

Manufacturing industries learned long ago that it’s better to prevent problems than fix them. That’s one of the basic tenets of being lean. Fixing problems is expensive and wasteful. Preventing them isn’t cheap but it’s less costly than fixing.

It seems that many in the software industry haven’t figured this out yet.

Software defects shouldn’t be allowed to reach system integration testing. Defects at the module or user story level need to be found and fixed within iterations or sprints. That’s where Acceptance Test Driven Development (ATDD) shows its value.

Here’s a brief comparison of how software is tested in a traditional (legacy) software project versus a newer agile approach like Scrum, Kanban, Lean or XP. The key differences are not in what gets done, who does it, or where it happens. The keys lie in when the testing gets done and how it gets done.

Here’s how the traditional software implementation and testing process works.

1. Write technical specification(s) for the software component.
2. Obtain specification approval from management.
3. Write the functional source code.
4. Test the functional code using manual techniques (or sometimes not).
5. Modify the functional code and repeat the tests (or not).
6. Submit the functional code to QA for formal testing.
7. Wait for QA to test and report problems at some time before the project ends.
8. Fix the problems reported by QA.
9. Update the specification(s).
10. Re-submit the functional code to QA.
11. Wait for QA to re-test and report problems.
12. Repeat 8-11 as often as needed to pass QA

Here’s how an ATDD process might work.

1. Select a user story and discuss the acceptance test criteria with the team.
2. Write the testing source code first. (Automated testing is the norm not the exception.)
3. Write the functional source code.
4. Run the tests against the functional code.
5. Modify the functional code until it passes the tests.
6. Refactor the functional code as needed. (There is no refactoring in the traditional approach.)
7. Re-run the tests.
8. Handoff the functional code and the test code for final verification during the sprint.

Notes:

• The quality of the acceptance tests is crucial. Discuss them in depth.
• The acceptance tests will focus on user behaviors. The test code needs to cover system behaviors as well.
• Use an automated testing tool to minimize the ‘how do I test the test code’ problem.
• Take time to refactor immediately. Minimize technical debt.
• Large projects will need to aggregate tested components and perform system integration testing prior to deployment.