UNIT-1

Introduction:
What is testing?
Testing is the process of evaluating a system components by manual or automated means
to verify that it satisfies specified requirements.

1. The Purpose of Testing:

Testing is the most time consuming, but a needful activity of a software project. It is vital
to the success of new system.

The main Purpose of testing is to:

1. Measure the quality of the software

2. Find out the faults in the application and software
3. Reduce the number of bugs in the program.
4. Check all the requirements and specifications given by client and customers are met or
not.
5. Produce a product which is full of quality oriented.
6. Comfort the need of client and customers.
7. Provide a defect and error free software.
8. Check whether the application is working as per the functional requirement specified or
not.
9. Carry the difference between the expected and actual results.
Important purpose of testing is to increase the project and product quality, and definitely
to increase the organization quality side by side also.

2. Dichotomies:

 Testing Versus Debugging: Many people consider both as same. Purpose of

testing is to show that a program has bugs. The purpose of testing is to find the
error or misconception that led to the program's failure and to design and
implement the program changes that correct the error.
 Debugging usually follows testing, but they differ as to goals, methods and most
important psychology. The below tab le shows few important differences between
testing and debugging.

Testing Debugging
Testing starts with known conditions, Debugging starts from possibly unknown
uses predefined procedures and has intial conditions and the end can not be
predictable outcomes. predicted except statistically.
Testing can and should be planned, Procedure and duration of debugging cannot
designed and scheduled. be so constrained.
Testing is a demonstration of error or
Debugging is a deductive process.
apparent correctness.
 Debugging is the programmer's vindication
Testing proves a programmer's failure.
(Justification).
Testing, as executes, should strive to
Debugging demands intutive leaps,
be predictable, dull, constrained, rigid
experimentation and freedom.
and inhuman.
Much testing can be done without Debugging is impossible without detailed
design knowledge. design knowledge.
Testing can often be done by an
Debugging must be done by an insider.
outsider.
Much of test execution and design can
Automated debugging is still a dream.
be automated.

 Function Versus Structure: Tests can be designed from a functional or a

structural point of view. In functional testing, the program or system is treated as
a blackbox. It is subjected to inputs, and its outputs are verified for conformance to
specified behaviour. Functional testing takes the user point of view- bother about
functionality and features and not the program's implementation. Structural
testing does look at the implementation details. Things such as programming style,
control method, source language, database design, and coding details dominate
structural testing.
 Both Structural and functional tests are useful, both have limitations, and both
target different kinds of bugs. Functional tets can detect all bugs but would take
infinite time to do so. Structural tests are inherently finite but cannot detect all
errors even if completely executed.
 Designer Versus Tester: Test designer is the person who designs the tests where
as the tester is the one actually tests the code. During functional testing, the
designer and tester are probably different persons. During unit testing, the tester
and the programmer merge into one person.
 Tests designed and executed by the software designers are by nature biased
towards structural consideration and therefore suffer the limitations of structural
testing.
 Modularity Versus Efficiency: A module is a discrete, well-defined, small
component of a system. Smaller the modules, difficult to integrate; larger the
modules, difficult to understand. Both tests and systems can be modular. Testing
can and should likewise be organised into modular components. Small,
independent test cases can be designed to test independent modules.
 Small Versus Large: Programming in large means constructing programs that
consists of many components written by many different programmers.
Programming in the small is what we do for ourselves in the privacy of our own
offices. Qualitative and Quantitative changes occur with size and so must testing
methods and quality criteria.
 Builder Versus Buyer: Most software is written and used by the same
organization. Unfortunately, this situation is dishonest because it clouds
accountability. If there is no separation between builder and buyer, there can be no
accountability.
 The different roles / users in a system include:
1. Builder: Who designs the system and is accountable to the buyer.
 2. Buyer: Who pays for the system in the hope of profits from providing
services.
3. User: Ultimate beneficiary or victim of the system. The user's interests
are also guarded by.
4. Tester: Who is dedicated to the builder's destruction.
5. Operator: Who has to live with the builders' mistakes, the buyers'
murky (unclear) specifications, testers' oversights and the users'
complaints.

3.Model For Testing:

A software testing method that uses models to automatically generate, execute, and
evaluate test cases.

Above figure is a model of testing process. It includes three models: A model of the
environment, a model of the program and a model of the expected bugs.

 ENVIRONMENT:
o A Program's environment is the hardware and software required to make
it run. For online systems, the environment may include communication
lines, other systems, terminals and operators.
o The environment also includes all programs that interact with and are
used to create the program under test - such as OS, linkage editor,
loader, compiler, utility routines.
o Because the hardware and firmware are stable, it is not smart to blame
the environment for bugs.
 PROGRAM:
o Most programs are too complicated to understand in detail.
o The concept of the program is to be simplified inorder to test it.
 o If simple model of the program doesnot explain the unexpected
behaviour, we may have to modify that model to include more facts and
details. And if that fails, we may have to modify the program.
 BUGS:
o Bugs are more insidious (deceiving but harmful) than ever we expect
them to be.
o An unexpected test result may lead us to change our notion of what a
bug is and our model of bugs.
o Some optimistic notions that many programmers or testers have about
bugs are usually unable to test effectively and unable to justify the dirty
tests most programs need.
o OPTIMISTIC NOTIONS ABOUT BUGS:
1. Benign Bug Hypothesis: The belief that bugs are nice, tame
and logical. (Benign: Not Dangerous)
2. Bug Locality Hypothesis: The belief that a bug discovered
with in a component effects only that component's behaviour.
3. Control Bug Dominance: The belief that errors in the
control structures (if, switch etc) of programs dominate the
bugs.
4. Code / Data Separation: The belief that bugs respect the
separation of code and data.
5. Lingua Salvator Est: The belief that the language syntax and
semantics (e.g. Structured Coding, Strong typing, etc)
eliminates most bugs.
6. Corrections Abide: The mistaken belief that a corrected bug
remains corrected.
7. Silver Bullets: The mistaken belief that X (Language, Design
method, representation, environment) grants immunity from
bugs.
8. Sadism Suffices: The common belief (especially by
independent tester) that a sadistic streak, low cunning, and
intuition are sufficient to eliminate most bugs. Tough bugs
need methodology and techniques.
9. Angelic Testers: The belief that testers are better at test
design than programmers are at code design.
 TESTS:
o Tests are formal procedures, Inputs must be prepared, Outcomes should
predicted, tests should be documented, commands need to be executed,
and results are to be observed. All these errors are subjected to error
o We do three distinct kinds of testing on a typical software system.
They are:
1. Unit / Component Testing: A Unit is the smallest testable
piece of software that can be compiled, assembled, linked,
loaded etc. A unit is usually the work of one programmer and
consists of several hundred or fewer lines of code. Unit
Testing is the testing we do to show that the unit does not
satisfy its functional specification or that its implementation
structure does not match the intended design structure.
A Component is an integrated aggregate of one or more
units. Component Testing is the testing we do to show that
 the component does not satisfy its functional specification or
