“Test Driven” Development for non-programming related tasks

Lately I’ve been toying with the idea of applying the concept of Test-Driven Development to development methodologies for  non-programming related tasks.  Test-driven development (TDD) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions.

It strikes me that pre-written test cases could lead to a more successful new technology or process implementation.  For example, we are currently working on a project to introduce a new technology into a sophisticated telecommunications network.  Without getting into too much detail, this technology could dramatically lower the cost to deliver telecommunication services under a certain scenario.

What would the equivalent of “Test-driven” development look like in that scenario?  First, we need to define the “unit” that we are testing.  For this example, the unit of functionality we would like to test is that the technology can be deployed to 50% of our customer base.  This is a critical assumption and worthy of such a test: If the technology cannot be deployed to at least 50% of our customer base then we would either have to scale back our deployment or even discontinue the project.  On the other hand, if we find that we can deploy to greater than 50% of our customers we may have an opportunity to expand deployment and achieve even greater benefits than expected.

Let’s step through a typical test-driven development process to see how a this methodology would be applied in the example above:

Step 1 – Write tests

In test-driven development, each new feature begins with writing a test.

For our project, the equivalent of a “test” would be to develop a query in our databases that determines if 50% of our customer orders are being successfully deployed on the new technology.  The benefits of preparing this query ahead of time is that it forces us to think about how we would measure and track this information – something that is often neglected in implementation projects.

Step 2 – Run the test and see if it fails

In software develop the first test fails because the code to pass the test hasn’t been written yet.  Test-driven development forces a programmer to think about what a unit of code will produce before actually writing the code.  This leads to better code and a more productive programmer.

For our project, running our query ahead of time also fails because we have not yet deployed the technology.  However, to prove the concept we could run a query on a similar technology to test our assumptions.  Having proving our assumptions we are not only more confident about the potential success of the project but we also now have a query ready for the next step.

Step 3 – Write some code

In this step the software developer now writes the code that will make the test pass.

For our project, we would deploy this new  technology a test environment – first in the lab and then in the field under a controlled environment.  We now have all the pieces in place to run our test.

Step 4 – Run the tests and see them succeed

Running and passing a test in the software world proves that the code works.

For our project, we would process some test orders under different scenarios to demonstrate that indeed at least 50% of our customers could be deployed on the technology.  Having completed this step in a lab and out in the field we’re now ready to deploy the service to real customers.  We continue to run this test, i.e. running database queries to determine, if indeed, at least 50% of our customers are being deployed with the new technology.

Step 5 – Refactor code

In software development the programmer now cleans up the code as necessary, removing any unecessary duplication.  By re-running the test cases, the developer can be confident that refactoring is not damaging any existing functionality.

In our project this is where we have an opportunity to improve the deployment of the technology.  For example, perhaps we can achieve far greater that a 50% deployment by changing the way we use the technology.  If so, we could revisit the original business case and seek additional benefits.

This is a step that is often left out in non-programming related projects.  We deploy some sort of new process or technology and neglect to follow-up afterwards.  Maybe the process or technology isn’t achieving the benefit we expected?  Or maybe it’s even better than we expected and could be deployed on a larger scale then originally intended?  Either way, it’s important to “refactor” to ensure we are achieving the greatest benefit possible.


In software development, the programming starts over with another new test, and the cycle is repeated to push forward new functionality.

For our project this also makes sense: customer demands change; new technologies are introduced;  we would prepare a new “test” and follow through with introducing the new functionality following steps 1 through 5 above.

Applies to more than just technical tests

The same principles for test-driven development would also apply nicely to testing expected cost benefits.  For example, our business model assumes that the successful implementation of our project would result in a 75% reduction in customer access costs.  But how do we know that we are achieving those results without preparing the appropriate “test” ahead of time?  The answer is that you won’t unless you have developed a way to measure the expected financial benefit and have deployed the appropriate test to ensure the expected benefit is being achieved.


The application of “test-driven” development methodologies translates nicely to other non-programming related development tasks.  It introduces a new way of thinking: clearly understanding the expected benefits of a project and definging a way to measure those benefits before implemention.  Not only should it result in more successful and cost-effective project implementations, but it should also result in a more productive and content project team.


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: