2019 SQA Unit 3-4

Surya InfoEdge
SQA UNIT 3-4

By: Zeeshan sir
Branches @ Bhandup and Thane
Head Office: UG 304 Dreams The Mall Bhandup(W) Contact No: 9821257630
Prof: Zeeshan Sir.. Surya InfoEdge
Dawn of your life
TYBSCIT Admission Starts From 5th May 2019
Unit 3
Q. Write a note on Unit Testing:
• It is a process of taking a module & testing it in isolation from the rest of the software
& comparing the actual results with the result defined in the specifications & design of
module.
• A unit can be
• a. Single procedure
b. A Function
c. A body of code that implements a single function
d. The smallest body of code that can be compiled and executed by itself.
• Why to test each unit independently?

• Fault isolation & debugging becomes easier during unit testing
• We can take an exhaustive approach in case of unit testing
• What to test during unit testing?

• Module Interfaces tested to check the correct flow of information in & outside the
module
• Local Data Structure
• Independent/Basis Paths tested to ensure all statements within the module are
executed at least once during testing
• Boundary Conditions: output/computation at boundary values is correct.
• Internal Logic: loops, precedence, comparison of data types
• Error handling Paths
• Problems with unit testing:

• A component is not a stand-alone unit so
• How to test it without anything to call it?
• How to test it without any module to be called by it?
• Driver & Stubs are the solution.
• Driver:
• Main program that accepts test case data, passes data to the component to be tested
and prints relevant results.
• Stub:
• Sub-ordinate modules that are called by the module to be tested.
• It is a dummy sub-program that does minimal data manipulation, provides verification
of entry and returns the control to module under testing.
• Scaffolding:
Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

Practical oriented teaching and easy notes prepare for best results.Page No: 1
Dawn of your life
• The overhead code are Drivers & Stubs
• A test harness used to automatically generate scaffolding
• It allows us to test our module in an isolated environment by simulating the rest of s/w
functionalities (taking care of i/p’s, o/p’s, parameters )
Q. Write a note on boundary value testing.
• The boundary-value-testing technique is a black-box technique that focuses on
Boundaries of the input & output equivalence classes.
• Input domain testing (also called "boundary value testing") is the best-known
specification-based testing techniques which focus on input domain.
• Functional Testing: program is an input from a certain domain to a certain

domain to a certain range
• Impossible to check all input/output combination need to choose some:
• For each variable, select five values:
• Min minimum
• Min+ Slightly above the minimum
• Nom Nominal
• Max- Slightly below the maximum
• Max Maximum
• Technique also applicable to range boundaries
.
• Using boundary Value Testing technique tester creates test cases for required input
field.
• For example, an Address text box which accepts values between 1- 500 characters.
So, writing test cases for each character once will be very difficult so that will choose
boundary Value Testing.
• Example1. Boundary Value Testing:

• Suppose you want to test the password field which accepts minimum of 8 characters
and maximum of 12 characters.
• So we need to define the boundary of each class of inputs
• The tester will have to write Test case to satisfy Boundary value considering values
from Valid Region to Invalid Region and Values which define exact boundary.

Dawn of your life
• For example, we require 5 Test cases:

• a. Password length less than 8
b. Password length exactly 8
c. Password length between 9-11
d. Password length exactly 12
e. Password length more than 12
• There are four variation of boundary value testing:
• Normal boundary value testing.

• Robust boundary value testing.
• Worst-case boundary value testing.
• Special value testing.
Q. Normal Boundary Value Testing
Normal boundary value concerned with valid values of the input variables. One or
more variables and 5 values (4 extreme and 1 nominal).

Dawn of your life
• For one variable there are 5 test cases.

• Test cases for a variable x, where a < = x < = b.
Experience shows that errors occur more frequently for extreme values a variable.
Example for Two variables (Variable X and Y):

Dawn of your life
In the above example there are two variables and each variable having 5 values
Example for variable X:
• Min value= 10
Min value +1= 11
Max value=100
Max value-1 = 99
Normal value = Min + max/2
=10 + 100/2
= 55
• Same will be calculated for variable Y and we will get value 155.

Dawn of your life
• In boundary, Extreme values are not taken. Only normal values are
taken for test cases.
• We have to write test cases by having 2 variables. One variable will be holding
extreme values and other variable will be holding normal values and conducting
different
test cases and feeding into the input engine will estimate whether these variables r
output values lying inside or outside the Domain.
•
Example to calculate Boundary Value Testing
Extreme Value: Min Min+1 Max-1 Max
• Normal values: Min+ Max/2
No. of Test Cases: 4x + 1 where x is no. of variable
4(2+1)
8+1=9
So total 9 test cases will be designed for Boundary value test.
TC1 = (10, 155)
TC2 = (11, 155)
• TC3 = (55,155)TC4 = (99, 155)
TC5 = (100,155)
ТС6 = (110, 55)
TC7 = (111, 55)
TC8 = (199, 55)
TC9 = (200, 55)
Q. Robust Boundary Value Testing:
• Robust boundary value testing is a simple extension of normal boundary value

testing, In addition to the five boundary value analysis values of a variable, when the

