Types of Software Testing

There are two different types of software testing currently used in the
industry both have their own advantages and disadvantages.

1. Manual Testing-Manual testing is a technique to test the

software that is carried out using the functions and features of an
application. In manual software testing, a tester carries out tests on the
software by following a set of predefined test cases.
In this testing, testers make test cases for the codes, test the
software, and give the final report about that software. Manual
testing is time-consuming because it is done by humans, and there
is a chance of human errors.

Advantages of Manual Testing

 Fast and accurate visual feedback: It detects almost every
bug in the software application and is used to test the
dynamically changing GUI designs like layout, text, etc.
 Less expensive: It is less expensive as it does not require any
high-level skill or a specific type of tool.
 No coding is required: No programming knowledge is
required while using the black box testing method. It is easy to
learn for the new testers.
  Efficient for unplanned changes: Manual testing is suitable
in case of unplanned changes to the application, as it can be
adopted easily.

2. Automation Testing-Automated Testing is a technique

where the Tester writes scripts on their own and uses suitable Software
or Automation Tool to test the software. It is an Automation Process of a
Manual Process. It allows for executing repetitive tasks without the
intervention of a Manual Tester.
Advantages of Automation Testing:
 Simplifies Test Case Execution: Automation testing can be
left virtually unattended and thus it allows monitoring of the
results at the end of the process. Thus, simplifying the overall
test execution and increasing the efficiency of the application.
 Improves Reliability of Tests: Automation testing ensures
that there is equal focus on all the areas of the testing, thus
ensuring the best quality end product.
 Increases amount of test coverage: Using automation
testing, more test cases can be created and executed for the
application under test. Thus, resulting in higher test coverage
and the detection of more bugs. This allows for the testing of
more complex applications and more features can be tested.
 Minimizing Human Interaction: In automation testing,
everything is automated from test case creation to execution
thus there are no changes for human error due to neglect. This
reduces the necessity for fixing glitches in the post-release
phase.

Manual vs. Automated testing

Here is the table of comparing Manual Testing and Automated
Testing:
Automation
Parameters Manual Testing Testing

In automated
In manual testing,
testing, the test
the test cases are
cases are executed
executed by the
by the software
human tester.
Definition tools.

Automation testing is
Manual testing is
faster than manual
time-consuming.
Processing Time testing.
 Automation
Parameters Manual Testing Testing

Automation testing
Manual testing takes takes up automation
Resources up human resources. tools and trained
requirement employees.

Exploratory testing Exploratory testing is

Exploratory is possible in manual not possible in
testing testing. automation testing.

Automation testing
Manual testing
uses frameworks like
Framework doesn’t use
Data Drive, Keyword,
frameworks.
requirement etc.

Software Testing – Boundary Value Analysis

Functional testing is a type of software testing in which the system is
tested against the functional requirements of the system. It is conducted
to ensure that the requirements are properly satisfied by the application.
Functional testing verifies that each function of the software application
works in conformance with the requirement and specification. Boundary
Value Analysis(BVA) is one of the functional testing.

Robustness Testing, Worst-Case Testing, Special Value Testing,

Software Testing – Boundary Value Analysis vs
Equivalence Partitioning

Software Testing is a process of finding bugs and verifying whether the

developed software meets its end-user requirements or not. To do
testing, testers write test cases (step-by-step procedure for how to test)
which take test data values as input to check the behavior of a software.
In some cases, there is a pool of input values to be tested, and writing
test cases for all input data values becomes laborious and error-prone. To
overcome such a situation, test case design techniques are used.
1. What is Boundary Value Analysis (BVA)?
2. What is Equivalence Partitioning?
3. BVA vs Equivalence Partitioning

What is Boundary Value Analysis (BVA)?

