JAI ENTERPRISES

SOFTWARE TESTING

Software
Software is a set of instructions, data or programs used to operate computers and
execute specific tasks.

Application software. The most common type of software, application software is a

computer software package that performs a specific function for a user, or in some
cases, for another application.
graphics software, databases and database management programs, web browsers,
word processors, software development tools, image editors and communication
platforms.
System software. These software programs are designed to run a computer's
application programs and hardware. System software coordinates the activities and
functions of the hardware and software.
The OS is the best example of system software; it manages all the other computer
programs.
The OS is the best example of system software; it manages all the other computer
programs.

Driver software. Also known as device drivers, this software is often considered a type
of system software. Device drivers control the devices and peripherals connected to a
computer, enabling them to perform their specific tasks. Every device that is connected
to a computer needs at least one device driver to function. Examples include software
that comes with any nonstandard hardware, including special game controllers, as well
as the software that enables standard hardware, such as USB storage devices,
keyboards, headphones and printers.

Middleware. The term middleware describes software that mediates between

application and system software or between two different kinds of application software.
For example, middleware enables Microsoft Windows to talk to Excel and Word. It is
also used to send a remote work request from an application in a computer that has
 JAI ENTERPRISES
one kind of OS, to an application in a computer with a different OS. It also enables
newer applications to work with legacy ones.

Programming software. Computer programmers use programming software to write

code. Programming software and programming tools enable developers to develop,
write, test and debug other software programs. Examples of programming software
include assemblers, compilers, debuggers and interpreters.

What is Testing
Testing is the process of determining how effective something is.

What is Software Testing

Software testing is a process, to evaluate the functionality of a software application
with an intent to find whether the developed software met the specified requirements
or not and to identify the defects to ensure that the product is defect-free in order to
produce a quality product.

Let’s see the standard definition, testing types such as manual testing and automation
testing, testing methods, testing approaches, and types of black-box testing.

What are the different types of Software Testing?

#1. Manual Testing

Manual testing is the process of testing the software by hand to learn more about it, to
find what is and isn’t working.
This usually includes verifying all the features specified in requirements documents, but
often also includes the testers trying the software with the perspective of their end user’s
in mind.
Manual test plans vary from fully scripted test cases, giving testers detailed steps and
expected results, through to high-level guides that steer exploratory testing sessions.
There are lots of sophisticated tools on the market to help with manual testing,
 JAI ENTERPRISES
#2. Automation Testing
Automation testing is the process of using automation testing tools to control the
execution of tests and compare the results against expected outcomes and to find the
defects.
In this process, testers execute the test scripts and generate the test results
automatically by using automation tools.
Some of the famous automation testing tools for functional testing include Selenium,
testRigor, and Katalon Studio.
Selenium is no longer a strange name for web application testers. It offers powerful
capabilities like cross-browser testing but is difficult to learn for those new to
automation or with limited programming experience.
That’s why most QAs freshers and manual testers start out with Selenium Alternatives.
testRigor is one of the best alternatives to selenium.

WHAT IS SOFTWARE QUALITY

Portability: A software device is said to be portable, if it can be freely made to work in various
operating system environments, in multiple machines, with other software products, etc.

Usability: A software product has better usability if various categories of users can easily invoke
the functions of the product.

Reusability: A software product has excellent reusability if different modules of the product
can quickly be reused to develop new products.

Correctness: A software product is correct if various requirements as specified in the SRS

document have been correctly implemented.

Maintainability: A software product is maintainable if bugs can be easily corrected as and

when they show up, new tasks can be easily added to the product, and the functionalities of
the product can be easily modified, etc.

A product is anything that can be offered to a market to solve a problem, or to satisfy a

want or need. Products have a cycle that consists of multiple stages. First, the product is
conceived, then developed, then introduced and managed in the market, and finally, the
product is retired when the need for it diminishes. Products are usually developed by a
product team.
 JAI ENTERPRISES
A project is a temporary endeavor that is undertaken to create a unique product or service.
With a project, there is a clear definition of what needs to be delivered by a specified date
in time. As in the previous item, projects are usually carried out by a project team.

Software testing is very important because of the following reasons:

1. Software testing is really required to point out the defects and errors that were
made during the development phase
o Example: Programmers may make a mistake during the implementation
of the software. There could be many reasons for this like lack of
experience of the programmer, lack of knowledge of the programming
language, insufficient experience in the domain, incorrect
implementation of the algorithm due to complex logic or simply human
error.
2. It’s essential since it makes sure that the customer finds the organization
reliable and their satisfaction in the application is maintained.
o If the customer does not find the testing organization reliable or is not
satisfied with the quality of the deliverable, then they may switch to a
competitor organization.
o Sometimes contracts may also include monetary penalties with respect
to the timeline and quality of the product. In such cases, if proper
software testing may also prevent monetary losses.
3. It is very important to ensure the Quality of the product. Quality product
delivered to the customers helps in gaining their confidence
o As explained in the previous point, delivering good quality product on
time builds the customers confidence in the team and the organization.
4. Testing is necessary in order to provide the facilities to the customers like the
delivery of high quality product or software application which requires lower
maintenance cost and hence results into more accurate, consistent and
reliable results.
o High quality product typically has fewer defects and requires lesser
maintenance effort, which in turn means reduced costs.
5. Testing is required for an effective performance of software application or
product.
6. It’s important to ensure that the application should not result into any failure
because it can be very expensive in the future or in the later stages of the
development.
o Proper testing ensures that bugs and issues are detected early in the
life cycle of the product or application.
 JAI ENTERPRISES
