SQA :: Software Defect Prevention

by
Dr. Rizwan
Do You Remember…
Quality Concepts
Significance of Quality
Quality Goals
SMART
Quality Engineering
Quality Planning
SQA
 Prevention
 Detection
 Measurement
 Containment

Significance of SQA activities

 Defect Prevention
 Defect prevention through error blocking or error
source removal can prevent certain types of faults from
being injected into the software.
 Since errors are the missing or incorrect human actions
that lead to the injection of faults into software systems,
we can directly correct or block these actions, or remove
the underlying causes for them.
 Defect Prevention
 Defect prevention can be done in two generic ways:
 Eliminating certain error sources, such as eliminating ambiguities or
correcting human misconceptions, which are the root causes for the
errors.
 Fault prevention or blocking by directly correcting or blocking these
missing or incorrect human actions.
 This group of techniques breaks the causal relation between error
sources and faults through the use of certain tools and
technologies, enforcement of certain process and product
standards, etc.
 Defect Prevention
Most of the defect prevention activities assume that there are
known error sources or missing incorrect actions that result in
fault injections, as follows:
If human misconceptions are the error sources, education and training
can help us remove these error sources.
If imprecise designs and implementations that deviate from product
specifications or design intentions are the causes for faults, formal
methods can help us prevent such deviations.
If non-conformance to selected processes or standards is the problem
that leads to fault injections, then process conformance or standard
enforcement can help use prevent the injection of related faults.
If certain tools or technologies can reduce fault injections under
similar environments, they should be adopted.
 Defect Prevention Techniques

• Fail-safes and constraints are among the most

powerful and effective error-prevention strategies.
• They involve true system changes in the design of
products or how individuals interact within the system.
• Examples At a community pharmacy where the
pharmacy is integrated with the cash register, a fail-
safe would prevent the clerk from ringing up the
prescription unless final verification by a pharmacist
was noted in the system.
 Defect Prevention Techniques

Forcing functions are procedures that create a "hard

stop" during a process to help ensure that important
information is provided before proceeding—often referred
to as a "lock and key" design.
Examples include a pharmacy computer system that
prevents overriding selected high-alert messages without a
notation (e.g, entry of the patient-specific indication for
selected error-prone medications), or a bar-code scanning
system that does not allow final verification of a product
without a positive match between the selected product
and the profiled medication.
 Defect Prevention Techniques

Automation and computerization of medication-use

processes and tasks can limit reliance on memory.
Examples include pharmacy computer systems that can
receive prescriptions sent electronically from a prescriber's
handheld device or computer and thus eliminate
transcriptions and misinterpretations; robotic prescription
preparation and dispensing technology (Rule based System);
and computer systems that provide accurate warnings
related to allergies, significant drug interactions, and
excessive doses.
 Defect Prevention Techniques

Standardization creates a uniform model to adhere to

when performing various functions, and it tends to reduce
the complexity and variation of a specific process.
For example, standardized processes could be created to
guide the pharmacist's final verification of a medication.
On its own, standardization relies on human vigilance to
ensure that a process is followed; therefore, it is less effective
than the strategies mentioned previously.
 Defect Prevention Techniques
Redundancies incorporate duplicate steps or add another
individual to a process to force additional checks in the
system.
Involving 2 individuals in a process reduces the likelihood
that both will make the same error with the same medication
for the same patient.
The potential for error still exists, however, because the
redundant step may be omitted or ignored.
Examples of redundancies include the use of both brand and
generic names when communicating medication information
or requiring independent double-checks of high-alert
medications before dispensing.
Patient counseling is often an underutilized redundancy that
can detect many errors.
Before Software Defect Prevention
 After Software Defect Prevention

- One Quality Assurance (QA) activity is fault prevention whose

goal is to prevent as much as possible defect injection through
creating processes, procedures, tools, jigs, etc. to prevent faults from occurring
- Development of methodologies & standards.
- Review if requirement being defined at proper level of detail?
 Assignment 2

 Apply Defect Prevention techniques upon any software

engineering artefacts.
 SQA ::
Software Defect Reduction/Identification
Through Inspection

by
Dr. Rizwan
 Defect Reduction Methods
 Reviews
 Personal, peer, pair, FTR
 Testing
 Structural, functional, integration, stress/performance, regression, field,
