|
June
2002 Feature Article
|
|
Test Management
by Metrics Using S-Curves to take Corrective Action Have you ever asked one of your testers what is the current status of their progress, and the answer is 25% … or 50% … or 75%? You do not feel too comfortable with the answer because that is exactly what it was yesterday! We feel frustrated because we have to know what is going on and there are all sorts of pressures from the project management team to deliver on time. Do not take that frustration out on the tester ... perhaps we are to blame for not putting a system in place whereby we can measure productivity. Merely having a project schedule or Gantt chart that states delivery dates will not bring the testing project in on time. We need to be able to compare the planned tasks to the actual time it is taking to complete these same tasks, and once we have this comparison we then need to take corrective action to bring these tasks back on track. This article will focus on the measurements required to be able to make this comparison that will facilitate the analysis of the current status. The basis of this measurement are the tasks planned on a Gantt chart or a task spreadsheet and the status of requirements as determined from the requirements management spreadsheet (see 3 part article "The Heart of a Tester's Job" Oct, Nov and Dec 2001 - available at www.testfocus.co.za on the Feature Articles page). Steps to Creating Graphs The following worked example will use the spreadsheet in Figure 1 to monitor the production progress (planned against actual) of test cases that have been documented.
|
Figure 1: Monitoring Testing in an Excel Spreadsheet
The s-curve can now be used to take corrective action. When the actual results are under the s-curve, it is an indicator that things are not going too well, and conversely when you are over the s-curve things are going well (but be warned, I have found that this is also an indicator that I have over estimated effort!) When you are under the s-curve, the choices are to either work overtime or allocate extra resources to bring you back on track (do not spend time worrying that you are behind, do something). The s-curve will now give you the new rate at which test cases must be completed. Do not try to catch up immediately, but use the new adjustment to meet the original completion date. When the actual data goes over the s-curve, it is indicating that there is a possibility that you over estimated the effort, or that your team are genuinely working hard and are ahead of schedule, you could now release one of your test analysts to another project or task on your current project. Notice that the s-curve can show more test cases than are planned, do not worry about this, as this is a property of polynomial trend lines (if you do follow the trend exactly, you should finish ahead of time). The s-curve can serve as a warning that not all is going as planned and that corrective action must be taken soon. Try doing the same with the other testing tasks / status types on your requirements management spreadsheet. Readers are welcome to email me their results for comment or with any queries at info@testfocus.co.za. Peter Sage |
<< May 2002 |
July 2002 >> |