In many program cases I see teams “testing to pass” when they should be “testing to improve”. Testing to pass is putting your best foot forward. There is a “mark” and you are going to hit it so you can advance to the next stage. Testing to Improve is looking for defects and response to inputs. The motivation for each is very different. The risk for leaders is overseeing teams who view their role objectives to be in line with “testing to pass.”
The program product release date and the field performance up to two years out are each milestones that reflect the results and effectiveness of a testing program. Team’s often find their role to be highly defined by the product release date. Leaders often find their role to be highly defined by product performance in the first two years. Quick Question?
If the program pressure is to release on time and your personal annual review is within a few months of release would you?
A) Want to explore all the deficiencies of your design?
or
B) Make sure it passes with flying colors and is not the system that drives a delay in product release?
Ok now let’s say you are designing a new plane and your family is going to be on the maiden flight. Would you?
A) Want to explore all the deficiencies of your design?
or
B) Make sure it passes with flying colors and is not the system that drives a delay in product release?
That’s the difference between an owner with accountability and a developer with a delivery date.
The challenge is for leadership to manage their teams to be owners of the design, same as they are. It’s no error of the teams that they are testing to pass. Their personal success depends on it in many current product development cultures.
-Adam
Leave a Reply