Chapter1
A perspective on testing
A PERSPECTIVE ON TESTING
Basic definitions:Error: - people make errors, a good synonym is mistake, when people make mistakes while
coding, we call these mistakes bugs, Error tend to propagate, a requirements error may be
magnified during design and amplified still more during coding.
Fault: - A fault is a result of an error. it is more precise to say that fault is representation of an
error, where representation is mode of expression, such as narrative text, dataflow diagrams,
hierarchy charts, source code, and so on, defect is a good synonym for fault, as bug, Faults can
be elusive, When a designer makes error of omission the resulting fault is that something is
missing that should be present in representation.
Failure: - A failure occurs when fault executes. 2 subtleties arise here: 1.Failures only occurs in
an executable representation, which is usually taken to be source code, or more precisely, loaded
object code. 2. This definition relates failure only to faults of commission.
Incident: - When a failure occurs, it may or may not be readily apparent to the user (or customer
or tester).An incident is the symptom associated with a failure that alerts the user to the
occurrence of the failure.
Test: - testing is obviously concerned with errors, faults, failures and incidents. A test is the act
of exercising s/w with test cases. A test has two distinct goals: to find failures and demonstrate
correct execution.
Test case: - Test case has an identity and is associated with a program behavior. A test case also
has a set of inputs and expected outputs.
Dept of MCA
KNSIT
Lecturer: Lalitha
Chapter1
A perspective on testing
Software Testing Life Cycle: -
Note: See this diagram in text book (all the diagrams)
In the development phases, opportunities arise for errors to be made, resulting in faults that
propagate through the remainder of the development processes.


The first three phases are putting bugs IN; the testing phase is finding bugs; and last three
phases are getting bugs OUT (Poston, 1990).
The process of testing can be subdivided into separate steps: test planning, test case
development, running test cases and evaluating test results.
Requirement Specification:-Business Analyst gathers the requirements from the client and
prepares Customer Requirement Specification (CRS) document.
Design:- If sr.Developers are able to understand the Customer Requirement Specification (CRS)
document they will prepare High Level Design and Low Level Design documents else they will
translate CRS to Software Requirement Specification(SRS) with the help of Business Analyst
and prepares High Level Design and Low Level Design documents.
Coding: - As per the requirement documents (SRS, HLD, LLD) developers have to develop
(code) the application.
Testing:- Tester has to understand the requirements thoroughly (SRS, HLD, LLD), prepare Test
Cases ( by using diff Black box testing methods like Boundary value analysis, Equivalence
class testing and decision table testing), execute the test cases by applying different Black box
testing types( functional ,Integration & system testing) with valid and invalid data.
Note:-Before the Black Box Testing developer has to finish the Unit Testing (by using diff white
box testing methods like path testing, conditional testing, loop testing etc.).
Dept of MCA
KNSIT
Lecturer: Lalitha
Chapter1
A perspective on testing
Testing: - Testers find the bugs by executing the Test Cases.
Fault Classification:-In Testing phase testers have to find the faults and send that information to
the developers with severity of the fault (high, medium and low) called fault classification.
Fault Isolation:-Developers & Testers have to involve to find the area of the fault (where, when
and why the fault occurs in the application) is called fault isolation.
Fault Resolution:-Developers have to confirm and fix the fault based on the requirements and
information given by the testers.
Conclusion:-If any error in the requirement phase it will fall till coding, that can be found in the
application at the time of testing and fixed at the fault resolution phase. Fixing the fault may
introduce another error, so tester has to do regration testing (retesting the fix whether the related
functionalities of faults are working correctly or not) till the application works according to the
requirements.
Test Case:Definition:

Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A
Test Case will consist of information such as requirements testing, test steps, verification steps,
prerequisites, outputs, test environment, etc.
A set of inputs, execution preconditions and expected outcomes developed for a particular
objective, such as to exercise a particular program path or to verify compliance with a specific
requirement.tfrdqi;’

