SOFTWARE TESTING AND

AUTOMATION
UNIT -1 - INTRODUCTION
What is software testing?

• Software testing is the process of assessing the functionality of a software

program. The process checks for errors and gaps and whether the
outcome of the application matches desired expectations before the
software is installed and goes live.
• The following are important reasons why software testing techniques should
be incorporated into application development:
• Identifies defects early
• Improves product quality
• Increases customer trust and satisfaction
• Detects security vulnerabilities
• Helps with scalability
• Saves money
 Types of software testing

• the two main categories are dynamic testing and static testing. Dynamic
testing is an assessment that's conducted while the program is executed;
static testing examines the program's code and associated documentation
. Dynamic and static methods are often used together.
 Testing as an Engineering Activity

• Software systems are becoming more challenging to build. New methods,

techniques, and tools are becoming available to support development and
maintenance tasks. Because software now has such an important role in
our lives both economically and socially, there is pressure for software
professionals to focus on quality issues
• Highly qualified staff ensure that software products are built on time,
within budget, and are of the highest quality with respect to attributes such
as reliability, correctness, usability, and the ability to meet all user
requirements.
Using an engineering approach to software development implies that:
• • The development process is well understood;
• • Projects are planned;
• • Life cycle models are defined and adhered to;
• • Standards are in place for product and process;
• • Measurements are employed to evaluate product and process quality;
• • Components are reused;
• • Validation and Verification processes play a key role in quality
determination;
• • Engineers have proper education, training, and certification.
 Testing as a process
• Step-1: Assess Development Plan and Status –
This initiative may be prerequisite to putting together Verification,
Validation, and Testing Plan wont to evaluate implemented software
solution. During this step, testers challenge completeness and correctness
of event plan. Based on extensiveness and completeness of Project Plan
testers can estimate quantity of resources they’re going to got to test
implemented software solution.
• Step-2: Develop the Test Plan –
Forming plan for testing will follow an equivalent pattern as any software
planning process. The structure of all plans should be an equivalent, but
content will vary supported degree of risk testers perceive as related to
software being developed.

• Step-3: Test Software Requirements –

Incomplete, inaccurate, or inconsistent requirements cause most software
failures. The inability to get requirement right during requirements
gathering phase can also increase cost of implementation significantly.
Testers, through verification, must determine that requirements are
accurate, complete, and they do not conflict with another.
• Step-4: Test Software Design –
This step tests both external and internal design primarily through verification techniques. The testers
are concerned that planning will achieve objectives of wants, also because design being effective and
efficient on designated hardware.

• Step-5: Build Phase Testing –

The method chosen to build software from internal design document will determine type and
extensiveness of testers needed. As the construction becomes more automated, less testing are going to
be required during this phase. However, if software is made using waterfall process, it’s subject to error
and will be verified. Experience has shown that it’s significantly cheaper to spot defects during
development phase, than through dynamic testing during test execution step.
• Step-6: Execute and Record Result –
This involves testing of code during dynamic state. The approach,
methods, and tools laid out in test plan are going to be wont to validate
that executable code actually meets stated software requirements, and
therefore the structural specifications of design.

• Step-7: Acceptance Test –

Acceptance testing enables users to gauge applicability and usefulness of
software in performing their day-to-day job functions. This tests what user
believes software should perform, as against what documented
requirements state software should perform.
• Step-8: Report Test Results –
Test reporting is continuous process. It may be both oral and written. It
is important that defects and concerns be reported to the appropriate
parties as early as possible, so that corrections can be made at the lowest
possible cost.

• Step-9: The Software Installation –

Once test team has confirmed that software is prepared for production
use, power to execute that software during production environment
should be tested. This tests interface to operating software, related
software, and operating procedures.
• Step-10: Test Software Changes –
While this is often shown as Step 10, within context of performing
maintenance after software is implemented, concept is additionally
applicable to changes throughout implementation process. Whenever
requirements changes, test plan must change, and impact of that change
on software systems must be tested and evaluate.

• Step-11: Evaluate Test Effectiveness –

Testing improvement can best be achieved by evaluating effectiveness of
testing at top of every software test assignment. While this assessment is
primarily performed by testers, it should involve developers, users of
software, and quality assurance professionals if function exists within the
IT organization.
 Testing Axioms

• In software testing field, there are several so called ‘fundamental truths’ which every tester should know and
keep during checking mobile or web software products. These statements are verified and supported by
constant practice and the rich experience of various testers.

• Testing Axioms Are the Following:

• The complete testing is impossible.

• The quality control is always risk-based.

• The absence of bugs cannot be shown with the help of testing.

• One discovered error causes the appearance of many other bugs.

• An unexperienced tester may believe that he is able to detect all bugs of the software product. He issure that
no errors, any at all, will be missed. But it is impossible to check every system element, every input variable,
etc.
 Why Is It Impossible to Completely Test a