o If defects related to requirements or design are detected late in the life
cycle, it can be very expensive to fix them since this might require
redesign, re-implementation and retesting of the application.
7. It’s required to stay in the business.
o Users are not inclined to use software that has bugs. They may not
adopt a software if they are not happy with the stability of the application.
o In case of a product organization or startup which has only one product,
poor quality of software may result in lack of adoption of the product and
this may result in losses which the business may not recover from.

What is a bug?
In software testing , a bug is the informal name of defects, which means that software or
application is not working as per the requirement. When we have some coding error, it leads a
program to its breakdown, which is known as a bug. The test engineers use the
terminology Bug.

If a QA(quality analyst) detect a bug, they can reproduce the bug and record it with the help of
the bug report template.

What is a Defect?
When the application is not working as per the requirement is knows as defects. It is specified
as the aberration from the actual and expected result of the application or software.

In other words, we can say that the bug announced by the programmer and inside the code
is called a defect.

What is Error?
The Problem in code leads to errors, which means that a mistake can occur due to the
developer's coding error as the developer misunderstood the requirement or the requirement
was not defined correctly. The developers use the term error.

Why software has bugs

 Miscommunication of requirements introduces error in code
 Unrealistic time schedule for development
 Lack of designing experience
 Lack of coding practices experience
 JAI ENTERPRISES
 Human factors introduces errors in code
 Lack of version control
 Buggy third-party tools
 Last minute changes in the requirement introduce error
 Poor Software testing skill
The stages of SDLC are as follows:

Stage1: Planning and requirement analysis

Requirement Analysis is the most important and necessary stage in SDLC.

Business analyst and Project organizer set up a meeting with the client to gather all the data
like what the customer wants to build, who will be the end user, what is the objective of the
product. Before creating a product, a core understanding or knowledge of the product is very
necessary.

For Example, A client wants to have an application which concerns money transactions. In this
method, the requirement has to be precise like what kind of operations will be done, how it will
be done, in which currency it will be done, etc.

Once the required function is done, an analysis is complete with auditing the feasibility of the
growth of a product. In case of any ambiguity, a signal is set up for further discussion.

Once the requirement is understood, the SRS (Software Requirement Specification) document
is created. The developers should thoroughly follow this document and also should be reviewed
by the customer for future reference.
 JAI ENTERPRISES
Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly represent and document
the software requirements and get them accepted from the project stakeholders.

This is accomplished through "SRS"- Software Requirement Specification document which

contains all the product requirements to be constructed and developed during the project life
cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis, and design
of the software project.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is built. The
implementation of design begins concerning writing code. Developers have to follow the
coding guidelines described by their management and programming tools like compilers,
interpreters, debuggers, etc. are used to develop and implement the code.

Stage5: Testing

After the code is generated, it is tested against the requirements to make sure that the products
are solving the needs addressed and gathered during the requirements stage.

During this stage, unit testing, integration testing, system testing, acceptance testing are done.

Stage6: Deployment

Once the software is certified, and no bugs or errors are stated, then it is deployed.

Then based on the assessment, the software may be released as it is or with suggested
enhancement in the object segment.

After the software is deployed, then its maintenance begins.

Stage7: Maintenance

Once when the client starts using the developed systems, then the real issues come up and
requirements to be solved from time to time.
 JAI ENTERPRISES
This procedure where the care is taken for the developed product is known as maintenance.

TYPES OF MODEL:-

WATERFALL MODEL

 Requirement Gathering and analysis − All possible requirements of the system to be

developed are captured in this phase and documented in a requirement specification
document.
 System Design − The requirement specifications from first phase are studied in this phase
and the system design is prepared. This system design helps in specifying hardware and
system requirements and helps in defining the overall system architecture.
 Implementation − With inputs from the system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is developed
and tested for its functionality, which is referred to as Unit Testing.
 Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
 Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
 Maintenance − There are some issues which come up in the client environment. To fix
those issues, patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily downwards
(like a waterfall) through the phases. The next phase is started only after the defined set of goals are
achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model, phases
do not overlap.
 JAI ENTERPRISES
APPLICATION:-
 Requirements are very well documented, clear and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are available to support the product.
 The project is short.

ADVATAGES:-
 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a
review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

DISADVATAGES:-

 No working software is produced until late during the life cycle.

 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow identifying any
technological or business bottleneck or challenges early.

SPIRAL MODEL:-

Spiral Model
It implements the potential for rapid development of new versions of the software. Using the
spiral model, the software is developed in a series of incremental releases. During the early
iterations, the additional release may be a paper model or prototype. During later iterations,
more and more complete versions of the engineered system are produced.
 JAI ENTERPRISES

Each cycle in the spiral is divided into four parts:

Objective setting: Each cycle in the spiral starts with the identification of purpose for that cycle,
the various alternatives that are possible for achieving the targets, and the constraints that
exists.

Risk Assessment and reduction: The next phase in the cycle is to calculate these various
alternatives based on the goals and constraints. The focus of evaluation in this stage is located
on the risk perception for the project.

Development and validation: The next phase is to develop strategies that resolve
uncertainties and risks. This process may include activities such as benchmarking, simulation,
and prototyping.

Planning: Finally, the next step is planned. The project is reviewed, and a choice made whether
to continue with a further period of the spiral. If it is determined to keep, plans are drawn up
for the next step of the project.

The development phase depends on the remaining risks. For example, if performance or user-
interface risks are treated more essential than the program development risks, the next phase
may be an evolutionary development that includes developing a more detailed prototype for
solving the risks.
 JAI ENTERPRISES
The risk-driven feature of the spiral model allows it to accommodate any mixture of a
specification-oriented, prototype-oriented, simulation-oriented, or another type of approach.
An essential element of the model is that each period of the spiral is completed by a review
that includes all the products developed during that cycle, including plans for the next cycle.
The spiral model works for development as well as enhancement projects.