Dawn of your life
extreme are exceeded with a value slightly greater than the maximum (max+) and
avalue slightly less than the minimum (min-).
• Robustness Testing is usuallydone to test exception handling.
In robustness testing, Software is tested insuch a way that some of the invalid valuesare
testedas inputs.
Example for Testing points with one variable (Variable X):

Dawn of your life
Test cases for a variable X, where a < = X < = b

Example for Testing points with Two variables (Variable X and Y):

Dawn of your life
In the above example there are Two Variables and each variable holding 7 values.
Total 13 Test Cases will be designed.
Total Normal values = 7 + 6 = 13
Formula for testing cases more than 2 variables: 6(n+1)
4 values are taken but in Robust on each variable two
values are added one slightly greater than Max (max +) and less than Min(min - ), So
values will be 6 instead of 4.
6(n+1) OR 7+6(N-1)
6(2+1) 7+6(2-1)
12+1=13 13(1) =13TC
TC1=(39,85), TC2=(40,85), TC3=(41,85),TC4=(60,85) TC5=(79,85),TC6=(80,85),

TC7=(81,85),TC8=(59,60), TC9=(60,60), TC10=(61,60), TC11=(109,60),TC12=(110,60),
TC13=(111,60)
Q. Worst case boundary value testing:
In worst case boundary value testing need to make combination of each value of one
variable with each value of other variable (Cartesian Product )

Dawn of your life
In worst case testing only 4 extreme values are tested not 6 values which are added in
robust testing. Only need to see the extension of the boundary value without single fault
assumption.
In worst case testing, need to perform Cartesian product i.e. each value of one variable
with each value of other variable.
So, according to above example we have 2 variables and each having 5 values.
Total 25 Test Cases will be designed.
Example:
TC1= (30, 60)
TC2 = (30, 61)
TC3= (30, 85)
TC4= (30, 109)
TC5 = (30, 110)
.
.
.
TC25 = (60,110)
If more than 2 variables are there then need to apply formula for test case
Formula for more than 2 variables is 5(N). Where N is number of variables.
Q. Special value testing:
Special Value Testing is executed by expert tester who goes through each and every
aspect of the program and uses their domain knowledge to devise test cases. This is the
highly popular functional testing which provides accurate results. Special value testing is
Dawn of your life
Ad-hoc in nature means no guidelines is used by the tester other than their “Best
Engineering practice”
Special Value Testing Example:

For integer: -1, O, 1
For String: Strings containing only blanks, strings containing no alphabetic
characters, The empty strings.
For floating point numbers: -e, o, +e
Other Special Value Example:

For times of the day: midnight, noon
Example of special values:

Employee age limit to check hire status of employee
.
Hire Status
1)Don't Hire
2)Can hire on part time basis only
3)Can hire as full time employee
4)Don't hire
Age Limit
1) 0-15
2) 16-17
3) 18-54
4) 55-99
What about ages -3 and 101?
The requirement doesn't specify how this value should be treated.
Code to implement the rules

If (employeeage>= o&& employeeage<=15) hirestatus="NO”
If (employeeage> = 16 && employeeage<=17) hirestatus="PART”
If (employeeage > =18 && employeeage<=54) hírestatus="FULL"
If (employeeage >=55 && employeeage<=99) hirestatus=”NO”
Special values on or near the boundaries in this example are:
{-1,0,1}, {14,15,16}, {17,18,19} {54.55.56} {99,100,101}
Q. Random Value Testing:

Random Testing is black box test design technique where test cases are always
selected randomly means by using an algorithm named pseudo random generation.
This technique is always used for non-functional attributes such as performance and
reliability points.
Results of the output are compared against software specifications to verify that the test
output is
Dawn of your life
pass or fail.
C++ example for Random testing
int myAbs(int x) {
if (x>0) {
return x;
}
else {
return x;// bug: should be ‘-x’
}
}
Random value for this function could be {123. 36, -35.48.o}. Only the value '-35’
triggers the bug.
Q. Equivalence Classes:
Equivalence classes is used as basis for functional testing

It is used ina situationwhen in-depth testing is required or when there is need to
avoid redundancy.
Asredundancy is not handled by BVA technique as massive redundancy is there
in tables of
test cases.
In Equivalence class technique the input and output domain is divided into finite
number of equivalence classes.
In this technique where input values required for testing are grouped into two
classes.
1) Valid Input Class: This class holds all valid inputs.

2) Invalid Input Class: This class holds all invalid inputs.
Dividing the set of test conditions into group is called equivalence partition
Equivalence partition is also known as equivalence classes
2) Example 1 of EP (Equivalence partition)

Username range (6-12)

Dawn of your life
Traditional Equivalence Class Testing:
Traditional form testing focuses on Invalid data values.

It was the program user's responsibility to provide valid data.