Product?

• The quantity of potential input combinations is huge.

• In accordance, the number of possible outputs is very large too.
• The amount of available paths through the software is huge.
• The product specification is not objective. A tester may discover an issue,
but a stakeholder does not find it to be a real bug.
• The whole life is not enough to check all test conditions and develop a
perfect product. To check every product aspect may require even the
work of whole generation of testers. So a specialist should keep this
statement in mind during functional testing or performance testing.
• As it is not possible to check all test scenarios, then the untested areas
will be certainly left. That is why software testing is a risk-based activity.
One cannot know where there may be bugs and where not. If a tester
misses a serious bug and discovers it after the release, then the cost of
this bug will be very high.
• Usually bugs do not appear one by one, sometimes they are
interconnected. A tester should be careful when he has discovered one
error during black box testing or usability testing, because nearby
there may be several more bugs. It can be easily explained.
 Why May Bugs Follow Each Other?

• It was a bad day for a programmer. Thedeveloper’s low spirit or a bad

mood influences the quality of work. In such a case, the code will be raw.
• People are slaves of their habits. The developers may repeat the same
mistake again and again.
• One bug may be only the tip of the iceberg. At first sight, some bugs may
seem to be unrelated. But if one examines them closely and deep, he will
find out that the whole design or architecture does not match the
specification at all.
 Software Testing Principles
1. Testing shows the presence of defects
2. Exhaustive testing is not possible
3. Early testing
4. Defect clustering
5. Pesticide paradox
6. Testing is context-dependent
7. Absence of errors fallacy
8. Testing Is a Risk-Based Activity
9. Testing Cannot Prove Software Correctness
10.Absence-of-Error Fallacy
11.Automated Testing Complements Manual Testing
12.Testing Is Iterative
• 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 testing can never ensure that software
is 100% bug-free. Testing can reduce the number of defects but not remove all defects.

• 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.
• 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.

• 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.
• 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.

• 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.
• 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.

• Testing Is a Risk-Based Activity: Testing efforts should be prioritized

according to the risks associated with different features or
functionalities. Focus testing on areas that are critical to the success of
the application.
• Testing Cannot Prove Software Correctness: Testing demonstrates the
presence of defects but cannot prove that the software is entirely correct.
It provides confidence in the software’s behavior within the scope of the
tests performed.

• Absence-of-Error Fallacy: The absence of detected defects does not

proof that the software is error-free. It implies that the testing process
has not found any issues within the defined scope and constraints
• Automated Testing Complements Manual Testing: Combining Both
automated and manual testing allows for more comprehensive test
coverage.

• Testing Is Iterative: Testing is an iterative process that continues

throughout the software development life cycle.
 The Tester's Role in a Software Development Organization

• The tester’s job is to

• Reveal defects,

• Find weak points,

• Inconsistent behavior,

• Circumstances where the software does not work as expected.

• It is difficult for developers to effectively test their own code. A tester needs very good
programming experience in order to understand how code is constructed, and to know
where and what types of, defects could occur.
• A tester should work with the developers to produce high-quality software that meets
the customers’ requirements.

• Teams of testers and developers are very common in industry, and projects should
have a correct developer/tester ratio. The ratio will vary depending on

• Available resources,

• Type of project,

• TMM level.(Test Maturity Model)

• Nature of the project

• Project Schedules
 Origins
of Defects

• The term defect and its relationship to the terms error and failure in the
context of the software development domain. Defects have detrimental affects
on software users, and software engineers work very hard to produce high-
quality software with a low number of defects. But even under the best of
development circumstances errors are made, resulting in defects being
injected in the software during the phases of the software life cycle. Defects
as shown in figure stem from the following sources
 Cost of defects

• The cost of defects identified during Software Testing, completely depends on the impact of the defects
found. The earlier the defect is found, easier and less costly it is to fix these defects. For instance, if there is
a defect found in the project requirement specifications and analysis, then it is relatively cheaper to fix it.

• Similarly, if the defects or failures are found in the design of the software, then the product design is
corrected and then re-issued. However, if these defects somehow get missed by testers and if they are
identified during the user acceptance phase, then it can be way too expensive to fix such type of errors.

• If during the software development process, an error is made and the consequent defect is detected in the
requirements phase itself, then it is relatively cheaper to fix it. This is because the software is not yet in
developing stage and it is easy to make requirement specified changes.
 Defect Classes,the Defect Repository, and Test Design

• Defects can be classified in many ways. It is important for an organization to follow a single classification scheme and

apply it to all projects.

• Some defects will fit into more than one class or category. Because of this problem, developers, testers, and SQA staff

should try to be as consistent as possible when recording defect data.

• The defect types and frequency of occurrence should be used in test planning, and test design. Execution-based