When to use Spiral Model?

o When deliverance is required to be frequent.
o When the project is large
o When requirements are unclear and complex
o When changes may require at any time
o Large and high budget projects

Advantages
o High amount of risk analysis
o Useful for large and mission-critical projects.

Disadvantages
o Can be a costly model to use.
o Risk analysis needed highly particular expertise
o Doesn't work well for smaller projects.

V-Model
V-Model also referred to as the Verification and Validation Model. In this, each phase of SDLC
must complete before the next phase starts. It follows a sequential design process same as the
waterfall model. Testing of the device is planned in parallel with a corresponding stage of
development.
 JAI ENTERPRISES

Verification: It involves a static analysis method (review) done without executing code. It is the
process of evaluation of the product development process to find whether specified
requirements meet.

Validation: It involves dynamic analysis method (functional, non-functional), testing is done by

executing code. Validation is the process to classify the software after the completion of the
development process to determine whether the software meets the customer expectations and
requirements.

So V-Model contains Verification phases on one side of the Validation phases on the other
side. Verification and Validation process is joined by coding phase in V-shape. Thus it is known
as V-Model.

There are the various phases of Verification Phase of V-model:

1. Business requirement analysis: This is the first step where product requirements
understood from the customer's side. This phase contains detailed communication to
understand customer's expectations and exact requirements.
2. System Design: In this stage system engineers analyze and interpret the business of the
proposed system by studying the user requirements document.
 JAI ENTERPRISES
3. Architecture Design: The baseline in selecting the architecture is that it should
understand all which typically consists of the list of modules, brief functionality of each
module, their interface relationships, dependencies, database tables, architecture
diagrams, technology detail, etc. The integration testing model is carried out in a
particular phase.
4. Module Design: In the module design phase, the system breaks down into small
modules. The detailed design of the modules is specified, which is known as Low-Level
Design
5. Coding Phase: After designing, the coding phase is started. Based on the requirements,
a suitable programming language is decided. There are some guidelines and standards
for coding. Before checking in the repository, the final build is optimized for better
performance, and the code goes through many code reviews to check the performance.

There are the various phases of Validation Phase of V-model:

1. Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module
design phase. These UTPs are executed to eliminate errors at code level or unit level. A
unit is the smallest entity which can independently exist, e.g., a program module. Unit
testing verifies that the smallest entity can function correctly when isolated from the rest
of the codes/ units.
2. Integration Testing: Integration Test Plans are developed during the Architectural
Design Phase. These tests verify that groups created and tested independently can
coexist and communicate among themselves.
3. System Testing: System Tests Plans are developed during System Design Phase. Unlike
Unit and Integration Test Plans, System Tests Plans are composed by the client ?s
business team. System Test ensures that expectations from an application developer are
met.
4. Acceptance Testing: Acceptance testing is related to the business requirement analysis
part. It includes testing the software product in user atmosphere. Acceptance tests reveal
the compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like load and
performance defects within the real user atmosphere.
 JAI ENTERPRISES
When to use V-Model?
o When the requirement is well defined and not ambiguous.
o The V-shaped model should be used for small to medium-sized projects where requirements
are clearly defined and fixed.
o The V-shaped model should be chosen when sample technical resources are available with
essential technical expertise.

Advantage (Pros) of V-Model:

1. Easy to Understand.
2. Testing Methods like planning, test designing happens well before coding.
3. This saves a lot of time. Hence a higher chance of success over the waterfall model.
4. Avoids the downward flow of the defects.
5. Works well for small plans where requirements are easily understood.

Disadvantage (Cons) of V-Model:

1. Very rigid and least flexible.
2. Not a good for a complex project.
3. Software is developed during the implementation stage, so no early prototypes of the software
are produced.
4. If any changes happen in the midway, then the test documents along with the required
documents, has to be updated.

What is Static Testing?

Static Testing is a type of software testing in which software application is tested
without code execution. Manual or automated reviews of code, requirement documents
and document design are done in order to find the errors. The main objective of static
testing is to improve the quality of software applications by finding errors in early
stages of software development process.
Static testing involves manual or automated reviews of the documents. This review is
done during an initial phase of testing to catch Defect early in STLC. It examines work
documents and provides review comments. It is also called Non-execution testing or
verification testing.

Examples of Work documents-

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

What is Dynamic Testing?

Under Dynamic Testing, a code is executed. It checks for functional behaviour of
software system, memory/CPU usage and overall performance of the system. Hence the
name “Dynamic”

The main objective of this testing is to confirm that the software product works in
conformance with the business requirements. This testing is also called an 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.

Differences between Black Box Testing vs White Box Testing:

S.
No. Black Box Testing White Box Testing

It is a way of software testing in which the It is a way of testing the software in which
internal structure or the program or the the tester has knowledge about the internal
code is hidden and nothing is known structure or the code or the program of the
1. about it. software.

Implementation of code is not needed for Code implementation is necessary for

2. black box testing. white box testing.

3. It is mostly done by software testers. It is mostly done by software developers.

No knowledge of implementation is
4. needed. Knowledge of implementation is required.
 JAI ENTERPRISES
S.
No. Black Box Testing White Box Testing

It can be referred to as outer or external It is the inner or the internal software

5. software testing. testing.

6. It is a functional test of the software. It is a structural test of the software.

This testing can be initiated based on the This type of testing of software is started
7. requirement specifications document. after a detail design document.

No knowledge of programming is It is mandatory to have knowledge of

8. required. programming.

9. It is the behaviour testing of the software. It is the logic testing of the software.