Dawn of your life
There was no guarantee about results based on invalid data.
Improved Equivalence Class Testing
Input and/or output variables have well defined intervals within the boundaries
If function F with two variables (X1, X2) then
a<-X1<=d, with intervals [a,b), [b,c),[c,d]
e<=x2<=g, with intervals [e,f), [f,g]
I closed interval,( open interval
Weak Normal Equivalence Class Testing:
Weak equivalence class testing is based on the single faultassumption,
if one or more faults occurring simultaneously then rarely an error is occurred.

Equivalence class testing is accomplished by using one variable from each
equivalence class
5. Strong Robust Equivalence Class Testing:
The robust part is consideration of invalid values and strong part refers to the
multiple fault assumptions. This form of testing produces test cases for all valid and
invalid elements of the Cartesian product of all the equivalence classes.

Dawn of your life
Decision Table-based:
1. Decision Table: A Decision Table is a good way to deal with combination of

things (e.g. inputs and their associated outputs).
It is called cause-effect table because it is an associated logic diagramming technique

called cause-effect graphing'. This is used to derive the decision table.
Why decision table is important:

Decision tables provide the systematic way of stating complex business rules,
which helps the developer and tester as well.
A decision table technique is used basically in both Testing and requirement

management.

Dawn of your life
it helps the developers to do a better job can also lead to better relationships with
them.
Testing combinations can be a challenge, as the number of combinations can

often be huge.
Testing all combinations may be unrealistic or unfeasible.
How to use decision table for testing design:
The first thing we need to know or need to identify a suitable function or

subsystem which reacts according to a combination of inputs or events.
The number of combination will be become unmanageable if the system contains

too many inputs. So system should always take fewer inputs.
To deal with large number of combinations or conditions it would be better to divide them
into subsets and to deal with subset one at a time.
Once you come to know or identified all the aspects which need to be combinedthen you
put them into a table listing all the combinations of ‘true and False’ or ‘yes and no’.
The decision table has four portions:
1) The part to the left of the bold vertical line is the stub portion.
2) The right is the entry portion.
3) The part above the bold horizontal line is the condition portion.
4) The below is the action portion.
The stub is divided into two parts, Condition stub for condition entries and action
stub for action entries. Rules indicate which action.
Dawn of your life
In decision table when conditions c1, c2 and c3 are all true, actions al
and a2 occur.
When c1 and c2 are both true and c3 is false, then action a1 and a3 occur.
Where ci is true and c2 is false is called a "don't care" entry, a4 occurs.
The 'don't care’ has two interpretations: The condition is irrelevant, or the
condition does not apply sometimes people enter "N/A" for latter interpretation.
When we have binary condition (true/false, yes/no, o/1), the condition portion of a
decision table is a truth table (from propositional logic). This structure guarantees that
we consider every possible combination of condition value.
Q. Decision Table Techniques:
In decision table techniques we deal with combinations of inputs.
To identity test cases with decision tables, we interpret conditions as inputs and actions
as outputs.
Conditions are interpreted as equivalence of inputs.

Actions are interpretedas output and action refers to major functional processing of the
item tested.
With a complete decision table need to have a complete

set of test cases.
Example: Triangle problem.
3 variables has been taken as input (a, b & c). On these 3 variables conditions will be
applied to check the output as per action taken on the conditions.
Conditions:
Condition will be applied on variables a,b,c.
Actions:
It's not a Triangle
It's a Triangle
It's a Triangle but size of three sides is different than it is a Scalene.
If it is a Triangle but size of Two side is equal than it should message it is a
Isosceles.
If all sides of triangle is equal than it should message it is an Equilateral
Otherwise if should message impossible when given condition is not satisfied.

Dawn of your life
Q. Cause and Effect Graphing:
Cause Effect Graph is a black box testing techniques.
It is basically used for hardwaretesting but now adapted to software testing,
it usually checks external behaviour of asystem.
In this testing technique, test cases that logically relate causes (inputs) to Effects
(outputs) to produce test cases.
A "Cause" stands for an input condition that state aboutan internal change in the system.
And an "Effect" represents an output conditionresulting is a combination of causes.
Cause-and-effect graphs attempt to follow this

pattern, by showing unit inputs on the left side of a drawing, and using AND, OR, and
NOT "gates" to express the flow of data across stages of a unit.

Dawn of your life
The basic Notation for the graph:
Decision tables do not scale up very well (a limited entry table with n conditions
has 2n rules). There are several ways to deal with this, use extended e
decision tables.
Path Testing
Path Testing is a structural testing method based on the source code or algorithm
and NOT based on the specification.
Path testing is an approach to testing where you ensure that every path through a
program has been executed at least once.
Path testing assumptions:

Dawn of your life
The Specifications are Accurate.
The Data is defined and accessed properly.
There are no defects that exist in the system other than those that affect control
flow.
Program Graphs:
Given a program written in an imperative programming language, its program graph

is a directed graph in which nodes are statements fragments, and edges represents
flow of controls. (A complete statement is a "default" statement fragment)
IF i and j are nodes in the program graph. An edge exists from I to node j if and onlyif the
statement fragment corresponding to node j can be executed immediately after
the statement fragment corresponding to node i
Deriving a program graph from a given program is an easy process. It is

illustrated herewith four of the basic structured programming constructs.
DD Paths:
The best-know form of code-based testing is based on a construct known as a
decision to decision path (DD- path) (Miller, 1977).
The name refers to a sequence of statements, In Miller's words, begins with the
"outway" of a decision statement an
ends with the "inway" of the next decision statement.
A Decision to Decision Path or DD-Path is a path for execution (usually through a

flow graph representing a program, such as flow chart) between two decisions.
The DD-path concepts is known as a" linear code sequence and jump" and is
abbreviated by the acronym LCSAJ.