BVA is used to check the behaviour of application using test data that
exist at boundary values or in more easy words, for a range of input data
values, boundary values (extreme end values) are used as input for
testing. It is mostly used design technique as it is believed that software
is most likely to fail at upper and lower limits of input data values.
Example: A software allows people of age 20 to 50 years (both 20 and
50 are inclusive) to fill a form, for which the user has to enter his age in
the age field option of the software.

The boundary values are 20 (min value) and 50 (max value).

Invalid Valid Value Invalid
Value (min, min+1, nominal value, Value
(min-1) max-1, max) (max+1)

19 20, 21, 30, 49, 50 51

In the above table, one can clearly identify all valid and invalid test
values (values consider during testing the system).
1. Valid value: Test values at which the system does not fail and
function properly as per user requirement.
2. Invalid Values: test values that do not meet the system
requirement.

What is Equivalence Partitioning (EP)?

It is also termed Equivalence Class Partitioning (ECP). It is a Black
Box Testing technique, where a range of input values are divided into
equivalence data classes. In this, the tester tests a random input value
from the defined interval of equivalence data classes and if the output
for that input value is valid, then the whole class interval is considered
valid and vice-versa.
Example: An application allow the user to enter the password of length
8-12 numbers (minimum 8 and maximum 12 numbers).
Invalid Valid Equivalence Invalid
Equivalence Class Class Equivalence Class

<8 8-12 >12

Let’s consider some password values for valid and invalid class
1. 1234 is of length 4 which is an invalid password as 4<8.
2. 567890234 is of length 9 which is a valid password as 9 lies
between 8-12
3. 4536278654329 is of length 13 which is an invalid password as
13>12.

Equivalence Partitioning Method

Equivalence Partitioning Method is also known as Equivalence

class partitioning (ECP). It is a software testing technique or black-box
testing that divides input domain into classes of data, and with the help
of these classes of data, test cases can be derived.
In equivalence partitioning, equivalence classes are evaluated for given
input conditions. Whenever any input is given, then type of input
condition is checked, then for this input conditions, Equivalence class
represents or describes set of valid or invalid states.
Guidelines for Equivalence Partitioning:
 If the range condition is given as an input, then one valid and
two invalid equivalence classes are defined.
 If a specific value is given as input, then one valid and two
invalid equivalence classes are defined.
 If a member of set is given as an input, then one valid and one
invalid equivalence class is defined.
 If Boolean no. is given as an input condition, then one valid and
one invalid equivalence class is defined.

Example-1:
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.
Example-1:
Let us consider an example of any college admission process. There is a
college that gives admissions to students based upon their percentage.

Equivalence Class Testing- Next date problem

Equivalence class testing (Equivalence class Partitioning) is a black-box
testing technique used in software testing as a major step in the
This testing technique is better than many of the testing techniques like
boundary value analysis, worst case testing, robust case testing and many
more in terms of time consumption and terms of precision of the test
cases.
Since testing is done to identify possible risks, equivalence class testing
performs better than the other techniques as the test cases generated
using it are logically identified with partitions in between to create
different input and output classes. This can be shown from the next-date
problem which is stated below:
Problem: Given a day in the format of day-month-year, you need
to find the next date for the given date. Perform boundary value
analysis and equivalence-class testing for this.
Conditions :
D: 1<Day<31
M: 1<Month<12
Y: 1800 <Year <2048
Boundary Value Analysis:
No. of test Cases (n = no. of variables) = 4n+1 = 4*3 +1 =13
Test Cases:
Test Case ID Day Month Year Expected Output
1 1 6 2000 2-6-2000
2 2 6 2000 3-6-2000
3 15 6 2000 16-6-2000
4 30 6 2000 1-7-2000
5 31 6 2000 Invalid Date
6 15 1 2000 16-1-2000
7 15 2 2000 16-2-2000
8 15 11 2000 16-11-2000
9 15 12 2000 16-12-2000
10 15 6 1800 16-6-1800
11 15 6 1801 16-6-1801
12 15 6 2047 16-6-2047
13 15 6 2048 16-6-2048
Input classes:
Day:
D1: day between 1 to 28
D2: 29
D3: 30
D4: 31
Month:
M1: Month has 30 days
M2: Month has 31 days
M3: Month is February
Year:
 Y1: Year is a leap year
