0% found this document useful (0 votes)
1 views

unit_2_testing_

The document outlines two primary testing methodologies: black-box and white-box testing. Black-box testing focuses on evaluating the functionality of an application without knowledge of its internal workings, while white-box testing involves examining the internal logic and structure of the code. Various techniques under each methodology, such as statement coverage, decision coverage, and loop testing, are discussed to highlight their advantages and disadvantages.

Uploaded by

Anushika Singh
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
1 views

unit_2_testing_

The document outlines two primary testing methodologies: black-box and white-box testing. Black-box testing focuses on evaluating the functionality of an application without knowledge of its internal workings, while white-box testing involves examining the internal logic and structure of the code. Various techniques under each methodology, such as statement coverage, decision coverage, and loop testing, are discussed to highlight their advantages and disadvantages.

Uploaded by

Anushika Singh
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 25

Unit 2

Testing methodologies

Black-Box Testing

The technique of testing without having any knowledge of the interior workings of
the application is called black-box testing. The tester is oblivious to the system
architecture and does not have access to the source code. Typically, while
performing a black-box test, a tester will interact with the system's user interface
by providing inputs and examining outputs without knowing how and where the
inputs are worked upon.
The following table lists the advantages and disadvantages of black-box testing.

Advantages Disadvantages

Well suited and efficient for large code segments. Limited coverage, since only a
selected number of test scenarios
is actually performed.

Code access is not required. Inefficient testing, due to the fact


that the tester only has limited
knowledge about an application.

Clearly separates user's perspective from the Blind coverage, since the tester
developer's perspective through visibly defined cannot target specific code
roles. segments or errorprone areas.

Large numbers of moderately skilled testers can The test cases are difficult to
test the application with no knowledge of design.
implementation, programming language, or
operating systems.

White-Box Testing

White-box testing is the detailed investigation of internal logic and structure of the
code. White-box testing is also called glass testing or open-box testing. In
order to perform white-box testing on an application, a tester needs to know the
internal workings of the code.
The tester needs to have a look inside the source code and find out which
unit/chunk of the code is behaving inappropriately.
The following table lists the advantages and disadvantages of white-box testing.

Advantages Disadvantages

As the tester has knowledge of the Due to the fact that a skilled tester is
source code, it becomes very easy to find needed to perform white-box testing, the
out which type of data can help in testing costs are increased.
the application effectively.

It helps in optimizing the code. Sometimes it is impossible to look into


every nook and corner to find out hidden
errors that may create problems, as many
paths will go untested.

Extra lines of code can be removed which It is difficult to maintain white-box testing,
can bring in hidden defects. as it requires specialized tools like code
analyzers and debugging tools.

Due to the tester's knowledge about the


code, maximum coverage is attained
during test scenario writing.

White box testing techniques

White box testing techniques analyze the internal structures the used data
structures, internal design, code structure and the working of the software rather
than just the functionality as in black box testing. It is also called glass box testing
or clear box testing or structural testing.
Working process of white box testing:
 Input: Requirements, Functional specifications, design documents, source
code.
 Processing: Performing risk analysis for guiding through the entire process.
 Proper test planning: Designing test cases so as to cover entire code.
Execute rinse-repeat until error-free software is reached. Also, the results are
communicated.
 Output: Preparing final report of the entire testing process.

Testing techniques:
 Statement coverage: In this technique, the aim is to traverse all statement
at least once. Hence, each line of code is tested. In case of a flowchart, every
node must be traversed at least once. Since all lines of code are covered, helps
in pointing out faulty code.

Statement Coverage Example

Statement Coverage is a white box testing technique in which all the executable
statements in the source code are executed at least once. It is used for calculation
of the number of statements in source code which have been executed. The main
purpose of Statement Coverage is to cover all the possible paths, lines and
statements in source code.
Statement coverage is used to derive scenario based upon the structure of the code
under test.

In White Box Testing, the tester is concentrating on how the software works. In
other words, the tester will be concentrating on the internal working of source code
concerning control flow graphs or flow charts.

