3 ms·

I'd love to see an article on unit testing that gives reasons they add business value, so hackers like us can convince pointy headed bosses that we should be al

by davedx 15y ago

I'd love to see an article on unit testing that gives reasons they add business value, so hackers like us can convince pointy headed bosses that we should be allowed the budget to write them. "Improving the quality of our software" is the one I tend to use, but it's so vague. How will unit testing convert into cold, hard cash is what upper management want to know.

wccrawford 15y ago
Sadly, like marketing, it's really hard to give definites with testing. Or any other good programming practice, for that matter. The best you might do would be to come up with examples of people who used unit testing and things came out beautifully because of it. Things rarely turn out that beautifully without testing, so it can be pretty convincing to anyone who has dealt with software development for any length of time.
coecoventures 15y ago
It's hard enough to convince them faster computers add value. It's almost like they have never heard of the concept of Return On Investment. It's all about cutting costs and not about increasing profitability. We resorted to being very vocal about how much time they were paying us to sit and wait. Our non-tech wrangler got the picture.
ZeroMinx 15y ago
I've seen a lot of this.. I don't believe in it. You don't give reasons for using an ORM in your code, do you? You just do it as part of your development work. It's nothing that's being questioned by PHB's. Writing tests is (or should be) part of your development work. Make sure you include the time it takes to write the tests in your "time estimate".
chsonnu 15y ago
If you have a dedicated QA group, you can say it will decrease the amount of time QA spends on regression testing.
raganwald 15y ago
Feigning incomprehension, I will ask, “Why do you need budget to write them?” If I am estimating how long the work will take, I am estimating how long it will take to get the functionality working correctly with X% confidence it works correctly when the product ships. Unless “X” is less than 50%, automated testing is part of writing the code, not a nice-to-have. “Improving the quality of our code” does sound vague, kind of like arguing how many knots are permissible in a plank of wood destined or a kitchen floor. Instead, I would simply explain that these tests I write are part of writing the code, and to explain that if management want the code without the tests, they need to tell me in writing that they are ok with a confidence level hovering around 50%. I am not kidding about this number. I may deliver code that appears to do what it is supposed to do, but my experience is that either it is broken in ways that a simple QA test doesn’t show, or somebody (somebody else or even me next week) is going to regress it between now and when the product ships. Automated tests give me the confidence that it works, works correctly, and will continue to work correctly.
- cdcarter 15y ago
  "kind of like arguing how many knots are permissible in a plank of wood destined or a kitchen floor" Having sat through an hour long lecture on lumber grades in a scenic construction course, let me tell you, it is anything but vague.

by davedx 15y ago

wccrawford 15y ago

Sadly, like marketing, it's really hard to give definites with testing. Or any other good programming practice, for that matter. The best you might do would be to come up with examples of people who used unit testing and things came out beautifully because of it. Things rarely turn out that beautifully without testing, so it can be pretty convincing to anyone who has dealt with software development for any length of time.

coecoventures 15y ago

It's hard enough to convince them faster computers add value. It's almost like they have never heard of the concept of Return On Investment. It's all about cutting costs and not about increasing profitability. We resorted to being very vocal about how much time they were paying us to sit and wait. Our non-tech wrangler got the picture.

ZeroMinx 15y ago

I've seen a lot of this.. I don't believe in it. You don't give reasons for using an ORM in your code, do you? You just do it as part of your development work. It's nothing that's being questioned by PHB's. Writing tests is (or should be) part of your development work. Make sure you include the time it takes to write the tests in your "time estimate".

chsonnu 15y ago

If you have a dedicated QA group, you can say it will decrease the amount of time QA spends on regression testing.

raganwald 15y ago

Feigning incomprehension, I will ask, “Why do you need budget to write them?” If I am estimating how long the work will take, I am estimating how long it will take to get the functionality working correctly with X% confidence it works correctly when the product ships. Unless “X” is less than 50%, automated testing is part of writing the code, not a nice-to-have. “Improving the quality of our code” does sound vague, kind of like arguing how many knots are permissible in a plank of wood destined or a kitchen floor. Instead, I would simply explain that these tests I write are part of writing the code, and to explain that if management want the code without the tests, they need to tell me in writing that they are ok with a confidence level hovering around 50%. I am not kidding about this number. I may deliver code that appears to do what it is supposed to do, but my experience is that either it is broken in ways that a simple QA test doesn’t show, or somebody (somebody else or even me next week) is going to regress it between now and when the product ships. Automated tests give me the confidence that it works, works correctly, and will continue to work correctly.

cdcarter 15y ago
"kind of like arguing how many knots are permissible in a plank of wood destined or a kitchen floor" Having sat through an hour long lecture on lumber grades in a scenic construction course, let me tell you, it is anything but vague.