CS -10
SAD, SOFTWARE QUALITY
ASSURANCE AND TESTING
By Rachel
UNIT 2 – PART 3
Basics Of Software Testing, Types Of
Software Testing, Verification and
Validation
Topic - 4
Static Testing
INTRODUCTION OF SOFTWARE TESTING
• The fifth phase of system development life cycle is testing
and each and every event about testing must be recorded in
test summary report which becomes work product of this
phase.
• Test summary report is one of the evidence for testing. Also
it helps in configuration Management.
• It should be clear in mind that the philosophy behind testing
is to find errors.
• Test cases are devised with this purpose in mind. A test case
is a set of data that the system will process as normal input.
STATIC TESTING
• In Static testing, software isn't actually used. This checks
algorithm in document and checks structural representation
without executing it. It is primarily syntax checking of the code
and manually reviewing the code or document to find errors.
• This can be used to care for coding standards. We can also find
uninitialized variable, parameter mismatching in prototypes,
variable declared but not used.
• It is carried out by different ways:
1. Informal Review
2. Walkthrough
3. Technical Review
4. Inspection
1. Informal Review
• Software reviews can find issues earlier and more cheaply than they
would be identified by testing or by defect detection process.
• The cost to find and fix a defect by review is very less than when the
same defect is found by test execution.
• These reviews can be used to train personnel who prepare
documentation easily and they can contribute in defect prevention
process.
• Without waiting the work has been completed, early and frequent
reviews work samples can identify errors, which can be corrected before
committing more erroneous work.
• This reduces overall development time and used to develop high-quality
software, and dramatically decrease the error-rate.
2. Walkthrough
• A designer or programmer organize peer review and invite members
of the development team and other interested parties to study a
software product including coding, and the participant can ask
questions and make comments about possible errors, violation of
development standards, and other problems.
3. Formal Technical Review
• A method involving a structured encounter in which a group of
technical personnel analyzes or improves the quality of the original
work product as well as the quality of the method.
• Software Quality Improvement can be achieved by improved quality
of the original work and finding defects early (less costly).
• It reduces defects and leads to improved productivity.
• The review team prepares a formal review plan around the objectives
of the review, the type of evaluation to be carried out and the time
schedule required. An overall plan covers the following areas:
(A)Administrative Plan: Review area objectives, operating costs,
actual operating performance and benefits.
(B)Personnel requirements Plan: Review performance objectives and
training performance to data.
(C)Hardware Plan: Review performance specifications
(D)Documentation Review Plan: Review the system development
effort.
• The review team prepares a formal review plan around the objectives
of the review, the type of evaluation to be carried out and the time
schedule required.
A. Administrative Plan
The following two activities are reviewed under this plan:
1. User Objective: This is an extremely critical area since
it may be possible that over a period of time either the
system does not meet the initial objectives of the user or
the user objectives get changed as a result of changes in
the overall objectives of the organization. The results of
the evaluation are documented for future reference.
2. Operating Costs and Benefits: Under the administration
plan, current budget designed to manipulate the costs and
savings of the system is closely reviewed.
B. Personnel Requirement Plan
• Under this plan, all activities involving system
personnel and staff members associated with the
system are evaluated.
• After the plan is developed, the review group
evaluates the following:
• Personnel performance objectives compared
with current performance levels and
• Training performance through testing,
conducting interviews and other data gathering
techniques.
C. Hardware Plan
The hardware of the new system is also reviewed including
terminals, CRT(Cathode Ray Tube) and communication
network. The main target is a comparison of current
performance specifications with design specifications. It also
points out necessary modification to be made.
D. Documentation Review Plan
The reason for review plan is to evaluate the accuracy and
completeness of the documentation compiled to date and to
its conformity with documentation standards established
earlier.
4. Inspection
An inspection is a visual examination of a software product to
detect and identify software anomalies, including errors and
deviations from standards and specifications. It is not widely
used because of the following reasons:
• Lack of time
• Not seen as a priority
• Not seen as value added
• Lack of understanding of formalized techniques
• Improper tools used to collect data
• Lack of training of participants
• Pit(Pre-Integration Test) programmer against reviewers
Topic - 5
Dynamic Testing
DYNAMIC TESTING
• Program execution and analysis is performed on its real
output. The output is recorded for different test cases
included in the test suite.
• Dynamic analysis tool can be used to analyze and produce
reports.
• The main concept is to produce report in the form of
histogram or any line chart showing how much proportion of
code is executed in terms of branch, code coverage or any
other way.
• The output of dynamic testing can be used as an evidence of
testing.