My previous post on Test Driven Development described its usefulness in a software development project. In this post, we will try to explore its utility beyond that - more specifically to projects relevant for services, and the service delivery itself. Our context of discussion will be limited to an instance, where a particular service delivery process is being setup, i.e. a project, and subsequently the service delivery. Before getting there, let's recap the principle of Test Driven Development once more: TDD is an approach that emphasizes the development to be done in a way so that the developed work product becomes just fit enough to pass through the test devised for it.
Now, let's think of setting up a process or a set of processes for a specific service delivery. Normally, we try to take a look at the existing set of processes that deliver identical or similar service(s) and then we try to replicate those processes. After replicating the processes, or establishing those with some modifications, we try to produce the work product using that setup. During this trial, we review each process block and verify whether the work products coming out it are matching up to the spec. Once we see the output of the new processes conforming to the specification, we put those outputs to tests. If the tests pass, voila! If not, let's go back to our own drawing board and try to find out the point of defect injections.
Test Driven Development approach would not challenge this method of setting up processes, though would offer a different variant. Instead of trying to match each output of each process block, it would emphasise the need to test the outputs first. In essence, the specification would be superseded by the test cases. The objective of the project manager responsible to setting up such a service delivery process would then focus on obtaining the test cases instead of the specifications.
In reality, this would make the job simpler too. Quite often, specifications go missing, even if they exist they are found to be dated, no similarity with the processes and steps running on ground. Re-writing the updated processes may become a tedious task. Moreover, the people possessing the latest knowledge may not be treating this as a priority work. They may not be willing too. Test cases, on the other hand, are easy to find in its updated form. Even if it is not updated as a documentation, involving the relevant people to perform the tests would ensure that the outputs are tested using recent updates. Moreover, an observer during testing can document all the quality checks and tests performed on the output and subsequently produce an updated test case documentation.
The problem would not end there though. This approach would bring out the test cases for the final work product, not necessarily for the interim. For the interim test cases, separate effort needs to be commissioned, and the present process owners may not be able to help here. So the approach would be to involve all the team members to understand the end work product, irrespective of the processes they are assigned, and to go through the final test cases even if their work product would not be subjected to that, so that they can apply their minds while doing their bit of the processes to strive for passing the final test. Once the test defects are identified, all the team members need to go through that defect through a common session/meeting, and do a causal analysis together. This would ensure that everybody understands the injection points for each of such defects. The collective learning would be harnessed at a later point of time to document the test cases corresponding to all interim work products.
Once the final work product passes through the final test cases, the service delivery process(s) is ready to roll. At this point of time, the team members would continue to follow the same set of steps they had done to pass the test. Simultaneously, the test cases for all the interim work products should be documented. Once that documentation is complete, the focus should shift towards passing through the interim test cases instead of trying to clear the final set of test cases. Passing through all the interim test cases would improve the probability of passing through the final test cases significantly. At the same time, the process specialist must work to establish a good degree of traceability or linkages between the test cases; between final and interim as well as between interim and interim.
As the service delivery progresses, there comes the changes. Broadly, the changes would come in two types: change in the product specification, or the change in the internal processes due to some improvement and optimization. A change in the product specification would call for a change in the final set of test cases. New test cases would get inserted, existing test cases would get deleted or altered. Using the traceability matrix, the impacted interim test cases should be identified and modified. Similarly, for the change in internal processes due to some improvement and optimization would also require change on the test cases relevant for those set of the processes. It would also require to verify and update the linked test cases as appropriate. Once done, the new set of test cases should be used for testing the final and interim work products. This change activities are to be performed by the team members only, so that maximum buy-in can be ensured, and the team members would also get an opportunity to prepare themselves to produce the new work products for passing through the new test cases.
In summary, there is room for reaping benefits by implementing a test driven development approach for a non-IT service work. However, TDD should not be taken as a replacement of classical way of setting up processes. There is no substitute of process design, setting up processes by thorough documentation of steps, determine and optimize the critical path and critical chain, encouraging the team members to perform work through the documented steps, and performing the self review through a checklist. A Test Driven Approach would help the entire service delivery to excel in quality, and to encourage the team to make the processes leaner by identifying the unwanted steps. Finally, even if it is part of Agile practices, it requires tailoring based on where it is to be applied.
No comments:
Post a Comment