If you don’t ask you don’t get. At least that’s how the saying goes. In my early days in testing I’d ask but still didn’t get. That is, I’d ask for software testing tools to support the test process but never get any.
I used to get very angry about not having any testing tools. I’d compare the software testing teams use of tools to the software development teams use of tools. I’d always see a huge disparity. The development team would have tools coming out of their ears. IDE’s, emulators, modelling, static analysis. You name it, they had it. The reason they got them and we didn’t? Well…
When a software developer approaches the budget holder to purchase software tools the conversation goes something like: “So you’d like to buy a software tool? How much? … Okay, what will it give us?”. And to that the developer says something along the lines of “We’ll deliver the product 2 weeks sooner and we’ll be able to deliver it with all these additional features”. At which point the guy signing off the tool purchase sees the return on investment and waves it through.
Now see it from the test team angle. When a software tester approaches someone for the budget to purchase testing tools the conversation goes something like “So you’d like to buy a tool? How much? … Okay, what will it give us?”. And to that the tester says something along the lines of “Well the quality will improve and it will make our life easier”. To which the reply comes back with “by how much will it improve?” “Err well I can’t quantify that exactly”. At which point the guy signing off the tool purchase fails to see the benefit and tells you to get lost.
After a few years of constant rejection I wised up. I realised it all comes down to selling the benefits. And the best way to sell those benefits for a test team is to write a good business case.
And for that reason we’ll spend the next few weeks looking at how to construct a well written business case for software testing tools.