It is applicable to the higher levels of It is generally applicable to the lower

10. testing of software. levels of software testing.

11. It is also called closed testing. It is also called as clear box testing.

12. It is least time consuming. It is most time consuming.

It is not suitable or preferred for algorithm

13. testing. It is suitable for algorithm testing.

Can be done by trial and error ways and Data domains along with inner or internal
14. methods. boundaries can be better tested.

Example: Search something on google by Example: By input to check and verify

15. using keywords loops

Black-box test design techniques-

 Decision table testing White-box test design techniques-
 All-pairs testing  Control flow testing
 Equivalence partitioning  Data flow testing
16.  Error guessing  Branch testing
 JAI ENTERPRISES
S.
No. Black Box Testing White Box Testing

Types of Black Box Testing: Types of White Box Testing:

 Functional Testing  Path Testing
 Non-functional testing  Loop Testing
17.  Regression Testing  Condition testing

It is less exhaustive as compared to white It is comparatively more exhaustive than

18. box testing. black box testing.

1. Walkthrough:

 It is not a formal process

 It is led by the authors
 Author guide the participants through the document according to his or her thought
process to achieve a common understanding and to gather feedback.
 Useful for the people if they are not from the software discipline, who are not used to
or cannot easily understand software development process.
 Is especially useful for higher level documents like requirement specification, etc.
The goals of a walkthrough:

 To present the documents both within and outside the software discipline in order to
gather the information regarding the topic under documentation.
 To explain or do the knowledge transfer and evaluate the contents of the document
 To achieve a common understanding and to gather feedback.
 To examine and discuss the validity of the proposed solutions
2. Technical review:

 It is less formal review

 It is led by the trained moderator but can also be led by a technical expert
 It is often performed as a peer review without management participation
 Defects are found by the experts (such as architects, designers, key users) who focus
on the content of the document.
 In practice, technical reviews vary from quite informal to very formal
The goals of the technical review are:

 To ensure that an early stage the technical concepts are used correctly
 JAI ENTERPRISES
 To access the value of technical concepts and alternatives in the product
 To have consistency in the use and representation of technical concepts
 To inform participants about the technical content of the document
3. Inspection:

 It is the most formal review type

 It is led by the trained moderators
 During inspection the documents are prepared and checked thoroughly by the
reviewers before the meeting
 It involves peers to examine the product
 A separate preparation is carried out during which the product is examined and the
defects are found
 The defects found are documented in a logging list or issue log
 A formal follow-up is carried out by the moderator applying exit criteria
The goals of inspection are:

 It helps the author to improve the quality of the document under inspection
 It removes defects efficiently and as early as possible
 It improve product quality
 It create common understanding by exchanging information
 It learn from defects found and prevent the occurrence of similar defects
Quality Assurance (QA) Quality Control (QC)

It focuses on providing assurance that the It focuses on fulfilling the quality

quality requested will be achieved. requested.

It is the technique of managing quality. It is the technique to verify quality.

It is not included during the

It is involved during the development phase. development phase.

It does not include the execution of the It always includes the execution of
program. the program.

It is process oriented. It is product oriented.

 JAI ENTERPRISES
Quality Assurance (QA) Quality Control (QC)

The aim of quality assurance is to prevent The aim of quality control is to identify
defects. and improve the defects.

It is a preventive technique. It is a corrective technique.

It is responsible for the entire software It is responsible for the software

development life cycle. testing life cycle.

It pays main focus is on the intermediate

process. Its primary focus is on final products.

All team members of the project are Generally, the testing team of the
involved. project is involved.

Example: Verification Example: Validation

Quality engineer(QE) -it is automation tester .he writes the code to test system
automatically.

Software engineer(SE)- It is an engineer who writes the code to develop the software.

What Is Incremental Testing

Incremental Testing, also known as Incremental Integration Testing, is one of the approaches of Integration
Testing and incorporates its fundamental concepts.

In this testing, we test each module individually in unit testing phase, and then modules are integrated
incrementally and tested to ensure smooth interface and interaction between modules.

In this approach, every module is combined incrementally, i.e., one by one till all modules or components
are added logically to make the required application, instead of integrating the whole system at once and
then performing testing on the end product. Integrated modules are tested as a group to ensure successful
integration and data flow between modules.
 JAI ENTERPRISES
As in integration testing, the primary focus of doing this testing is to check interface, integrated links, and
flow of information between modules. This process is repeated till the modules are combined and tested
successfully.

Ex:-software and they have sub module

Incremental Integration testing approach

 Each Module i.e. M1, M2, M3, etc. are tested individually as part of unit testing
 Modules are combined incrementally i.e. one by one and tested for successful interaction
 In Fig2, Module M1 & Module M2 are combined and tested
 In Fig3, Module M3 is added and tested
 In Fig4, Module M4 is added and testing is done to make sure everything works together
successfully
 Rest of the Modules are also added incrementally at each step and tested for successful
integration

Fig2

Fig3
 JAI ENTERPRISES

Fig4

#1) Top Down

As the name suggests, testing takes place from top to bottom, i.e., from the central module to sub module.
Modules framing the top layer of application are tested first.

Top down Incremental Integration Testing Approach

Following test cases will be derived:
Test Case1: Module L and Module O will be integrated and tested
Test Case2: Module L, O and P will be integrated and tested
Test Case3: Module L, O, P and R will be integrated and tested.
#2) Bottom-up
In this approach, testing takes place from bottom to top, i.e., modules at bottom layer are integrated and
tested first and then sequentially other modules are integrated as we move up.
 JAI ENTERPRISES

Bottom up Incremental Integration testing approach