that its implementation structure does not match the intended
design structure.
2. Integration Testing: Integration is the process by which
components are aggregated to create larger
components. Integration Testing is testing done to show that
even though the componenets were individually satisfactory
(after passing component testing), checks the combination of
components are incorrect or inconsistent.
3. System Testing: A System is a big component. System
Testing is aimed at revealing bugs that cannot be attributed to
components. It includes testing for performance, security,
accountability, configuration sensitivity, startup and recovery.
 Role of Models: The art of testing consists of creating , selecting, exploring, and
revising models. Our ability to go through this process depends on the number of
different models we have at hand and their ability to express a program's
behaviour.

4.Levels Of Testing:

The four levels of software testing are:

Unit testing: Tests individual lines of code
Integration testing: Tests how interconnected units work together
System testing: Tests the overall system
Acceptance testing: Tests how well the software meets user requirements

5.Software Testing Principles:

1. Testing shows the Presence of Defects

The goal of software testing is to make the software fail. Software testing reduces the
presence of defects. Software testing talks about the presence of defects and doesn’t talk
about the absence of defects. Software testing can ensure that defects are present but it can
not prove that software is defect-free. Even multiple tests can never ensure that software is
100% bug-free. Testing can reduce the number of defects but not remove all defects.
2. Exhaustive Testing is not Possible
It is the process of testing the functionality of the software in all possible inputs (valid or
invalid) and pre-conditions is known as exhaustive testing. Exhaustive testing is impossible
means the software can never test at every test case. It can test only some test cases and
assume that the software is correct and it will produce the correct output in every test case.
If the software will test every test case then it will take more cost, effort, etc., which is
impractical.
3. Early Testing
To find the defect in the software, early test activity shall be started. The defect detected in
the early phases of SDLC will be very less expensive. For better performance of software,
software testing will start at the initial phase i.e. testing will perform at the requirement
analysis phase.
4. Defect Clustering
In a project, a small number of modules can contain most of the defects. The Pareto
Principle for software testing states that 80% of software defects come from 20% of
modules.
5. Pesticide Paradox
Repeating the same test cases, again and again, will not find new bugs. So it is necessary to
review the test cases and add or update test cases to find new bugs.
6. Testing is Context-Dependent
The testing approach depends on the context of the software developed. Different types of
software need to perform different types of testing. For example, The testing of the e-
commerce site is different from the testing of the Android application.
7. Absence of Errors Fallacy
If a built software is 99% bug-free but does not follow the user requirement then it is
unusable. It is not only necessary that software is 99% bug-free but it is also mandatory to
fulfill all the customer requirements.

6.The Tester‘s Role in a Software Development:

In software development, the tester plays a crucial role in ensuring the quality and reliability
of the final product. Their primary responsibility is to identify and report defects or bugs in
the software, which are then fixed by the development team. Testers also verify that the
software meets the required specifications and functional requirements. Additionally, they
often participate in requirements gathering, usability testing, and exploratory testing to
identify potential issues early on. Effective testers must possess strong analytical skills,
attention to detail, and excellent communication skills to collaborate with the development
team.

7.Consequences of Bugs:
Here are the consequences of bugs in software testing in simple words:
1. System Crash: Software stops working completely.
2. Data Loss: Important data is deleted or corrupted.
3. Security Risks: Hackers can exploit bugs to steal sensitive information.
4. Financial Loss: Bugs can cause monetary losses due to system downtime or incorrect
calculations.
5. Reputation Damage: Bugs can harm a company's reputation and erode customer trust.
6. Time and Resource Waste: Debugging and fixing bugs can be time-consuming and
costly.
7. User Frustration: Bugs can cause frustration and annoyance for end-users.
8. Compliance Issues: Bugs can lead to non-compliance with regulatory requirements.
9. Maintenance Challenges: Bugs can make software maintenance and updates more
difficult.
10. Business Disruption: Bugs can disrupt business operations and impact revenue.

8. Taxonomy of Bugs:
Here's a simple taxonomy of bugs in software testing methodologies:

Functional Bugs

1. Syntax Errors: Mistakes in code syntax.

2. Logic Errors: Flaws in program logic.
3. Calculation Errors: Incorrect calculations or formulas.

Non-Functional Bugs

1. Performance Issues: Slow or inefficient program execution.

2. Security Vulnerabilities: Weaknesses that allow unauthorized access.
3. Usability Issues: Difficulties with user interface or experience.

Environmental Bugs
1. Compatibility Issues: Problems with different hardware, software, or browsers.
2. Configuration Errors: Mistakes in system configuration or setup.
3. Network Issues: Problems with network connectivity or communication.

User Interface Bugs

1. Layout Issues: Problems with screen layout or formatting.

2. Navigation Issues: Difficulties with menu navigation or links.
3. Display Issues: Problems with text, image, or video display.

Data Bugs

1. Data Corruption: Errors in data storage or retrieval.

2. Data Loss: Loss of important data due to bugs or errors.
3. Data Inconsistency: Inconsistent data across different parts of the system.

This taxonomy helps testers categorize and prioritize bugs based on their severity and impact
on the software system.

FLOW GRAPHS AND PATH TESTING:

BASICS OF PATH TESTING:

Basis Path Testing is a white-box testing technique based on the control structure of a
program or a module. Using this structure, a control flow graph is prepared and the various
possible paths present in the graph are executed as a part of testing. Therefore, by
definition, Basis path testing is a technique of selecting the paths in the control flow graph,
that provide a basis set of execution paths through the program or module. Since this testing
is based on the control structure of the program, it requires complete knowledge of the
program’s structure. To design test cases using this technique, four steps are followed :
1. Construct the Control Flow Graph
2. Compute the Cyclomatic Complexity of the Graph
3. Identify the Independent Paths
4. Design Test cases from Independent Paths
Let’s understand each step one by one. 1. Control Flow Graph – A control flow graph (or
simply, flow graph) is a directed graph which represents the control structure of a program
or module. A control flow graph (V, E) has V number of nodes/vertices and E number of
edges in it. A control graph can also have :
 Junction Node – a node with more than one arrow entering it.
 Decision Node – a node with more than one arrow leaving it.
 Region – area bounded by edges and nodes (area outside the graph is also counted as a
region.).

Below are the notations used while constructing a flow graph :

 Sequential Statements –

 If – Then – Else –

 Do – While –
 While – Do –

 Switch – Case –

Predicates:
A predicate is a logical expression that evaluates to true or false.
- Simple predicate: A predicate that involves a single variable or constant.
- Compound predicate: A predicate that involves multiple variables or constants.

Path Predicates and Achievable Paths:

A path predicate is a predicate that is associated with a path in a flow graph.
- Path predicate: A predicate that is true if and only if the path is executed.
- Achievable path: A path that can be executed by providing appropriate input values.
Path Sensitizing:
Path sensitizing is the process of identifying the input values that will cause a particular path
to be executed.
- Path sensitizing: Identifying the input values that will cause a particular path to be executed.