Y2: Year is a normal year
Output Classes:
Increment Day
Reset Day and Increment Month
Increment Year
Invalid Date
Test Cases:

Test Case ID Day Month Year Expected Output

E1 15 4 2004 16-4-2004
E2 15 4 2003 16-4-2003
E3 15 1 2004 16-1-2004
E4 15 1 2003 16-1-2003
E5 15 2 2004 16-2-2004
E6 15 2 2003 16-2-2003
E7 29 4 2004 30-4-2004
E8 29 4 2003 30-4-2003
E9 29 1 2004 30-1-2004
E10 29 1 2003 30-1-2003
E11 29 2 2004 1-3-2004
E12 29 2 2003 Invalid Date
E13 30 4 2004 1-5-2004
E14 30 4 2003 1-5-2003
E15 30 1 2004 31-1-2004
E16 30 1 2003 31-1-2003
E17 30 2 2004 Invalid Date
E18 30 2 2003 Invalid Date
E19 31 4 2004 Invalid Date
E20 31 4 2003 Invalid Date
E21 31 1 2004 1-2-2004
E22 31 1 2003 1-5-2003
E23 31 2 2004 Invalid Date
E24 31 2 2003 Invalid Date
So from this problem it is clearly seen that equivalence class testing
clearly checks for many cases that boundary value did not considered like
that of February which has 28-29 days, leap year which lead to variation in
number of days in February and many more. Hence the above example
proves that equivalence partitioning generates more efficient test cases
that should be considered during risk assessment.
In the software testing world, there is a saying “Exhaustive
testing is a myth and is just not feasible”. And there are many
different types of software testing techniques available each
with its own strength and weakness. We need a more
preferable testing technique based on the requirement and
project, that can select test cases intelligently and make sure
all test scenarios are covered.

There are two main categories of software testing techniques

present.

1. Static Testing Techniques: Testing of a component

or system at specification or implementation level
without execution of the software product, for
example, different types of review, planning, kick-off
meetings, preparation for work etc.
2. Dynamic Testing Techniques: Testing that involves
the execution of the software product or the system.

Dynamic Testing techniques are again subdivided into

three more categories:
 Specification-based Technique / Blackbox Testing
Technique/ Behavioural Testing Technique
 Structure-based Technique/ Whitebox Testing Technique/
Structural testing technique
 Experience-based Testing Technique

The Specification-based testing technique is a

procedure to derive and/or select test cases based on an
analysis of the specification, either functional or non-
functional of a component or system without reference
to its internal structure. In short, the tester is more
concentrated on what the software does not how it does the
work.
There are four specification-based design techniques available:
1. Equivalence partitioning
 2. Boundary value analysis
3. Decision table
4. State transition testing
The technique of Equivalence partitioning and Boundary value
analysis is often more focused on the user interface, whereas
Decision table and State transition testing are more focused on
business logic or business rules.
What is Decision Table Testing?
“Decision Table Testing” is a black box test design technique in
which test cases are designed to execute the combinations of
inputs shown in a decision table. Decision table testing is a
good way to deal with combinations of inputs.
What is a Decision table?
“Decision tables” are a concise visual representation for
specifying which actions to perform depending on given
conditions or inputs. These are the algorithms whose output is
a set of actions. These actions further can be used to design
the test cases.
This table is sometimes also referred to as a “cause-effect”
table. The reason for this is that there is an associated logic
diagramming technique called as “cause-effect graphing”
which was sometimes used to help derive the decision table.
Can this Decision Table Testing Technique be used
during Test Automation?
As we saw, decision table testing is a technique to design test
cases based on the combinations of inputs and outputs for a
system or a component. It helps to cover all possible scenarios
and helps us to reduce redundancy and complexity. However,
creating and executing decision table tests manually can be
time-consuming and error-prone. Hence, automating decision
table testing can bring us several advantages, such as:
 Saving time and effort
 Improving test coverage and hence the quality
