Task 1: Script the Manual/Automated GUI/Function Tests

In Chapter 15, a GUI/Function Test Matrix was built that cross-references the tests to the functions. The business functions are listed vertically, and the test cases are listed horizontally. The test case name is recorded on the matrix along with the number.

In the current task, the functional test cases are documented and transformed into reusable test scripts with test data created. To aid in the development of the script of the test cases, the GUI-based Function Test Matrix template in Table 16.1 can be used to document function test cases that are GUI-based (see Appendix E7, “GUI-Based Functional Test Matrix,” for more details).

Consider the script in Table 16.1, which uses the template to create a new customer order. The use of this template shows the function, the case number within the test case (a variation of a specific test), the requirement identification cross-reference, the test objective, the case steps, the expected results, the pass/fail status, the tester name, and the date the test was performed. Within a function, the current GUI component is also documented. In Table 16.1, a new customer order is created by first invoking the menu bar to select the function, followed by the Edit-Order Window to enter the order number, customer number, model number, product number, and quantity.

Task 2: Script the Manual/Automated System Fragment Tests

In a previous task, the system fragment tests (Chapter 15) were designed. They are sample subsets of full system tests, which can be performed during each spiral loop.

In this task, the system fragment tests can be scripted using the GUI-based Function Test Matrix discussed in the previous task. The test objective description is probably more broad than the Function/GUI tests, as they involve more global testing issues such as performance, security, usability, documentation, procedure, and so on.

Task 1: Schedule/Prepare for Review

The test development review should be scheduled well in advance of the actual review and the participants should have the latest copy of the test design.

As with any interview or review, it should contain certain elements. The first is defining what will be discussed, or “talking about what we are going to talk about.” The second is discussing the details, or “talking about it.” The third is summarization, or “talking about what we talked about.” The final element is timeliness. The reviewer should state up front the estimated duration of the review and set the ground rule that if time expires before completing all items on the agenda, a follow-on review will be scheduled.

The purpose of this task is for development and the project sponsor to agree and accept the test development. If there are any suggested changes to the test development during the review, they should be incorporated into the test development.

Task 2: Obtain Approvals

Approval is critical in a testing effort, because it helps provide the necessary agreements among the testing, development, and the sponsor. The best approach is with a formal sign-off procedure of a test development. If this is the case, use the management approval sign-off forms. However, if a formal agreement procedure is not in place, send a memo to each key participant, including at least the project manager, development manager, and sponsor. In the document, attach the latest test development, and point out that all their feedback comments have been incorporated and that if you do not hear from them, it is assumed that they agree with the development. Finally, indicate that in a spiral development environment, the test development will evolve with each iteration but that you will include them in any modification.