Path Instrumentation:
Path instrumentation is the process of modifying a program to collect data about the paths
that are executed.
- Path instrumentation: Modifying a program to collect data about the paths that are executed.

Applications of Path Testing:

Path testing has several applications in software testing:
- Test case generation: Path testing can be used to generate test cases that cover all possible
paths in a program.
- Test coverage analysis: Path testing can be used to analyze the coverage of test cases and
identify areas of the program that need more testing.
- Debugging: Path testing can be used to identify the causes of errors and debug a program.

UNIT-02
1.Transaction Flows:
Transaction flow testing is a method used in software testing that aims to verify each stage of
a transaction within a system, particularly in applications with payment processes. These
stages usually are data entry, processing, output generation, and validation.
2.Transaction Flow Techniques:

Transaction flow testing is a method used in software testing that aims to verify each stage
of a transaction within a system, particularly in applications with payment processes. These
stages usually are data entry, processing, output generation, and validation. It helps
developers identify design flaws, coding errors, and system-level issues, helping prevent
potential issues with the software.
 Transaction Flow Testing Techniques

Get the Transaction Flows:

 Complicated systems that process a lot of different, complicated

transactions, should have explicit representations of the transactions
flows or the equivalent

 Transaction flows are like control flow graphs, and consequently, we should
expect to have them in increasing levels of details

 The systems design documentation should contain an overview section,

that details the main transaction flows

 Detailed transaction flows are a mandatory prerequisite to the rational

design of a systems functional test
Inspections, Reviews and Walkthroughs

 Transaction flows are natural agenda for system reviews or inspections

 In conducting the walkthrough, you should:
 Discuss enough transaction types to account for 98%-99% of the transaction, the system is expected to
process

 Discuss paths through flows in functional rather than technical terms

 Ask the designers to relate every flow to the specification and to show how that transaction, directly or
indirectly, follows from the requirements

 Make transaction flow testing the corner stone of system functional testing, just as path testing is the
corner stone of unit testing

 Select additional flow paths for loops, extreme values, and domain boundaries
 Design more test cases to validate all births and deaths
 Publish and distribute the selected test paths through the transaction flows as early as possible, so that
they will exert the maximum beneficial effect on the project

Path Selection

 Select a set of covering paths (C + C ) using the analogous criteria you used for structural
1 2

path testing

 Select a covering set of paths based on functionally sensible transactions as you would for
control flow graphs

 Try to find most tortuous, longest, strongest path from the entry to the exit of the
transaction flow

Path Sensitization

 Most of the normal paths are very easy to sensitize. 80% - 95% transaction flow coverage (C 1 + C2) is
usually easy to achieve

 The remaining small percentage is often very difficult

 Sensitization is the act of defining the transaction, if there are sensitization problems on the easy paths,
then bet on either bug in transaction flows or a design bug

Path Instrumentation

 Instrumentation plays a bigger role in transaction flow testing than in unit path testing

 The information of the path taken for a given transaction must be kept with that transaction
and can be recorded by a central transaction dispatcher or by the individual processing
modules

 In some systems, such traces are provided by the operating systems or a running log

Design and Maintain Test Database

 Design and maintenance of the test databases constitute about 30% to 40% of the effort in
transaction flow test design

 People are often unaware that a test database needs to designed

 Test databases must be centrally administrated and configuration controlled with a

comprehensive design plan

 Creating a comprehensive test databases is itself a big project on its own

 It requires talented, matured, and diplomatic designers who are experienced in both system
design and test design
 Test Execution:

 Commit to automation of test execution if you want to do transaction flow testing for a
system of any size

 If the numbers of test cases are limited, you need not worry about test execution automation

 If the number of test cases run into several hundred, performing transaction flow testing to
achieve (C1 + C2) needs execution automation without which you cannot get it right.

Referal
Link:https://csestudyzone.blogspot.com/2015/06/transaction-flow-
testing-techniques-in.html

Basics Of Data Flow Testing:

What is Data Flow Testing?
Data Flow Testing is a type of structural testing . It is a method that is used to find the test
paths of a program according to the locations of definitions and uses of variables in the
program. It has nothing to do with data flow diagrams. Furthermore, it is concerned with:
 Statements where variables receive values,
 Statements where these values are used or referenced.
By analyzing control flow graphs, this technique aims to identify issues such as unused
variables or incorrect definitions, ensuring proper handling of data within the code. This
course provides detailed insights into Data Flow Testing, including its types, advantages,
and practical applications, helping you implement effective testing strategies and improve
software quality.
To illustrate the approach of data flow testing, assume that each statement in the program is
assigned a unique statement number. For a statement number S-
DEF(S) = {X | statement S contains the definition of X}
USE(S) = {X | statement S contains the use of X}
If a statement is a loop or if condition then its DEF set is empty and the USE set is based on
the condition of statement s. Data Flow Testing uses the control flow graph to find the
situations that can interrupt the flow of the program. Reference or defined anomalies in the
flow of the data are detected at the time of associations between values and variables. These
anomalies are:
 A variable is defined but not used or referenced,
 A variable is used but never defined,
 A variable is defined twice before it is used
Types of Data Flow Testing
1. Testing for All-Du-Paths: It Focuses on “All Definition-Use Paths. All-Du-Paths is an
acronym for “All Definition-Use Paths.” Using this technique, every possible path from
a variable’s definition to every usage point is tested.
2. All-Du-Path Predicate Node Testing: This technique focuses on predicate nodes, or
decision points, in the control flow graph.
3. All-Uses Testing: This type of testing checks every place a variable is used in the
application.
4. All-Defs Testing: This type of testing examines every place a variable is specified
within the application’s code.
5. Testing for All-P-Uses: All-P-Uses stands for “All Possible Uses.” Using this method,
every potential use of a variable is tested.
6. All-C-Uses Test: It stands for “All Computation Uses.” Testing every possible path
where a variable is used in calculations or computations is the main goal of this
technique.
7. Testing for All-I-Uses: All-I-Uses stands for “All Input Uses.” With this method, every
path that uses a variable obtained from outside inputs is tested.
8. Testing for All-O-Uses: It stands for “All Output Uses.” Using this method, every path
where a variable has been used to produce output must be tested.
9. Testing of Definition-Use Pairs: It concentrates on particular pairs of definitions and
uses for variables.
10. Testing of Use-Definition Paths: This type of testing examines the routes that lead from
a variable’s point of use to its definition.
Advantages of Data Flow Testing:
Data Flow Testing is used to find the following issues-
 To find a variable that is used but never defined,
 To find a variable that is defined but never used,
 To find a variable that is defined multiple times before it is use,
 Deallocating a variable before it is used.
Disadvantages of Data Flow Testing
 Time consuming and costly process
 Requires knowledge of programming languages
 Link: https://www.geeksforgeeks.org/data-flow-testing/

Strategies in Data Flow Testing in Software Testing Methodologies:

Strategies in Data Flow Testing are:

All-du Paths (ADUP)

