Software Testin

Software Testing........................................................................................................... 1
1. What is Software Testing?................................................................................. 2
2. Importance of the Software Testing................................................................2
3. Seven Testing Principles.................................................................................... 3
4. Software Development Cycle............................................................................ 4
5. Manual Testing vs Automation Testing............................................................6
6. Static Testing vs Dynamic Testing....................................................................7
7. Functional Testing............................................................................................. 11
8. White box - Unit Testing.................................................................................. 12
9. Black box - Integration Testing.......................................................................13
10. Smoke Testing................................................................................................. 15
11. Sanity / Delta testing....................................................................................... 16
12. System Testing............................................................................................... 17
13. The Software Testing Hierarchy..................................................................17
14. Equivalence Class Partitioning (ECP)..........................................................18
15. Boundary Value Analysis (BVA)....................................................................20
16. Decision Table Testing................................................................................... 21
17. Non-functional Testing.................................................................................. 24
18. Regression testing......................................................................................... 27
 1.What is Software Testing?

Software testing is a process used to identify the correctness,

completeness, and quality of developed computer software. It includes a set of
activities conducted with the intent of finding errors in software so that it could
be corrected before the product is released to the end users.

In simple words, software testing is an activity to check whether the actual

results match the expected results and to ensure that the software system is

defect free.

2.Importance of the Software Testing

Software bugs can potentially cause monetary and human loss, history is
full of such examples:
- China Airlines Airbus A300 crashing due to a software bug on April 26,
1994, killing 264 innocent lives
- In 1985, Canada's Therac-25 radiation therapy machine malfunctioned
due to software bug and delivered lethal radiation doses to patients,
leaving 3 people dead and critically injuring 3 others
- In April of 1999, a software bug caused the failure of a $1.2 billion military
satellite launch, the costliest accident in history
- In may of 1996, a software bug caused the bank accounts of 823
customers of a major U.S. bank to be credited with 920 million US dollars

As Paul Elrich puts it - "To err is human, but to really foul things up you
need a computer."
 3.Seven Testing Principles

Principle 1 Testing shows presence of defects

Testing can show that the defects are present, but cannot prove that there
are no defects. Even after testing the application or product thoroughly we
cannot say that the product is 100% defect free. Testing always reduces the
number of undiscovered defects remaining in the software but even if no
defects are found, it is not a proof of correctness.

Principle 2 Exhaustive testing is impossible

Testing everything including all combinations of inputs and preconditions

is not possible. So, instead of doing the exhaustive testing we can use risks and
priorities to focus testing efforts. So, accessing and managing risk is one of the
most important activities and reason for testing in any project.

Principle 3 Early Testing

In the software development life cycle testing activities should start as

early as possible and should be focused on defined objectives.

Principle 4 Defect Clustering

A small number of modules contains most of the defects discovered

during pre-release testing or shows the most operational failures.

Principle 5 Pesticide Paradox

If the same kinds of tests are repeated again and again, eventually the
same set of test cases will no longer be able to find any new bugs. To overcome
this Pesticide Paradox, it is really very important to review the test cases
regularly and new and different tests need to be written to exercise different
parts of the software or system to potentially find more defects

Principle 6 Testing is context dependent

 Testing is basically context dependent. Different kinds of sites are tested
differently. For example, safety critical software is tested differently from an e-
commerce site.

Principle 7 Absence of error - fallacy

If the system built is unusable and does not fulfil the users needs and
expectations then finding and fixing defects does not help.

4.Software Development Cycle

Activities performed in each stage

Requirement Gather as much information as possible about the

Gathering
details & specifications of the desired software from the
stage
client. This is nothing but the Requirements gathering
stage.

Design Stage Plan the programming language like Java, PHP, .net;
database like Oracle, MySQL, etc. Which would be suited
for the project, also some high-level functions &
architecture.

Built Stage After design stage, it is built stage, that is nothing but
actually code the software