Following test cases will be derived:
Test Case1: Unit testing of module Practical and Theory
Test Case2: Integration and testing of Modules Marks-Practical-theory
Test Case3: Integration and testing of Modules Percentage-Marks-Practical-Theory
Test Case4: Unit testing of Module Sports Grade
Test Case5: Integration and testing of Modules Rank-Sports Grade-Percentage-Marks-Practical-Theory
#3) Sandwich Testing
This approach is a hybrid of top-down and bottom-up methodology. Stub and drivers are used for
incomplete or not developed modules.

Testing Approach
 A middle layer is identified from which bottom-up and top-down testing are done. This
middle layer is also known as target layer
 Target layer is identified as per Heuristic approach, i.e., select a layer which allows minimal
use of Stubs and drivers
 Top-down testing starts from middle layer and moves downwards towards lower level
modules. This layer below middle layer is known as Bottom layer
 Bottom-up testing also starts from middle layer and move up towards top layer modules.
This layer above middle layer is known as Top layer
 JAI ENTERPRISES
 With use of stubs and drivers, user interface and functions of lower level modules are tested
respectively
 In the end, only middle layer is left for the execution of the final test

Following test cases can be derived with Sandwich Testing Strategy:

Test Case1: Test A, X, Y, and Z individually – where Test A comes under Top layer test and Test X, Y
and Z comes under Bottom layer tests
Test Case2: Test A, G, H and I
Test Case3: Test G, X, and Y
Test Case4: Test Hand Z
Test Case5: Test A, G, H, I, X, Y, and Z

Stubs and Drivers

Stubs and Drivers are the dummy programs in Integration testing used to facilitate the
software testing activity. These programs act as a substitutes for the missing models
in the testing. They do not implement the entire programming logic of the software
module but they simulate data communication with the calling module while testing.
Stub: Is called by the Module under Test.

Driver: Calls the Module to be tested.

 JAI ENTERPRISES

What is GUI Testing?

GUI Testing is a software testing type that checks the Graphical User Interface of the
Software. The purpose of Graphical User Interface (GUI) Testing is to ensure the
functionalities of software application work as per specifications by checking screens
and controls like menus, buttons, icons, etc.

Functional Testing Non-functional Testing

It verifies the operations

and actions of an It verifies the behavior of
application. an application.

It is based on
requirements of It is based on expectations
customer. of customer.

It helps to enhance the It helps to improve the

behavior of the performance of the
application. application.

Functional testing is It is hard to execute non-

easy to execute functional testing
manually. manually.

It tests what the product It describes how the

does. product does.

Functional testing is Non-functional testing is

based on the business based on the performance
requirement. requirement.

Examples:
1. Unit Testing
2. Smoke Testing Examples:
3. Integration 1. Performance Testing
Testing 2. Load Testing
4. Regression 3. Stress Testing
Testing 4. Scalability Testing
 JAI ENTERPRISES

Retesting vs Regression Testing

Regression Testing Re-testing

Re-testing is carried out

Regression Testing is carried out to confirm whether a recent
failed in the final executi
program or code change has not adversely affected existing features
defects are fixed

The purpose of Regression Testing is that new code changes should

Re-testing is done on the
not have any side effects to existing functionalities

Defect verification is not the part of Regression Testing Defect verification is the

Based on the project and availability of resources, Regression Testing Priority of re-testing is h
can be carried out parallel with Re-testing so it is carried out before

You can do automation for regression testing, Manual Testing could

You cannot automate the
be expensive and time-consuming

Regression testing is known as a generic testing Re-testing is a planned t

Regression testing is done for passed test cases Retesting is done only fo

Re-testing makes sure th

Regression testing checks for unexpected side-effects
corrected

Re-testing executes a de
Regression testing is only done when there is any modification or
the same environment w
changes become mandatory in an existing project
new build

Test cases for regression testing can be obtained from the functional
Test cases for retesting c
specification, user tutorials and manuals, and defect reports in
start testing.
regards to corrected problems
JAI ENTERPRISES
 JAI ENTERPRISES

End To End Testing

End To End Testing is a software testing method that validates entire software from
starting to the end along with its integration with external interfaces. The purpose of
end-to-end testing is testing whole software for dependencies, data integrity and
communication with other systems, interfaces and databases to exercise complete
production like scenario.
Along with the software system, it also validates batch/data processing from other
upstream/downstream systems. Hence, the name “End-to-End”. End to End Testing is
usually executed after functional and System Testing.

Positive Testing
Positive testing ensures that software performs as it is expected to do. When writing test cases
for positive testing, only legitimate (valid) inputs are provided as inputs.
In other words, positive testing is the process of evaluating a system or application using
accurate input data.
The primary goal of positive testing is to validate if a software program does what it is intended
to do.
 JAI ENTERPRISES
Simply put, a positive test is conducted by providing an expected set of values as inputs to the
test cases.

Negative Testing
It is vice versa for positive testing. In Negative testing, a software program is evaluated against
false or incorrect data.
Negative testing is also known as error path testing or failure.
It is best to check if the computer program reacts as expected to false or invalid user inputs.
Negative testing ensures the software program does not crash and continues running even
with wrong data inputs.
A software tester most likely starts by considering the positive inputs when considering the test
scenarios. Still, it is equally important to know that understanding the importance of negative
tests is always crucial. It is seen as being essential to the execution of test cases.
Negative testing ensures that the software program displays an error when it should and does
not display an error when it should not. Additionally, it helps software developers find more
flaws and improve the software program being tested.

Boundary Value Analysis (BVA)

Boundary value analysis is based on testing at the boundaries between partitions. It
includes maximum, minimum, inside or outside boundaries, typical values and error
values.