The all-du-paths strategy is the strongest data flow testing strategy
It requires that every du path form every definition of every variable to
every use of that definition be exercise under some test
For variable X
In image, because variable X are used only on link (1, 3) any test that
starts at the entry satisfies this criterion (for variable X, but not for all
variables as required by the strategy)

For Variable z
The situation for variable z (image) is more complicated because the
variable is redefined in many places

Related:Implementation Comments in Transaction Flow Testing Unit 3

For the definition on link (1, 3) we must exercise paths that include sub
paths (1, 3, 4) and (1, 3, 5)
The definition on link (4, 5) is covered by any path that includes (5, 6)
such as sub path (1, 3, 4, 5, 6 ....)
The (5, 6) definition requires paths that include sub paths (5, 6, 7 and 4)
and (5, 6, 7 and 8)

For variable v
Variable V (image) is defined only once on link (1, 3)
Because V has a predicate use at node 12 and the subsequent path to the
end must be forced for both directions at node 12, the all-du-paths
strategy for this variable requires that we exercise all loop-free entry/exit
paths and at least one path that includes the loop caused by (11, 4)
Note that we must test paths that include both sub paths (3, 4, 5) and (3,
5) even though neither of these has V definition

Related:Transaction Flow Testing Techniques in Software Testing

Methodologies Unit 3

They must be included because they provide alternate du paths to the V

se on link (5, 6)
Although (7, 4) is not used in the test set for variable V, it will be included
in the test set that covers the predicate uses of array variable v() and U
The all-du-paths strategy is a strong criterion, but it does not take as
many tests as it might seem at first because any one test simultaneously
satisfies the criterion for several definitions and uses of several different
variables

All Uses Strategy (AU)

The all uses strategy is that at least one definition clear path from every
definition of every variable to every use of that definition be exercised
under some test
Just as we reduced our ambitions by stepping down from all paths (P) to
branch coverage (C2), say, we can reduce the number of test cases by
asking that the test set should include at least one path segment from
every definition to every use that can be reached by that definition
For Variable V

Related:Structure of Transaction Flow in Software Testing Methodologies

Unit 3

In image, ADUP requires that we include sub paths (3,4,5) and (3,5) in
some tests because subsequent uses of V, such as on link (5,6) can be
reached by either alternative
In AU, either (3,4,5) or (3,5) can be used to start paths, but we don't have
to use both
Similarly, we can skip the (8,10) link if we've included the (8,9,10) sub
path
Note the hole, we must include (8,9,10) in some test cases because that's
the only way to reach the c use at link (9,10-) but suppose our bug for
variable V is on link (8,10) after all? Find a covering set of paths under AU
for the image shown below

All p-uses/some c-uses strategy (APU + C)

For every variable and every definition of that variable, include at least
one definition free path from the definition to every predicate use

If there are definitions of the variables that are not covered by the above
prescription, and then add computational use test cases as required to
cover every definition

For variable Z

In image for APU + C we can select paths that all take the upper link (12,
13) and therefore we do not cover the c-use of Z but that's okay according
to the strategy's definition because every definition is covered

Links (1,3), (4,5), (5,6) and (7,8) must be included because they contain
definitions for variable z

Links (3,4), (3,5), (8,9) (8,10), (9,6) and (9,10) must be included because
they contain predicate uses of Z

Find a covering set of test cases under APU + C for a ll variables in this
example - it only takes two test
For variable V

In image, APU + C is achieved for V by (135678,

10,11,4,5,6,7,8,10,11,12[upper],13,2) and (1,3,5,6,7,8,10,11,12[lower],
13,2)

Note that the c-use at (9,10) need not be included under the APU + C
criterion

All c-uses/some p-uses strategy (ACU + P)

The all c-uses/some p-uses strategy (ACU+P) is to first ensure coverage by

computational use cases

If any definition is not covered by the previously selected paths, add such
predicate use cases as are needed to assure that every definition is
included in some test
For variable z

In image ACU + P coverage is achieved for Z by path

(1,3,4,5,6,7,8,10,11,12,13[lower], 2) but the predicate uses of several
definition are not covered

Specifically, the (1,3) definition is not covered for the (3,5) p-use, the (7,8)
definition is not covered for the (8,9), (9,6) and (9,10) p-uses

The above examples imply that APU+C is stronger than branch coverage,
but ACU+P may be weaker than, or incomparable to branch coverage

All Definition Strategy (AD)

the 'all definitions strategy' reveals that every definition of every variable
be covered by at least one use of that variable; be it the use a
computational use or a predicate use.
For variable Z
Related:Complications in Transaction Flow in Software Testing
Methodologies unit 3

Path(1,3,4,5,6,7,7....) satisfies this criterion for variable Z, whereas any

entry/exit path satisfies it for variable V
From the definition of this strategy we would expect it to be weaker than
both ACU +P and APU+C

All Predicate Uses (APU), All Computational Uses (ACU) Strategies

The 'all predicate uses strategy' is derived from APU+C strategy by
dropping the requirement that we include a c-use for the variable if there
are no p-uses for the variable
The 'all computational uses strategy' is derived form ACU+P strategy by
dropping the requirement that we include a p-use for the vaiable if there
are no c-uses for the variable
It is obvious that ACU should be weaker than ACU+P, and APU should be
weaker than APU+C
Link:https://csestudyzone.blogspot.com/2015/06/strategies-in-data-flow-
testing-in.html
Link: https://www.testbytes.net/blog/data-flow-testing/

UNIT-03
FIRST PART LINK: https://www.recw.ac.in/v1.8/wp-content/uploads/2021/03/unit-4-
ST.pdf

Syntax Testing:
Syntax Testing is a type of black box testing technique which is used to examine the format
and the grammar of the data inputs used in the software application, either external or input,
which may be formally described in technical or established & specified notations such as
BNF and could be used to design input ...
Grammar Formats:
 Gherkin: A plain text language used to describe application behavior in a
concise and readable way.
 Cucumber: A testing framework that uses Gherkin to define test
scenarios.
 TestNG XML: A standard format for defining test suites and test cases in
Java-based testing.
 JUnit: A popular testing framework for Java that uses a specific XML
format for test cases.
Test Case Generation:
What is a Test Case Generator?

A Test Case Generator is a tool in software testing. It creates test cases

automatically. These cases help check if software works right. Here's more
about it:

 Automates Test Creation: It makes test cases without manual work.

This saves time and effort.
 Improves Test Coverage: It covers more parts of the software. This
finds more bugs.
 Reduces Human Error: Less manual work means fewer mistakes in
tests.
 Adapts to Changes: It can quickly make new tests when software
changes.
  Efficient Testing: It speeds up the testing process. This helps software
reach users faster.

Test Case Generators are vital for quality software. They make testing
efficient and thorough. This is key for any software project.

Why Use a Test Case Generator?

Using a Test Case Generator can transform software testing. It brings

efficiency and accuracy. Here's why it's a smart choice:

1. Time and Resource Saving: A Test Case Generator saves time. It