Test Stage Next, you test the software to verify that it is built as
per the specifications given by the client.

Deployment Deploy the application in the respective environment

stage

Maintenance Once your system is ready to use, you may require to

stage
change the code later on as per customer request
 Costs of fixing a defect increases across the development life cycle. The earlier
in life cycle a defect is detected, the cheaper it is to fix it.

The V model of testing was developed where for every phase, in the
Development life cycle there is a corresponding Testing phase:

The left side of the model is Software Development Life Cycle - SDLC
The right side of the model is Software Test Life Cycle - STLC
The entire figure looks like a V, hence the name V model

SDLC:
SDLC is Software Development Life Cycle. It is the sequence of
activities carried out by Developers to design and develop high-quality
software.
 Though SDLC uses the term Development, it does not involve just coding
tasks done by developers but also incorporates the tasks contributed by
testers and stakeholders.
In SDLC, test cases are created.

STLC:
STLC is Software Testing Life Cycle. It consists of series of activities
carried out by Testers methodologically to test your software product.
Though STLC uses the term testing it does not involve just testers, at
some instances, they have to involve developers as well.
In STLC Test cases are executed.

5.Manual Testing vs Automation Testing

Manual Testing Automated Testing

Manual testing requires human Automation Testing is use of tools to

intervention for test execution. execute test cases

Manual testing will require skilled labor, Automation Testing saves time, cost
long time & will imply high costs. and manpower. Once recorded, it's
easier to run an automated test suite

Any type of application can be tested Automated testing is recommended

manually, certain testing types like ad- only for stable systems and is mostly
hoc and monkey testing are more suited used for regression testing
for manual execution.
Manual testing can be become repetitive The boring part of executing same
and boring. test cases time and again, is handled
by automation software in
automation testing.

6.Static Testing vs Dynamic Testing

Under Static Testing code is not executed. Rather it manually
checks the code, requirement documents, and design documents to find
errors. Hence, the name "static".
Main objective of this testing is to improve the quality of software
products by finding errors in early stages of the development cycle. This
testing is also called as Non-execution technique or Verification testing.
Static testing involves manual or automated reviews of the
documents. This review, is done during initial phase of testing to catch
defect early in STLC. It examines work documents and provides review
comments
Work document can be of following:

Requirement specifications
Design document
Source Code
Test Plans
Test Cases
Test Scripts
Help or User document
 Web Page content

Summary:

Static testing is to find defects early as possible.

Static testing not a substitute to dynamic testing, both find
different type of defects
Reviews are effective technique for Static Testing
Reviews not only help finding defects but also understand missing
requirements, design defects, non-maintainable code,

Under Dynamic Testing code is executed. It checks for functional

behavior of software system, memory/cpu usage and overall performance
of the system. Hence the name "Dynamic".
Main objective of this testing is to confirm that the software product
works in conformance with the business requirements. This testing is also
called as Execution technique or Validation testing.
Dynamic testing executes the software and validates the output with
the expected outcome. Dynamic testing is performed at all levels of
testing and it can be either black or white box testing.
 Testing Techniques used for Static Testing:
Informal Reviews: This is one of the type of review which doesn't
follow any process to find errors in the document. Under this technique,
you just review the document and give informal comments on it.
Technical Reviews: A team consisting of your peers, review the
technical specification of the software product and checks whether it is
suitable for the project. They try to find any discrepancies in the
specifications and standards followed. This review concentrates mainly
on the technical document related to the software such as Test
Strategy, Test Plan and requirement specification documents.
Walkthrough: The author of the work product explains the product
to his team. Participants can ask questions if any. Meeting is led by the
author. Scribe makes note of review comments
Inspection: The main purpose is to find defects and meeting is led
by trained moderator. This review is a formal type of review where it
follows strict process to find the defects. Reviewers have checklist to
 review the work products .They record the defect and inform the