It is generally seen that a large number of errors occur at the boundaries of the
defined input values rather than the center. It is also known as BVA and gives a
selection of test cases which exercise bounding values.

This black box testing technique complements equivalence partitioning. This software
testing technique base on the principle that, if a system works well for these
particular values then it will work perfectly well for all values which comes between
the two boundary values.

Guidelines for Boundary Value analysis

 If an input condition is restricted between values x and y, then the test cases
should be designed with values x and y as well as values which are above and
below x and y.
 JAI ENTERPRISES
 If an input condition is a large number of values, the test case should be
developed which need to exercise the minimum and maximum numbers. Here,
values above and below the minimum and maximum values are also tested.
 Apply guidelines 1 and 2 to output conditions. It gives an output which reflects
the minimum and the maximum values expected. It also tests the below or
above values.

Example:
Input condition is valid between 1 to 10

Boundary values 0,1,2 and 9,10,11

Equivalence Class Partitioning

Equivalent Class Partitioning allows you to divide set of test condition into a partition
which should be considered the same. This software testing method divides the input
domain of a program into classes of data from which test cases should be designed.

The concept behind this Test Case Design Technique is that test case of a
representative value of each class is equal to a test of any other value of the same
class. It allows you to Identify valid as well as invalid equivalence classes.

Example:

Input conditions are valid between

1 to 10 and 20 to 30
Hence there are five equivalence classes
--- to 0 (invalid)
1 to 10 (valid)
11 to 19 (invalid)
20 to 30 (valid)
31 to --- (invalid)
You select values from each class, i.e.,
-2, 3, 15, 25, 45

Decision Table Based Testing

A decision table is also known as to Cause-Effect table. This software testing
technique is used for functions which respond to a combination of inputs or events.
For example, a submit button should be enabled if the user has entered all required
fields.
 JAI ENTERPRISES
The first task is to identify functionalities where the output depends on a combination
of inputs. If there are large input set of combinations, then divide it into smaller
subsets which are helpful for managing a decision table.

For every function, you need to create a table and list down all types of combinations
of inputs and its respective outputs. This helps to identify a condition that is
overlooked by the tester.

Following are steps to create a decision table:

 Enlist the inputs in rows

 Enter all the rules in the column
 Fill the table with the different combination of inputs
 In the last row, note down the output against the input combination.

Example: A submit button in a contact form is enabled only when all the inputs are
entered by the end user.

State Transition
In State Transition technique changes in input conditions change the state of the
Application Under Test (AUT). This testing technique allows the tester to test the
behaviour of an AUT. The tester can perform this action by entering various input
conditions in a sequence. In State transition technique, the testing team provides
positive as well as negative input test values for evaluating the system behaviour.
 JAI ENTERPRISES
Guideline for State Transition:

 State transition should be used when a testing team is testing the application
for a limited set of input values.
 The Test Case Design Technique should be used when the testing team wants to
test sequence of events which happen in the application under test.

Example:

In the following example, if the user enters a valid password in any of the first three
attempts the user will be able to log in successfully. If the user enters the invalid
password in the first or second try, the user will be prompted to re-enter the
password. When the user enters password incorrectly 3rd time, the action has taken,
and the account will be blocked.

State Transition Diagram

In this diagram when the user gives the correct PIN number, he or she is moved to
Access granted state. Following Table is created based on the diagram above-
 JAI ENTERPRISES

State Transition Table

Correct PIN Incorrect PIN

S1) Start S5 S2

S2) 1st attempt S5 S3

S3) 2nd attempt S5 S4

S4) 3rd attempt S5 S6

S5) Access Granted – –

S6) Account blocked – –

In the above-given table when the user enters the correct PIN, the state is transitioned
to Access granted. And if the user enters an incorrect password, he or she is moved to
next state. If he does the same 3rd time, he will reach the account blocked state.

Error Guessing
Error Guessing is a software testing technique based on guessing the error which can
prevail in the code. The technique is heavily based on the experience where the test
analysts use their experience to guess the problematic part of the testing application.
Hence, the test analysts must be skilled and experienced for better error guessing.
The technique counts a list of possible errors or error-prone situations. Then tester
writes a test case to expose those errors. To design test cases based on this software
testing technique, the analyst can use the past experiences to identify the conditions.

Guidelines for Error Guessing:

 The test should use the previous experience of testing similar applications
 Understanding of the system under test
 Knowledge of typical implementation errors
 Remember previously troubled areas
 Evaluate Historical data & Test results

STLC Phases
There are following six major phases in every Software Testing Life Cycle Model
(STLC Model):
 JAI ENTERPRISES

STLC Model Phases

1. Requirement Analysis
2. Test Planning
3. Test case development
4. Test Environment setup
5. Test Execution
6. Test Cycle closure

Each of these stages has a definite Entry and Exit criteria, Activities & Deliverables
associated with it.

What is Entry and Exit Criteria in STLC?

 Entry Criteria: Entry Criteria gives the prerequisite items that must be
completed before testing can begin.
 Exit Criteria: Exit Criteria defines the items that must be completed before
testing can be concluded

You have Entry and Exit Criteria for all levels in the Software Testing Life Cycle
(STLC)

In an Ideal world, you will not enter the next stage until the exit criteria for the
previous stage is met. But practically this is not always possible. So for this tutorial,
we will focus on activities and deliverables for the different stages in STLC life cycle.
Let’s look into them in detail.
 JAI ENTERPRISES

Requirement Phase Testing