Generally in any software, if we look at the source code, there will be a wide variety
of elements like operators, functions, looping, exceptional handlers, etc. Based on
the input to the program, some of the code statements may not be executed. The
goal of Statement coverage is to cover all the possible path’s, line, and statement in
the code.

Let’s understand this with an example, how to calculate statement coverage.

Ex: Source Code:

Printsum (int a, int b) { ------------ Printsum is a function


int result = a+ b;
If (result> 0)
Print ("Positive", result)
Else
Print ("Negative", result)
} ----------- End of the source code
Scenario 1:
If A = 3, B = 9

The statements marked in yellow color are those which are executed as per the
scenario

Number of executed statements = 5, Total number of statements = 7

Statement Coverage: 5/7 = 71%

Likewise we will see scenario 2,

Scenario 2:

If A = -3, B = -9

The statements marked in yellow color are those which are executed as per the
scenario.

Number of executed statements = 6

Total number of statements = 7

Statement Coverage: 6/7 = 85%

But overall if you see, all the statements are being covered by 2 nd scenario’s
considered. So we can conclude that overall statement coverage is 100%.
What is covered by Statement Coverage?

1. Unused Statements
2. Dead Code
3. Unused Branches
4. Missing Statements

Decision Coverage
Decision Coverage is a white box testing technique which reports the true or false
outcomes of each boolean expression of the source code. The goal of decision
coverage testing is to cover and validate all the accessible source code by checking
and ensuring that each branch of every possible decision point is executed at least
once.
In this coverage, expressions can sometimes get complicated. Therefore, it is very
hard to achieve 100% coverage. That’s why there are many different methods of
reporting this metric. All these methods focus on covering the most important
combinations. It is very much similar to decision coverage, but it offers better
sensitivity to control flow.

Example of decision coverage


Consider the following code-

Demo(int a) {
If (a> 5)
a=a*3
Print (a)
}
Scenario 1:Value of a is 2

The code highlighted in yellow will be executed. Here the “No” outcome of the
decision If (a>5) is checked.

Decision Coverage = 50%

Scenario 2: Value of a is 6
The code highlighted in yellow will be executed. Here the “Yes” outcome of the
decision If (a>5) is checked.

Decision Coverage = 50%

Test Case Value of A Output Decision Coverage

1 2 2 50%

2 6 18 50%

 Branch Coverge: In this technique, test cases are designed so that each
branch from all decision points are traversed at least once. In a flowchart, all
edges must be traversed at least once.

4 test cases required such that all branches of all decisions are covered, i.e, all

edges of flowchart are covered

Branch Coverage is a white box testing method .The purpose of branch coverage
is to ensure that each decision condition from every branch is executed at least
once. It helps to measure fractions of independent code segments and to find out
sections having no branches.
For example, if the outcomes are binary, you need to test both True and False
outcomes.

The formula to calculate Branch Coverage:

Example of Branch Coverage


To learn branch coverage, let’s consider the same example used earlier

Consider the following code

Demo(int a) {
If (a> 5)
a=a*3
Print (a)
}

Branch Coverage will consider unconditional branch as well

Test Case Value of A Output Decision Coverage Branch Cover

1 2 2 50% 33%

2 6 18 50% 67%

Advantages of Branch coverage:

Branch coverage Testing offers the following advantages:

 Allows you to validate-all the branches in the code


 Helps you to ensure that no branched lead to any abnormality of the
program’s operation
 Branch coverage method removes issues which happen because of
statement coverage testing
 Allows you to find those areas which are not tested by other testing methods
 It allows you to find a quantitative measure of code coverage
 Branch coverage ignores branches inside the Boolean expressions
 Condition Coverage: In this technique, all individual conditions must be
covered as shown in the following example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’
In this example, there are 2 conditions: X == 0 and Y == 0. Now, test these
conditions get TRUE and FALSE as their values. One possible example would
be:
 #TC1 – X = 0, Y = 55
 #TC2 – X = 5, Y = 0
