Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

Let's say you are a developer (specifically, the team lead) and you want to improve the quality of your company's products. Since you cannot change the whole company, you focus on what you and your fellow developers can do to enhance the quality of the applications you create/maintain. You decide that this can best be done by embracing TDD for class verification and FDD for integration testing.

Since we are talking about .NET development here, let's be specific and use:

  • MSTEST as a unit testing framework for the TDD
    As a development house you already use TFS 2010 so the MSTEST solution is a given with its integration of code coverage and test pass validation at check-in.
  • SpecFlow for the FDD
    SpecFlow is more subjective, but I propose it as a FDD tool as it integrates well with VS 2010 and source control, and the gherkin/cucumber syntax is, I think, easier than that of Fitnesse.

Moving from "coding with ad hoc testing, followed by a release to QA" to a "TDD/FDD" approach will save time and money over the life of an application—but, it will extend the time a program spends in development over the ad hoc approach (although arguably the QA time should reduce as QA should then mostly find system test faults rather than those and integration and class bugs devs now find and fix sooner).

Assume some minor TDD/FDD projects have already been completed so your company is not overly nervous about the technology, but have yet to "go for it" with a full size project.

But in this business, development is a different cost centre from QA, and both are different from support and operations.

So, how do you sell the benefit to the company of adopting TDD/FDD to development managers who are held to account for the increased cost (i.e., time) of the development department?

This, to me, is all the harder given the benefits of failing early, etc. seem largely unquantifiable.

How do you go about winning hearts and minds on the topic?

share|improve this question
add comment

2 Answers 2

up vote 6 down vote accepted

One of the realities about corporate politics (I hate to say it, but it's a big part of our job) is that everyone wants to put out the image that they're open minded and willing to do what's best for the company, but in reality most people want to go with what is safest for their career and with what they know and are comfortable with.

< tangent > If you're familiar with the movie A Few Good Men, you know the famous "You can't handle the truth!" scene. The Colonel ends up getting caught by saying one thing, and having actions that contradict it. While I don't recommend you go yelling at each other like they do in that fictional courtroom, I do think a lesson can be gleaned from it. < /tangent >

I would ask the question What would it take for your confidence in TDD to warrant trying it on a large scale project? If you can get them to give you some criteria to meet, then you have something to aim for. Go, meet those criteria (you may find you actually already do!) and then come back and say that you have fulfilled the trial criteria, and in your estimation your team is ready to test the waters on a bigger project.

If they can't give you a straight answer why to not go for it, they're simply xenophobes and honestly you can't expect their minds to ever be swayed. At that point, it's time to have lunch with a VP (with some case studies, including internal success) or time to fire up Petes_resume.doc.

share|improve this answer
add comment

"it will extend the time a program spends in development"

Initially, this may be true but as the software matures and becomes more complex, the TDD approach will actually reduce the time a program spends in development since the code-base will be more robust, easier to maintain and less prone to bugs.

Once you have good unit test code coverage and a full suite of acceptance tests you have effectively defined the "behavioural boundary" for your software. Any developer who breaks this behaviour during later development will be alerted to it immediately in a TDD / Continuous Integration environment.

Being alerted to bugs almost instantly (Failing Fast) is a huge cost saver for the software industry and one any development manager worth his/her salt should be very interested in hearing about.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.