|
September
2002 Feature Article
|
|
Test Management
by Metrics Managing your resources I have found that the effective utilisation of resources (testers, tools, processes etc) is one of the most exciting challenges on a testing project. Although this is generally seen as a Project Managers role, I see it as normal management. For the purpose of this article I want to apply utilisation of resources to Test Management in particular, and share with you some of the tips I have picked up along the way. (I will make the assumption that the reader is familiar with some previous articles in Test Focus, particularly Risk Management and Requirements Management - if you do not have these then apply for back copies). To be successful I believe in the principle of breaking large tasks into multiple smaller tasks, and, if necessary, breaking those down further (you eat an elephant one bite at a time, or to be appropriate, you test a large system one test case at a time). I view resources in the following categories:
Testers You should have a metric that will let you know how long each testing task should take to complete on average, and then compare this to the actual time it is taking testing staff to complete these tasks (a mature manager will not jump on anyone who is under achieving, but would rather find the cause and prevent this from happening - never use metrics as a stick to beat up on testers). If this is used in conjunction with defect detection rate (remember your s-curves), then you will be able to see when testing is becoming less effective and time for release is approaching. You will thus be able to predict when staff are becoming available to start work on other projects. This issue is also closely related to the following category - achieving target delivery dates. Target Date I am astounded to see the amount of projects that end up planning to work overtime and even weekends. If you plan to work 12 to 14 hours per day including weekends, you will burn your team out. I honestly believe that a manager is being irresponsible by making such plans. If you do not have enough time, then hire more testers. The budget will stay the same due to the amount of overtime being paid and your testers will be fresh and productive. This metric is carried out by means of a simple spreadsheet that is based on an 8 hour day, which will be mapped against the total time left to complete the testing task. (i.e. total time required to test / 8 hours = number of testing days required, which is then divided by the time left to achieve target date = number of testers required). If for example you need 560 hours to complete the testing task, but only have 10 working days to target delivery date … 560 / 8 = 70 testing days, 70 / 10 working days to delivery date = 7 testers required. |
Even though the solution is so simple, I still see this problem all the time. In addition to this, managers who bring warm pizza or hamburgers for their team at 3am think they are rewarding their staff - WRONG - warm pizza is no substitute for being away from your family. Testers are human. Look after them and they will remain loyal. There is a difference between emergencies and bad planning. At the end of the day you will end up with disgruntled staff who will leave your team at the first available opportunity. It is highly important for managers to protect their testers from being exploited by not so good project managers. If you need more testers then consider using contractors, but only for the period required. You can check this by simply plotting a graph that will indicate the average hours worked per week (should be 40) and use this as a basis for controlling projects that are out of control. An additional benefit of conducting a Risk Analysis and Prioritisation exercise is that if there is insufficient time to test all requirements, then the highest risk issues (from both business and systems perspectives) can be addressed first, and then the lower risk requirements until time runs out. Infrastructure As you have to control your human resources, so you have to control your infrastructure (hardware, software, tools and office equipment). By carefully tracking testing projects as they move into and out of your testing environment, you will be able to better limit the amount of equipment that will have to be used at any time. I have seen some large labs with oodles of PC's, networks, printers etc and yet these labs are empty for long periods (a lab that is not used for a working day, is a waste of funds). If you measure the time that projects actually spend in test execution vs test planning and design, you will find that only 25% of the time on average is being used (i.e. your equipment is not being used 75% of the time). If you get projects to book test time you will be able to limit the amount of equipment (but please make this judgement with the objective of also representing the operational environment - manage the risks and then act when it comes to purchasing equipment). If you have any queries or would like to contact me in connection with your own metrics efforts, you can email me at info@testfocus.co.za.and mark it for my attention. Peter Sage |
<< August 2002 |
October 2002 >> |