Slashdot Mirror

← Back to Stories (view on slashdot.org)

How Do You Prove Software Testing Saves Money?

Posted by samzenpus on from the taking-it-for-a-test-drive dept.

cdman52 writes "I work at a small software development company. We have one app that is used by a few hundred clients and was initially developed by a few undergrads about 10 years ago. The app is collection of about 25 developers preferences and ideas. Testing wasn't an initial concern since it was created as an internal application, I guess. Anyway, the app is now large and used frequently. Part of my duties are to fix bugs users find, I'm on a team with a few other people and at least once every 2-3 months I see some bug I fixed come back, and I can only assume it's because we don't have a formal test suite. The owner doesn't want to invest time or money in getting one set up, but I'm sure that in the long run it would save time and money. Can anyone offer suggestions for how to convince the owner that setting up a test suite is in his own best interest?"

3 of 312 comments (clear)

  1. First things first by Anrego · · Score: 5, Insightful

    Can anyone offer suggestions for how to convince the owner that setting up a test suite is in his own best interest?

    Are you sure that it will be?

    but I'm sure that in the long run it would save time and money

    How much time and how much money?

    What you need here is hard numbers to back up your opinion. Specifically, and I hate to say the word, but you need metrics.

    - How much do these bugs cost (these are a mixruee of hard numbers (dev time, etc) and "fuzzy" numbers (customer relations and so forth)?
    - How much is setting up this test suite going to cost? How much is it going to cost to use it?
    - How effective do you think it will be (look at existing bugs.. would they have been caught)?

    That last one is especially important. Testing is good, but it doesn't solve all problems and there are other options. Really take a good look at whether previous bugs would have been found in your proposed system.

    Once you have this information, the math then becomes pretty simple.

    If your program is modular-ish .. it might be possible to do a trial. This is probably a good idea anyway. There are different ways to do testing, some of which are incompatible with certain development mindsets. Best to find that out early on a small piece vice the entire code base.

  2. start small by sugarmotor · · Score: 5, Insightful

    Just start small, with "failing tests" for each new bug. Bug fixed, test passes. Keep expanding the test coverage.

    --
    http://stephan.sugarmotor.org
    1. Re:start small by VirexEye · · Score: 5, Insightful

      +1 to moding parent up.

      You won't get far convincing a product owner that you should spend months writing tests for the entire system.

      Convincing someone that you should write unit tests for all new functionality to help guarantee the bug fix/new feature will continue to always work into the future is a much easier sell.