TCSS 360
Validation and Verification Results Guidelines

Version March 8, 2002.

Your Verification and Validation Report (VVR) should summarize all of your V and V activities, both static and dynamic. Please use the following report structure, preserving both the section/subsection numbering and headers as in the template below. Report on any design walk-throughs or other V and V activities that you might have done in class. Also, please briefly summarize all of the V and V activities that you did on an ongoing basis, including the highly informal ones. If your activities concerned anything to do with ensuring that you were building the right system, or ensuring that you were building the system correctly, then document them here.

  1. Project state.

    Your first section should summarize what functionality from your specification and design documents have and have not been implemented. For functional requirements, you should summarize this information with respect to which scenarios from your use cases have and have not been implemented. Feel free to use statements such as "All scenarios from use case 1 have been implemented, and all scenarios from use case 2 have been implemented except failure scenarios 3.1.1, 4.2.1, and 5.1.2." in order to economically express this information. This section should be an honest assessment of the extent to which you have met your project goals. Missing or deliberately misleading statements will be viewed as academic misconduct and a serious breach of professional ethics, and may be pursued through university-wide mechanisms for handling student misconduct.

  2. Static V and V.

    1. Design Walk-through.

      Document your in-class walk-through, summarizing what was presented, by whom, the questions or issues that were raised, and the actions that your group took to respond to these.

    2. Code walk-through

      Make sure to have at least one code walk-through attended by every member of your group for a code module between 50 and 100 lines. Record a summary of the inspection as above.

    3. Other static V and V activities.

      Add additional sections and subsections as necessary.

  3. Dynamic V and V

    1. Black-box testplan.

      Document your blackbox testplan for your six most important methods (you choose) that are not getter or setter methods. For each method,

      1. provide the name of the class and a hyperlink to the javadoc comments generated for this class,
      2. provide the method name and a hyperlink to the javadoc comments generated for this method,
      3. a list of the set of input cases and initial states, output cases and final states, and "border" cases, and
      4. a table that provides a sample input and/or initial state that you will use to test each case, the case(s) tested (there might be more than one case tested by a single input), using an "i" to indicate the input cases described and an "o" for the output cases described, and the expected output and final state, and the actual output and final state. You can leave this last column blank if the actual output and final state are identical to the expected output and final state, i.e. only put something in this column if there was a difference. Once an output state has been tested, you need not include this state again in your table even if it tested by another input.

      Here is an example for the pop() method of the java.util.Stack class:

      1. Class: Stack
      2. Method: pop
      3. Input cases: Stack is empty, Stack is non-empty
      4. Output cases: Element is returned, EmptyStackException, Element is removed from Stack
      5. Border cases: Stack has a single element

      Case(s) tested Input
      Initial State      		 Expected output
      Final State      		 Actual output
      Final State
      Stack is empty(i)
      EmptyStackException(o)      		Empty Stack EmptyStackException
      Stack is non-empty(i)
      Element is returned(o)
      Element is removed(o)      		Stack: ["hi" "bye" "big"] "hi" returned
      Stack:["bye" "big"]
      Stack has 1 element(i)Stack: ["bye"] "bye" returned
      Stack is empty

      Note that when you actually go to test these methods, you will need to fashion some way to test the state of the object variables operated upon to actually determine what their final state is. For example, in the example above, you might want to print out the Stack after each operation to determine if the stack has been pushed and popped as appropriate. Therefore, for all of the above methods, provide a summary of how you performed and verified that the unit tests were correct.

    2. White-box testplan.

      Document your white-box testplan for the three methods that most closely capture your three TSP algorithms. For each of these methods,

      1. provide the name of the class and a hyperlink to the javadoc comments generated for this class,
      2. provide the method name and a hyperlink to the javadoc comments generated for this method,
      3. a flow graph using a UML activity diagram as we did in class for the method,
      4. a list of inputs (or descriptions of inputs) that will provide complete node coverage. For each input, list the nodes in the flow graph visited during an execution on that input.

    3. Integration Testing

      4. Provide a description of your integration testing for the project. In particular, discuss the order in which the units were integrated, and how the evolving software product was constructed and verified dynamically.

    4. Scenario Test Cases.

      For each use case or partial use case that you are delivering, provide a test case for each scenario in the use case, i.e. the Main Success Scenario (MSS) and each Extension. For each scenario, 1) provide a sample initial state for all data objects and a set of sample input values, all of which satisfy the trigger for the given scenario and 2) provide the expected final state for all data objects and the expected output values/responses of the system. The sample initial state and inputs are provided in italics following each line that indicates an Actor's action; the expected output states/responses are provided in italics following each line that indicates the System's action.

      Here is the MSS and Extensions from a hypothetical use case (adapted from Writing Effective Use Cases by A. Cockburn, Addison-Wesley, 2001, pp178,179), along with the sample inputs and outputs. Below each use case step is are the actual inputs and outputs, as well as initial and final states. 

      Main Success Scenario
1. Customer logs in.
Name: Fred Jones, Cust#: 14456
2. Customer selects items and quantities.
10 Widgets in stock.
Customer orders 5 Widgets at a price of $10.00/each.
3. System allocates required quantities to customer.
5 Widgets in stock.
4. System sends picking instructions to distribution.
Distribution has order lines and shipping data.

      
Extensions
1a. Login fails:
Name: Sybil Richards, Cust#: 29384
  1a1. Customer exits system.
  1a2. Customer retries login.
  1a3. Customer registers as new customer.
3a. Insufficient stock to meet required quantity for item:
4 Widgets in stock.
  3a1. Customer cancels order.
  4. System Test Cases

    Describe the test cases that you will run on your entire system that provide full coverage of all features of your system if these were not covered in earlier testing. Discuss all of the different system cases that you will be testing.

Change Log