refers to the process of determining whether or not the products of a given phase of a software development process fulfill the requirements established during the previous phase.

Proof of Correctness - Verifies a programs formal specifications

1. Static practice of verifying document, design, code and program

2. does not include executing the code

3. methods: inspections, reviews, walkthroughs

conducted by a facilitator,recorder and participants 
verification is done by the QA team 

refers to the process of evaluation software at the end of its development to insure that it is free from failures and complies with its requirements.

1. always involves executing the code 
2. uses methods like black box - functional testing and white box testing - structural testing

3. is caried out with the involvement of the test team

** customers & end users are concerned with the validation of the software 

1. Its impratical to test all the data - Combinatorial explosion - Testing oracle required

2. Impratical to test all Paths of a program 

3. Overall goal os to have a produc that is failure free and meets the user's expectations

What is the role of V&V?

(RSDIC)

Should be determined for each of the products below:

1. Requirements Doc. - informal statement of the user's needs

2. specifications: refined meant to represent the users needs and be satisfied by the product

3. designs - how the specification will be satisfied

4. implementation - source code/interface

5. changes - modifications to the product as a result of bug fixes

objectives are determined on a project to project basis

FACTOR IN:

1. criticality - medical device/automotive/mobile application

2. complexity

3. constraints

1. correctness: is product fault free

2. consistency: consisten w/ itself and and other products

3. necessity: is everything in product necessary

4. sufficiency: is product complete

5. performance: satisfies the requirements

What are the 5 steps?

(SMCDS)

1. start w/ an obvious and simple test

is the program functioniong? Is itready to test? do simple tests

2. make notes about what else needs testing

continue to work on your analysis - what now needs to be tested

3. check valid cases and see what happens

run through your first round of testing - document the results

4. do some testing on the fly

Exploratory testing: Document these may become formal tests in later rounds

5. summarize what you need to know about the program and its problems

Prepare your notes for the next round testing

Simple Test->Observation->Run Valid Cases->

On the Fly->Summarize 

1. fields to collect

2. program

3. release/version problem summary

4. Problem summary

 5. steps to produce the problem

6. suggested fix

7. reported by

8. comments 

Define:

1. Formal Test Series

2. Boundary Condition

1. documented test cases to be used each time u test

2. largest and smallest values in a class - Anything that makes the a program change it's behavior marks the boundary between 2 classes

what is the SW development Lifecycle?

5 (PDCTP)

1. Planning - objectives, requirements analysis

2.Design - specification, functional definitions

3. coding and documentation

4. testing and fixing

5. post release - maintenance and enhanacements

What are their duties?

1. Project manager/SW development manager

2. architect

3. subject matter expert

4. business analyst

5. user expereince designer

1. responsible for qualiy level

2. specifies overall integral design of code and data structures

3. understands what customer wants

4. writers for requirements, design, analysis, documentation

5. makes SW design usable

What are their duties?

1. User interface programmer

2. lead programmer

3. product manager

4. operations analyst

5. testers

1. specializes in creating the user interface

2. writes internal design specifications

3. responsible to deliver product into long term strategy

4. represents operations team

5. team that does the testing

What are requirement analyst?

1. objective that must be met

2. are defined in functional terms

3. may express fundamental hardware decisions

1. gather information

working copies or documentation to see how new product compares to exsisting unit - evaluations of the comparative products

2. create focus groups

small group representative of a market segment

goal - gauge current market reaction to an idea

3. Task analysis - automation of manual process

how do ppl do it now?

what order are the subtasks done it?

1. are these the right requirement?

2. are these req. complete?

3. are they comportable?

4. are they achiveable?

5. are they reasonable?

6. are they testable?

designers try to figure out how to provide planned capabilities of the product. coding doesn't start until this portion is complete. prototype might be created

1. complete description of the user interface

2. external specification

3. user manual

specifies how tasks will be divided among code

ex:account object - add/remove funds

Strutural Design

1. System

2. Protocol documents

3. SW Architecture

4. Modular decompostion

System - collection of self contained but related program rather than a single program

Protocol documents - specify the rules governing communication between processes

SW Architecture - divides components and defines communication between them

Modular decompostion - breaking a program into modules

Module sends data to another module/ can retrun dara

Defines the data structures

the proper naming conventions

design does not end with modules or decompostion

doesn't end with the data design

Someone has to determine how to do the task.

a model of the system or part of it

built as quickly and cheaply as possible

allows a view of how its not working

is the design good?

does the design meet the requirements?

is the design complete?

do we have a enough memory?

how well does the design cover error handeling?

objective is to identify problems with the design

walkthrough are done as a step by stepto show what the program will do.

inspections check every line in the design with each item in the checklist

Black box testing

white box testing

1. you can't see into the program - we feed in data and evaluate the expected output - this test data is expected to expose an error in a program 

2. you can see into the program - you can test one module at a time using interesting values - u can determine which branches of the code have been tested - has a control flow: allows tester to report what the program is doing while executing - can spot issues passing data btwn modules - can see internal boundaries (overflow conditions and can test those) - testers can test against the algorithms

Incremental testing

Big bang testing

Integration testing

testing in piecemeal

testing in 1 big lumpsum

Incremental - each piece is tested seprately 

Integration - testing in groups of modules together until all groups of modules are tested

Big bang saves sooo much time, but tracking failures is difficult and all modules have to be functioning in order to test

top-down

bottom up 

they are both incremental 

bu- lowest level modules are tested first

td- highest level modules are tested first 

code is examined w/out being executed

ex - the compiler

code is executed

test casees are fed into the program either manually by tester or by automation testing

automated tooldcan see if code meets compnay standards

programmers often leave 1-3 errors per line

metrics are often reported on bugs found and fixed per cycle

can be black box or white box

examines the affects on system performance, memory,disk, and impact to otehr applications

looks at compute time between modules, sql query time, and network performace

fundamental between black box and glassbox testers

FIND ERROR - FIX ERROR, RE-TEST ERROR = REGRESSION TESTING

ensures fix does what it's supposed to do

1. is the program stable enough to be tested

2. run mainstream tests on mainstream data - typical things a user would do

3. this testing can be automated