*******************
*   on Tuesday, December 5, during class, we'll do a random draw
    for presentation/demonstration order in Wednesday, December 6th's
    labs
    *   IF you have a client who would like attend, and they have time
        constraints, you need to let me know that by classtime on
	Tuesday December 5!
*******************

*   ASIDE/REMINDER:
    verification - "the process of evaluating software to determine whether
        the products of a given development phase satisfy the conditions
	imposed at the start of that phase"

    validation - "the process of evaluating software during or at the
        end of the development process to determine whether it satisfies
	specified requirements"

    ...or, if you prefer: [I THINK THIS GETS THE DISTINCTION
                           ACROSS BETTER...]
    verification ensures "you built it right", it meets the specification;
    validation ensures "you built the right thing", it actually meets
        the user's needs, it meets the requirements (and that the
	specification were correct in the first place)

    *   which of these better characterizes:
        *   unit testing? 
            *   Jalote, Ch. 8, 8.1.4, p. 229: VERIFICATION
	*   acceptance testing? 
            *   Jalote, Ch. 8, 8.1.4., p. 230: VALIDATION
	*   requirements review? 
            *   Jalote, Ch. 3, 3.6, p. 65: VALIDATION
	*   code inspection? 
            *   Jalote, Ch. 7, 7.5, p. 210: VERIFICATION

*   let's also poke at
    black box testing
    white box testing

    *   let's say you design your test cases trying to obtain
        complete statement coverage.
	...is that more accurately considered black box or
	   white box testing?
           *   it is considered to be WHITE BOX testing --
	       you are using the structure of the code to
	       determine test cases

    *   ...trying to obtain complete branch coverage?
	...is that more accurately considered black box or
	   white box testing?
           *   it is considered to be WHITE BOX testing --
	       you are using the structure of the code to
	       determine test cases

    *   ...trying to determine what the different categories of
        input data are, and making sure you include test cases
        with data from each such category?
	...is that more accurately considered black box or
	   white box testing?
           *   it is considered to be BLACK BOX testing -- 
               when you can devise test cases without
	       considering the actual structure of the
	       software under test

*   there's also STATE-based testing --
    when the behavior of a system depends
    on its state, you might want to consider test
    cases built considering that state;

    ...sometimes considered to be GRAY-box testing!

    *   examples of state-based testing criteria:
        *   all-transitions coverage - every edge in the
	    state diagram is exercised
	*   all transition pair - test cases must execute
	    all pairs o ADJACENT transitions
	    (incoming and outcoming transitions in a state)
        *   transition tree coverage - test cases must execute
	    all simple paths 

*   pair-wise testing - trying to uncover multi-modal faults,
        when a COMBINATION of inputs has an issue;

*   consider a few METRICS, then:
    *   note that defects are often LOGGED in software
        development; 

    *   since high reliability is desired,
        MTTF - mean-time to failure - is often tracked, also

    *   also measured, as a measure of efficiency rather thsn
        reliability...
        DRE - defect removal efficiency
        *   measured over time, even after software delivered
	*   CAN use to help determine/suggest which quality control
	    activities are effective