acceptance
 Simulations
 Prototypes, models
 Field Trials
 Prototypes, beta testing
 Mathematical
 Proofs of correctness
 Inspection
Defect reduction through defect detection since they have
been injected into the software systems is in fact most traditional
QA activities fall into this category
 Software inspections are critical examinations of software
artifacts by human inspectors aimed at discovering and fixing
faults in the software systems.
 Inspection is a well-known QA alternative familiar to most
experienced software quality professionals.
 Inspection is most commonly applied to code, but it could also be
applied to requirement specifications, designs, test plans and test
cases, user manuals, and other documents or software artifacts.
 The advantages of inspections are that they are very systematic,
controlled, and less stressful.
 Inspection
 Each development phase has entrance requirements; for
example, how to qualify to enter an inspection and exit
criteria, and how to know when to exit the inspection.
 The inspection team (which includes reader, author)
may have had a few hours to prepare, perhaps by
applying an analytic technique to a small section of the
product or to the entire product with a focus only on
one aspect, e.g., interfaces.
 A checklist, with questions is a common tool used in
inspections.
 Inspection of SRS
 Software Requirement Specification (SRS) phase is the

base of all subsequent phases in software engineering.

 The result is that the requirements are verified to be correct

and complete.
 Poor requirements ripple down the software development

and results in a product that does not meet the user’s

requirements or expectations.
 Inspection of SRS

 A major difficulty in testing the requirements document is

that testers have to determine whether the problem
definition has been translated properly to the requirements
document. Which requires:
 human skills which vary from person to person.
 envisioning the final product and coming up with what should be
tested to determine that the requirement solves the problem.
 Web Application Failures
A 2003 study by the Business Internet Group of San
Francisco found that:
72% (29/40) leading e-commerce sites, and
68% (28/41) government sites contained Web application
failures
25 “technical errors”
 E.g., page not found, multiple attempts to subscribe to a service

3 data errors
 E.g., page without text, wrong page returned
 Inspection of Web Site
 Easiest way to start is by treating the web site as a black
box.
Look at a sample website such as www.apple.com to get a
sense of the scale of such an endeavor.
Treat each page as a state with hyperlinks as state transitions.
 Verifying if
 HCI principles are properly followed
 Documented and de facto standards are met
 Uses
 Scenarios
 Questionnaire
 Inspections
 Inspection of Web Site
Web page text should be treated like documentation and
tested using the techniques we described previously.
Check for …
correctness of contact information e.g., phone numbers,
addresses
correctness of dates and copyright notices
title bar text, bookmark text on browser’s favorites
correctness of the ALT text (i.e., mouse over text)
layout issues when browser window is resized
 Inspection of Web Site
Each link should be checked to make sure it jumps to the
correct destination or website.
Ensure that hyperlinks are obvious:
E.g., underlined text, mouse pointer changes
If the link opens an e-mail message, test it
Send an e-mail and verify that you get a response.
Check for orphan pages that are part of the website but
cannot be accesses through a hyperlink.
Someone forgot to create the link
Might be intentional … Google will find it, though
 Inspection of Web Site
Do all graphics load and display properly?
Is a graphic missing or incorrectly named?
Does the website intermix text and graphics?
Does the text wrap around the graphics?
What happens when the browser window is re-sized?
Does the page load fast enough?
Are there too many graphics?
Did you try to test the website on a dialup connection
instead of a high-speed LAN?
 Inspection of Web Site
Forms are the text boxes, list boxes, and other fields
for entering and selecting information on the web
page.
Are the form fields positioned properly?
Are the fields the correct size?
Do they accept correct data?
Do they reject bad data?
Are optional fields really optional?
A favorite entry point for buffer overflow attacks (more
on this later).
Visibility of System Status
Course add/drop
 Course add/drop
Problem Check List Reference Detail
No information Visibility of 1.3 Users should kept
displayed about System Status informed about
system progress system progress with
in appropriate time.

No Confirmation Visibility of 1.4 No feedback messages

message when the System Status that would state
save button is (1) what the computer
pressed
has done and
(2) whether it was
successful or not
Consistency and Standards
 Consistency and Standards
Interface name Problem Check List Detail
Assessments Window title is not clear 4.1 Consistency and Window title should be
Standards clear

Assessments Sound( soft/harsh) is not 4.2 Consistency and Sound should be exists
exist. Standards in the interface(form)