Requirement Phase Testing also known as Requirement Analysis in which test team
studies the requirements from a testing point of view to identify testable
requirements and the QA team may interact with various stakeholders to understand
requirements in detail. Requirements could be either functional or non-functional.
Automation feasibility for the testing project is also done in this stage.
Activities in Requirement Phase Testing

 Identify types of tests to be performed.

 Gather details about testing priorities and focus.
 Prepare Requirement Traceability Matrix (RTM).
 Identify test environment details where testing is supposed to be carried out.
 Automation feasibility analysis (if required).

Deliverables of Requirement Phase Testing

 RTM
 Automation feasibility report. (if applicable)

Test Planning in STLC

Test Planning in STLC is a phase in which a Senior QA manager determines the test
plan strategy along with efforts and cost estimates for the project. Moreover, the
resources, test environment, test limitations and the testing schedule are also
determined. The Test Plan gets prepared and finalized in the same phase.
Test Planning Activities

 Preparation of test plan/strategy document for various types of testing

 Test tool selection
 Test effort estimation
 Resource planning and determining roles and responsibilities.
 Training requirement

Deliverables of Test Planning

 Test plan /strategy document.

 Effort estimation document.
 JAI ENTERPRISES

Test Case Development Phase

The Test Case Development Phase involves the creation, verification and rework of
test cases & test scripts after the test plan is ready. Initially, the Test data is identified
then created and reviewed and then reworked based on the preconditions. Then the
QA team starts the development process of test cases for individual units.
Test Case Development Activities

 Create test cases, automation scripts (if applicable)

 Review and baseline test cases and scripts
 Create test data (If Test Environment is available)

Deliverables of Test Case Development

 Test cases/scripts
 Test data

Test Environment Setup

Test Environment Setup decides the software and hardware conditions under which a
work product is tested. It is one of the critical aspects of the testing process and can
be done in parallel with the Test Case Development Phase. Test team may not be
involved in this activity if the development team provides the test environment. The
test team is required to do a readiness check (smoke testing) of the given
environment.
Test Environment Setup Activities

 Understand the required architecture, environment set-up and prepare

hardware and software requirement list for the Test Environment.
 Setup test Environment and test data
 Perform smoke test on the build

Deliverables of Test Environment Setup

 Environment ready with test data set up

 Smoke Test Results.

Test Execution Phase

Test Execution Phase is carried out by the testers in which testing of the software
build is done based on test plans and test cases prepared. The process consists of test
 JAI ENTERPRISES
script execution, test script maintenance and bug reporting. If bugs are reported then
it is reverted back to development team for correction and retesting will be
performed.
Test Execution Activities

 Execute tests as per plan

 Document test results, and log defects for failed cases
 Map defects to test cases in RTM
 Retest the Defect fixes
 Track the defects to closure

Deliverables of Test Execution

 Completed RTM with the execution status

 Test cases updated with results
 Defect reports

Test Cycle Closure

Test Cycle Closure phase is completion of test execution which involves several
activities like test completion reporting, collection of test completion matrices and
test results. Testing team members meet, discuss and analyze testing artifacts to
identify strategies that have to be implemented in future, taking lessons from current
test cycle. The idea is to remove process bottlenecks for future test cycles.
Test Cycle Closure Activities

 Evaluate cycle completion criteria based on Time, Test coverage, Cost,Software,

Critical Business Objectives, Quality
 Prepare test metrics based on the above parameters.
 Document the learning out of the project
 Prepare Test closure report
 Qualitative and quantitative reporting of quality of the work product to the
customer.
 Test result analysis to find out the defect distribution by type and severity.

Deliverables of Test Cycle Closure

 Test Closure report

 Test metrics

Test Plan
 JAI ENTERPRISES
A test plan is a detailed document which describes software testing areas and activities. It
outlines the test strategy, objectives, test schedule, required resources (human resources,
software, and hardware), test estimation and test deliverables.

The test plan is a base of every software's testing. It is the most crucial activity which ensures
availability of all the lists of planned activities in an appropriate sequence.

The test plan is a template for conducting software testing activities as a defined process that
is fully monitored and controlled by the testing manager. The test plan is prepared by the Test
Lead (60%), Test Manager(20%), and by the test engineer(20%).

How to write a Test Plan

Making a test plan is the most crucial task of the test management process. According to IEEE
829, follow the following seven steps to prepare a test plan.

o First, analyze product structure and architecture.

o Now design the test strategy.
o Define all the test objectives.
o Define the testing area.
o Define all the useable resources.
o Schedule all activities in an appropriate manner.
o Determine all the Test Deliverables.

Test plan components or attributes

The test plan consists of various parts, which help us to derive the entire testing activity.
 JAI ENTERPRISES

What is Use Case?

o In software testing, a use case is a graphic representation of business needs explaining how the
end-user will cooperate with software or an application. And the use cases allow us all the
possible techniques of how the end-user uses the application.
o In simple words, we can express that with the help of use cases; we can define how to use the
system for executing a precise task.
o The use case is not a part of execution which means that it is only a graphic demonstration of a
document that explains how to implement a particular task.
o With the help of the use case, we get to know how the product should work.

What is Test Case?

o A test case is defined as a group of conditions under a test engineer concludes whether a
software application is working as per the customer's requirements or not.
o The test case designing includes preconditions, case name, input conditions, and expected
result.
o These are derived from the test scenarios, and it is a first-level action.
o Mainly, test cases are used to validate the developed software by test engineers that the
particular software is working as per requirement or not.
o A test Caseis described as a group of various testing activities like test inputs, execution
conditions, and expected results that additionally lead to evolving a particular test objective.
 JAI ENTERPRISES
o Writing test cases is a one-time attempt that can be used in the future at the time of regression
testing.

What is Test Scenarios?

It is a detailed document of test cases that cover end to end functionality of a software
application in liner statements. The test scenario is a high-level classification of testable
requirements. Before performing the test scenario, the test engineer needs to consider the test
cases for each scenario.