Condition Coverage or Expression coverage
is a testing method used to test and evaluate the variables or sub-expressions in
the conditional statement. The goal of condition coverage is to check individual
outcomes for each logical condition. Condition coverage offers better sensitivity to
the control flow than decision coverage. In this coverage, expressions with logical
operands are only considered.
For example, if an expression has Boolean operations like AND, OR, XOR, which
indicates total possibilities.

Condition coverage does not give a guarantee about full decision coverage.

The formula to calculate Condition Coverage:

Example:

For the above expression, we have 4 possible combinations

 TT
 FF
 TF
 FT

Consider the following input

X=3
(x<y) TRUE
Y=4
Condition Coverage is ¼ = 25%
A=3
(a>b) FALSE
B=4

Multiple Condition Coverage: In this technique, all the possible


combinations of the possible outcomes of conditions are tested at least once.
Let’s consider the following example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’
 #TC1: X = 0, Y = 0
 #TC2: X = 0, Y = 5
 #TC3: X = 55, Y = 0
 #TC4: X = 55, Y = 5
Hence, four test cases required for two individual conditions.
n
Similarly, if there are n conditions then 2 test cases would be required.

Basis Path Testing (CONTROL FLOW GRAPH METHOD)


In this technique, control flow graphs are made from code or flowchart and
then Cyclomatic complexity is calculated which defines the number of
independent paths so that the minimal number of test cases can be designed
for each independent path.
Steps:
1. Make the corresponding control flow graph
2. Calculate the cyclomatic complexity
3. Find the independent paths
4. Design test cases corresponding to each independent path
Flow graph notation: It is a directed graph consisting of nodes and edges.
Each node represents a sequence of statements, or a decision point. A
predicate node is the one that represents a decision point that contains a
condition after which the graph splits. Regions are bounded by nodes and
edges.

Cyclomatic Complexity: It is a measure of the logical complexity of the


software and is used to define the number of independent paths. For a graph G,
V(G) is its cyclomatic complexity.
Calculating V(G):
5. V(G) = P + 1, where P is the number of predicate nodes in the flow graph
6. V(G) = E – N + 2, where E is the number of edges and N is the total number
of nodes
7. V(G) = Number of non-overlapping regions in the graph
Example:

V(G) = 4 (Using any of the above formulae)


No of independent paths = 4
 #P1: 1 – 2 – 4 – 7 – 8
 #P2: 1 – 2 – 3 – 5 – 7 – 8
 #P3: 1 – 2 – 3 – 6 – 7 – 8
 #P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8

Loop Testing is defined as a software testing type, that completely focuses on the
validity of the loop constructs. It is one of the parts of Control Structure Testing
(path testing, data validation testing, condition testing).

Loop testing is a White box testing. This technique is used to test loops in the
program.

Types of loop Tested

 Simple loop
 Nested loop
 Concatenated loop
 Unstructured loop

Why do Loop Testing?


Loop Testing is done for the following reasons
 Testing can fix the loop repetition issues
 Loops testing can reveal performance/capacity bottlenecks
 By testing loops, the uninitialized variables in the loop can be determined

 It helps to identify loops initialization problems.


How to do Loop Testing: Complete Methodology
While testing loop, it has to be checked at three different levels:

 When loop is entered


 During its execution and
 When the loop is left

Types of Loop Testing:


Loop testing is classified on the basis of the types of the loops:
1. Simple Loop Testing:
Testing performed in a simple loop is known as Simple loop testing. Simple loop
is basically a normal “for”, “while” or “do-while” in which a condition is given
and loop runs and terminates according to true and false occurrence of the
condition respectively. This type of testing is performed basically to test the
condition of the loop whether the condition is sufficient to terminate loop after
some point of time.
Example:
while(condition)
{
statement(s);
}

2. Nested Loop Testing:


