Part 13
Test Case Design (Do)
If you will recall, in the spiral development environment, software testing is described as a continuous improvement process that must be integrated into a rapid application development methodology. Deming’s continuous improvement process using the PDCA model is applied to the software testing process. We are now in the Do part of the spiral model (see Exhibit 13.1).
Exhibit 13.2 outlines the steps and tasks associated with the Do part of spiral testing. Each step and task is described along with valuable tips and techniques.
SOFTWARE TESTING METHODOLOGY
Exhibit 13.1. Spiral Testing and Continuous Improvement
Exhibit 13.2. Test Design (Steps/Tasks)
The requirements serve as the basis for creating test cases. The follow- ing quality assurance test checklists can be used to assure that the require- ments are clear and comprehensive:
• Appendix E22: Clarification Request that can be used to document questions that may arise while the tester analyzes the requirements.
• Appendix F25: Ambiguity Review Checklist that can be used to assist in the review of a Functional Specification of structural ambiguity (not to be confused with content reviews).
• Appendix F26: Architecture Review Checklist that can be used to review the architecture for completeness and clarity.
• Appendix F27: Data Design Review Checklist that can be used to review the logical and physical design for clarity and completeness.
• Appendix F28: Functional Specification Review Checklist that can be used in Functional Specification for content completeness and clar- ity (not to be confused with ambiguity reviews).
• Appendix F29: Prototype Review Checklist that can be used to review a prototype for content completeness and clarity.
• Appendix F30: Requirements Review Checklist that can be used to verify that the testing project requirements are comprehensive and complete.
• Appendix F31: Technical Design Review Checklist that can be used to review the technical design for clarity and completeness.
A functional breakdown is used to illustrate the processes in a hierarchi- cal structure showing successive levels of detail. It is built iteratively as processes and nonelementary processes are decomposed (see Exhibit 13.3).
A data flow diagram shows processes and the flow of data among these processes. It is used to define the overall data flow through a system and consists of external agents that interface with the system, processes, data flow, and stores depicting where the data is stored or retrieved. A data flow diagram should be reviewed, and each major and leveled function should be listed and organized into a hierarchical list.
A CRUD matrix, or association matrix, links data and process models. It identifies and resolves matrix omissions and conflicts and helps refine the data and process models, as necessary.
A functional window structure describes how the functions will be implemented in the windows environment. Exhibit 13.4 shows a sample functional window structure for order processing.
Task 2: Build a Function/Test Matrix
The function/test matrix cross-references the tests to the functions. This matrix provides proof of the completeness of the test strategies, illustrating
SOFTWARE TESTING METHODOLOGY
in graphic format which tests exercise which functions. See Exhibit 13.5 and Appendix E5, Function/Test Matrix for more details.
The matrix is used as a control sheet during testing and can also be used during maintenance. For example, if a function is to be changed, the maintenance team can refer to the function/test matrix to determine which tests need to be run or changed. The business functions are listed verti- cally and the test cases are listed horizontally. The test case name is recorded on the matrix along with the number. (Also see Appendix E24, Test Condition Versus Test Case, Matrix I, which can be used to associate a requirement with each condition that is mapped to one or more test cases.
)
Exhibit 13.3. Functional Breakdown
Functional Test Requirements (Breakdown) Order Processing
Create new order Fulfill order Edit order Delete order
Customer Processing Create new customer Edit customer Delete customer Financial Processing Receive customer payment Deposit payment
Pay vendor Write a check Display register Inventory Processing Acquire vendor products Maintain stock
Handle back orders Audit inventory Adjust product price Reports
Create order report
Create account receivable report Create account payable report Create inventory report
Exhibit 13.4. Functional Window Structure
The Main Window
a. The top line of the main window has the standard title bar with Min/Max controls.
b. The next line contains the standard Windows menu bar.
c. The next line contains the standard Windows tool bar.
d. The rest of the Main-Application Window is filled with the Customer-Order Window.
The Customer-Order Window
a. This window shows a summary of each previously entered order.
b. Several orders will be shown at one time (sorted by order number and customer name). For each customer order, this window will show:
1. Order Number 2. Customer Name 3. Customer Number 4. Date
5. Invoice Number 6. Model Number 7. Product Number 8. Quantity Shipped 9. Price
c. The scroll bar will be used to select which orders are to be viewed.
d. This window is read-only for viewing.
e. Double-clicking an order will display the Edit-Order Dialog where the order can be modified.
The Edit-Order Window
a. This dialog is used to create new orders or for making changes to previously created orders.
b. This dialog will be centered over the Customer-Order Window. The layout of this dialog will show the following:
1. Order Number (automatically filled in) 2. Edit field for: Customer Name
3. Edit field for: Customer Number 4. Date (initialized)
5. Edit field for: Invoice Number 6. Edit field for: Model Number 7. Edit field for: Product Number 8. Edit field for: Quantity Shipped 9. Price (automatically filled in) 10. Push buttons for: OK and Cancel
The Menu Bar Will Include the Following Menus:
File:
New:
Used to create a new order file Open:
Used to open the order file
SOFTWARE TESTING METHODOLOGY
Exhibit 13.4. Functional Window Structure (Continued) Save:
Used to save the order file Save As…:
Used to save the current order file under a new name Exit:
Used to exit Windows Order:
Create New Order:
Display Edit-Order Window with blank fields (except date) Fulfill Order:
This dialog will be used to verify that the order quantity is available in inventory stock and validate customer credit.
The dialog will include:
1. Edit field for: Order Number 2. Edit field for: Customer Name 3. Edit field for: Customer Number 4. Date (initialized)
5. Invoice Number (initialized) 6. Model Number (initialized) 7. Product Number (initialized) 8. Quantity Shipped (initialized) 9. Price (initialized)
10. Push buttons for: OK and Cancel
a. The quantity order is checked against the inventory stock level. If the order cannot be filled, a back order note is sent to purchasing.
b. The customer history will be displayed (the scroll bar will be used to view the history information).
c. An Accept button will fulfill the order and create an invoice for shipping.
d. A Reject button deletes the order and creates a customer order rejection letter.
Edit an Order:
This dialog will be used to edit an existing order. The dialog will include:
1. Edit field for: Order Number 2. Edit field for: Customer Name 3. Edit field for: Customer Number 4. Push buttons for: OK and Cancel Delete an Order:
This dialog will be used to delete an existing order. The dialog will include:
1. Edit field for: Order Number 2. Edit field for: Customer Name 3. Edit field for: Customer Number 4. Push buttons for: OK and Cancel
a. A confirmation message will be displayed with Yes, No, or Cancel options.
Order Report:
This dialog will display one or more orders based upon order number or date ranges.
It is also important to differentiate those test cases that are manual and those that are automated. One way to accomplish this is to come up with a naming standard that will highlight an automated test case; for example, the first character of the name is “A.”
Exhibit 13.5 shows an example of a function/test matrix.