Dawn of your life
Program graphs of four structured programming constructs

Properties of DD- Path:
Every node on a flow graph of a program belongs to one DD-path.
If the first node on a DD-path is traversed, then all other nodes on that path will
also be traversed.
The DD path graph is used to find independent path for testing.
Every statement in the program has been executed at least once
Definition:
A DD-path is a sequence of nodes in a program graph such that
Case 1: It consists of a single node with indeg=0.

Case 2: It consists of a single node with outdeg=0.
Case 3: It consists of a single node with indeg>= 2 or outdeg>=2.
Case 4: It consists of a single node with indeg =1 and outdeg = 1.
Case 5: It is a maximal chain of length >=1.
Case 1 and 2 establish the unique source and sink nodes of the program graph of
a structured program as initial and final DD-paths.
Case 3 deals with complex nodes; it assures that no node is contained in more
than one DD-path.
Case 4 is needed for "short branches"; it also preserves the one-fragment, one
' Case 5 is the "normal case," in which a DD-path is a single entry, single-exitsequence
of nodes (a chain).

Dawn of your life
The "maximal" part of the case 5 definition is used to
determine the final node of a normal (nontrivial) chain.
DD-path graph is the directed graph in which nodes are DD paths of its program
graphs, and edges represent control flow between successors DD-path.
·
Node 4 is a case 1 DD-path, we will call it "first" Node 23 is a case 2 DD-path and
we will call it "last".
Node 5 through 8 are case 5 DD-paths. Node 8 is the last node in this DD-path
because it is the last node that preserves the 2-connected property of the chain.

Dawn of your life
If we go beyond node 8 and include node 9 then we violate the indegree =outdegree = 1
criterion of a chain.
If we stop at node 7, we violate the "maximal" criterion.Node 10,11,15,17,18 and 21 are
case 4 DD-paths.
Node 9,12,13,14,16,19,20 and 22 are case 3 DD-paths.
Node 23 is a case 2 DD path.
Basis Path Testing:
Basis Path Testing is a type of Structural Testing (White Box Testing) used
designing test cases to determine all possible paths of execution at least once.
There are 4 steps to create Basis Path Testing:
Step 1: Draw the flow Graph.

Step 2: Calculate the Cyclomatic complexity.
Step 3:.Calculate the basis set of independent path.
Step 4: Prepare test cases that for each path.
Example: Draw Flow graph of program.
Step1: Draw Flow Graph.
Step 2: Calculate Cyclomatic complexity
V(G) = E-N+2
Where
E-Number of edges
N-Number of Nodes
V(G)=P+ 1

Dawn of your life
Where P Number of predicate nodes (node that contains condition)
V(G) =8-7+2=3
V(G) 2+1= 3
Step 3:
Calculate the basis set of independent paths:
Path 1: 1,2,3,5,6,7
Path 2: 1,2,4,5,6,7
Path 3: 1,6,7
Step 4: Prepare Test cases for each path
Test cases Expected Outcome

Path 1 A=B
Path 2 A=c
Path 3 A=50
Q. Data flow testing:
Data flow testing refers to forms of structural testing that focus on the points
which variables receive values and the points at which these values are used (or
referenced).
Two mainline forms of data flow testing: one provides a set of basic
definitions and a unifying structure of test coverage metrics, while the other is based on
a concept called a "program slice."
Both start with a program graph, both move back in the direction of functional
testing.
Both of these methods are difficult to perform manually.
Few commercial tools exist to make life easier for the data flow and slicing testers.
On the positive side, both techniques are helpful for coding and debugging.
Most programs deliver functionality in terms of data. Variables that represent data
somehow receive values, and these values are used to compute values for other
variables.
Early data flow analyses often centered on a set of faults that are now
known as define/reference anomalies:
A variable that is defined but never used (referenced)

Dawn of your life
A variable that is used before it is defined

A variable that is defined twice before it is used
1.Define/use Testing:
The following definitions refer to a program P that has a program graph G(P) and a
set of program variables v.
G(P) has a single-entry node and a single-exit node.
We also disallow edges from a node to itself. Paths, sub-paths. The set of all paths inP
is PATHS(P)
Definition
Node n e G(F) is a defining node of the variable v ㅌ V, written as DEF(v, n), if
and only if the value of variable vis defined as the statement fragment corresponding to
node n.
Input statements, assignment statements, loop control statements, and procedure

calls are all examples of statements that are defining nodes. When the code
corresponding to such statements executes, the contents of the memory location(s)
associated with the variables are changed.
Node n e G(P) is a usage node of the variable v E V, written as USECv, n), if and
only if the value of the variable v is used as the statement fragment corresponding to
node n.
Output statements, assignment statements, conditional statements, loop control

statements, and procedure calls are all examples of statements that are usage nodes
When the code corresponding to such statements executes, the contents of the memory
location(s) associated with the variables remain unchanged.
A usage node USE(V, n) is a predicate use (denoted as P-use) if and only if the statement n
(denoted C-use).
Mn The T
nodes corresponding to predicate uses always have an outdegree>=2
nodes corresponding to computation uses always have an outdegree <1.