participants to rectify those errors.
Static code Review: This is systematic review of the software
source code without executing the code. It checks the syntax of the
code, coding standards, code optimization, etc. This is also termed as
white box testing .This review can be done at any point during
development.

Testing Techniques used for Dynamic Testing:

Unit Testing: Under unit testing, individual units or modules are

tested by the developers. It involves testing of source code by
developers.
Integration Testing: Individual modules are grouped together and
tested by the developers. The purpose is to determine that modules are
working as expected once they are integrated.
System Testing: System testing is performed on the whole system
by checking whether the system or application meets the requirement
specification document.

Difference between Static and Dynamic Testing:

Static Testing Dynamic Testing

Testing done without executing the Testing done by executing the

program program
 This testing does verification process Dynamic testing does validation
process

Static testing is about prevention of Dynamic testing is about finding and

defects fixing the defects

Static testing gives assessment of code Dynamic testing gives

and documentation bugs/bottlenecks in the software
system.

Static testing involves checklist and Dynamic testing involves test cases for
process to be followed execution

This testing can be performed before Dynamic testing is performed after

compilation compilation

Static testing covers the structural and Dynamic testing covers the executable
statement coverage testing file of the code

Cost of finding defects and fixing is Cost of finding and fixing defects is
less high

Return on investment will be high as Return on investment will be low as

this process involved at early stage this process involves after the
development phase

More reviews comments are highly More defects are highly recommended
recommended for good quality for good quality.

Requires loads of meetings Comparatively requires lesser

meetings

Conclusion:

Verification and Validation are two measures used to check that the
software product meets the requirements specifications. Static testing
involves verification whereas dynamic testing involves validation.
Together they help improve software quality
 7.Functional Testing
Functional testing verifies that each function of the software
application operates in conformance with the requirement specification.
This testing mainly involves black box testing and it is not concerned
about the source code of the application.
The testing can be done either manually or using automation

Types of Functional testing are:

Unit Testing
Smoke Testing
Sanity Testing
Integration Testing
White box testing
Black Box testing
User Acceptance testing
Regression Testing

8.White box - Unit Testing

EXAMPLE
 What is Unit Testing?

Unit testing of software applications is done during the development

(coding) of an application.

The objective of unit testing is to isolate a section of code and verify

its correctness. The goal of unit testing is to isolate each part of the
program and show that the individual parts are correct. Unit testing is
usually performed by the developer.
A unit is the smallest testable part of an application like functions,
classes, procedures, interfaces.
Unit tests are basically written and executed by software
developers to make sure that code meets its design and requirements and
behaves as expected.

Method Used for unit testing:

White Box Testing method is used for executing the unit test.

When Unit testing should be done?

Unit testing should be done before Integration testing.

By whom unit testing should be done?

Unit testing should be done by the developers

Advantages of Unit testing:

1. Issues are found at early stage. Since unit testing are carried out
by developers where they test their individual code before the integration.
Hence the issues can be found very early and can be resolved then and
there without impacting the other piece of codes.

2. Unit testing helps in maintaining and changing the code. This is

possible by making the codes less interdependent so that unit testing can
be executed. Hence chances of impact of changes to any other code gets
reduced.

3. Since the bugs are found early in unit testing hence it also helps
in reducing the cost of bug fixes. Just imagine the cost of bug found
during the later stages of development like during system testing or
during acceptance testing.

4. Unit testing helps in simplifying the debugging process. If suppose

a test fails then only latest changes made in code needs to be debugged.

White-box techniques

1. Branch Coverage

2. Statement Coverage

3. Modified condition/Decision Coverage [MC/DC]

 9.Black box - Integration Testing

EXAMPLE
What is Integration Testing?
In Integration Testing, individual software modules are integrated
logically and tested as a group.
A typical software project consists of multiple software modules,
coded by different programmers.
Integration testing focuses on checking data communication
amongst these modules.

Why do Integration Testing?

Although each software module is unit tested, defects still exist for
various reasons like:

