How to Convince management that a specific product training is important to QA?

Question

I am leading a QA team of 10 people. we have been received the request for a training of a ETL dataware housing tool for QA, Support and Development. But however the management does not feel that it is important for QA to be involved in such a training as it is support and development team who will be involved ih developing or fixing the issues in the product.

How do I convince the management that this training is very important from the QA perspective as this is the team that will find bugs and which will reduce the maintainance cost?

Answer 1

How do I convince the management that this training is very important from the QA perspective as this is the team that will find bugs and which will reduce the maintenance cost?

I'd suggest taking the approach of asking how much of a cost will be incurred by QA and development having to spend time to build up QA's expertise in this tool that could be reduced by the training. QA has to know how the tool will be used which if done in a trial and error fashion could be rather expensive if there is a lot of time spent tracking down answers about how something could be used.

Something to consider though is what is the cost to the company in having QA do the training? If the training is done on the company time and the average QA person is being paid $15/hour, given an 8 hour work day and the training is 2 days that cost is $2400 just to pay the employees. Add the cost of the training and possible transportation costs if the training is done off-site and you have to show how this is a good investment for the company to make. Why is doing this such a good idea? Well, the expertise QA could gain would make the testing be more efficient and effective resulting in a higher quality product initially.

Answer 2

Have a talk with the management centered around,

1. How do they expect you to QA the tool without training? (May be they have something in mind that has not come out yet. May be they don't want QA)
2. Talk to them about the general benefits of QA - give them an empirical list of issues you have identified in the past and their approximate $$ value.
3. Wait for the developers to slip in a costly bug:)