What is a Test Suite?

Test suite is a container that has a set of tests which helps testers in executing and reporting the test
execution status. It can take any of the three states namely Active, Inprogress and completed.
A Test case can be added to multiple test suites and test plans. After creating a test plan, test suites are
created which in turn can have any number of tests.
Test suites are created based on the cycle or based on the scope. It can contain any type of tests, viz -
functional or Non-Functional.
 JAI ENTERPRISES
Test Suite - Diagram:

What is Traceability Matrix?

Requirement Traceability Matrix (RTM) is used to trace the requirements to the
tests that are needed to verify whether the requirements are fulfilled.
 JAI ENTERPRISES

What is a Test Environment?

A testing environment is a setup of software and hardware for the testing teams to
execute test cases. In other words, it supports test execution with hardware, software
and network configured.

Test bed or test environment is configured as per the need of the Application Under
Test. On a few occasion, test bed could be the combination of the test environment
and the test data it operates.

Setting up a right test environment ensures software testing success. Any flaws in this
process may lead to extra cost and time to the client.

What is Test Execution?

Test execution is the process of executing the code and comparing the expected and actual results.
Following factors are to be considered for a test execution process:
 Based on a risk, select a subset of test suite to be executed for this cycle.
 Assign the test cases in each test suite to testers for execution.
 Execute tests, report bugs, and capture test status continuously.
 Resolve blocking issues as they arise.
 Report status, adjust assignments, and reconsider plans and priorities daily.
 Report test cycle findings and status.
 1. Error or Mistake:

 Error is a human action that produces an incorrect result. It is deviation from

actual and expected value. The mistakes made by programmer is known as
an ‘Error’.
 JAI ENTERPRISES
 2. Bug:

 A Bug is the result of a coding Error or Fault in the program which causes the
program to behave in an unintended manner.

 3. Defect or Fault:

 A Defect is a deviation from the Requirements. A Software Defect is a

condition in a software product which does not meet a software requirement
or end-user expectations.

 Bug vs. Defect

 A Bug is the result of a coding Error and A Defect is a deviation from the
Requirements. A defect does not necessarily mean there is a bug in the code,

 5. Failure:

 If an end-user detects an issue in the product, then that particular issue is

called a failure.

 A Sample Defect report or Bug report:

 Defect ID – Every bug or defect has it’s unique identification number

 Defect Description – This includes the abstract of the issue.

 Product Version – This includes the product version of the application in

which the defect is found.
 JAI ENTERPRISES
 Detail Steps – This includes the detailed steps of the issue with the
screenshots attached so that developers can recreate it.

 Date Raised – This includes the Date when the bug is reported

 Reported By – This includes the details of the tester who reported the bug
like Name and ID

 Status – This field includes the Status of the defect like New, Assigned, Open,
Retest, Verification, Closed, Failed, Deferred, etc.

 Fixed by – This field includes the details of the developer who fixed it like
Name and ID

 Date Closed – This includes the Date when the bug is closed

 Severity – Based on the severity (Critical, Major or Minor) it tells us about

impact of the defect or bug in the software application

 Priority – Based on the Priority set (High/Medium/Low) the order of fixing the
defect can be made.

Defects are classified from the QA team perspective as Priority and from the development perspective
as Severity (complexity of code to fix it). These are two major classifications that play an important role
in the timeframe and the amount of work that goes in to fix defects.

What is Priority?
Priority is defined as the order in which the defects should be resolved. The priority status is usually set
by the QA team while raising the defect against the dev team mentioning the timeframe to fix the defect.
The Priority status is set based on the requirements of the end users.
For example, if the company logo is incorrectly placed in the company's web page then the priority is
high but it is of low severity.

Priority Listing
A Priority can be categorized in the following ways −
 JAI ENTERPRISES
 Low − This defect can be fixed after the critical ones are fixed.
 Medium − The defect should be resolved in the subsequent builds.
 High − The defect must be resolved immediately because the defect affects the
application to a considerable extent and the relevant modules cannot be used until it is
fixed.
 Urgent − The defect must be resolved immediately because the defect affects the
application or the product severely and the product cannot be used until it has been fixed.
What is Severity?
Severity is defined as the impishness of defect on the application and complexity of code to fix it from
development perspective. It is related to the development aspect of the product. Severity can be decided
based on how bad/crucial is the defect for the system. Severity status can give an idea about the deviation
in the functionality due to the defect.
Example − For flight operating website, defect in generating the ticket number against reservation is
high severity and also high priority.

Severity Listing
Severity can be categorized in the following ways −
 Critical /Severity 1 − Defect impacts most crucial functionality of Application and the
QA team cannot continue with the validation of application under test without fixing it.
For example, App/Product crash frequently.
 Major / Severity 2 − Defect impacts a functional module; the QA team cannot test that
particular module but continue with the validation of other modules. For example, flight
reservation is not working.
 Medium / Severity 3 − Defect has issue with single screen or related to a single function,
but the system is still functioning. The defect here does not block any functionality. For
example, Ticket# is a representation which does not follow proper alpha numeric
characters like the first five characters and the last five as numeric.
 Low / Severity 4 − It does not impact the functionality. It may be a cosmetic defect, UI
inconsistency for a field or a suggestion to improve the end user experience from the UI
side. For example, the background colour of the Submit button does not match with that
of the Save button.

Defect Resolution
Defect Resolution in software testing is a step by step process of fixing the defects.
Defect resolution process starts with assigning defects to developers, then developers
schedule the defect to be fixed as per priority, then defects are fixed and finally
developers send a report of resolution to the test manager. This process helps to fix
and track defects easily.