A Module in general is designed by an individual software developer

whose understanding and programming logic may differ from other
programmers. Integration testing becomes necessary to verify the
software modules work in unity
At the time of module development, there are wide chances of
change in requirements by the clients. These new requirements may not
be unit tested and hence system integration testing becomes necessary.
Interfaces of the software modules with the database could be
erroneous
External Hardware interfaces, if any, could be erroneous
Inadequate exception handling could cause issues.

Integration Test Case:

 Integration Test case differs from other test cases in the sense
it focuses mainly on the interfaces & flow of data/information
between the modules. Here priority is to be given for the integrating
links rather than the unit functions which are already tested.

Sample Integration Test Cases for the following scenario: Application

has 3 modules say 'Login Page', 'Mail box' and 'Delete mails' and each of
them are integrated logically.

Here do not concentrate much on the Login Page testing as it's

already been done in Unit Testing. But check how it's linked to the Mail
Box Page.

Similarly Mail Box: Check its integration to the Delete Mails Module.

Tes Test Case Objective Test Case Expected Result

t Description
Cas
e
ID

1 Check the interface Enter login To be directed to the

link between the Login credentials and Mail Box
and Mailbox module click on the Login
button

2 Check the interface From Mail box select Selected email

link between the the an email and should appear in the
Mailbox and Delete click delete button Deleted/Trash folder
Mails Module
 10. Smoke Testing
Smoke testing is a type of software testing which ensures that
the major functionalities of the application are working fine. This testing is
also known as Build Verification testing.
It is a non-exhaustive testing with very limited test cases to ensure
that the important features are working fine and we are good to proceed
with the detailed testing.
The term smoke testing is originated from the hardware
testing, where a device when first switched on is tested for the smoke or
fire from its components. This ensures that the hardwares basic
components are working fine and no serious failures are found.
In Smoke Testing, the test cases chosen cover the most
important functionality or component of the system. Smoke testing is
done to ensure that the basic functionalities of the application are working
fine.

Example a typical smoke test would be:

- Verify that the application launches successfully

- Check that the GUI is responsive
- "Does the program run?"
- Do we have the correct version installed?
- "Does it open a window?"
- "Does clicking the main button do anything?"

Examples for Smoke Testing

Let us assume that there is an application like Student Network

which has 15 modules. Among them, there are 4 important components
 like Login page, Adding student details, updating it and deleting it. As a
part of smoke testing we will test the login page with valid input. After
login we will test the addition, updating and deletion of records. If all the 4
critical components work fine then the build is stable enough to proceed
with detailed testing. This is known as Smoke testing.

Advantages of Smoke testing

It helps in finding the bugs in the early stage of testing.
It helps in finding the issues that got introduced by the integration of
components.
It helps in verifying the issues fixed in the previous build are NOT
impacting the major functionalities of the application.
Very limited number of test cases is required to do the smoke
testing.
Smoke testing can be carried out in small time.

11. Sanity / Delta testing

After receiving a software build, with minor changes in code,

or functionality, Sanity testing is performed to ascertain that the
bugs have been fixed and no further issues are introduced due to
these changes. The goal is to determine that the proposed functionality
works roughly as expected. If sanity test fails, the build is rejected
to save the time and costs involved in a more rigorous testing.
The objective is "not" to verify thoroughly the new
functionality, but to determine that the developer has applied some
rationality (sanity) while producing the software. For instance, if your
scientific calculator gives the result of 2 + 2 =5, then, there is no point
testing the advanced functionalities like sin 30 + cos 50.
12. System Testing
In the world of software testing, system testing is the testing of a
complete and fully integrated software product.

Usually software is only one element of a larger computer based

system. Ultimately, software is interfaced with other software/hardware
systems.
System testing is actually a series of different tests whose
sole purpose is to exercise the full computer based system.
System testing falls under the black box testing category of
software testing.
White box testing is the testing of the internal workings or code of a
software application. In contrast, black box or system testing is the
opposite system testing involves the external workings of the software
from the user's perspective.