A definition / use path with respect to a variable v (denoted du-path) is a path in PATHS(P)
nodes DEF(, m)and USECv, ) such that mand n are the initial and final nodes of the path.

Dawn of your life
A definition-clear path with respect to a variable v (denoted de-path) isa
definition/use path in PATHS(P) with initial and final nodes DEF(, m) and USECv,
n) such that no other node in the path is a defining node of v.
Q. Slice - Based Testing:
It creates various subset(called slice) of a program with respect to its variables and their
selected locations in the program.
It simplify the process of testing of the program. Hence slices are simpler than the
original program
A program slice is a set of program statements that contributes to, or affects the value
of, a variable at some point in a program.
Example 1. of slice-based Testing:

Program code which we need to slice for testing:
a=4;
b=5;
c = b2;
d= a2 + b2
c = a+b
Slicing is done to focus on variables and their use in the

program. For slicing of program we will use formula of slicing.
Slicing criteria:
S(v,n); where v is variable and n is number of line where you want to check the
variable.
I want to check the variable 'c'. So, we need to slice the variable 'c' to check the
line number where it is and where it is used.
Two times 'c' is used in the program.

We will slice the program and check both the slice wherever 'c' is used.

Dawn of your life
In the above example we checking Variable 'e is at line no. 3 and on
line no. 3 the program code is cbe. It means c is used with b which is at line no. 2.
So,
we have mentioned line no. 2 and 3 in our example
S(c, 5)-1,2,5
Slice 2
In this example will take another slice of program where c is used. In this example
we
are checking variable c which is at line no. 5. And at line no. 5 the code is c
a
It means c is used with variable a and variable b. variable is used at line no. 1 and
variable b is used at line no. 2 and variable c which we are checking is at line no.
5. In the
above example we have used line no. 1,2,5
Example 2. Of slicing:

Dawn of your life
Unit 4
Q. Write a note on verification &validation.
• Verification and Validation activities are complementary &completely dependent on

each other.
• Two views of quality can be seen in software testing:
• A. Conformance of requirement' is defined as developers view of quality.
• It is called as Verification
• Fitness for use, which is definedas customer view of quality performed by tester &
given to customer for acceptance testing.
Verification:
• Verification is also called as 'static technique'

• It is not involving execution ofcode, program and work product.
• It helps in identification of defect and its location which helps in correction.
Advantages of Verification:
• Verification ensures that the work product is following the processes correctly
defined by organization or customer.
It can find the defects & it’s root cause
• Cost of finding & fixing defects is less.
• Disadvantages of Verification:
• It cannot show whether the developed software is correct or not. Rather, it shows
whether the processes have been followed or not.
• Actual working software may not be accessed by verification as it does not cover
a kind of execution of a work product.
Validation:
• Validation is an approach to evaluate whether the final built software product

meets its specification or not.
• Validation is also called as 'dynamic testing' because it involves execution of code to

find defects.
• Validation is basically done by the testers during testing
Advantages of Validation

Dawn of your life
• It satisfies customer’s requirement & needs
• It represents actual user interaction with the system
• Black-box testing approach is use for system, integration & acceptance testing
Disadvantages of Validation:
• Test cases can fail to find defects.

• Overhead code needs to be written for drivers & stubs
• Tester might do redundant testing by executing same section of code again &
again.
Q. Methods of Verification.
There are many methods of verification:
Self-Review:
It is not an official review in verification as it is assumed that everybody does as self-

check before giving product for verification
Defects found in self-review help in self-education & improvement
Advantages of self-review:
It is an excellent tool for self-learning
There is no ego involved as finding is not shared with anybody.
Disadvantages:
Developer will be more focus on coding rather than reviewing the code developed by
them
Developer with less confidence may change the correct implementation
Peer review:
This reviews are conducted frequently in SDLC
Code review is done by developer

Dawn of your life
Test case review is done by tester
Two types of peer review:
Online peer review:
In this review, author & reviewer meet together & give review jointly
Offline peer review:
In this review, author informs reviewer that software is ready for review & reviewer
reviews it according to his time availability & send results to author
Author may accept or reject review comments
Advantages:
It is highly informal & unplanned
Defects are discussed & decision are taken informally
Disadvantages:
Reviewer might not be an expertise
Peer might fix defects but won’t show mistake of his friends
Superior Review:
Superior such as team leader or module leader will review the product made by sub-
ordinates
Advantages of superior review:
Superior may have better understanding than author about requirements & design
Superior can share his experience
Disadvantages of superior review:
It can hamper superior’s work itself
If project is related to new technology then this approach won’t work
Walk-Through:
It involves larger team along with author reviewing the project
Advantages:
Each & every member is involve in decision-making

Dawn of your life
Useful for training entire team at once
Disadvantages:
Time can be constrained
Whole team might not be expert in project
Inspection
It involves domain expert & absence of author
They can be external to the organization
Advantages:
Expert opinions are available
Disadvantages:
Expert may give his judgement but he might be unaware about need of the customer.
Q. Entities involved in verification:
These are some entities may change as per specific circumstance, organisation and
customer requirements.
List of entities performing verification:
Requirement review:
Business analysis, System analysis, Project team.
Design review:
Project team, Customer/user