testing strategies should be selected that have the strongest possibility of detecting particular types of defects. The

four classes of defects are as follows,

• Requirements and specifications defects,

• Design defects,

• Code defects,

• Testing defects
• 1. Requirements and Specifications Defects

• The beginning of the software life cycle is important for ensuring high quality in
the software being developed. Defects injected in early phases can be very
difficult to remove in later phases. Since many requirements documents are
written using a natural language representation, they may become
• Ambiguous,
• Contradictory,
• Unclear,
• Redundant,
• Imprecise.
• Some specific requirements/specification defects are:

• 1.1 Functional Description Defects

• The overall description of what the product does, and how it should behave

(inputs/outputs), is incorrect, ambiguous, and/or incomplete.

• 1.2 Feature Defects

• Features is described as distinguishing characteristics of a software component or

system. Feature defects are due to feature descriptions that are missing, incorrect,

incomplete, or unnecessary.
•
1.3 Feature Interaction Defects

• These are due to an incorrect description of how the features should

interact with each other.

• 1.4 Interface Description Defects

These are defects that occur in the description of how the target software

is to interface with external software, hardware, and users.

Design Defects

• Design defects occur when the following are incorrectly designed,

• System components,
• Interactions between system components,
• Interactions between the components and outside software/hardware, or users
• It includes defects in the design of algorithms, control, logic, data elements, module interface
descriptions, and external software/hardware/user interface descriptions. The design defects are,
• 2.1 Algorithmic and Processing Defects

• These occur when the processing steps in the algorithm as described by the pseudo code are
incorrect.
• 2.2 Control, Logic, and Sequence Defects

• Control defects occur when logic flow in the pseudo code is not correct.
• 2.3 Data Defects

• These are associated with incorrect design of data structures.

• 2.4 Module Interface Description Defects

• These defects occur because of incorrect or inconsistent usage of parameter

types, incorrect number of parameters or incorrect ordering of parameters.

• 2.5 Functional Description Defects

The defects in this category include incorrect, missing, or unclear design

elements.
• 2.6 External Interface Description Defects

• These are derived from incorrect design descriptions for interfaces with

COTS components, external software systems, databases, and hardware

devices.
• Coding Defects

• Coding defects are derived from errors in implementing the code. Coding
defects classes are similar to design defect classes. Some coding defects come
from a failure to understand programming language constructs, and
miscommunication with the designers.
• Algorithmic and Processing Defects

• Code related algorithm and processing defects include

• Unchecked overflow and underflow conditions,

• Comparing inappropriate data types,

• Converting one data type to another,

• Incorrect ordering of arithmetic operators,

• Misuse or omission of parentheses,

• Precision loss,

• Incorrect use of signs.

• Control, Logic and Sequence Defects
• This type of defects include incorrect expression of case statements,
incorrect iteration of loops, and missing paths.
• 3.3 Typographical Defects
• These are mainly syntax errors, for example, incorrect spelling of a
variable name that are usually detected by a compiler or self-reviews, or
peer reviews.
• 3.4 Initialization Defects

• This type of defects occur when initialization statements are omitted or are
incorrect. This may occur because of misunderstandings or lack of
communication between programmers, or programmer`s and designer`s,
carelessness, or misunderstanding of the programming environment.
• Data-Flow Defects
• Data-Flow defects occur when the code does not follow the necessary data-flow
conditions.
• 3.6 Data Defects
• These are indicated by incorrect implementation of data structures.
Module Interface Defects

• Module Interface defects occurs because of using incorrect or inconsistent

parameter types, an incorrect number of parameters, or improper ordering
of the parameters.
• 3.8 Code Documentation Defects
• When the code documentation does not describe what the program
actually does, or is incomplete or ambiguous, it is called a code
documentation defect.
 • Interrupts and exception