creates test cases quickly. This means testers spend less time on
routine tasks. They can focus on more complex issues. It also reduces
the need for a large testing team. This saves resources.
2. Consistent Quality: Manual test case creation can vary in quality. A
Test Case Generator offers consistency. Every test case follows the
same high standards. This means reliable results every time. Consistent
quality is crucial for trustworthy software.
3. Comprehensive Coverage: Manual testing might miss some areas. A
Test Case Generator covers more ground. It checks every part of the
software. This thorough approach finds more bugs. It ensures the
software is robust and user-friendly.
4. Adaptability to Changes: Software often changes during development.
A Test Case Generator adapts quickly. It can create new test cases to
match these changes. This keeps the testing process up-to-date. It
ensures the final product meets all requirements.

How Does Test Case Generator Work?

How a Test Case Generator works is key in software testing. It's a tool that
automates and simplifies the process. Here's a breakdown:

1. Input Analysis: The generator starts by analyzing inputs. These inputs

are software requirements and specifications. It understands what the
software should do. This step is crucial. It sets the foundation for
relevant test cases.
2. Test Case Design: Based on the analysis, the generator designs test
cases. It uses algorithms to create scenarios. These scenarios test
different aspects of the software. The goal is to cover all functionalities.
This step ensures comprehensive testing.
3. Output Generation: After designing, the generator produces test
cases. These are detailed instructions for testing. They include steps to
follow, expected outcomes, and test data. This output is ready for
testers to use. It makes their work easier and more focused.
 4. Maintenance and Updates: Software changes over time. The Test
Case Generator adapts to these changes. It updates test cases to
match new requirements. This keeps the testing process relevant. It
ensures ongoing quality control.

How to Create a Test Case With This Generator?

Creating a test case with the Onethread Generator is straightforward. Here's

how to do it:

1. Input Software Specifications: Start by entering your software's

details. Include its functions and requirements. This information guides
the generator. It helps create relevant test cases.
2. Select Test Criteria: Choose what you want to test. This could be
performance, functionality, or usability. The generator uses these criteria
to focus the test cases.
3. Generate Test Cases: Click the generate button. The Onethread
Generator will create test cases based on your inputs. These cases will
cover different scenarios and aspects of your software.
4. Review and Customize: Once generated, review the test cases. You
can customize them if needed. This ensures they match your specific
testing needs.
5. Export and Implement: Finally, export the test cases. They are now
ready for your testing team to use. Implement them in your testing
process to check your software's performance.

By following these steps, you can efficiently create comprehensive test cases
with the Onethread Generator. This tool simplifies and streamlines the test
case creation process.

Importance of Test Case

Test cases are vital in software development. They ensure the software works
well. Here's why they are important:

 Ensures Software Quality: Test cases check if software meets

requirements. They find bugs and issues. This helps in delivering high-
quality software.
 Facilitates Thorough Testing: They cover different scenarios. This
includes normal, boundary, and error conditions. This thorough testing
ensures software reliability.
 Aids in Regression Testing: When software changes, test cases help
check if new changes break anything. This is key for maintaining
software over time.
 Improves User Experience: By finding and fixing issues, test cases
help in creating user-friendly software. This leads to satisfied users.
  Documentation and Knowledge Transfer: Test cases serve as
documentation. They help new team members understand the software.
This is useful for training and knowledge sharing.

Test cases are essential for creating reliable, user-friendly software. They are
a key part of the software development and maintenance process.

Implementation and Application and Testability Tips:

Syntax Testing: Implementation, Application, and Testability Tips

Syntax testing is a systematic approach to testing software systems by validating the input
format and structure. It ensures that the system correctly processes both valid and invalid
inputs based on a predefined syntax. Here’s a simplified explanation of its implementation,
application, and testability tips:

Implementation of Syntax Testing

1. Define the Syntax Rules:

o Start by identifying the formal grammar (e.g., BNF or regular
expressions) that defines the structure of inputs.
o Document these rules to create a reference for the testing
process.

2. Create Test Cases:

o Generate test cases that represent:
 Valid Inputs: Examples conforming to the defined
syntax.
 Invalid Inputs: Examples violating the syntax rules.

3. Automate Test Execution:

o Use tools like lexical analyzers or parsers to validate the input.
o Automate the generation and execution of test cases
wherever possible to improve efficiency.

4. Integrate into the Development Pipeline:

o Incorporate syntax testing early in the development process
to catch issues early.

Application of Syntax Testing

1. Software with Defined Input Formats:

o Syntax testing is particularly useful for compilers, parsers,
APIs, and systems that rely on strict data formats (e.g., JSON,
XML, or HTML).
 2. Validating Communication Protocols:
o Ensures messages adhere to the protocol’s syntax during data
exchange between systems.

3. Configuration and Command Testing:

o Verifies that configuration files and commands meet the
required structure.

4. Security Testing:
o Identifies potential vulnerabilities by testing malformed inputs
to ensure the system rejects them gracefully.

Testability Tips for Syntax Testing

1. Start Simple, Expand Gradually:

o Begin with basic valid and invalid inputs.
o Gradually add edge cases, boundary values, and complex
scenarios.

2. Utilize Existing Syntax Definitions:

o If the syntax is based on a standard (e.g., JSON Schema), use
existing tools or libraries to validate inputs.

3. Automate Test Case Generation:

o Leverage tools to automatically generate a wide range of valid
and invalid inputs to save time and increase coverage.

4. Ensure Comprehensive Coverage:

o Cover all rules of the syntax, including optional elements,
repetitions, and rare conditions.

5. Focus on Boundary Conditions:

o Test inputs that are at the edge of what is considered valid
(e.g., longest/shortest allowable inputs).

6. Log and Analyze Failures:

o Record all test results to understand failure patterns and
improve input handling.

UNIT-04
Logic Based Testing: Logic-based testing is a method of designing
software tests using logical expressions found in software artifacts.

Logic-based testing can be used in a variety of ways, including:

 Structural testing: When applied to structure, such as the control flow graph of an
implementation
 Functional testing: When applied to a specification
 Unit testing: One of the stages of testing where logic-based testing can be
performed
 Integration testing: One of the stages of testing where logic-based testing can be
performed
 System testing: One of the stages of testing where logic-based testing can be
performed
 Acceptance testing: One of the stages of testing where logic-based testing can be
performed
Logic-based testing focuses on the truth values of control flow
predicates. Testers design tests using logical expressions from software
artifacts such as:
 Decision statements in program source
 UML diagrams
 Architectural languages
 Finite state machines
 Natural language requirements
 Formal specifications