Code review:
Development team, Customer/user
Project plan review:

Project team, Customer/user, Suppliers
Test artifact review:
Test team, Development team, Customer/user

Dawn of your life
2) SDLC phase and verification techniques used:

Planning documents
Inspection, Walkthrough, Peer Review
Requirements
Inspection, Peer Review

Design
Walkthrough, Peer Review

Coding
Peer Review, Superior Review
Test plan
Inspection, Walkthrough, Peer Review
Test scenario
Test Cases
Peer Review, Superior Review
Test Results
Q.Types of review on the basis of stage/phase
There are three types of review:
In-process review
Milestone review
Post-implementation review
In-process review:

Dawn of your life
This review is conducted to check whether the input given is correct or not whether all
processes are following correctly or not
It can take place in between any project of SDLC
Common steps of in-process reviews are:
Work product & metric undergoing review are created & submitted to the stakeholder in
advanced
Inputs are received from stakeholders to initiate various actions
Risk are identified, reviewed & actions are implemented
Issues like hardware availability, software availability & training are identified & actions
are implemented
2. Milestone review
It is performed periodically basis on time frame, completion of phase or milestone

achieved
Ex. Requirement review at the end of requirement phase
Three types of milestone review:
Phase end review:
It is performed at the end of any phase of SDLC
It is suitable for waterfall cycle
Periodic Review:
It is performed in weekly, monthly & quarterly manner
Percent Completion Review:
It is a combination of both periodic & phase-end
Development activities are assessed on basis of percent completion
Post-Implementation Review:
It is performed after the deployment of project
Process:
All activities of project are reviewed

Dawn of your life
All reusable components are added in an organization repository
Q. Review in testing lifecycle:
Reviews associated with STLC are as follows:
Test-readiness review:
It is conducted by test managers or test leads with the project manager to ensure that
the product under development is ready for testing
It is carried out at every stage of development (Unit testing, integration testing, system
testing, interface testing, system testing acceptance testing, etc.)
Prerequisites Training:
Prerequisites such as the database, operating system, etc. may be needed during the
software installation.
If it is specified in the requirement statement that installation must check for the
availability of such prerequisites, then it must be tested for these requirements.
Updation Testing:
During software installation, it is expected that the system should check whether the
same software already exists there or not.
Ifthe existing version of the software is older than the one being installed, then it also
prompts for a repair or new installation.
Un-installation testing:
This is done by the organizations to verify if the un-installation is clean or not

whenever any application is un-installed,all the associated files should be removed
from the disk.
Care should be taken that applications running before installation must be running
after installation and also once un-installation is done.
Test-completion review:
It is conducted when a testing cycle is completed.
It recommends about the status of an application.
It indicates the development team whether a product can go to the next phase or it
needs any repairing before it can be declared successful.

Dawn of your life
Q. Coverage in verification:
Coverage in verification are:
Statement coverage
It is a white box testing technique, which involves the execution of all the statements at
least once in the source code.
It is a metric, which is used to calculate and measure the number of statements in the
source code which have been executed.
The main drawback of this technique is that we cannot test the false condition in it.
(Statement coverage = No of statements Executed/Total no of statements in the source

code * 100)
Example:
Read A
Read B
if A>B
Print “A is greater than B”
else
Print "B is greater than A"
end if
Set1: If A =5, B =2
No of statements Executed: 5
Total no of statements in the source code: 7
Statement coverage =5/7*100 = 71.00 %
Set1:If A =2, B =5
No of statements Executed: 6
Total no of statements in the source code: 7
Statement coverage =6/7*100 = 85.20 %
Path Coverage:
The way that path coverage testing works is that the testers must look at each possible
scenario, so that all lines of code are covered.
In a very basic example, consider a code function that takes in a variable "x" and returns
one of two results: if x is greater than 5, the program will return the result "A" and if x is
less than or equal to 5, the program will return the result "B."
The code for the program would look something like this:
Dawn of your life
input x
if x > 5 then
return A
else return B
In order for path coverage testing to effectively "cover all paths," the two test cases must
be run, with x greater than 5 and x less than or equal to 5.
Experts generally consider path coverage testing to be a type of white box testing, which
actually inspects the internal code of a program, rather just relying on external inputs
and strategies that are considered black box testing, which do not consider internal
code.
Decision Coverage:
Decision coverage or Branch coverage is a testing method, which aims to ensure that
each one of the possible branch from each decision point is executed at least once and
thereby ensuring that all reachable code is executed.
That is, every decision is taken each way, true and false. It helps in validating all the
branches in the code making sure that no branch leads to abnormal behaviour of the
application
Read A
Read B
IF A+B >10 THEN
Print"A+B is Large"
ENDIF
IfA>5 THEN
Print"A Large"
ENDIF
to calculate BranchCoverage, one has to find out the minimum number of paths which
will ensure that all the edges are covered.Inthiscase there isno single path which will
ensure coverage of all the edges at once.The aim is to cover all possible true/false
decisions.
(1)1A-2C-3D-E-4G-5H
(2)1A-2B-E-4F
HenceDecisionorBranchCoverageis2.

