The Image Computing Systems Laboratory (ICSL) at the University of Washington has been developing an image computing library (UWICL) for the Texas Instruments (TI) TMS320C80 Multimedia Video Processor (MVP). The purpose of the UWICL is to provide a portable and efficient library of core image computing algorithms to the MVP user community. This library will be made available as source code to those consortium member companies for their product development with the MVP.
The purpose of this document is to establish the Quality Assurance program and bug handling procedures for the UWICL. Like every other product, the UWICL should be tested to conform to high quality standards. By creating these procedures, we do not wish to overload some of our team members with the QA testing. It needs to be understood that we seek a good balance between quality and productivity since having an overwhelming QA system could result in lower productivity and "non quality".
Any code implemented in the UWICL will be subject to design review, white box testing, and black box testing.
Prior to implementation of any new function, the programmer will prepare a high-level design of the new function and it will be reviewed during our design review meeting. The UWICL team members will be able to provide "a third-party look" at the design, raise some interesting issues, and give some tips for the implementation of the function.
Once the function is coded, the programmer is responsible for the documentation of the function (restrictions, use of the function) and what we call "white box testing". The function should comply in any case to the rules established in the style guide and design guide documents. The programmer should test the function both on the simulator and on the Media-Station 5000 board with different image sizes including the upper and lower limit of the image size. The results should be also validated and compared with those from a reference program such as Khoros (for image processing).
In the UWICL team, one person is exclusively assigned for the task of the QA testing. This person will check each function created for the library. He will verify the conformity of the program against the style and design guides and then perform the "black box testing".
The value of this testing is given by the fact that the person assigned has little or no involvement in the programming of the function being checked. The QA control will make sure that the program is working as intended without any problem, and within the restrictions documented. The QA person will also verify the correctness of the results with a reference software when available (e.g., Khoros for image processing).
The black box testing procedure will be incremental. Each time a new function is checked in, the author will send an e-mail message to the person in charge of the QA. The QA control will then take place. If it appears that there is any problem, the QA person will send back an e-mail with the description of the problem to the author in order to solve it. In any case, all the functions are highly recommended to be finished at least five weeks before a new release. Four weeks will be dedicated to the "build cycle" which is an internal release of the ICLIB software. During this period, all the functions which have not been tested will be checked if possible in the first week in order to provide enough time for the author to correct any bugs. The fifth week will be dedicated to the preparation of the installation of the ICLIB software. This installation will be simulated internally on an account which is not part of the UWICL team.
When a bug is found in one of the functions of the UWICL, the member of the consortium should send an e-mail to "iclib-bugs@icsl.ee.washington.edu" in which he/she needs to describe precisely the nature of the problem. It is very important to have all the details in order to be able to recreate the environment in which the bug appeared. When we get a bug report, we will send back an acknowledgment of the reception of the claim which will contain a reference claim number. In the case of insufficient information about the case when the bug appears, we will get back to the bug founder via e-mail asking for more information. We will not proceed until we have enough details.
Once we have enough information regarding the case when the bug occurs, the QA person will recreate the conditions and verify that the reported problem is a bug. If so, he will assign a member of the UWICL team (preferably the function's original author if he/she is still available in ICSL) to correct the bug.
The modified function will go through the QA cycle and a document will be written on the correction made. The corrected program will be checked in, and it will also be placed on the FTP site in a "bug" directory. An e-mail will be broadcast to all the members of the UWICL consortium to let them know the existence of a bug in the function and how to import the corrected version from our FTP site.
For a bug report, the person assigned to the Quality Assurance will have up to one week (5 working days) to answer via e-mail to the sender. We estimated from one to three weeks the reasonable time frame in which we will correct a bug. If a problem needs more time to be fixed, an e-mail will be sent to the original sender.
As for the support, the UWICL Team will answer to a question via e-mail within a week (5 working days). The UWICL Team will dedicate a certain amount of time per week for the support. The questions will be sorted in a company specific queue and be answered in a round-robin fashion. Any question not answered within a week will be queued for the next week.
This Quality Assurance Guide has presented a guideline and detailed procedures for maintaining the quality and handling the bugs in the UWICL. It is intended to be a reasonable quality and support procedure without being too overwhelming to maintain our productivity in developing and supporting the MVP image computing library.
All documents referring to a bug should be saved under the reference number which corresponds to the acknowledgment number:
Subject: Bnumber.name of function
We have received your message and we are looking at the problem. For our correspondence, please note the reference "Bnumber.name of function" to be used in the subject of any e-mail concerning this matter.
Regards,
UWICL.
Subject: Bnumber.name of function
We have received your message, but we need more information about the circumstances in which the problem happens in order to proceed. Please note the reference "Bnumber.name of function" to be used in the subject of any e-mail concerning this matter.
Regards,
UWICL.
Subject: Bnumber.name of function
We have looked at the problem you have encountered, but this is not a bug. The problem you have encountered is due.....
Regards,
UWICL.
Subject: Bnumber.name of function
Dear Members of the UWICL consortium,
We have been aware of a bug in........ The bug was......
It has been fixed, and you can import the fixed version from our FTP site.
Regards,
UWICL.