Testing performed in a nested loop in known as Nested loop testing. Nested loop
is basically one loop inside the another loop. In nested loop there can be finite
number of loops inside a loop and there a nest is made. It may be either of any
of three loops i.e., for, while or do-while.
Example:
while(condition 1)
{

while(condition 2)
{
statement(s);
}

}
3..Concatenated Loop Testing:
Testing performed in a concatenated loop is known as Concatenated loop
testing. It is performed on the concatenated loops. Concatenated loops are loops
after the loop. It is a series of loops. Difference between nested and
concatenated is that in nested loop is inside the loop but here loop is after the
loop.
Example:
while(condition 1)
{ statement(s); }
while(condition 2)
{ statement(s); }

3. Unstructured Loop Testing:


Testing performed in an unstructured loop is known as Unstructured loop testing.
Unstructured loop is the combination of nested and concatenated loops. It is
basically a group of loops that are in no order.
Example:
while()
{
for()
{}
while()
{}
}
Advantages of Loop Testing:
 Loop testing limits the number of iterations of loop.
 Loop testing ensures that program doesn’t go into infinite loop process.
 Loop testing endures initialization of every used variable inside the loop.
 Loop testing helps in identification of different problems inside the loop.
 Loop testing helps in determination of capacity.
Disadvantages of Loop Testing:
 Loop testing is mostly effective in bug detection in low-level software.
 Loop testing is not useful in bug detection.

What is Black Box Testing?


Black Box Testing is also known as behavioral, opaque-box, closed-box,
specification-based or eye-to-eye testing.

It is a Software Testing method that analyzes the functionality of a


software/application without knowing much about the internal structure/design of
the item that is being tested and compares the input value with the output value.

The main focus of Black Box Testing is on the functionality of the system
as a whole. The term ‘Behavioral Testing’ is also used for Black Box Testing.
A majority of the applications are tested using the Black Box method. We need to
cover the majority of test cases so that most of the bugs will get discovered by the
Black-Box method.

This testing occurs throughout the Software Development and Testing Life Cycle i.e
in Unit, Integration, System, Acceptance, and Regression Testing stages.
This can be either Functional or Non-Functional.

Types of Black Box Testing


Practically, there are several types of Black Box Testing that are possible, but if we
consider a major variant of it then only the below mentioned are the two
fundamental ones.

#1) Functional Testing


This testing type deals with the functional requirements or specifications of an
application. Here, different actions or functions of the system are being tested by
providing the input and comparing the actual output with the expected output.

For example, when we test a Dropdown list, we click on it and verify if it expands
and all the expected values are showing in the list.
Few major types of Functional Testing are:
 Smoke Testing
 Sanity Testing
 Integration Testing
 System Testing
 Regression Testing
 User Acceptance Testing
#2) Non-Functional Testing
These are required to be test and improve the quality and performance of the
application.

Few major types of Non-Functional Testing include:


 Usability Testing
 Load Testing
 Performance Testing
 Compatibility Testing
 Stress Testing
 Scalability Testing

Introduction To Functional Testing
There must be something that defines what is acceptable behavior and what is not.
This is specified in a functional or requirement specification. It is a document that
describes what a user is permitted to do so, that he can determine the conformance
of the application or system to it.

Functional Testing Types


Functional testing has many categories and these can be used based on the
scenario.

Unit Testing:
 Unit testing is a type of software testing that focuses on individual units or
components of a software system.
 The purpose of unit testing is to validate that each unit of the software
works as intended and meets the requirements.
 Unit testing is typically performed by developers, and it is performed early
in the development process before the code is integrated and tested as a
whole system.
 Code coverage is an important part of unit testing where the test cases need
to exist to cover the below three:

i)Line coverage
ii) Code path coverage
iii) Method coverage

Smoke Testing:
 This type of testing is performed before the actual system testing to check if
the critical functionalities are working fine in order to carry out further
extensive testing.
 This, in turn, saves time installing the new build again and avoids further
testing if the critical functionalities fail to work. This is a generalized way of
testing the application.

Sanity Testing:
 It is a type of testing where only a specific functionality or a bug which is