What do you verify in System Testing?

System testing involves testing the software code for following

Testing the fully integrated applications including external
peripherals in order to check how components interact with one another
and with the system as a whole. This is also called End to End scenario
testing.
Verify thorough testing of every input in the application to check
for desired outputs.
Testing of the user's experience with the application. .

13. The Software Testing Hierarchy

These are the steps taken to fully test new software in preparation
for marketing it:
 Unit testing - testing performed on each module or block of code
during development. Unit testing is normally done by the programmer
who writes the code.
Integration testing - testing done before, during and after
integration of a new module into the main software package. This involves
testing of each individual code module. One piece of software can contain
several modules which are often created by several different
programmers. It is crucial to test each module's effect on the entire
program model.
System testing - testing done by a professional testing agent on
the completed software product before it is introduced to the market.
Acceptance testing - beta testing of the product done by the
actual end users.

14. Equivalence Class Partitioning (ECP)

- Este o tehnica black box ce poate fi aplicata tuturor nivelelor de

testare ca: unit, integration, system.

- Aceasta tehnica imparte datele de intrare in parti echivalente.

- De obicei se foloseste aceasta tehnica cand se testeaza range-ul al

unei date de intrare.

Exemplu Equivalence Partitioning (EP)

Let's consider the behavior of tickets in the Flight reservation

application, while booking a new flight.
 Ticket values 1 to 10 are considered valid & ticket is booked. While
value 11 to 99 are considered invalid for reservation and error message
will appear, "Only ten tickets may be ordered at one time."

Here is the test condition

1. Any Number greater than 10 entered in the reservation column (let

say 11) is considered invalid.

2. Any Number less than 1 that is 0 or below, then it is considered

invalid.

3. Numbers 1 to 10 are considered valid

4. Any 3 Digit Number say -100 is invalid.

 We cannot test all the possible values because if done, the number
of test cases will be more than 100.To address this problem, we use
equivalence partitioning hypothesis where we divide the possible values
of tickets into groups or sets as shown below where the system behavior
can be considered the same.

The divided sets are called Equivalence Partitions or Equivalence

Classes. Then we pick only one value from each partition for testing. The
hypothesis behind this technique is that if one condition/value in a
partition passes all others will also pass. Likewise, if one condition
in a partition fails, all other conditions in that partition will fail.
 15. Boundary Value Analysis (BVA)

- You test boundaries between equivalence partitions

In our earlier example instead of checking, one value for each

partition you will check the values at the partitions like 0, 1, 10, 11 and so
on. As you may observe, you test values at both valid and invalid
boundaries. Boundary Value Analysis is also called range checking.

Why Equivalence & Boundary Analysis Testing

1. This testing is used to reduce infinite number of test cases

2. Very clear guidelines on determining test cases

3. Appropriate for calculation-intensive applications with variables that
represent physical quantities

Summary:

Boundary Analysis testing is used when practically it is impossible to

test large pool of test cases individually
Two techniques - Equivalence Partitioning & Boundary Value Analysis
testing techniques is used
In Equivalence Partitioning, first you divide a set of test condition
into a partition that can be considered.
In Boundary Value Analysis you then test boundaries between
equivalence partitions

16. Decision Table Testing

Decision Table Testing is a good way to deal with a combination of

inputs, which produce different results. It helps reduce test effort in
verifying each and every combinations of test data, at the same time
ensuring complete coverage

Example: To understand the importance of Decision Table Making

we will see an example, let's consider the behavior of Flight Button for
different combinations of Fly From & Fly To.
Rule 1: When destination for both Fly From & Fly To are not set the Flight

Icon is disabled. In the decision table, we register values False for Fly
From & Fly To and the outcome would be False, which is Flights Button
will be disabled. Likewise, you can decide different outcome for
different situation.