Dawn of your life
Q. Coverage in Validation:
It is also termed as 'prioritization technique where primary parts of the system are tested
fully so that the system should not have defects under normal circumstances.
And the slices are obtained on the basis of prioritization.
Following are the some famous coverage of Validation:
Requirement Coverage:
Requirements are defined in 'requirement specification
All the requirements are not mandatory.
They can be put in different classes such a must be, 'should be', and 'could be' and are
prioritized accordingly.
All high-priority requirements expressed as 'must' and lower level priority requirements
expressed as should be' and could be'.
Requirement coverage definition:
Priority of requirement
P1(Must)
P2 (Should be)
P3(Could be)
Coverage offered
100%
50%
25%
Functionality Coverage Sometimes, requirements are expressed in terms of

functionality required for the application to work successfully. Functionalities also have
different priorities as per their requirement.
Priority of Functionalities
P1(Must)
P2 (Should be)
P3(Could be)
Coverage
100%
50%
25%

Dawn of your life
Feature coverage:
An application may need some features as defined in requirements.
Features are a group of functionalities doing similar things
Feature may have different feature of doing things, and each of them is functionality for
the application.
If we are saving a file in Microsoft Word, then 'saving represents the

features while 'different ways to save the file' may represent different functionalities.
Features coverage definition:
Priority of Features
P1(Must)
P2 (Should be)
P3(Could be)
Coverage offered
100%
50%
25%
Q. Acceptance testing.
Acceptance Testing generally done by the user and/or customer to understand

whether the software satisfies their requirement or not.
Here are some predefined methodologies, condition and test cases will be used for
acceptance testing.
There are three levels of acceptance testing:
Alpha Testing:
Alpha testing is done by the customer in development

environment.
The testing is done at development side on dummy data.
Alphatesting may be doneworking properly.
There is no direct impact of such testing on customer as testingis done off-site.

Dawn of your life
Beta Testing:
Beta testing is done at customer side.
Testing is actuallyconducted by customer in production/semi-production environment.
Tester/Developer may be appointed to help customer in testing the application

and recording the problem, if any.
Gamma Testing:
Gamma testing is used for limited liability testing at selectedplaces.
Gamma check is performed when the application is ready for release to the specified
requirements
This is performed directly without going throughall the testing activities at home.
The application is given to few people for usingit in production, and feedback is obtained
from them.
Q. Levels of Validations:
Validation can be applied at different stages of software development.
Unit Testing:
Software is made up of many units.

Individual unit need to betested to find whether they have implemented the design
correctly or not.
Unit testing is done by developer as they are capable of understanding individual
units under testing.
Thus, unit testing needs a definition, coding and use of stubs
and drivers for testing
Integration Testing:
Integration testing involves testing of many units bycombining them together to form a
sub-module or module.
If designing of stubs/drivers are needed to execute integrated parts,then in such
cases integration is done by developer.
And if integration is executed independently, then integration is done by tester.
Integration testing mainly refers to detail design or low-level design.
Interface Testing:
Dawn of your life
Interface testing involves testing of software with
environment factors (such as database and operating system), where
application is supposed to work.
If an application is communicating with other application then third-party

components (such as communication software) combining all these application
and then conducting testing is termed as 'interface testing
System Testing:
System testing involves end-to-end testing of a system to find the behaviour of system
with respect to expectations
System testing is actually a set of processes which may include functionality, user
interface, performance and security testing.
Q. V-Model for Software.
V-Model is a Validation Model.
Validation model describes the validationactivities associated with different phases of

software development.
At the requirement phase, during system testing & acceptance testing, thesystem tester
and users confirm that requirements have been really met or not.
Design phase is associated with interface testing which covers design specification
testing as well as structural testing
Program-level designs are associated with integration testing.
At code level, unit testing is done to validate individual units
Requirement Analysis:
Requirements are gathered, analysed & studied in this phase.
It is not important how the system is implemented but important is what the system is
supposed to do.
Here, the product requirements is understood from customer's perspective.
System Design:
It is a time to design the complete software, after getting product requirements.
The system design will have the understanding detailing the complete hardware and
communication setup for the product development.
Dawn of your life
The system test plan is developed based on the system design.
Architectural Design:
In this phase, the data transfer and communication between the internal modules and
other system is clearly understood
Module Design:
In this phase, the system breaks down into small modules.
Coding phase:
Best programming language is decided based on system & architectural requirements
Coding of the system module is designed.
Code goes through multiple code reviews.
Unit Testing:
Unit testing is a white box testing technique, where code is written which invokes a
method (or any other piece of code) to testwhether the code fragment is giving the
expected output or not
Integration Testing:
In this phase the integration test cases are executed.
Integration testing is a technique where tested modules are integrated and tested
whether
Integrated modules are giving the expected results.
In simpler words, it validates whether thecomponents of the application work together as

expected.
System Testing:
In this phase all the system test cases, functional test cases andnon-functional test
cases are executed.
In other words, the actual and full fledge testing of the application takes place here.
Defects are logged and tracked for itsclosure
Acceptance Testing:
Dawn of your life
Acceptance testing is done to validate that business requirements are met in the user
environment.
Q. VV Model:
VV Model is known as Verification and Validation Model.
VV model the activities related to verification and validation.
It is also termed as 'Quality Model’.
Various Activities of VV Model associated with each phase of development life cycle.
Requirements:
Requirements are obtained from customer using techniquewith the intention to find if
there is any gap between user requirement and requirement definitions
Requirement Verification:
Generally requirement verification through inspection
Experts in domain, customers and other stakeholders may involve in conducting