fixed is tested to check whether the functionality is working fine and see if
there are no other issues due to the changes in the related components. It is
a specific way of testing the application.
 Subset of regression testing
Regression Tests: Testing performed to ensure that adding new code,
enhancements, fixing of bugs is not breaking the existing functionality or causing
any instability and still works according to the specifications.
Regression tests need not be as extensive as the actual functional tests but should
ensure just the amount of coverage to certify that the functionality is stable.

Integration Tests:
 Integration testing is the process of testing the interface between two
software units or modules.
 It focuses on determining the correctness of the interface.
 The purpose of integration testing is to expose faults in the interaction
between integrated units.
 Once all the modules have been unit-tested, integration testing is
performed.
 Integration testing is a software testing technique that focuses on verifying
the interactions and data exchange between different components or
modules of a software application.
 The goal of integration testing is to identify any problems or bugs that arise
when different components are combined and interact with each other.
System testing is a testing that is performed on a complete system to verify if it
works as expected once all the modules or components are integrated.

End to end testing is performed to verify the functionality of the product. This
testing is performed only when system integration testing is complete including
both the functional & non-functional requirements.
What is Non-Functional Testing?
There are some aspects which are complex such as the performance of an
application etc and this testing checks the Quality of the software to be tested.
Quality majorly depends on time, accuracy, stability, correctness and durability of a
product under various adverse circumstances.

In software terms, when an application works as per the user’s expectation,


smoothly and efficiently under any condition, then it is stated as a reliable
application. Based on these aspects of quality, it is very critical to test under these
parameters. This type of testing is called Non- Functional Testing.It is not feasible to
test this type manually, hence some special automated tools are used to test it.

Example tools: LoadRunner, JMeter etc.


Types of Non-Functional Testing
Given below are the various types of Non-Functional Testing.
Performance Testing:

1) Load Testing:
 An application which is expected to handle a particular workload is tested for
its response time in a real environment depicting a particular workload.
 It is tested for its ability to function correctly in a stipulated time and is able
to handle the load.
2) Stress Testing:
 In Stress testing, the application is stressed with an extra workload to check if
it works efficiently and is able to handle the stress as per the requirement.
 Example: Consider a website which is tested to check its behavior when the
user accesses is at its peak. There could be a situation where the workload
crosses beyond the specification. In this case, the website may fail, slow
down or even crash.
 Stress testing is to check these situations using automation tools to create a
real-time situation of workload and find the defects.

3) Volume Testing:
 Under Volume testing the application’s ability to handle data in the volume is
tested by providing a real-time environment. The application is tested for its
correctness and reliability under adverse conditions.
4) Endurance Testing:
 In Endurance testing the durability of the software is tested with a repeated
and consistent flow of load in a scalable pattern. It checks the endurance
power of the software when loaded with a consistent workload.

 All these testing types are used to make the software work bug-free and
crash free under any real time situation by addressing the issues and finding
solutions accordingly for a quality product.

Usability Testing:
 In this type of testing, the User Interface is tested for its ease of use and see
how user-friendly it is.

Security Testing:
 Security Testing is to check how secure the software is regarding data over
the network from malicious attacks.
 The key areas to be tested in this testing include authorization,
authentication of users and their access to data based on roles such as
admin, moderator, composer, and user level.

Black Box Testing Techniques


In order to systematically test a set of functions, it is necessary to design test cases.
Testers can create test cases from the requirement specification document using
the following Black Box Testing techniques:

 Equivalence Partitioning
 Boundary Value Analysis
 Decision Table Testing
 State Transition Testing
 Error Guessing
 Graph-Based Testing Methods
 Comparison Testing
#1) Equivalence Partitioning
This technique is also known as Equivalence Class Partitioning (ECP). In this
technique, input values to the system or application are divided into different
classes or groups based on its similarity in the outcome.

Hence, instead of using each and every input value, we can now use any one value
from the group/class to test the outcome. This way, we can maintain test coverage
while we can reduce the amount of rework and most importantly the time spent.

For Example:

As present in the above image, the “AGE” text field accepts only numbers from 18
to 60. There will be three sets of classes or groups.

Two invalid classes will be:


a) Less than or equal to 17.

b) Greater than or equal to 61.

A valid class will be anything between 18 and 60.

We have thus reduced the test cases to only 3 test cases based on the formed
classes thereby covering all the possibilities. So, testing with any one value from
each set of the class is sufficient to test the above scenario.

Example-2:
Let us consider an example of any college admission process. There is a college
that gives admissions to students based upon their percentage.
Consider percentage field that will accept percentage only between 50 to 90 %,
more and even less than not be accepted, and application will redirect user to an
error page. If percentage entered by user is less than 50 %or more than 90 %, that
equivalence partitioning method will show an invalid percentage. If percentage
entered is between 50 to 90 %, then equivalence partitioning method will show
valid percentage.

#2) Boundary Value Analysis


 The name itself defines that in this technique, we focus on the values at
boundaries as it is found that many applications have a high amount of issues
on the boundaries.
 Boundary refers to values near the limit where the behavior of the system
changes. In boundary value analysis, both valid and invalid inputs are being
tested to verify the issues.

For Example:

If we want to test a field where values from 1 to 100 should be accepted, then we
choose the boundary values: 1-1, 1, 1+1, 100-1, 100, and 100+1. Instead of using
all the values from 1 to 100, we just use 0, 1, 2, 99, 100, and 101.

#3) Decision Table Testing


As the name itself suggests, wherever there are logical relationships like:

If
{
(Condition = True)
then action1 ;
}
else action2; /*(condition = False)*/
Then a tester will identify two outputs (action1 and action2) for two conditions (True
and False). So based on the probable scenarios a Decision table is carved to
prepare a set of test cases.

For Example:
Take an example of XYZ bank that provides an interest rate for the Male senior
citizen as 10% and 9% for the rest of the people.
In this example condition, C1 has two values as true and false, C2 also has two
values as true and false. The total number of possible combinations would then be
four. This way we can derive test cases using a decision table.

#4) State Transition Testing

STATE----EVENT---- ACTION ---- TRANSITION

State Transition Testing is a technique that is used to test the different states of the
system under test.

The state of the system changes depending upon the conditions or events. The
events trigger states which become scenarios and a tester needs to test them.

A systematic state transition diagram gives a clear view of the state changes but it
is effective for simpler applications. More complex projects may lead to more
complex transition diagrams thereby making it less effective.

For Example:

#5) Error Guessing


This is a classic example of Experience-Based Testing.In this technique, the tester
can use his/her experience about the application behavior and functionalities to
guess the error-prone areas. Many defects can be found using error guessing where
most of the developers usually make mistakes.

Few common mistakes that developers usually forget to handle:


 Divide by zero.
 Handling null values in text fields.
 Accepting the Submit button without any value.
 File upload without attachment.
 File upload with less than or more than the limit size.

#6) Graph-Based Testing Methods


 The Cause-Effect Graph technique restates the requirements
specification in terms of the logical relationship between the input
and output conditions.
 Identify the inputs(cause) and outputs(effect) from one specification
and assigned unique number to that.
 Draw a graph linking cause effect and graph
 Specify the constraints of the graphs
 Convert the graph to decision table.
 Since it is logical, it is obvious to use Boolean operators like AND, OR
and NOT.
 Notations Used:

Now let’s try to implement this technique with some examples:

 Draw a Cause and Effect graph based on a requirement/situation.


 Cause and Effect Graph is given, draw a Decision table based on it to draw
the test case.
Let’s see both of them one by one.

Draw A Cause And Effect Graph According To Situation


Situation:
The “Print message” is software that reads two characters and, depending on their
values, messages is printed.

 The first character must be an “A” or a “B”.


 The second character must be a digit.
 If the first character is an “A” or “B” and the second character is a digit, then
the file must be updated.
 If the first character is incorrect (not an “A” or “B”), the message X must be
printed.
 If the second character is incorrect (not a digit), the message Y must be