Rule 2: When Fly From destination is set but Fly to is not set, Flight

button is disabled. Correspondingly, you register True for Fly from

destination in the decision table, and the rest of the entries are false.

Rule 3: When Fly from destination is not set but Fly to destination is set,

Flight button is disabled and you make entries in the decision table.
 Rule 4: only when Fly to and Fly from destinations are set, Flights button

is enabled and you make the corresponding entry in the decision table.

If you observe the outcomes for Rule 1, 2 & 3 it remains the same.
So you can select any one of them and rule 4 for your testing.

The significance of this technique becomes immediately clear as the

number of inputs increases. Number of possible Combinations is given by 2

^ n , where n is the number of Inputs. For n = 10, which is very common

in the web based testing, having big input forms, the number
of combinations will be 1024. Obviously, you cannot test all but you will
choose a rich sub-set of the possible combinations using decision based
testing technique
17. Non-functional Testing

Like functional testing, there are non-functional requirements like

performance, usability, load factor that are also important.

Software performance testing is a means of quality assurance (QA).

It involves testing software applications to ensure they will perform well
under their expected workload.
Features and Functionality supported by a software system is not the
only concern. A software application's performance like its response
time, do matter. The goal of performance testing is not to find bugs but
to eliminate performance bottlenecks

The focus of Performance testing is checking a software program's

Speed - Determines whether the application responds quickly
Scalability - Determines maximum user load the software
application can handle.
Stability - Determines if the application is stable under varying
loads

Why do Performance Testing?

Performance testing is done to provide stakeholders with information

about their application regarding speed, stability and scalability. More
importantly, performance testing uncovers what needs to be improved
before the product goes to market. Without performance testing,
software is likely to suffer from issues such as: running slow while
several users use it simultaneously, inconsistencies across different
operating systems and poor usability. Performance testing will
determine whether or not their software meets speed, scalability and
stability requirements under expected workloads. Applications sent to
market with poor performance metrics due to non existent or poor
performance testing are likely to gain a bad reputation and fail to meet
expected sales goals. Also, mission critical applications like space
launch programs or life saving medical equipments should be
performance tested to ensure that they run for a long period of time
without deviations

Types of Performance Testing

Load testing
Load testing is a kind of performance testing which determines a
system's performance under real-life load conditions. This testing helps
determine how the application behaves when multiple users access it
simultaneously.
This testing usually identifies -
The maximum operating capacity of an application
Determine whether current infrastructure is sufficient to run the
application
Sustainability of application with respect to peak user load
Number of concurrent users that an application can support, and
scalability to allow more users to access it.
It is a type of non-functional testing. Load testing is commonly used
for the Client/Server, Web based applications - both Intranet and
Internet.

Stress testing
Stress testing is used to test beyond the normal operating point and
evaluates how the system works under those extreme conditions. Stress Testing
is done to make sure that the system would not crash under crunch situations.
Most prominent use of stress testing is to determine the limit, at which
the system or software or hardware breaks. It also checks whether system
demonstrates effective error management under extreme conditions.
 Need for Stress Testing
During festival time, an online shopping site may witness a spike
in traffic, or when it announces a sale.
When a blog is mentioned in a leading newspaper, it experiences
a sudden surge in traffic.

Goals of stress testing

The goal of stress testing is to analyze the behavior of the system
after failure. For stress testing to be successful, system should display
appropriate error message while it is under extreme conditions.

Difference between Load and Stress testing

Load Testing Stress Testing

Load testing identifies the Stress testing determines the

bottlenecks in the system under breaking point of the system
various workloads and checks how to reveal the maximum point
the system reacts when the load after which it breaks.
is gradually increased

Load Testing is to test the system Stress testing is to test the

behavior under normal workload system behavior under
conditions, and it is just testing or extreme conditions and is
simulating with the actual carried out till the system
workload failure.