inspection.
Outcome of the inspection must be recorded
Defects must becorrected before going to the next stage of development life cycle
Requirement Validation:
First stage of validation is writing complete use-case
Second stage of validation is writing test cases
Design:
Design may include high-level design or architectural design, and low-level design or
detail design
Design verification:
Project team along withdesigner may walkthrough the design to find the completeness
and give comments.
Many organisation follow some specific tools or methodologies(UML) to create

design
Dawn of your life
Design Validation:
Validation of design is done at two stages during softwaredevelopment life cycle.
The first stage of Validation happens when data low diagram canbe created by referring
to the design document.
If the flow of data is complete, design isalso considered complete.
The second stage of validation happens at integration testingand interface testing
Coding:
Coding is an activity of writing individual units as defined in low-level design

Itis done by developers
Code verification:
As coding is done, It undergoes a code review i.e. peer review
Peer review helps in identification of errors with respects to coding standards, indenting
standards, commenting standards, and variable declaration.
Validation of coding is done through unit testing where individual units are tested
separately.
Drivers & Stubs code needs to be written.
Q. Characteristics of good requirements:
Adequate:
Requirement must explain entire system from user’s side.
Constraints & Assumptions must be defined & documented with possible solutions
Requirement should not talk about any impossible thing
Clear/Unambiguous:
Requirement must be clear for designer as well as for developer.
For ex: if user wants username textbox should contain at least 8 characters then he
should specify that appropriate message should be generated if user don’t enter
minimum 8 characters
Dawn of your life
Measurable:
Requirement can be specified within boundaries like minimum & maximum so that it can
be verified
Feasible:
Requirement must be feasible
Requirement should be supported by technology or system configuration.
Non-conflicting with each other:
Two requirements must not specify anything which is conflicting with each other
Generally, requirements are prioritized.

Dawn of your life
Surya InfoEdge
King of Certification (KOC)
Advanced Web Designing @ 15000

Course starts from 1st May 2018
Microsoft SQL Server 2012-14 Certification @ 12000

Course starts from 18th February 2018
Java, Basic Android & Advanced Android @ 15000

Course starts from 1st May 2018
CMS using Wordpress @ 7000

Course starts from 24thFebruary 2018
ASP.NET MVC @ 12000

TYBSCIT starts from 1st February 2018
TYBSCIT @ 25000
TYBSCIT starts from 1st May 2019
Branches at Bhandup and Thane


2019 SQA Unit 3-4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2019 SQA Unit 3-4

Uploaded by

Copyright:

Available Formats

Surya InfoEdge

SQA UNIT 3-4

Branches @ Bhandup and Thane

Q. Write a note on Unit Testing:

• Why to test each unit independently?

• What to test during unit testing?

• Problems with unit testing:

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

• Functional Testing: program is an input from a certain domain to a certain

• Example1. Boundary Value Testing:

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

• For example, we require 5 Test cases:

• There are four variation of boundary value testing:

• Normal boundary value testing.

Q. Normal Boundary Value Testing

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

• For one variable there are 5 test cases.

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

Q. Robust Boundary Value Testing:

• Robust boundary value testing is a simple extension of normal boundary value

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

Example for Testing points with one variable (Variable X):

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

Test cases for a variable X, where a < = X < = b

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

12+1=13 13(1) =13TC

TC1=(39,85), TC2=(40,85), TC3=(41,85),TC4=(60,85) TC5=(79,85),TC6=(80,85),

Q. Worst case boundary value testing:

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

Total 25 Test Cases will be designed.

Q. Special value testing:

Special Value Testing Example:

Other Special Value Example:

Example of special values:

What about ages -3 and 101?

The requirement doesn't specify how this value should be treated.

Code to implement the rules

Q. Random Value Testing:

Equivalence classes is used as basis for functional testing

1) Valid Input Class: This class holds all valid inputs.

2) Example 1 of EP (Equivalence partition)

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

Traditional Equivalence Class Testing:

Traditional form testing focuses on Invalid data values.

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

There was no guarantee about results based on invalid data.

Improved Equivalence Class Testing

a<-X1<=d, with intervals [a,b), [b,c),[c,d]

e<=x2<=g, with intervals [e,f), [f,g]

I closed interval,( open interval

Weak Normal Equivalence Class Testing:

Weak equivalence class testing is based on the single faultassumption,

if one or more faults occurring simultaneously then rarely an error is occurred.

5. Strong Robust Equivalence Class Testing:

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

1. Decision Table: A Decision Table is a good way to deal with combination of

It is called cause-effect table because it is an associated logic diagramming technique

Why decision table is important:

A decision table technique is used basically in both Testing and requirement

Suggest your friends to join Surya InfoEdge. TY BSCIT @ 25000

Testing combinations can be a challenge, as the number of combinations can

Testing all combinations may be unrealistic or unfeasible.