Thinking back

I have been working on the introduction to product testing course at Value Transformation’s learning portal.  Working through the material reminded me of some experiences I have had that I think should make it to the rest of the world.

I was once a verification and test person; I have been a tester, and a manager of a test department.  Project management and testing seem to always be at odds. The project managers were very interested in cost, and delivery (time) and ancillary interested in quality a less tangible feature of the product and often not immediately apparent after launch while late and over budget are fairly quickly known.  I especially recall two instances that stand out the greatest. 

Raining on My Project!

The first was a project manager that had planned how the testing would work without the discussions with the test department. The scope, duration and risks were not discussed until a few days before the tests. Even more risky, was the device or in this case the system that was to be the subjected for the test was not available at the local facility.  To make the test even remotely work, a specimen had to be delivered to the test department from another part of the company in another state. The test department had experience getting material from this off site.  There were logistical challenges around making the system suitable for testing that meant the start of testing would not be as soon as the vehicle arrived but perhaps many days later. This range of past experiences was presented in the form of a histogram demonstrating the range of possible duration for systems test preparation.  Not one example of the amount of time the project manager desired this preparation work to take was in the population.  When this evidence was presented, the project manager exclaimed that the test manager was raining on his schedule.

Don’t ask Questions!

The second occurrence was with a more seasoned project manager.  This company had a customer engineering organization that made specific adaptations for the customer. These designs were of such defined and limited scope that they were delivered outside of the product development engineering organization.  These were theoretically small adaptations that required low levels of engineering talent. However, occasionally the volumes on these low level product offerings would escalate and there was a desire to make this custom adaptations part of the formal product offering.  On some occasions this move to standard offering was quick and without much of a review, only to find many problems and considerable warranty and rework costs after the transition.  Having had this experience, it was not unreasonable to ask questions and want to review quality reports on these systems before moving to mass offering.  This project manager thought the test department was stonewalling and being obstructionist without any purpose, he was quite irate.  Upon review of these mentioned areas, it was found that there were many problems with this adaptation and to move it to a standard customer offering would be very costly due to quality of the design.  In other words there would be considerable field rework and warranty dollars spent to fix this offering on a larger number of systems.

You have a problem

The real point of this post is to suggest if you think of your testers and test department as obstructionist because they ask questions and desire to see evidence of the product’s suitability prior to launch, you probably have a REAL problem.  The test and verification activities are there for the organization and the project.  These are in place to mitigate risks to the customer and to our organization.  It is not obstructionist to want to ensure a measure of critique is in place when it comes to the quality, potential risks and safe use of the product.  Many companies have gone out of business or have had costly recalls due to insufficient scrutiny of the product through testing that demonstrates the true capability of the product.  Understanding these risks are important for the project as well as for the organization. It is time to stop thinking of the test department as an impediment and understand the reasons for verification and test.