improves.
  Enhancing maintainability and scalability, and
facilitating communication and collaboration.
 Generating test cases and executing them
automatically eliminates human errors.
 Updating test cases becomes easy and reusing them
for different scenarios makes the process more
efficient.
That’s why you might want to automate decision table testing
using some tools or techniques.
There are various tools available to help you automate the tests
that you derive via decision tables, depending on your needs
and preferences.
For instance, you can automate the inputs and expected
outcome of the decision tables using Testsigma a unified
cloud-based test automation tool that lets you automate the
test cases just in simple English – no coding required.
Example 1: How to make Decision Base Table for Login
Screen
Specification:
Let’s take the example of a login screen of say Testsigma
application. The condition states that if the user provides the
correct username and password the user will be redirected to
the homepage. If any of the input is wrong, an error message
will be displayed on the screen.
Decision Table for login screen:
Conditions Rule 1/TC1 Rule 2/TC2 Rule 3/TC3 Rule 4/TC4

Email Id (Input) T T F F

Password (Input) T F T F

Action(Output) H E E E

In the above example, the

T stands for correct Email id/password.
F stands for incorrect Email id/password
H stands for Home screen to be displayed to the user
E stands for the Error message to be displayed to the user
TC stands for the Test case.
Now let’s discuss the actions or output of the above decision table as per
the provided inputs(email id and password).
Test Case 1 – The email id and password both are correct. Hence, the
user should be directed to Testsigma’s Homepage.
Test Case 2 – The email id was correct, but the password was wrong.
Hence, an error message should be shown to the user mentioning
“Incorrect Password”.
Test Case 3 – The email id was wrong, but the password was correct.
Hence, an error message should be shown to the user mentioning
“Incorrect Email Id”.
Test Case 4 – The email id and password both are incorrect. Hence, an
error message should be shown to the user mentioning “Incorrect Email
Id”.
In the above example, you saw how all possible conditions or test cases
have been included, the testing team can refer to this decision table and
create their test cases so that upcoming bugs can be found at the testing
level.
Why Decision Table Testing is Important?
· Decision table testing provides a systematic way of stating a complex
business rule in the form of decision tables, which is useful for developers
as well as for testers.
· Decision tables testing technique can be used in test designs even if
the test conditions are not used in specifications. This helps the testers to
explore the effects of combinations of different inputs and other software
states, that must correctly implement business rules.
· While testing the behaviour of a large set of inputs where system
behaviour differs with each set of inputs, the decision table testing
provides good coverage and the representation is simple so it is easy to
interpret and use.
The technique of equivalence partitioning and boundary value analysis are
often applied to specific situations or inputs. However, if different
combinations of inputs result in different actions being taken, this can be
more difficult to show using equivalence partitioning and boundary value
analysis. For combinations of inputs decision table testing design
technique is preferable.
· For example decision table for credit card interest rates. For same credit
card, interest rates varies based on different inputs such as new
customer, loyalty point, coupons, etc. So in such cases creating a decision
table based on the specification and different input combinations would be
very useful.

Data-flow testing is a white box testing technique that can be used to detect improper use of data
values due to coding errors. For instance, a software programmer might use a variable without
defining it. Additionally, he/she may define a variable, but not initialize it and then use that variable
in a predicate.

e.g. int x ;

if (x ==100)

};

In data-flow testing, the first step is to model the program as a control flow graph. This helps to
identify the control flow information in the program. In step 2, the associations between the
definitions and uses of the variables that is needed to be covered in a given coverage criterion is
established. In step 3, the test suite is created using a finite number of paths from step 2.