handling,
• External Hardware, Software
Interfaces Defects • Data exchanges with hardware,
• Protocols,
• These defects occur because of
• Formats,
problems related to
• Interfaces with build files,
• System calls,
• Timing sequences.
• Links to databases,
• Input/output sequences,
• Memory usage,
• Resource usage,
• Testing Defects
• Test plans, test cases, test harnesses, and test procedures can also contain
defects. These defects are called testing defects. Defects in test plans are
best detected using review techniques.
• 4.1 Test Harness Defects
• In order to test software, at the unit and integration levels, auxiliary code
must be developed. This is called the test harness or scaffolding code. The
test harness code should be carefully designed, implemented, and tested
since it is a work product and this code can be reused when new releases
of the software are developed.
• Test Case Design and Test Procedure Defects
• These consists of incorrect, incomplete, missing, inappropriate test cases,
and test procedures.
• DEFECT EXAMPLES:- The Coin Problem Requirement
Specification
• Specification for program calculate_coin_value This program
calculates the total dollars and cents value for a set of coins.
the user inputs the amount of pennies, nickels , dimes ,
quarters, half-dollars, and dollar coins held. There are six
different denominations of coins. The program outputs the
total dollar and cent values of the coins to the users
Input:number_of_coins is an integer Outputs:-
number_of_dollars is an integer Number_of_cents is an
integer
• A spec above shows the sample informal specification for a simple program
that calculates the total money value of a set of coins. The program could be
a component of an incentive cash register system to support retail store
clerks. Coin Problem in Detail : (100 cent = 1 dollar) if suppose input for coin
values given as 1 for all then the calculation as shown below.
• No of Coins (input) Coin Value
• 1(pennies) X 1 = 1
• 1 (nickels) X 5 = 5
• 1(dimes) X 10 = 10
• 1(quarters) X 25 = 25
• 1(half-dollars) X 50 = 50
• 1(dollar) X 100 = 100
• 191
• Output
• No of Dollars : 1
• No of Cents : 91
• The given specification does not specify the above details
clearly.
 Developer/Tester Support for
Developing a Defect Repository
• Software engineers and test specialists should follow the examples of
engineers in other disciplines who make use of defect data. A requirement
for repository development should be a part of testing and/or debugging
policy statements.
• Forms and templates should be designed to collect the data. Each defect
and frequency of occurrence must be recorded after testing.
• Defect monitoring should be done for each on-going project. The
distribution of defects will change when changes are made to the process.
• The defect data is useful for test planning. It is a TMM level 2 maturity
goal. It helps a tester to select applicable testing techniques, design the
test cases, and allocate the amount of resources needed to detect and
remove defects. This allows tester to estimate testing schedules and
costs.
• The defect data can support debugging activities also. A defect repository
can help in implementing several TMM maturity goals including
• Controlling and monitoring of test,
• Software quality evaluation and control,
• Test measurement,
• Test process improvement.
 Defect Prevention strategies

• is basically defined as a measure to ensure that defects being detected so

far, should not appear or occur again. For facilitating communication
simply among members of team, planning and devising defect prevention
guidelines, etc., Coordinator is mainly responsible. Coordinator is mainly
responsible to lead defect prevention efforts, to facilitate meetings, to
facilitate communication between team members and management, etc.
• DP board generally has a quarterly plan in which sets some goals at
organization level. To achieve these goals, various methods or activities
are mostly used and carried out to achieve and complete these goals.
 Software Requirement Analysis

• The main cause of defects in software products is due to error in software requirements and designs.

Software requirements and design both are important, and should be analyzed in an efficient way with

more focus. Software requirement is basically considered an integral part of

Software Development Life Cycle (SDLC). These are the requirements that basically describes features

and functionalities of target product and also conveys expectations or requirement of users from

software product.

• Therefore, it is very much needed to understand about software requirements more carefully, If

requirements are not understood well by tester and developers, then there might be chance of occurring

of issue or defect in further process. Therefore, it is essential to analyze and evaluate requirements in

more appropriate and proper manner.

 Review and Inspection :
• Review and inspection, both are essential and integral part of software
development. They are considered as powerful tools that can be used to
identify and remove defects if present before their occurrence and impact
on production.
• Review and inspection come in different levels or stages of defect
prevention to meet different needs. They are used in all software
development and maintenance methods. There are two types of review
i.e., self-review and peer-review.
 Defect Logging and
Documentation
• After successful analysis and review, there should be records maintained
about defects to simply complete description of defect. This record can be
further used to have better understanding of defects.

• After getting knowledge and understanding of defect, then only one can
take some effective and required measures and actions to resolve
particular defects so that defect cannot be carried further to next phase.
4.Root Cause Analysis : Root because analysis is basically analysis of main
cause of defect. It simply analysis what triggered defect to occur. After
analyzing main cause of defect, one can find best way to simply avoid
occurrence of such types of defects next time.

5.Static Code Analysis: To find any problems in the source code without
running the program, use automated techniques for static code analysis.
Before the code is even compiled, these tools can detect typical
programming errors, coding standard violations and other problems.
6.Pair programming: It involves two programmers sharing a workstation,
where one writes code while the other goes over each line as it is written.
This real-time communication between team members promotes constant
feedback and helps in the early detection of mistakes.

7.Test-Driven Development (TDD): Prior to writing any code, write

automated tests. This method helps identify errors early in the
development process and guarantees that the code complies with the
requirements.
8.Training and Skill Development: Investing in continuous training and
skill development for team members is recommended. Skilled developers
are better able to follow best practices and are less prone to make
frequent mistakes.

9.Checklists: To make sure that crucial actions are not missed during the
various stages of development, use checklists. Developers and reviewers
can quickly confirm that established standards are being followed by
using checklists as a reference.