Weak Measurement – follow up
To follow up my post on weak measurement being better than no measurement I decided to write some things I think can affect the ability of a development team to turn bugs around and hence make the use of the metrics from past releases not useful.
- Starting testing too early
- Starting testing too late
- Incorrect Risk Assessments by testers/developers/product managers
- Misunderstood Features by testers, developers, project team
- Constantly changing features (code churn/ greater risk of regression bugs)
- Inexperienced and/or Immature coders/testers
- Vacations/Sick days/Personal days/emergencies/snow days/Halo 3/WOW was released yesterday days
- Too many bugs carried over from last release.
- Unknown changes being checked in
- Misunderstood Features
- 3rd party applications cause problems
- Software licenses run out for development/test software.
- Busted Build process
- Product won’t install
- No business spec
- No Technical Spec
- Not enough hardware
- Incorrect hardware
- Not enough power to run the hardware
- Hardware/hardrives die unexpectedly (Does this ever happen expectedly?)
- Not enough People
- No Unit Tests
- Incorrect Time Estimates (oxymoron?)
- Miscommunication of vital pieces of information
- Features not cast/frozen/signed off on or otherwise stopped changing
- No requirements/Unclear requirements
- Bug system goes down.
- Internet connection goes down
- Power goes out
- Key stakeholders not available
- More time spent in meetings than fixing/testing software
- Customer problems take senior resources away.
- Meeting Interruptions/Coding interruptions/testing interruptions
January 15th, 2008 at 6:47 PM
Oh dear, I’m sorry for having to tell you this, but I AM a tester. You have misunderstood features down twice on your list. Recently bit by that one?
Does too much Rockband count on the list? I’ve developed a habit since the holidays.
December 6th, 2008 at 9:16 AM
After reading through this post and the previous one, I can’t really disagree with you, but I’m still not sure what the solution is. Can you help clear this up for me?
A current example for me is we have a project that is 3 months behind schedule, and the number of defects and fixes are quite numerous. Our scope is to re-test about 50 defects, and quite a bit of regression testing.
Based on what I know TODAY I’m estimating that it will take about 5 weeks to complete this, but I plan on constant communication to let them know if I think that the timeline will slip, and/or what major questions about the system we won’t have answered.
I’ve read a lot of the time estimation articles, blogs, and RST slides from James Bach and Michael Bolton so this isn’t the first time I’ve been exposed to the idea of not estimating how long it will take to test, but as someone who is somebody’s customer myself I would be appalled if I went anywhere for service and they couldn’t give me any estimate of how long it would take to get the service I desire. Is that the lesson here, though? That we will provide better customer service if we don’t provide an estimate?