We have our requirements, our iterative packages and content defined, and now the developers are producing the iterations. During this time, the verification and test folks have been creating the test cases or details on how we intend to confirm the product performance.

Our requirements provide the fodder for our testing.  For each requirement there must be a way to confirm that requirement has been delivered, fulfilled or otherwise met.  Confirmation the need is satiated is also part of the project closing activities.  We do not counsel testing only to the requirements, however this blog series is on requirements and we want to show the link between the requirements and product verification. How else will are you to know the product meets the desired outcome?  These test cases should be traced all the way back to the project scope via the product requirements (see the table below).

Traceability from scope through requirements to testing is fundamental and all too frequent missing in many product development organizations. Without this traceability, we end up wasting considerable time testing functions that are not working or delivered. Without the requirements, we do not know what to test independent of the packages delivered or even how to go about the testing. When the product arrives we are scurrying to figure out how to test based upon the myriad of and often based upon opinion on how the product works. The result of this neglect is uncertainty in the product delivery.  We do not know whether our confirmation of the product is adequate – risk in the field performance of the product and all that entails. Further, we find ourselves in the unenviable position of not knowing if our contractual obligations are truly slaked when the contract closure is due.