Selling ourselves to management
The QA test automation group has recently been placed under a "hands off" manager. In our first meeting last week, the topic of "expectations" never came up. The manager has roughly 30+ people under him and there’s really no time for us to communicate what we’re doing. Weekly status reports and one-on-one meetings will not continue with the new management.
One area of concern I have is that my employer really has no expectations on our test automation group. There's no test lead to give us solid direction. The automation test engineers essentially define and drive the efforts.
My question is this: has anyone worked on a team where it is necessary to convince the management that your efforts are a benefit to the company? It seems strange that a grass roots effort is necessary for survival due to little or no direction from management. If anyone can provide specific, real life examples of how they handled this issue, how they succeeded/failed, I would greatly appreciate it!
Re: Selling ourselves to management
OUCH!!! Your in a world of hurt and don't know it (or do and not sure how deep the hole is).
Your right, you will need visibility (as will the other people in the Test group) to the manager and to other groups. You run the chance of "going dark", which means no one can see you.
Keep doing the weekly status reports for one thing. This is your audit trail of what is going on. Even if the new manager does not read them you have them for evidence later on. Cover your butt!
One of you is going to have to step and lead. You need to determine what your purpose as a group is and how best to accomplish that. Build a business plan (projects to do, resources needed, time needed & schedule, and money needed) to accomplish your mission. Show this plan to management and development. Keep things realistic, set the proper expectation (I do this all the time because on my first automation implementation I got burned badly by not setting a realistic expectation). Build out in small manageable incremental steps. Get a quick win situation, like a quick smoke test that helps development prove the build is alright. (I did this once and made a lot of people happy)
As part of doing this keep track of what defects are found via automation and in what part of the cycle they are found. Also, keep track of manual execution time vs. automated execution time. Show how you can improve execution performance for testing. Don't sell it completely as speed, but as economy of time. For example, it takes 4 manual testers 3 days to test [4x8x3 = 96 man hours] where it takes 4 machines 1 day [4x24x1 = 96 machine hours]. This is because the machine can work continously over a 24 hour period, and execute tests at a faster pace. The time to execute may be the same or faster, but the workload is the same. The only other thing to factor in is analysis time for a person to review the logs of the automation execution. (I am currently doing this on a project, my group is showing how using a multple machine approach improves execution performance and the analysts only have to look at output to validate the test run. The analysts are also free to do other tasks while the automation executes, which make management happy because we are getting work done in a timely fashion)
This is the illusion of time savings that automation gives (and is sold by every tool salesman, and incorrectly so). This is only after you have taken the high up front cost of automation (design, setup, proving, and maintaining).
I recommend reading articles by Brian Marick, Brett Pettichord, James Bach and Elfriede Dustin on this subject.
Hope this blather helps.