Decision Tables:
Decision tables are used in various engineering fields to represent
complex logical relationships. This testing is a very effective tool in testing
the software and its requirements management. The output may be
dependent on many input conditions and decision tables give a tabular
view of various combinations of input conditions and these conditions are
in the form of True(T) and False(F). Also, it provides a set of conditions
and its corresponding actions required in the testing.
Parts of Decision Tables :
In software testing, the decision table has 4 parts which are divided into
portions and are given below :
1. Condition Stubs : The conditions are listed in this first upper left part
of the decision table that is used to determine a particular action or set
of actions.
2. Action Stubs : All the possible actions are given in the first lower left
portion (i.e, below condition stub) of the decision table.
3. Condition Entries : In the condition entry, the values are inputted in
the upper right portion of the decision table. In the condition entries
part of the table, there are multiple rows and columns which are known
as Rule.
4. Action Entries : In the action entry, every entry has some associated
action or set of actions in the lower right portion of the decision table
and these values are called outputs.
Types of Decision Tables :
The decision tables are categorized into two types and these are given
below:
1. Limited Entry : In the limited entry decision tables, the condition
entries are restricted to binary values.
2. Extended Entry : In the extended entry decision table, the condition
entries have more than two values. The decision tables use multiple
conditions where a condition may have many possibilities instead of
only ‘true’ and ‘false’ are known as extended entry decision tables.
Applicability of Decision Tables :
 The order of rule evaluation has no effect on the resulting action.
 The decision tables can be applied easily at the unit level only.
 Once a rule is satisfied and the action selected, n another rule needs to
be examined.
 The restrictions do not eliminate many applications.
Example of Decision Table Based testing :
Below is the decision table of the program for determining the largest
amongst three numbers in which its input is a triple of positive integers
(x,y, and z) and values are from the interval [1, 300].
Table 1 : Decision Table of largest amongst three numbers :
Conditi R R R R R R R R R R1 R1 R1 R1 R1
ons 1 2 3 4 5 6 7 8 9 0 1 2 3 4

c1: x >
F T T T T T T T T T T T T T
= 1?

c2: x <=
F T T T T T T T T T T T T
300?

c3: y >
F T T T T T T T T T T T
= 1?

c4: x <=
F T T T T T T T T T T
300?

c5: z >
F T T T T T T T T T
= 1?

c6: z <=
F T T T T T T T T
300?

c7:
T T T T F F F F
x>y?

c8:
T T F F T T F F
y>z?

c9:
T F T F T F T F
z>x?

Rule 25 12 6 3 1
8 1 1 1 1 1 1 1 1
Count 6 8 4 2 6

a1 :
Invalid X X X X X X
input

a2 : x is
X X
largest
 a3 : y is
X X
largest

a4 : z is
X X
largest

a5 :
Impossi X X
ble

KV CHARTS: https://youtu.be/0BsmlNCFe8g?si=hk7xJcvhSGn3JY1w

State Graphs and Transition Testing: State Graphs, Good & Bad State
Graphs:

Characteristics of a Good State Graph

A state graph, also known as a state diagram or state machine diagram, is a visual
representation of a system's behavior over time. It's a powerful tool for modeling and
analyzing complex systems, especially those with discrete states and transitions.

To be effective, a state graph should possess the following characteristics:

1. Clear and Concise Notation:

 Consistent Symbols: Use consistent symbols for states (e.g., rounded rectangles) and
transitions (e.g., arrows) to enhance readability.
 Meaningful Labels: Label states and transitions with clear and concise names that
accurately reflect their meaning.
 Avoid Clutter: Keep the diagram uncluttered by avoiding excessive details and
unnecessary elements.

2. Well-Defined States:

 Distinct States: Each state should represent a unique condition or mode of the
system.
 Mutually Exclusive: States should be mutually exclusive, meaning the system cannot
be in multiple states simultaneously.
 Complete Coverage: The state graph should cover all possible states of the system.

3. Clear and Precise Transitions:

 Trigger Conditions: Each transition should be triggered by a specific event or

condition.
 Action Specification: Transitions can optionally be associated with actions that are
executed when the transition occurs.
  Guard Conditions: Transitions can be guarded by conditions that must be met before
the transition can take place.

1. Initial state

We use a black filled circle represent the initial state of a System or a Class.

2. Transition

We use a solid arrow to represent the transition or change of control from one state to
another. The arrow is labelled with the event which causes the change in state.
3. State

We use a rounded rectangle to represent a state. A state represents the conditions or

circumstances of an object of a class at an instant of time.

4. Fork

We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow
from the parent state and outgoing arrows towards the newly created states. We use the fork
notation to represent a state splitting into two or more concurrent states.
5. Join

We use a rounded solid rectangular bar to represent a Join notation with incoming arrows
from the joining states and outgoing arrow towards the common goal state. We use the join
notation when two or more states concurrently converge into one on the occurrence of an
event or events.

6. Self transition

We use a solid arrow pointing back to the state itself to represent a self transition. There
might be scenarios when the state of the object does not change upon the occurrence of an
event. We use self transitions to represent such cases.
7. Composite state

We use a rounded rectangle to represent a composite state also. We represent a state with
internal activities using a composite state.

8. Final State

We use a filled circle within a circle notation to represent the final state in a state machine
diagram.
4. Hierarchical Structure:

 Substate Diagrams: Complex state machines can be broken down into smaller, more
manageable substate diagrams.
 Orthogonal Regions: Multiple state machines can be combined into a single diagram
to model concurrent behavior.

5. Effective Visualization:

 Layout: The state graph should be laid out in a clear and organized manner, with
states and transitions arranged to minimize crossing lines and improve readability.
 Color Coding: Use color coding to differentiate between different types of states or
transitions, enhancing visual clarity.
 Annotations: Add annotations or comments to explain complex parts of the diagram.

Elements Contributing to Effectiveness:

 Clarity: A well-structured state graph is easy to understand and interpret.

 Completeness: The state graph should cover all possible system behaviors.
 Consistency: Consistent use of notation and terminology ensures clarity and avoids
confusion.
 Correctness: The state graph should accurately reflect the system's behavior.
 Maintainability: The state graph should be easy to update and modify as the system
evolves.

State Testing, and Testability Tips:

State testing is a functional testing tool that uses state graphs to test a
system's implementation against its specification. It's most effective when
used early in the design process.
 Here are some things to know about state testing:
 State graphs
A state graph is a collection of states that represent a system's behavior. States
are conditions or situations that an object goes through during its lifetime.
 Test case generation
To generate test cases, you can map the elements of the state graph to the
elements of the implementation. These elements include states, events, actions,
transitions, guards, classes, objects, attributes, messages, methods, and
expressions.
 Equivalent states
Two states are equivalent if the same sequence of outputs is produced when
starting from either state.
Testability is a critical software characteristic that measures how easy or
difficult it is to test a system or software. It's often measured by how many
tests can be executed on a given system.

UNIT-05
Automation Testing:
 Automated Testing means using special software for tasks that
people usually do when checking and testing a software product.
Nowadays, many software projects use automation testing from start to
end, especially in agile and DevOps methods. This means
the engineering team runs tests automatically with the help of software
tools . It will help to keep the testing team to make the process faster.
Continuous delivery (CD) and quickly sends the new code to users.
 It is used to automate the testing tasks that are difficult to perform
manually.
 Automation tests can be run at any time of the day as they use scripted
sequences to examine the software.
 Automation tests can also enter test data compare the expected result