Assessments Save button is not at 4.4 Consistency and If ” save” is a menu

bottom Standards choice, does it always
appear at the bottom of
the list?

Assessments exit button is not at 4.4 Consistency and If "exit" is a menu

bottom Standards choice, does it always
appear at the bottom of
the list?
 Consistency and Standards
Interface name Problem Check List Detail
Class attendance Window title is not 4.1 Consistency and Window title should be
clear Standards clear

Class attendance Sound( soft/harsh) is 4.2 Consistency and Sound should be exists
not exist. Standards in the interface(form)

class attendance Text color of button is 4.8Consistency and Are field labels
not consistent Standards consistent from one data
through out the entry screen to another?
system
 Consistency and Standards
Interface name Problem Check List Detail
Course offering-old Window title is not 4.1 Consistency and Window title should be
students clear Standards clear

Course offering-old Sound( soft/harsh) is 4.2 Consistency and Sound should be exists
students not exist. Standards in the interface(form)
Error Prevention
Attendance Entry
 Attendance Entry
R
e
q
.

N
o Description Problem Checklist Details
1Attendance Entry If teacher mistakenly clicks 1.1 Does the system prevents user Does System make this button
Present button 2nd time. All making error wherever possible? disabled ? or
already marked attendance will 1.3 Does the system warns the No Confirmation message is
be over written to Present states user if they are about take serious displayed.
which required rework. error?
2Attendance Entry if multiple records are open for 1.2 Does the error message No warning message with Yes/No
attendance marking, teacher indicates what action user need option "Are you sure you want to
might accidently click the Update to take? proceed loading the records of
button on different row which date:XX-XX-XXXX" is displayed.
will load attendance record of
different date which create
confusion or required rework.
3Attendance Entry if teacher wants to submit/lock 1.2 Does the error message Does System design provide
the attendance after attendance indicates what action user need Submit/Lock mechanism to lock
marking, currently there is no to take? the attendance of specific week?
mechanism. This record still
available for update for number
of days
4Attendance Entry If teacher click Select All check 1.1 Does the system prevents user Do system design supports
box then it will over write status making error wherever possible? removal of this checkbox? or
of all the check boxes to new 1.3 Does the system warns the No Confirmation message with
status which might force teacher user if they are about take serious Yes/Option “you data may be lost.
to rework again. error? Do you want to proceed?” is
displayed.
Course Offerings
 Course Offerings

R
e
q
.
N
oDescription Problem Checklist Details
1Course There is greater chance of 1.1 Does the system Does System provides verification
Offering typing mistake while prevents user making error mechanism?
entering semester number wherever possible? No verification message is displayed
in class-Id column of grid. if user type it wrongly.

2Course User might click Clear [1.3 Does the system warns No warning message "Are you sure,
Offering button accidently at any the user if they are about you want to clear the data" is
time which cause data loss. take serious error? displayed on click of clear button

3Course User might click Exit button 1.1 Does the system No warning message "Have you save
Offering accidently which cause data prevents user making error the data, Are you sure, you want to
loss. wherever possible? Exit" is displayed on click of Exit
button
Assigning Course to Teachers
R Assigning Course to Teachers

e
q
.
N
oDescription Problem Checklist Details
1Assigning courses It is difficult to work in grid 1.1 Does the system prevents user Does system provide row disable
and there might be chance making error wherever possible? mechanism which will help to avoid
that after selection of 1.3 Does the system warns the user if unnecessary change of record?
teacher and TF against they are about take serious error?
specified record it might be
change it again mistakenly

2Assigning courses User might click Clear button 1.1 Does the system prevents user No warning message "Are you sure,
accidently which cause data making error wherever possible? you want to clear the data" is
loss. 1.3 Does the system warns the user if displayed on click of clear button.
they are about take serious error?

3Assigning courses User might click Exit button 1.1 Does the system prevents user No warning message "Have you
accidently which cause data making error wherever possible? save the data, Are you sure, you
loss. 1.3 Does the system warns the user if want to Exit" is displayed on click
they are about take serious error? of Exit button
User Control and Freedom
Recognition Rather than Recall
Flexibility and Ease of Use
Help users recognize and recover
from errors
Help and Documentation
Assignment 3
Application of some other Web Testing Check list
upon any Web site.