Quality Assurance, Testing, and Implementation

3690 Words Aug 5th, 2011 15 Pages
Quality Assurance, Testing, and Implementation
Frequent Shopper Program, Part III Quality Assurance Process and Procedures
While developing and implementing the Kudler Fine Foods Frequent Shopper Program, Smith Systems Consulting proposes to adhere to a well planned, comprehensive, and lifecycle-encompassing quality assurance process to assure the minimal standards of quality, as defined by Kudler Fine Foods within the functionality and performance requirements are met.
This process goes well beyond debugging the software itself. Rather, the quality assurance process will begin on day one of the project lifecycle and will be completed the day the software is retired.
That said, though, the goal and guiding principle of the
…show more content…
Testing Procedures
Testing has two main objectives:
1. Detect and fix errors
2. Correct operation of the software
Of greater concern to this paper is the correct operation of the Frequent Shopper Program at all levels: program, network, systems, and interfaces. Testing procedures that can help guarantee this include:
1. Drawing up a test plan
2. Writing test cases
3. Static testing
4. Functional testing
5. Structured (non-functional) testing
6. Performance testing
The first procedure that needs to be followed if testing is to be effective in accomplishing these goals is drawing up a test plan which would include an “overall test plan description” and “detailed test execution instructions” (Everett & McLeod, 2007, p. 79).
The test plan should take each level of the system into consideration including when parts of the test should be conducted (test schedule), what, in particular, should be tested, test data (drawn up with the help of business analysts), expected results, and so on. In effect, the test plan determines what will be tested and why it needs to be tested.
Drawing up a test plan involves writing test cases per development phase. Test cases describe how testing will be conducted and are usually based on use cases.
Just as with use cases, test cases become more and more detailed as details about the program, system, network, or interfaces are developed and become evident. In fact, the fleshing-out of use
Open Document