testing

Quality Issues
The quality of software is the extent to which the product satisfies its specifications.
The Software Quality Assurance Group (SQA) has additional responsibilities with regard to software quality.
Software Quality Assurance
ensures that software is correct at each phase
ensures that the entire product is correct
SQA also applies to the software process itself.
responsibilities of the SQA include the development of various standards to which the software must conform, as well as the establishment of monitoring procedures.

Managerial Independence
It is important to have managerial independence between the development team and the SQA group. Both managers should report to a more senior manager who could decide which of two possibly conflicting choices should be made so that the decision is in the best interest of everyone involved.
The additional cost of an SQA group is relatively small compared to the resulting benefit, namely higher quality software.
Where it is not economically viable to have a separate SQA group (company too small) it is at least best to ensure that the specification document be checked by someone other than the person responsible for producing those specifications.

 

Nonexecution-Based Testing
The review task must be assigned to someone other than the original author of the document.
Two types of review techniques: Walkthroughs and Inspections
Fundamental difference between them is that walkthroughs have fewer steps and are less formal than inspections.
Walkthroughs
A walkthrough team should consist of 4 to 6 individuals.
A specification walkthrough team should include:
at least one representative from the specifications team
manager responsible for the specifications
a client representative
a representative of the team who will perform the next phase
a representative of the SQA group.
the SQA group member should chair the walkthrough, because the SQA representative has the most to lose if the walkthrough is poorly performed and faults slip through.
The quality of the product is a direct reflection of the professional competence of the SQA group.
Each reviewer should review the material  for the walkthrough and develop two lists:
items the reviewer does not understand
items the reviewer believes are incorrect
Managing Walkthroughs
Task of the team is to record the faults for later correction, not to correct them.
Reasons:
A final document by the committee would be inferior; person trained should do the corrections.
Cost for paying off team members is not an effective use of time.
Analyze proposed faults; not everything found is necessarily a fault.
Not enough time to detect and fix - walkthrough should last no more than two hours.
Two ways of conducting a walkthrough:
Participant driven
participants present their lists and the representative of the specifications team answers their questions.
Document driven
more thorough
recommended by IEEE
Person responsible for the document walks through it
reviewers interrupt either with prepared questions or questions triggered by the presentation
NOTE: Neither walkthroughs nor inspections should be used to evaluate the participants Inspections
first proposed by Fagan in 1976 for testing of designs and code
Five Formal Steps:
Overview of Document - summary of the document is given, and then copies are distibuted to all participants at end of overview.
Preparation - participants try to understand document; similar to a walkthrough but look over all fault types and frequency from other documents and similar products
Inspection Meeting - Be sure every item is covered
Purpose - Faults are uncovered, not corrected
Moderator productes a report from the activities of the meeting
Rework
Faults and problems are resolved during the rework
Follow-up:
Check all items that were resolved or fixed
All new fixes have to be checked and if more than 5% of the material from the original document was changed, then you do a complete reinspection
fault statistics are recorded by severity
major faults
minor faults
How to use this record:
compare faults with a similar product
detect parts in subparts of product; then look at related parts
If there are many faults in a particular part then redo that phase
Number and types of faults in one phase help you to prepare for the next phase
Overall, the strengths of reviews are that they are :
effective ways to find faults
faults are detected early
Weaknesses
Large-scale software is hard to review unless there are independent units
O.O. technique helps here
Need documentation from previous stage


Execution-Based Testing
What Should Be Tested?
 

Who Should Perform Execution-Based Testing?
 

Testing Distributed Software
 

Testing Real-Time Software
 

When Testing Stops