Test Driven Development (TDD) is an automation testing approach to develop high quality product with minimum or negligible quality issues.  Having this approach implemented strategically results in reliability on the product until its retirement.   Initial investment on TDD approach will reap the great results in product maintenance phase and helps to obtain return on investments (ROI) seamlessly.

You might want to ask question, how TDD is different from traditional development methodology?

Unlike traditional or standard development process, in TDD approach, the testing will start at the early stages of the product development and validates the completed activities for the desired output.  Most importantly focus on quality starts at the beginning of the product development rather than at completion.  This gives opportunity to learn lessons quickly and apply best practices in subsequent implementations with the increased productivity.

What are the real challenges with the TDD approach?

• Define work breakdown structure and work breakdown dictionary;
• Define sequence of activities and identify critical path;
• Prepare realistic schedules;
• Prepare cost estimates;
• Getting budget approval.

You might be surprised with the above non-technical list.  Since developer needs to write automation test cases for the completed activities immediately, project manager should plan these efforts meticulously without disturbing the critical path.   Project manager might want to use schedule compression techniques by resource crashing or fast tracking to meet customer deadlines.  In either case, additional budget is required to implement the TDD approach.

Really there is no technical challenge to take up the TDD approach, because several open source tools honor this approach and provides technical support through online forums and blogs.   If you think about TDD, it appears like a unit testing approach, but it’s not!    Using unit testing tool, you can test a specific part of the code segment.  But in TDD, you can perform integration testing and business analysts can verify those test cases at the same time.

FIT and FitNesse are two open source tools allow us to apply TDD principles efficiently and improve communication with customers and business analysts. Framework for Integrated Testing (FIT) is an acceptance testing framework.  FIT improves the collaboration and allow customers and business analysts to write and verify tests.

Writing FIT tests require general programming knowledge. FitNesse is a web-based server, allowing easy collaboration. Business analysts and other non–technical people do not have to set up any software in order to use FitNesse. Any browser will do just fine.

You can find more information about Fitneese at http://fitnesse.org/.

How about making “upgrade projects” as a part of your annual service model and bundle them into operating expenses budget as against capital expenditure spending? Companies who have invested in the right outsourcing models should challenge their vendors to reduce the intensity (or budget) of a typical R12 upgrade project. In other words the spending should be apportioned over 12 months or 24 months annual operating expenses instead of spending “huge project budget”. The ROI to spend significant amounts on functional features versus routine technical upgrades has lot of room for prioritization and spread the risk over several months at the same time get short term benefits. When you look at task level detailed project plans of many upgrade projects, there are at least 40% to 60% of the scope items that can spread over a calendar year or down load them to support & maintenance budget instead going for “project budget”. This will minimize risk for corporations and vendors will have better chances to succeed with flexible implementation schedules for non-prioritized items. Corporations burn huge amounts for expensive consulting hours in figuring out the scope of these projects but focus less on how to minimize the spending patterns to get better and real ROI.

In one of the recent surveys conducted in our webinar, one of the validation for the above concept is when people answered that they are not sure about the ROI as well as no bandwidth in house to start an R12 project. Companies spend millions of dollars upgrading their sytems and budget approvals for such initiatives are tough. People sharpen their pencils with ROI calculations and “how to convince the management” for a “CapEX” (Capital Expenditure Budget) approval. This is inspite of having large IT teams as well as vendors supporting their system in an “outsourcing model”. My earlier blog post mentioned “valuesourcing” as means of getting better ROI and “multishoring” is one of the tools to achieve the real value. Use these tools on your R12 upgrade.