Start a spreadsheet that shows lines code, number of tests, total test execution time, and number of bugs, and track this with every release. The numbers will defend your investment.
These high level steps show how to capture metrics over time:
- Create a spreadsheet to track number of test cases, time to run test suite, date of test run, bugs, and average time per test.
- Check the spreadsheet into your code base as another controlled artifact.
- Add some graphs to show the curve of test time versus test quantity.
- Add a new row of data at least every time you do a release. If you can capture data more often, like once/week or even once/day, that is better.
As you write more tests, the test suite will take longer to run. But you will also find that the number of bugs tend to decrease. The more testing you do, and the more often you do it leads to overall code quality. Capturing the metrics of your testing can act as hard evidence that the time spent writing and running tests is a well-placed investment.
Why do I need this document? Don't I already know that testing works? Think of it as a backup for your assertion of quality. Months down the road, you may be challenged by the management to speed things up. Maybe they need something faster, and they think you are simply spending too much time on this "testing stuff".
If you can pull out your spreadsheet and show how bugs decreased with testing effort, they will have little to argue with. But if you don't have this, and simply argue that "testing makes things better", you may lose the argument.
I personally enjoyed seeing the tests grow and the bugs decline. It was a personal way to track myself and keep a handle on how much progress was made. And to be honest, my last manager gave me full support for automated testing. He had his own metrics of success, so I never had to pull out mine.