Well, maybe "lied" is too strong a word.

If Linda is on the ball, she'll tell me that the customer for our software (COTS, embedded systems, OEM stuff, etc) is the product manager. He or she is the middleman, or reseller, who is paying us to develop the software in the believe that he or she can sell it to others and recoup that cost. Therefore, the PM's requirements are the parameters that should drive testing.

In some companies, the PM role is split across sales, marketing, and engineering. In other companies, the role is more formalized.

  8:57:01 PM    

In response to this StickyMinds article, I wrote

Linda,

While I believe your analysis holds true for software developed in-house or on-contract for a business customer, I don't think it's a good approach for other testing situations.

Yes, testing against requirements (and testing the requirements) are part of customer-acceptance testing (or customer-acceptance testing by proxy, as would be the case for COTS, some OEM deals, and some embedded systems). But there is more to the testing (or QC) part of our jobs that relates directly to the process improvement (QA) part.

Testing is a measurement activity. We should strive to know as much as possible, in quantifiable ways, about the software under test. These numbers can then be used for risk assessment and management (a project-wide activity), and as feedback for process improvement (more in line with QA).

So *I* would want to hear you saying, "The cost of development of this product includes the cost of determining a risk profile, as well as the cost for us to measure our performance so that we can improve our efficiency on future projects." For projects with only one customer, the risk profile takes the form of the assurance you mentioned; for projects with many customers, it can take the form of a sales and profit projection (is it good enough so that we can see them at that price, and not lose our shirts of maintenance and support).

I hope it is not rejected by the editors.  1:51:03 PM