Test Case template:Test Case ID
Purpose
Precondition
Inputs
Expected Outputs
Post Condition
Executed History
Date
Dept of MCA
Result
Version
KNSIT
Run By
Lecturer: Lalitha
Chapter1
A perspective on testing
Test Case Id: - Test Case Id is used to identify the test case uniquely and to communicate the
defect with the development team. For example tester found defect while executing the
TC#2(Test Case Id)
Tester has to include Test Case id (TC#2) in the defect report to communicate with developers.
Purpose: - Purpose is nothing but description of the Test Case, suppose if you want to test a
gmail login page purpose is gmail login with valid user.
Precondition: - Before executing the Test Case what are the updates or settings we have to do in
the application is called pre condition.
If you want test a Gmail login page is working correctly or not with valid user, precondition is
user should signup (Existing user).
Inputs:-What inputs we are giving to test this particular test case. (Gmail login with valid user)
Inputs to test a gmail login page are URL, UNAME, PWD, SUBMIT BUTTON, and LOGOUT
MENU ITEM.
Expected Output: - As per the requirement we can expect result called expected result.
Eg: INPUT
EXPECTED OUTPUT
URL
GMAIL LOGIN PAGE
VALID UNAME, PWD, SUBMIT BUTTON
GMAIL MAIN PAGE
Post Condition:It should update the Gmail previous login time on gmail home page.
Execution History:Date: - Test Case Execution date
Result: - Pass/Fail
After reading the requirement specifications we can expect the output that is called expected
output, result after executing the test case is actual result.
Note: - If both expected and actual results are same Test Case is Pass else Test Case is Fail.
Version: - If any change in the requirement causes modifications in the test case too (that time u
have to change the version of the Test case v1.1, v1.2 etc.)
Run by: - Name of the Tester, who executed the particular Test case.
Dept of MCA
KNSIT
Lecturer: Lalitha
Chapter1
A perspective on testing
Sample Test Case:http://testcasehelp.blogspot.in/2009/12/22-testcases-to-test-gmail.html
Test Case ID:Purpose:Pre-condition:Input
GM#1
Gmail login with valid user
User should signup (existing user)
Expected Output
Status
Open browser and type the Url It should disply the gmail login
www.gmail.com
page and cursor should be
positioned at Username textbox.
Type valid username
Password
and click
“submit” button.
and It should display Gmail Home
on page. Home page should have the
unread mails and read mails of
Inbox.
Click on one unread mail
Mail should be Displayed.
Click on spam
If any junk mails are there that
should be displayed.
Enter senders mail id, subject,
type text and click on “send”
button.
It should display the sent mails.
Click on compose mail
Click on sent mails
Click on sign out
Page should be logged out and
should redirect to gmail login
page.
Remarks
Pass
Pass
Pass
Pass
Pass
Pass
Pass
Executed History:
Date:
Result:
Version:
Run By:
Dept of MCA
20/10/2012
Pass
GM V1.0
Pushpa
KNSIT
Lecturer: Lalitha
Chapter1
A perspective on testing
Insights from a Venn diagram
Testing is fundamentally concerned with behavior is orthogonal to the structural view common
to s/w developers.
A quick differentiation is that the structural view focuses what it is and the behavioral view
considers what it does. One of the continuing sources of difficulty for testers is that the base
documents are usually written by and for developers: the emphasis is therefore on structural,
7instead of behavioral information. In this section we develop a simple Venn diagram that
clarifies several nagging questions about testing.
Consider a universe of program behaviors. Given a program and its specification,
consider the set S of specified behaviors and the set P of programmed behaviors. The below
diagram shows the relationship among our universe of discourse as well as the specified and
programmed behaviors. What if certain specified behaviors have not been specified? These are
faults of omission. Similarly, what if certain programmed behaviors have not been specified?
These correspond to faults of omission and to errors that occurred after the specification was
complete. The interaction of S and P is the correct portion that is behavior that are both specified
and implemented
Now consider the relationship among sets S, P and T. There may be specified behaviors that are
Not tested (region 2&5), specified behaviors that are tested (region 1 & 4) test cases that
correspond to unspecified behaviors (region 3 & 7).
Similarly, there may be programmed behaviors that are not tested (region 2&6) programmed
behaviors that are tested (region 1 & 3) and test cases correspond to unprogrammed
behaviors (region4 & 7).each of these regions is important. If specified behaviors exist for which
No test cases are available. The testing is necessarily incomplete. If certain test cases correspond
to unspecified behaviors, some possibilities arise: either such a test case is unwarranted, the
Specification is deficient, or the tester wishes to determine that specified non behavior does not
Occur.
Dept of MCA
KNSIT
Lecturer: Lalitha
Chapter1
A perspective on testing
Identifying test cases: 

Two fundamental approaches are used to identify test cases, Known as functional and
structural testing.
Each of these approaches has several distinct test cases identification methods, more
commonly testing methods (BVA, ECT, DTT, Path Testing etc).
Functional Testing:It is based on the view that any program can be considered to be function that maps
values from its input domain to values in its output range.
Functional test cases have 2 distinct advantages:
1) They are independent of how the software is implemented, so if implementation changes, the
test cases still useful.
Dept of MCA
KNSIT
Lecturer: Lalitha
Chapter1
A perspective on testing
2) Test case development can occur in parallel with the implementation, thereby reducing the
overall project development interval.
Structural Testing: It is the other fundamental approach to test case identification. It is also called white box
(or even clear box) testing
The below diagram shows the results of test case identified by two functional methods.
A identifies a larger set of test cases than does method B. Is larger set of test cases necessarily
better? This is an excellent question and structural testing provides important ways to develop an
answer. notice that, for both methods, the set of test cases is completely contained within the set
of programmed behavior. Because the structural methods are based on the program, it is hard to
imagine these methods identifying behaviors that are not programmed. It is easy to imagine,
however that a set of structural test cases is relatively small with respect to the full set of
programmed behaviors.
Dept of MCA
KNSIT
Lecturer: Lalitha
Chapter1
A perspective on testing
The Functional versus Structural Debate: The Venn diagram presented earlier yield a strong resolution to this debate, Recall that
the goal of both approaches is to identify test case.
Functional testing uses only the specification to identify test cases, while structural
testing uses the program source code as the basis of test cases identification.
The Venn diagram view of testing provides one final insight. What is the relationship
between the set T of test cases and set S and P of specified implementation behaviors? Clearly
the test cases in T are determined by the test case identification method used. A very good
question to ask is how appropriate is this method? To close a loop from earlier discussion, recall
the casual trail from error to fault, failure, and incident. If we know what kind of errors we are
prone to make and if we know what kind of faults are likely to reside in the s/w to be tested.
Dept of MCA
KNSIT
Lecturer: Lalitha
Chapter1
A perspective on testing
Error and Fault taxonomies: 