printed.
Solution:
The Causes of this situation are:
C1 – First character is A
C2 – First character is B
C3 – the Second character is a digit

The Effects (results) for this situation are:


E1 – Update the file
E2 – Print message “X”
E3 – Print message “Y”

LET’S START!!

First, draw the Causes and Effects as shown below:

Key – Always go from Effect to Cause (left to right). That means, to get
effect “E”, what causes should be true.
In this example, let’s start with Effect E1.

Effect E1 is for updating the file. The file is updated when


– The first character is “A” and the second character is a digit
– The first character is “B” and the second character is a digit
– The first character can either be “A” or “B” and cannot be both.

Now let’s put these 3 points in symbolic form:

For E1 to be true – the following are the causes:


– C1 and C3 should be true
– C2 and C3 should be true
– C1 and C2 cannot be true together. This means C1 and C2 are mutually exclusive.

Now let’s draw this:

So as per the above diagram, for E1 to be true the condition is (C1 C2) C3
The circle in the middle is just an interpretation of the middle point to make the
graph less messy.
There is a third condition where C1 and C2 are mutually exclusive. So the final
graph for effect E1 to be true is shown below:

Let’s move to Effect E2:


E2 states print message “X”. Message X will be printed when the First character is
neither A nor B.
This means Effect E2 will hold true when either C1 OR C2 is invalid. So the graph for
Effect E2 is shown as (In blue line)

For Effect E3.


E3 states print message “Y”. Message Y will be printed when the Second character
is incorrect.
This means Effect E3 will hold true when C3 is invalid. So the graph for Effect E3 is
shown as (In Green line)

This completes the Cause and Effect graph for the above situation.

Now let’s move to draw the Decision table based on the above graph.

Writing Decision Table Based On Cause And Effect graph


First, write down the Causes and Effects in a single column shown below

The Key is the same. Go from bottom to top which means traverse from Effect to
Cause.
Start with Effect E1. For E1 to be true, the condition is (C1 C2) C3.
Here we are representing True as 1 and False as 0

First, put Effect E1 as True in the next column as

Now for E1 to be “1” (true), we have the below two conditions –


C1 AND C3 will be true
C2 AND C3 will be true

For E2 to be True, either C1 or C2 has to be False shown as,

For E3 to be true, C3 should be false.

So it is completed. Let’s complete the graph by adding 0 in the blank column and
include the test case identifier.

Writing Test Cases From The Decision Table


Below is a sample test case for Test Case 1 (TC1) and Test Case 2 (TC2).
In a similar fashion, you can create other test cases.
#7) Comparison Testing
In this method, different independent versions of the same software are used to
compare to each other for testing.

Advantages and Disadvantages


Advantages
 The tester does not need to have a technical background. It is important to
test by being in the user’s shoes and think from the user’s point of view.
 Testing can start once the development of the project/application is done.
Both the testers and developers work independently without interfering in
each other’s space.
 It is more effective for large and complex applications.
 Defects and inconsistencies can be identified in the early stages of testing.
Disadvantages
 Without any technical or programming knowledge, there are chances of
ignoring possible conditions of the scenario to be tested.
 In a stipulated time there is a possibility of testing less and skipping all
possible inputs and their output testing.
 Complete Test Coverage is not possible for large and complex projects.
Difference Between White Box Testing and Black Box Testing
Given below are some of the differences between the two:
Black Box Testing White Box Testing

It is a testing method without having knowledge It is a testing method having knowledge


about the actual code or internal structure of the about the actual code and internal
application. structure of the application.

This is a higher level testing such as functional This type of testing is performed at a
testing. lower level of testing such as Unit
Testing, Integration Testing.

It concentrates on the functionality of the system It concentrates on the actual code –


under test. program and its syntax's.

Black box testing requires Requirement White Box testing requires Design
specification to test. documents with data flow diagrams,
flowcharts etc.
Black Box Testing White Box Testing

Black box testing is done by the testers. White box testing is done by Developers
or testers with programming knowledge.

You might also like