September 14, 2015 | Author: PM Hut | Filed under: Agile Project Management
Test Driven Development (TDD) – An Instrument to Deliver Projects More Efficiently
By Ambadapudi Sridhara Murthy
Projects have been moving at a very rapid pace since the past ten years and everyone has been talking about quicker delivery, early dispatch of product and short project completion schedules. While projects have been completed and the respective products have gone-live and are being used in production, based on the outputs/results/maintenance of the products developed and being used – there has been a sort of feedback thinking that has been around for some time now which hints at “what could we have done differently to provide a more efficient product or solution?” Almost every team and/or organization which have been dealing with continuous development of existing products or with maintenance of old products/software’s come across this efficiency question every now and then as part of their improvement strategies. Depending upon the type of the organization, product, process, complexity and other similar factors, there might be a variety to proficient ways in which a more efficient product or solution can be developed when compared to the one that is already in use. Speaking specifically about software development projects that span across a wide variety of industries, applications, functionalities and source code bases, “Testing” or “Testing Phase” or “Testing Stage” across the project could be a vital component that can really change the wind of product quality and efficiency from good and better to Excellent and Outstanding when viewed from a broader perspective. This article throws light on the approach of how the tools of “testing” and “test driven development” be used to help project teams and managers to develop and deliver quick, effective and efficient solutions without losing the profitable cost window of project/product solutions.
What is “test driven development”? How and when can it come-in as part of the product/project cycle? What is the value-add for the product/project/solution being developed due to the inclusion of the “test driven development”? These are the sort of questions that we would get from anybody in the first instance as soon as they hear about something new like “test driven development”. Great Questions- aren’t they?
Normally, everyone expects that testing on any product/solution happens after the solution is developed. Issue are found as part of testing, then fixed, retested and then again fixed if issue re-occurs or if new issues are found. This cycle sometimes goes-on for extended periods of time and hence organizations/teams set some checkpoints/standards till which point this testing/fixing cycle should go-on and when can it be called ‘a day’ so that the product can be assumed to be completely tested and ready to be released to the customer/market. Now, what happens if we think in the reverse direction? Can we not use the classic testing principles prior to start of development? Will that not help us in streamlining which features can be developed independently and tested in one go? Can these principles not help in the breakdown of the overall requirements into design/development of smaller chunks of working pieces that can be tested independently and then integrated to form a final product/solution? I would say, “yes”, it can. Listed below are some of the advantages of how this “test driven development” can add value to the various stages/phases/roles during the course of product/project requirements, design and execution.
During Requirements and Design
Typically, the requirements phase is mostly used to understand the functionalities needed by the customer and then taken forward by the project technical team to go ahead with the architecture and the design needed to implement the given requirements. The testing team is given the set of requirements and asked to prepare the high-level test cases or test scenarios based on the design considerations or approaches put forth by the project technical team. In this case, sometimes, we tend to under-utilize the skills of the testing resources and they are in some way enforced to follow a given functional flow and prepare their high or low level test scenarios. However, in “test driven development”, we throw open the imaginary wings of the testing team and seek their inputs on how the given set of requirements be broken down into smaller functional features without hampering the importance, process-flow or much-needed logic to be built-in into the product. It is here that the breakdown of the features happens from a “testing” perspective rather than from a design perspective. Nevertheless, the features breakdown now happens from an end-user perspective wherein blocks or pieces of product will be decided and developed keeping the product utilization, effectiveness and efficiency at a maximum level to enable the end-user a smoother transition for getting acquainted with the new/upgraded product being developed. This also ensures that the each piece of the product is treated as a “working black box” right from beginning which in-turn ensures that feature functional risk is automatically restricted to a minimum level.
The tricky part is when the project/product moves into the design phase – it is here that the testing team is in the “driver’s seat” which together in collaboration with the customer/end-client and the technical team present the final functional flow (as per the requirements) for each of the functional pieces and the overall functionality/product as a whole. This does pose a challenge to the project technical team wherein the architecture/design needs to be modeled to meet the functional flow requests defined by the testing team per the needs to the customer requirements. However, the functional supply and quality that will be resulted from this approach could far outweigh the delivery resulting from any other traditional approach.
During Project Execution
The steps taken in the requirements and design phase make life a lot easier during the execution phase – since the previous phase already defines the various building blocks/chunks that will be developed and also the series in which these blocks will be built. This lays the foundation for the technical team as they now have clarity on the pieces that need to be built first and also on the process flow that governs the piece/functionality that is being built. By doing so, the project team gets precision on what they are developing/building and for what purpose – since the testing team would have already documented the process flow/functionality flow as part of the “working black box” theory during the requirements and design phase. This documentation also explains what functionality the first piece of the product/project will contain, what will be functionalities coming across in the next releases and how will the next set of functionalities being developed be integrated with the previous release version to release an enhanced product in the next release. Looking at it from a higher level, we can clearly see that at all stages/sub-products of the execution post the first release, there is always a working version of the product with one or more subsets of the overall functionality desired in the product/project. This also ensures that the product is tested-in-full for a particular functionality (that is already developed and released) at any point in time and also ensures that a re-check or a regression happens on this the next time round when this same functionality is anyway included as part of the enhanced next release. To sum-up, this enforces an iterative process wherein new working pieces are added on top of existing working pieces to create a “bigger” working piece which also aligns with a progressive approach of building/developing a product in such a manner that each release can be tested and sent across to the customer for demos/verification. This is the main add-on value that test-driven development adds to the execution of a project/product – since, in a general scenario, teams tend to develop product/functionality/feature/project requirements without a proper structure or progressive functionality planning which eventually leads to the development/testing teams spending more time to fix unknown issues that crop-up at multiple stages and also hamper the overall connectivity of features/product thereby impacting both quality and project costs. Test Driven Development overcomes all of these hassles as the product-build planning process is completely structured and organized as individual working blocks thereby ensuring that a high-quality ready-to-test product/functionality is available at all times during the project execution paving the way for a smoother and cost-efficient product/project delivery to customer.
In summary, Test Driven Development is a prominent tool that if used and implemented in appropriate projects, can help with the best integration of requirements, design and testing, support in eliminating fears of application development, create a structured and organized structure for progressive product/functionality development, drives for a superior enhancement in quality, can significantly reduce costs and rework and ensure highest level of customer satisfaction because of its “working black box” theory which guarantees that the customer always has a running functionality product at all times during the entire course of the project.
Ambadapudi Sridhara Murthy, M.Tech, PMI-SP, PMP has extensive experience in the fields of software project planning, scheduling, risk management, budget management, vendor management, contract management, execution, tracking, monitoring, controlling, quality assurance, and on-time delivery. He has delivered projects over a wide range of domains, such as Leak Detection Software, Semiconductor software, implementing desktop/mobile websites, and Bio-Information Management Systems, in addition to the field of software services.
This entry was posted on Monday, September 14th, 2015 and is filed under Agile Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.