Load testing does not break the Stress testing tries to break
system the system by testing with
overwhelming data or
resources.
Endurance testing - is done to make sure the software can handle the
expected load over a long period of time.

Spike testing - tests the software's reaction to sudden large spikes in

the load generated by users.

Volume testing - Under Volume Testing large no. of. Data is populated
in database and the overall software system's behavior is monitored.
The objective is to check software application's performance under
varying database volumes.

Scalability testing - The objective of scalability testing is to determine

the software application's effectiveness in "scaling up" to support an
increase in user load. It helps plan capacity addition to your software
system.
It focusses on the performance of your websites, software, hardware
and application at all the stages from minimum to maximum load.

Common Performance Problems

Most performance problems revolve around speed, response time, load

time and poor scalability. Speed is often one of the most important
attributes of an application. A slow running application will lose
potential users. Performance testing is done to make sure an app runs
fast enough to keep a user's attention and interest. Take a look at the
following list of common performance problems and notice how speed
is a common factor in many of them:

Long Load time - Load time is normally the initial time it takes an
application to start. This should generally be kept to a minimum. While
some applications are impossible to make load in under a minute, Load
time should be kept under a few seconds if possible.
 Poor response time - Response time is the time it takes from when a
user inputs data into the application until the application outputs a
response to that input. Generally this should be very quick. Again if a
user has to wait too long, they lose interest.
Poor scalability - A software product suffers from poor scalability
when it cannot handle the expected number of users or when it does
not accommodate a wide enough range of users. Load testing should be
done to be certain the application can handle the anticipated number of
users.
Bottlenecking - Bottlenecks are obstructions in system which degrade
overall system performance. Bottlenecking is when either coding errors
or hardware issues cause a decrease of throughput under certain loads.
Bottlenecking is often caused by one faulty section of code. The key to
fixing a bottlenecking issue is to find the section of code that is causing
the slow down and try to fix it there. Bottle necking is generally fixed by
either fixing poor running processes or adding additional Hardware.
Some common performance bottlenecks are
CPU utilization
Memory utilization
Network utilization
Operating System limitations
Disk usage

18. Regression testing

The purpose of regression testing is to confirm that a recent

program or code change has not adversely affected existing features.
Regression testing is nothing but full or partial selection of already
executed test cases which are re-executed to ensure existing
functionalities work fine.
 This testing is done to make sure that new code changes should not
have side effects on the existing functionalities. It ensures that old code
still works once the new code changes are done.
Regression Testing is required when there is a
Change in requirements and code is modified according to the
requirement
New feature is added to the software
Defect fixing
Performance issue fix

Software maintenance is an activity which includes enhancements,

error corrections, optimization and deletion of existing features. These
modifications may cause the system to work incorrectly. Therefore,
Regression Testing becomes necessary. Regression Testing can be carried
out using following techniques:

Retest All
This is one of the methods for regression testing in which all the
tests in the existing test bucket or suite should be re-executed. This is
very expensive as it requires huge time and resources.
Regression Test Selection
Instead of re-executing the entire test suite, it is better to select part
of test suite to be run
 Test cases selected can be categorized as 1) Reusable Test Cases 2)
Obsolete Test Cases.
Re-usable Test cases can be used in succeeding regression cycles.
Obsolete Test Cases can't be used in succeeding cycles.
Prioritization of Test Cases
Prioritize the test cases depending on business impact, critical &
frequently used functionalities. Selection of test cases based on priority
will greatly reduce the regression test suite.

Difference between Re-testing and regression testing:

Re-testing means testing the functionality or bug again to ensure

the code is fixed. If it is not fixed, defect needs to be re-opened. If fixed,
defect is closed.
Regression testing means testing your software application when it
undergoes a code change to ensure that the new code has not affected
other parts of the software.

19. What is Software Defect/Bug?

When a tester executes the test cases, he might come across the test result
which is contradictory to expected result. This variation in the test result is referred
as a defect. These defects or variation are referred by different names in a
different organization like issues, problem, bug or incidents.

