TESTING TERMINOLOGY &

METHODOLOGY
OBJECTIVES
DIFFERENCE BETWEEN FAILURE,FAULT
AND ERROR
TEST CASE TEMPLATE

 Test case :Test case is a well-documented procedure designed to

test the functionality of a feature in the system.
TEST CASE TEMPLATE

Sr
NO Test Case ID Purpose Precondition Input Expected Output
SAKECECS Verify The login Need valid SAKEC
1 mail2022 SAKEC Account to login manjusha.kulkarni Successful login
@sakec.ac.in
           
           
           
           
           
           
           
           
           
TEST CASE TEMPLATE

 Test case ID: is the identification number given to each test case.
 Purpose :defines why the case is being designed.
 Preconditions: for running the inputs in a system can be defined, if required, in a
test case.
 Inputs : Inputs should not be hypothetical. Actual inputs must be provided, instead
of general inputs..
 Expected outputs are the outputs which should be produced when there is no
failure.
 Test cases are designed based on the chosen testing techniques. They provide
inputs when the system is executed. After execution, observed results are compared
with expected outputs mentioned in the test case
LIFE CYCLE OF BUG
BUGS-IN PHASE

 This phase is where the errors and bugs are introduced in the
software. Whenever we commit a mistake, it creates errors on a
specific location of the software .

 when this error goes unnoticed, it causes some conditions to fail,

leading to a bug in the software.

 This bug is carried out to the subsequent phases of SDLC, if not

detected.
BUGS-OUT PHASE

 If failures occur while testing a software product, we come to the

conclusion that it is affected by bugs.

 However, there are situations when bugs are present, even though
we don’t observe any failures.

 That is another issue of discussion. In this phase, when we observe

failures, the following activities are performed to get rid of the bugs.
BUG CLASSIFICATION

 In this part, we observe the failure and classify the bugs

according to its nature. A bug can be critical or catastrophic in
nature or it may have no adverse effect on the output behaviour
of the software.

 Bug isolation

 Bug resolution
 BUG CLASSIFICATION
 Bug isolation Bug isolation is the activity by which we locate the module
in which the bug appears. Incidents observed in failures help in this
activity. We observe the symptoms and back-trace the design of the
software and reach the module/files and the condition inside it which has
caused the bug. This is known as bug isolation.

 Bug resolution Once we have isolated the bug, we back-trace the design
to pinpoint the location of the error. In this way, a bug is resolved when
we have found the exact location of its occurrence.
STATES OF A BUG
STATES OF A BUG

New: The state is new when the bug is reported first time by a tester.

Open :The new state does not verify that the bug is genuine. When the
test leader approves that the bug is genuine, its state becomes open.

Assign: An open bug comes to the development team where the

development team verifies its validity. If the bug is valid, a developer is
assigned the job to fix it and the state of the bug now is ‘ASSIGN’.
STATES OF A BUG

 Deferred: The developer who has been assigned to fix the bug
will check its validity and priority. If the priority of the reported
bug is not high or there is not sufficient time to test it or the bug
does not have any adverse effect on the software, then the bug
is changed to deferred state which implies the bug is expected
to be fixed in next releases.
STATES OF A BUG

 Rejected: It may be possible that the developer rejects the bug after checking its validity, as it is
not a genuine one. Test After fixing the valid bug, the developer sends it back to the testing team
for next round of checking. Before releasing to the testing team, the developer changes the bug’s
state to ‘TEST’.

 Test:It specifies that the bug has been fixed by the development team but not tested and is
released to the testing team.

 Verified/fixed :The tester tests the software and verifies whether the reported bug is fixed or not.
After verifying, the developer approves that the bug is fixed and changes the status to ‘VERIFIED’.
STATES OF A BUG

 Reopened :If the bug is still there even after fixing it, the tester changes its status
to ‘REOPENED’. The bug traverses the life cycle once again. In another case, a bug
which has been closed earlier may be reopened if it appears again. In this case, the
status will be REOPENED instead of OPEN.

 Closed: Once the tester and other team members are confirmed that the bug is
completely eliminated, they change its status to ‘CLOSED’.
BUGS AFFECT ECONOMICS OF SOFTWARE
TESTING
BUG CLASSIFICATION BASED ON
CRITICALITY
Bugs can be classifi ed based on the impact they have on the software under test.
Critical Bugs

This type of bugs has the worst effect such that it stops or hangs the normal functioning of the software. For

example, in a sorting program, after providing the input numbers, the system hangs and needs to be reset.

Major Bugs

This type of bug does not stop the functioning of the software but it causes a functionality to fail to meet its

requirements as expected. For example, in a sorting program, the output is being displayed but not the correct

one.
Medium Bugs
Medium bugs are less critical in nature as compared to critical and major
bugs. If the outputs are not according to the standards or conventions, e.g.
redundant or truncated output, then the bug is a medium bug.
Minor Bugs
These types of bugs do not affect the functionality of the software. These
are just mild bugs which occur without any effect on the expected behaviour
or continuity of the software. For example, typographical error or misaligned
printout
BUG CLASSIFICATION BASED ON SDLC

Requirements and Specifi cations Bugs

The fi rst type of bug in SDLC is in the requirement gathering and specifi cation
phase
Design Bugs
Design bugs may be the bugs from the previous phase and in addition those errors
which are introduced in the present phase.
Control fl ow bugs
Logic bugs
Processing bugs
BUG CLASSIFICATION BASED ON SDLC

 Data fl ow bugs
 Error handling bugs
 Race condition bugs
 Boundary-related bugs
 User interface bugs
Coding Bugs
Interface and Integration Bugs
System Bugs
 DIFFERENCE BETWEEN EXHAUSTIVE
TESTING AND EFFECTIVE TESTING
Sr. Effective Testing Exhaustive Testing
No.
1 Effective testing emphasizes efficient techniques to test Exhaustive or complete testing means that energy
the s/ws/w so that important features will be tested statement in the program of every possible path
within the constrained resources. combination with every possible combination of data
must be executed.
2 It is a practical method It is not possible to perform complete testing

3 It is feasible because: a) It checks for s/w reliability and It is not feasible because: a) Achieving deadlines b)
no Bugs in the final product b) It tests in each phase c) It Various possible outputs c) Timing constraints d) No.
uses constrained resources of possible test environments.
4 It is cost effective It is not cost effective
5 It is less complex and less time consuming It is complex and time consuming
6 It is adopted such that critical test cases are concerned It corners all the test cases
first
TESTING PRINCIPLES