with the actual result and generate detailed test reports.
 The goal of automation tests is to reduce the number of test cases to
be executed manually but not to eliminate manual testing.
 It is possible to record the test suit and replay it when required.
Automated Testing uses specialized software to replace manual testing
tasks, speeding up the process and integrating seamlessly with CI/CD
pipelines. It allows for continuous code verification and quicker
deployment. To master automation testing and streamline your processes,
check out the Complete Guide to Software Testing & Automation by
GeeksforGeeks . This course offers essential insights and techniques to
optimize your automated testing approach.
Table of Content
 Why Transform From Manual to Automated Testing?
 What kinds of software tests should be automated first?
 What kinds of software tests should be done manually?
 Difference between Manual Testing vs Automated Testing
 Automation Testing Types
 Test Automation Frameworks
 Which Tests to Automate?
 Automation Testing Process
 Criteria to Select Automation Tool
 Best Practices for Test Automation
 Popular Automation Tools
 Advantages of Automation Testing
 Disadvantages of Automation Testing
Why Transform From Manual to Automated Testing?
In 1994, an aircraft completing its routine flight crashed just before
landing. This was due to a bug or defect in their software. The testers
didn’t even care about the final testing, so this accident happened. In such
high-priority cases, accurate automation testing becomes critical to
replace a few manual tests. Automation testing tools
like BrowserStack can help teams thoroughly test and speed up the
execution time of test suites. Below are some of the reasons for using
automation testing:
 Quality Assurance: Manual testing is a tedious task that can be
boring and at the same time error-prone. Thus, using automation
testing improves the quality of the software under test as more test
coverage can be achieved.
 Error or Bug-free Software: Automation testing is more efficient for
detecting bugs in comparison to manual testing.
 No Human Intervention: Manual testing requires huge manpower in
comparison to automation testing which requires no human
intervention and the test cases can be executed unattended.
 Increased test coverage: Automation testing ensures more test
coverage in comparison to manual testing where it is not possible to
achieve 100% test coverage.
 Testing can be done frequently: Automation testing means that the
testing can be done frequently thus improving the overall quality of the
software under test.
For more refer – Manual Testing to Automated Testing
What Kinds of Software Tests Should Be Automated First?
1. End-to-End tests
End-to-end testing is a type of software testing used to test whether the
flow of software from the initial stage to the final stage is behaving as
expected. The purpose of end-to-end testing is to identify system
dependencies and to make sure that the data integrity is maintained
between various system components and systems. End-to-end testing:
End-to-end testing, also known as end-to-end functional testing, is a type
of testing that validates the flow of a system from start to finish.
2. Unit tests
Unit testing is automated and is run each time the code is changed to
ensure that new code does not break existing functionality. Unit tests are
designed to validate the smallest possible unit of code, such as a function
or a method, and test it in isolation from the rest of the system.
3. 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.
4. Performance tests
Performance Testing is a type of software testing that ensures software
applications perform properly under their expected workload. It is a testing
technique carried out to determine system performance in terms of
sensitivity, reactivity, and stability under a particular workload.
What Kinds of Software Tests Should Be Done Manually?
Automating tests will save the time and speed up the productivity, but not
every test needs automation. sometime the investment in creating
automated tests the benefits of manual testing.
1. Exploratory testing
Exploratory Testing is a type of software testing in which the tester is
free to select any possible methodology to test the software. It is an
unscripted approach to software testing. In exploratory testing, software
developers use their learning, knowledge, skills, and abilities to test the
software developed by themselves. Exploratory testing checks the
functionality and operations of the software as well as identify the
functional and technical faults in it.
2. Visual Regression Testing
Visual regression testing is a software development technique for
identifying unintentional visual modifications made to the user interface
(UI) of a web application. To find any differences, screenshots of the user
interface (UI) of the application are compared before and after code
changes. Developers can guarantee that changes to the coding don’t
bring about unexpected visual changes that could degrade the user
experience by automating this process.
3. Building a test automation framework for your DevOps
team
Automated testing do not have one is not fit for all. When setting up
automated testing for your team, consider a few important things.
4. Frequency of release
For software that releases regular, like in every month or week, manual
testing is might be okay. But for faster purpose, the automated testing is a
more helpful because it is need for the continuous integration and
delivery.
5. Available tools and ecosystem
Every programming language it has been its own set of tools and utilities
that work well with it. with the same, each type of automated testing has
its own tools for testing, which may not be available for every
programming language. for successfully implement automated testing,
you need tools which match the both the programming language and the
testing pattern you are using.
6. Product market fit and code base maturity
Product-market fit refers to the alignment between a product or service
and the market it serves. It signifies the degree to which a product
satisfies strong market demand and effectively addresses the needs or
problems of a specific market segment. Product market fit means being
in a good market with a product that can satisfy that market.
Difference Between Manual Testing vs Automated Testing
Below are some of the differences between manual testing and automated
testing:
Parameters Manual Testing Automated Testing

Manual testing is not Since it is performed by

accurate at all times third-party tools and/or
due to human error, scripts, therefore it is
Reliability thus it is less reliable. more reliable.

Investment in tools
Heavy investment in
rather than human
human resources.
Investment resources.
 Parameters Manual Testing Automated Testing

Automation testing is
Manual testing is time-
time-saving as due to
consuming due to
the use of the tools the
human intervention
execution is faster in
where test cases are
comparison to manual
generated manually.
Time efficiency testing.

There is no need to It is important to have

have programming programming
Programming knowledge to write the knowledge to write test
knowledge test cases. cases.

There is a possibility
When there are
that the test cases
changes in the code,
executed the first time
regression testing is
will not be able to catch
done to catch the bugs
the regression bugs
due to changes in the
due to the frequently
code.
Regression testing changing requirements.

For more refer – Difference Between Manual Testing vs Automated

Testing
Automation Testing Types
Below are the different types of automation testing:
 Unit testing: Unit testing is a phase in software testing to test the
smallest piece of code known as a unit that can be logically isolated
from the code. It is carried out during the development of the
application.
 Integration testing: Integration testing is a phase in software testing in
which individual software components are combined and tested as a
group. It is carried out to check the compatibility of the component with
the specified functional requirements.
 Smoke testing: Smoke testing is a type of software testing that
determines whether the built software is stable or not. It is the
preliminary check of the software before its release in the market.
 Performance testing: Performance testing is a type of software
testing that is carried out to determine how the system performs in
terms of stability and responsiveness under a particular load.
 Regression testing: Regression testing is a type of software testing
that confirms that previously developed software still works fine after
the change and that the change has not adversely affected existing
features.
 Security testing: Security testing is a type of software testing that
uncovers the risks, and vulnerabilities in the security mechanism of the
software application. It helps an organization to identify the loopholes
in the security mechanism and take corrective measures to rectify the
security gaps.
 Acceptance testing: Acceptance testing is the last phase of software
testing that is performed after the system testing. It helps to determine
to what degree the application meets end users’ approval.
 API testing: API testing is a type of software testing that validates the