While reporting the bug to developer, your Bug Report should contain the
following information

Defect_ID - Unique identification number for the defect.

Defect Description - Detailed description of the defect including information
about the module in which defect was found.
Version - Version of the application in which defect was found.
 Steps - Detailed steps along with screenshots with which the developer can
reproduce the defects.
Date Raised - Date when the defect is raised
Reference- where in you Provide reference to the documents like .
requirements, design, architecture or may be even screenshots of the error to
help understand the defect
Detected By - Name/ID of the tester who raised the defect
Status - Status of the defect , more on this later
Fixed by - Name/ID of the developer who fixed it
Date Closed - Date when the defect is closed
Severity which describes the impact of the defect on the application
Priority which is related to defect fixing urgency. Severity Priority could be
High/Medium/Low based on the impact urgency at which the defect should be
fixed respectively

20.Defect Management Process

This topic will guide you on how to apply the defect management process.
You can follow the below steps to manage defects.
Discovery

In the discovery phase, the project teams have to discover

as many defects as possible, before the end customer can discover it. A
defect is said to be discovered and change to status accepted when it is
acknowledged and accepted by the developers

Categorization

Defect categorization help the software developers to prioritize their

tasks. That means that this kind of priority helps the developers in fixing
those defects first that are highly crucial.
Resolution
Once the defects are accepted and categorized, you can follow the
following steps to fix the defect.

Assignment: Assigned to a developer or other technician to fix, and

changed the status to Responding.
Schedule fixing: The developer side take charge in this phase.
They will create a schedule to fix these defects, depend on the defect
priority.
Fix the defect: While the development team is fixing the defects,
the Test Manager tracks the process of fixing defect compare to the
above schedule.
 Report the resolution: Get a report of the resolution from
developers when defects are fixed.

Verification

After the development team fixed and reported the defect, the testing
team verifies that the defects are actually resolved.

For example, in the above scenario, when the development team reported
that they already fixed 61 defects, your team would test again to verify
these defects were actually fixed or not.

Closure

Once a defect has been resolved and verified, the defect is changed
status as closed. If not, you have send a notice to the development to
check the defect again.

Reporting

The management board has right to know the defect status. They must
understand the defect management process to support you in this project.
Therefore, you must report them the current defect situation to get
feedback from them.
Defect/Bug Life Cycle

New: When a new defect is logged and posted for the first time. It is
assigned a status NEW.
Assigned: Once the bug is posted by the tester, the lead of the
tester approves the bug and assigns the bug to developer team
 Open: The developer starts analyzing and works on the defect fix
Fixed: When developer makes necessary code change and verifies
the change, he or she can make bug status as "Fixed."
Pending retest:Once the defect is fixed the developer gives
particular code for retesting the code to the tester. Since the testing
remains pending from the testers end, the status assigned is "pending
request."
Retest: Tester does the retesting of the code at this stage to check
whether the defect is fixed by the developer or not and change the
status to "Re-test."
Verified: The tester re-tests the bug after it got fixed by the
developer. If there is no bugdetected in the software, then the bug is
fixed and the status assigned is "verified."
Reopen: If the bug persists even after the developer has fixed the
bug, the tester changes the status to "reopened". Once again the bug
goes through the life cycle.
Closed: If the bug is no longer exits then tester assign the status
"Closed."
Duplicate: If the defect is repeated twice or the defect corresponds
the same concept of the bug, the status is changed to "duplicate."
Rejected: If the developer feels the defect is not a genuine defect
than it changes the defect to "rejected."
Deferred: If the present bug is not of a prime priority and if it is
expected to get fixed in the next release, then status "Deferred" is
assigned to such bugs
Not a bug:If it does not affect the functionality of the application
then the status assigned to a bug is "Not a bug".

AGILE Cycle
AGILE Methodology
AGILE Methodology2