Many agile projects go beyond what’s defined in the official guide and implement additional features such as Refinements. Among the popular project artefacts that are not ‘official’ but very common are a Definition of Done (DOD or DoD) and—just slightly less common—a Definition of Ready (DOR or DoR). What’s also very popular in software engineering is Test-Driven Development (TDD), i.e. the idea to let tests guide the development process by first implementing them, letting them fail, and then implementing the actual feature, which would then turn green more and more tests.
TDD itself can be implemented in a variety of ways. For example, it might be that test definitions are supplied by stakeholders other than the developer who actually implements the requested feature, e.g. business analysts or testers. It might also be the case that that developer himself writes the tests that cover ‘his’ feature. The latter is a far more common pattern, I’d say. It might also be that TDD is done as described in the workbook: Define test cases; implement them; let them fail; implement feature. In contrast, the developer may implement feature and test in conjunction or even in reversed order. As above, this latter approach also seems to be more common, at least based on what I experienced.
Now, the DoR, if present in your agile project, is an excellent lever to ‘enforce’ TDD proper, especially if intertwined with your issue tracker. Here is how: You’d set up a field in your User Story (US) issue type that reflects test status. ‘Testing not relevant’, ‘Needs to be tested’, ‘Test definition in progress’, and ‘Test definition complete’ are candidates for such states that come to mind. Ideally, you now technically block the status transition of the User Story from New/Backlog to In Progress for any test status other than ‘Testing not relevant’ or ‘Test definition complete’. In your DoR, you define the Ready state of a story accordingly. In your process definition for testing activities, you’d make sure that ‘Test definition complete’ may only be reached if there is a link from the US item to its corresponding Test Case item.
You thereby make sure that:
1. It is both technically and procedurally impossible for a developer to start working on an item without knowing what minimum test activities a piece of code would be confronted with.
2. There is always a test case available for manual execution once a story is being handed over to testers. There can’t be any additional bottleneck for test definition or test implementation.
3. Testers and developers work more closely together, as testers might need to take into account the developer’s options for implementing component tests and developers might raise questions regarding the tester’s ideas documented in issues linked to each story.
In that way you encourage everyone to have as much clarifying discussions as possible upfront. You thereby slow down the progression of a user story in the early phase of its lifecycle. However, you gain significant advantages in its later phases: quicker testing; reduced likelihood of in-sprint bugs; much smoother sprint throughput; overall higher product quality.
No responses yet