Application Programming Interface(API) and checks the functionality,
security, and reliability of the programming interface.
 UI Testing: UI testing is a type of software testing that helps testers
ensure that all the fields, buttons, and other items on the screen
function as desired.
Test Automation Frameworks
Some of the most common types of automation frameworks are:
 Linear framework: This is the most basic form of framework and is
also known as the record and playback framework. In this testers
create and execute the test scripts for each test case. It is mostly
suitable for small teams that don’t have a lot of test automation
experience.
 Modular-Based Framework: This framework organizes each test case
into small individual units known as modules each module is
independent of the other, having different scenarios but all modules are
handled by a single master script. This approach requires a lot of pre-
planning and is best suited for testers who have experience with test
automation.
 Library Architecture Framework: This framework is the expansion of
a modular-based framework with few differences. Here, the task is
grouped within the test script into functions according to a common
objective. These functions are stored in the library so that they can be
accessed quickly when needed. This framework allows for greater
flexibility and reusability but creating scripts takes a lot of time so
testers with experience in automation testing can benefit from this
framework.
Which Tests to Automate?
Below are some of the parameters to decide which tests to automate:
 Monotonous test: Repeatable and monotonous tests can be
automated for further use in the future.
 A test requiring multiple data sets: Extensive tests that require
multiple data sets can be automated.
 Business critical tests: High-risk business critical test cases can be
automated and can be scheduled to run regularly.
 Determinant test: Determinant test cases where it is easy for the
computer to decide whether the test has failed or not can be
automated.
 Tedious test: Test cases that involve repeatedly doing the same action
can be automated so that the computer can do the repetitive task as
humans are very poor at performing the repetitive task with efficiency,
which increases the chances of error.
Automation Testing Process
1. Test Tool Selection: There will be some criteria for the Selection of
the tool. The majority of the criteria include: Do we have skilled
resources to allocate for automation tasks, Budget constraints, and Do
the tool satisfies our needs?
2. Define Scope of Automation: This includes a few basic points such
as the Framework should support Automation Scripts, Less
Maintenance must be there, High Return on Investment, Not many
complex Test Cases
3. Planning, Design, and Development: For this, we need to Install
particular frameworks or libraries, and start designing and developing
the test cases such as NUnit , JUnit , QUnit , or required Software
Automation Tools.
4. Test Execution: Final Execution of test cases will take place in this
phase and it depends on Language to Language for .NET, we’ll be
using NUnit, for Java, we’ll be using JUnit, for JavaScript, we’ll be
using QUnit or Jasmine, etc.
5. Maintenance: Creation of Reports generated after Tests and that
should be documented to refer to that in the future for the next
iterations.
Criteria to Select Automation Tool
Following are some of the criteria for selecting the automation tool:
 Ease of use: Some tools have a steep learning curve, they may
require users to learn a completely new scripting language to create
test cases and some may require users to maintain a costly and large
test infrastructure to run the test cases.
 Support for multiple browsers: Cross-browser testing is vital for
acceptance testing. Users must check how easy it is to run the tests on
different browsers that the application supports.
 Flexibility: No single tool framework can support all types of testing,
so it is advisable to carefully observe what all tool offers and then
decide.
 Ease of analysis: Not all tools provide the same sort of analysis.
Some tools have a nice dashboard feature that shows all the statistics
of the test like which test failed and which test passed. On the other
hand, there can be some tools that will first request users to generate
and download the test analysis report thus, not very user-friendly. It
depends entirely on the tester, project requirement, and budget to
decide which tool to use.
 Cost of tool: Some tools are free and some are commercial tools but
many other factors need to be considered before deciding whether to
use free or paid tools. If a tool takes a lot of time to develop test cases
and it is a business-critical process that is at stake then it is better to
use a paid tool that can generate test cases easily and at a faster rate.
 Availability of support: Free tools mostly provide community support
on the other hand commercial tools provide customer support, and
training material like tutorials, videos, etc. Thus, it is very important to
keep in mind the complexity of the tests before selecting the
appropriate tool.
Best Practices for Test Automation
Below are some of the best practices for test automation that can be
followed:
 Plan self-contained test cases: It is important to ensure that the test
is clearly defined and well-written. The test cases should be self-
contained and easy to understand.
 Plan the order to execute tests: Planning the test in the manner that
the one test creates the state for the second test can be beneficial as it
can help to run test cases in order one after another.
 Use tools with automatic scheduling: If possible use tools that can
schedule testing automatically according to a schedule.
 Set up an alarm for test failure: If possible select a tool that can raise
an alarm when a test failure occurs. Then a decision needs to be made
whether to continue with the test or abort it.
 Reassess test plans as the app develops and changes: It is
important to continuously reassess the test plan as there is no point in
wasting resources in testing the legacy features in the application
under test.
Popular Automation Tools
 Selenium: Selenium is an automated testing tool that is used
for Regression testing and provides a playback and recording facility. It
can be used with frameworks like JUnit and Test-NG . It provides a
single interface and lets users write test cases in languages like Ruby,
Java, Python, etc.
 QTP: Quick Test Professional (QTP) is an automated functional testing
tool to test both web and desktop applications. It is based on the VB
 scripting language and it provides functional and regression test
automation for software applications.
 Sikuli: It is a GUI-based test automation tool that is used for interacting
with elements of web pages. It is used to search and automate
graphical user interfaces using screenshots.
 Appium: Apium is an open-source test automation framework that
allows QAs to conduct automated app testing on different platforms like
iOS, Android, and Windows SDK.
 Jmeter: Apache JMeter is an open-source Java application that is
used to load test the functional behavior of the application and
measure the performance.
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.
 Saves Time and Money: The initial investment for automation testing
is on the higher side but it is cost-efficient and time-efficient in the long
run. This is due to the reduction in the amount of time required for test
case creation and execution which contributes to the high quality of
work.
 Earlier detection of defects: Automation testing documents the
defects, thus making it easier for the development team to fix the
defect and give a faster output. The earlier the defect is identified, the
more easier and cost-efficient it is to fix the defects.
Disadvantages of Automation Testing
 High initial cost: Automation testing in the initial phases requires a lot
of time and money investment. It requires a lot of effort for selecting the
tool and designing customized software.
 100% test automation is not possible: Generally, the effort is to
automate all the test cases but in practical real situations not all test
cases can be automated some test cases require human intervention
 for careful observation. There is always a human factor, i.e., it can’t test
everything like humans(design, usability, etc.).
 Not possible to automate all testing types: It is not possible to
automate tests that verify the user-friendliness of the system. Similarly,
if we talk about the graphics or sound files, even their testing cannot be
automated as automated tests typically use textual descriptions to
verify the output.
 Programming knowledge is required: Every automation testing tool
uses any one of the programming languages to write test scripts. Thus,
it is mandatory to have programming knowledge for automation testing.
 False positives and negatives: Automation tests may sometimes fail
and reflect that there is some issue in the system but there is no issue
present and in some cases, it may generate false negatives if tests are
designed to verify that some functionality exists and not to verify that it
works as expected