Our definitions of error and fault hinge on the distinction between process and the
product: process refers to how we do something, and product is the end result of a
process.
The point at which testing and s/w quality assurance (SQA) meet is that SQA typically
tries to improve the product by improving the process. In that sense, testing is clearly
more product oriented.
SQA is more concerned with reducing errors endemic in the development process, while
testing is more concerned with discovering faults in a product
Faults can be classified in several ways: the development phase in which the
6corresponding error occurred, the consequences of corresponding failure, difficulty to
resolve risk of no resolution and so on.
1. Mild
Misspelled word
2. Moderate
information
Misleading or redundant
3. Annoying
Truncated names, bill for $0.00
4. Distributin
Some truncations not processed
5. Serious
Lose a transaction
6. Very serious
Incorrect transaction execution
7. Extreme
Frequent “very serious” errors
8. Intolerable
Database corruption
9. Catastrophic
System shutdown
10.classified
Infections
Fault
by severity
TYPE
Input faults
Output faults
Logic faults
Computation faults
Interface faults
Data faults
Dept of MCA
Shutdown that spreads to others
INSTANCE
Correct Input not accepted
Correct result at wrong time
Extreme condition neglected
Incorrect operand
Parameter mismatch
Incorrect storage
KNSIT
Lecturer: Lalitha
Chapter1
A perspective on testing
Waterfall Model (WFM):Waterfall model is one of the Software Development Life Cycle model (SDLC) used to
develop the software, contains seven phases.
1.
2.
3.
4.
5.
6.
7.
Requirement specification
Preliminary Design
Detailed Design
Coding
Unit Testing
Integration Testing
System Testing
Requirement Specification:-Business Analyst gathers the requirements from the client and
prepares CRS document.
Design: - If sr. Developers are able to understand the CRS document they will prepare HLD and
LLD documents else they will translate CRS to SRS and prepares HLD (Preliminary Design) and
LLD (Detailed Design) documents.
HLD design like blue print of the building (structure of the building, how many windows, doors
and shape of the building)
LLD is like internal structure of the building (color of the window, metal of the window etc.)
Coding: -As per the requirement documents (SRS, HLD, LLD) developers have to develop
(code) the application.
Dept of MCA
KNSIT
Lecturer: Lalitha
Chapter1
A perspective on testing
Unit testing:-Testing each and every line of source code by applying different structural testing
methods like (Path Testing, Data Flow Testing etc.)
Integration Testing: - The testing of combined parts of an application to determine if they
function correctly together is called Integration testing. There are two methods of doing
Integration Testing Bottom-up Integration testing and Top Down Integration testing.
System Testing: - This is the next level in the testing and tests the system as a whole. Once all the
components are integrated, the application as a whole is tested rigorously to see that it meets
Quality Standards.
System testing is so important because of the following reasons:

The application is tested thoroughly to verify that it meets the functional and technical
specifications.

The application is tested in an environment which is very close to the production environment
where the application will be deployed.

System Testing enables us to test, verify and validate both the business requirements.
Why water fall model:
In this requirements are freezed.
Why to freeze the requirements in WFM:1. If the requirements are changed in middle, we should change the design documents then
there is a chance to get more bugs.
Where to use WFM:1. Life critical software uses WFM (X-RAY, Health related)
2. Machine critical software uses WFM(Aircraft)
Advantage:- At the end we will get stable project because the requirements are freezed.
Disadvantages:-Testing is a small phase which is done after coding, if there is a mistake in a
requirement it falls till coding it leads lot of rework.
Dept of MCA
KNSIT
Lecturer: Lalitha