Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Software Quality Assurance and Testing

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 14

Software Quality Assurance and

Testing
Testing Objectives
 Testing should systematically uncover different classes of
errors in a minimum amount of time and with a minimum
amount of effort.
 A secondary benefit of testing is that it demonstrates that
the software appears to be working as stated in the
Software Requirement Specifications(SRS). 
 The data collected through testing can also provide an
indication of the software's reliability and quality. But,
testing cannot show the absence of defect -- it can only
show that software defects are present.
Testing Objectives are:
1. Testing is a process of executing a program with the intent
of finding an error.
2. A good test case is one that has a high probability of
finding an as-yet-undiscovered error.
3. A successful test is one that uncovers an as-yet
-undiscovered error.
Testing Principles
1. All tests should be traceable to customer
requirements
As we have seen, the objective of software testing is to
uncover errors. It follows that the most severe defects
(from the customer’s point of view) are those that cause
the program to fail to meet its requirements.
2. Tests should be planned long before
testing begins.
Test planning can begin as soon as the requirements model
is complete. Detailed definition of test cases can begin as
soon as the design model has been solidified. Therefore, all
tests can be planned and designed before any code has been
generated.
3. The Pareto principle applies to software testing.
Stated simply, the Pareto principle implies that 80 percent of
all errors uncovered during testing will likely be traceable
to 20 percent of all program components. The problem, of
course, is to isolate these suspect components and to
thoroughly test them.
4. Testing should begin “in the small” and
progress toward testing “in the large”.
The first tests planned and executed generally focus on
individual components. As testing progresses, focus shifts in
an attempt to find errors in integrated clusters of
components and ultimately in the entire system
5. Exhaustive testing is not possible.

The number of path permutations for even a moderately


sized program is exceptionally large. For this reason, it is
impossible to execute every combination of paths during
testing. It is possible, however, to adequately cover program
logic and to ensure that all conditions in the component-
level design have been exercised.
6. To be most effective, testing should be
conducted by an independent third party.
By most effective, we mean testing that has the highest
probability of finding errors (the primary objective of
testing).
Test Plan
 Document that consists of test cases designed for
different testing objects and testing attributes.

 The tests are executed in a logical and sequential manner.


•Test Plan helps us determine the effort needed to validate the
quality of the application  under test.
The test plan serves as a summary of the test activities to be
performed.

•A test plan states the following:


1. What the items to be tested are?
2. At what level they will be tested?
3. What sequence should the be tested in?
4. How the test strategy will be applied to the testing of each
item and describes the test environment
Test Case Design
 Def:- “A test
case is a set of instructions designed to
discover a particular type of error or defect in the
software system by inducing a failure.”
 The goal of test case is to ensure that there are no errors in the
program and if there is it should be depicted immediately.
 An ideal test case should contain all inputs to the program.
 There are two criteria to select test cases they are:
 Specifying a criterion for evaluating a set of test cases.
 Generating a set of test cases that satisfy a given criterion.
 Each test cases require a proper documentation preferably a
fixed format.
 Example is given below:
Test Case Name Test Case ID
Purpose of Test Testing Object(Unit, Application, or module,
etc.)
Test attribute
Test Focus(Function, Feature, Process, Interface, Validation Verification, etc.)

Test Type(Alpha, Beta, Unit, Integration, System)


Test Process Set of Instructions For conducting the Test-
Initial State Condition-Inputs-Specifications-
Output Expected.

Test Result Expected and Actual and Comparison, Error


Description, Post-Process State

Action Correction, Authorization, and Feedback


Through Retest

Action to Initialize Pre-Test Status

You might also like