Software Testing

Software testing is widely used technology because it is compulsory to test each and
every software before deployment.

What is Software Testing ?

Software testing is a process of identifying the correctness of software by
considering its all attributes (Reliability, Scalability, Portability, Re-usability, Usability)
and evaluating the execution of software components to find the software bugs or
errors or defects.

What is Testing ?
Testing is a group of techniques to determine the correctness of the
application.

Type of Software testing

We have various types of testing available in the market, which are used to test the
application or the software.
Manual Testing
The process of checking/testing the functionality of an application as per the
customer needs without taking any help of automation tools is known as manual
testing.

While performing the manual testing on any application, we do not need any specific
knowledge of any testing tool, rather than have a proper understanding of the
product so we can easily prepare the test document.

Manual testing can be further divided into three types of testing, which are as
follows:

● White box testing

● Black box testing

● Grey box testing

Advantage of manual testing

● Fast and accurate visual feedback.

● Less expensive.

● No coding is required.

● No code visibility to T.E

Disadvantage of manual testing

● Less reliable.

● Can not be reused.

● Some specific tasks can’t be performed manually.

● The tester needs to know the application well.

● If the project is large then the testing process is time-consuming.

Automation testing
Automation testing is a process of converting any manual test cases into the test
scripts with the help of automation tools.

We can enhance the speed of our test execution because here, we do not require
any human efforts. We need to write a test script and execute those scripts.

Basics Questions and Answers

1. What is Software ?

○ A Software is the collection of computer programs that helps us to

perform a task.

2. Types of Software :

○ System software

■ Example: Device drivers, Operating systems, Servers, etc.

○ Programming software

■ Example: Compilers, debuggers, interpreters etc.

○ Application Software

■ Web Application, Mobile application, Desktop application etc.

3. What is software testing ?

○ Software testing is a part of the software development process.

○ Software testing is a technique to identify the defects/bugs in the

software.

4. What is software quality ?

○ A high-quality product is outlined in terms of its fitness of purpose.

○ That is, a high-quality product will specifically be what the users

need it to try to do.

5. Software quality factors are :

○ Application should be bug-free.

 ○ Product delivered on time.

○ Product should be within the budget.

○ Software should be according to requirements / Expectations.

○ It should be maintainable.

6. Project Vs Product

PROJECTS PRODUCTS

Requirements gathered from a particular Requirements gathered from a market

client. survey.

End user is one. End users are more than one.

Develop the application for a particular Develop the application for Global
client. clients.

Example: Banking projects like ICICI, Example: Gmail, Drive (Free sources)
HDFC and e-commerce projects like and Oracle products like Databases etc
flipkart.com and bigbasket.com. These are
specific to clients.

● Project - If a software application is developed for a specific

customer based on the requirement then it's called Project.
● Product - If a software application is developed for multiple
customers based on the market requirement then it's called
Product.

7. Why do we need to do the testing ?

○ Helps in saving money (cost-effectiveness).

○ Security.
○ Quality of the product.
○ Satisfaction of the customer.
○ Enhancing the development process (bug-free).
○ Easy while adding new features.
○ Determining the performance of the software.

8. Missing, Error, Bug and Failure :

 ○ Missing - A requirement of the customer that was not fulfilled.

○ Error - An error is a part of coding which is found by the

developer.

○ Bug - If any software which is not implemented according to

requirements that's called bug.

○ Failure - When the defects reach the end customer it is called a

Failure.

9. Why does the software have bugs ?

○ Changing Requirements

○ Miscommunication or No communication

○ Software complexity

○ Programming errors (Bad coding)

○ Lack of time (Time pressure)

○ Overconfident people

○ Lack of skilled testers

○ Poorly documented

10. Ends…
Software Development Life Cycle (SDLC)
SDLC is a process used by the software industry to design, develop and test the
softwares.

OR

SDLC is a process that creates a structure of software development.

Each phase requires deliverables (output from each phase) from the previous phase
in a life cycle of software development.

Requirements are translated into design, design into development and

development into testing, after testing, it is given to the client.

P - People
P - Process
P - Product

Different phases of the software development cycle.

● Requirement Phase

● Design Phase

● Build /Development Phase

● Testing Phase

● Deployment/ Deliver Phase

● Maintenance

1. Requirement Phase -
During this phase, the client explains the requirements, specifications,
expectations, and any other special requirement related to the product or software.

All information gathered in this phase as per the customer requirements.

All these are gathered by the business manager or project manager or business
analyst of the service providing company.

The requirement includes below points

How the product will be used and

who will use the product to determine the load of operations.

2. Design Phase

The design phase includes the logical designing of the system and is converted
into physical designing.

There are 2 stages in design,

HLD – High Level Design

LLD – Low Level Design

HLD – gives the architecture of the software product to be developed and is done by
architects and senior developers.

LLD – done by senior developers. It describes how each and every feature in the
product should work and how every component should work.

Here, only the design will be there and not the code.

For example, let us consider the example of building a house.

3. Development Phase

In this phase, work is divided into small units, and coding starts by the team of
developers according to the design discussed in the previous phase.
The decision required all essential tools such as programming languages like
Java, JavaScript, TypeScripts .NET, PHP, a database like Oracle, MySQL.

Front-end developers start their front-end work to develop UI.

Back-end developers start their back-end work to fetch the details from
database/API.

Since this is the coding phase, it takes the longest time and more focused approach
for the developer in the software development life cycle.

- done by all developers – seniors, juniors, freshers

- this is the process where we start building the software and start writing the
code for the product.

4. Testing Phase

In this phase, after getting the developed GUI (Graphical user interface) and
back-end combination.

it is tested against the requirements stated in the requirement phase.

Here the QA/QE team test the build/Application according to requirements

using types of essential testing such as Functional like

● integration testing,
○ Integration testing is of four types:
○ (i) Top-down (ii) Bottom-up (iii) Sandwich (iv) Big-Bang
● unit testing,
● acceptance testing
● Regression testing, and
● system testing.

Non-functional testing is also done in this phase (Ex: Performance, Security, etc..)

If there are any defects in the software or it is not working as per expectations,
Then the testing team logged the bug/defect in JIRA or some other tools which are
used by the organisation.

5. Deployment/ Deliver Phase

When software testing is completed according to requirement.

it is delivered to the customer for their use.

As soon as customers receive the product, they are recommended first to do the
beta testing.

In beta testing, customers can require any changes which are not present in the
software but mentioned in the requirement document or any other GUI changes to
make it more user-friendly.

Besides this, if any type of defect is encountered while a customer is using the
software; it will be informed to the development team of that particular software to
sort out the problem.

If it is a server issue, then the development team solves it in a short time; otherwise,
it will wait for the next version.

After the solution of all types of bugs and changes, the software finally deployed to
the end-user.

6. Maintenance

The maintenance phase is the last and long-lasting phase of SDLC because it is the
process which continues until the software's life cycle comes to an end.

When a customer starts using software, then actual problems start to occur, and at
that time there's a need to solve these problems.

Service – based companies and Product – based companies

Service – based companies: -

They provide service and develop software for other companies.

They provide software which is and specified as per the client company’s
requirement and never keep the code of the developed product and does not provide
the software to any other company other than the client company.

Ex – Wipro, Infosys, TCS, Accenture

Product – based companies :-

They develop software products and sell it to many companies which may need
the software and make profits for themselves.

They are the sole owners of the product they develop and the code used and sell it
to other companies which may need the software.

Ex – Oracle, Microsoft

1. Waterfall model
It is a traditional model.

It is a sequential design process, often used in SDLC, in which the progress is seen
as flowing steadily downwards (like a waterfall), through the different phases as
shown in the figure.
Requirements Collection :-

- done by Business Analysts and Product Analysts

- gathering requirements

- translates business language into software language

For example, let us consider the example of a banking software.

Feasibility Study :-

- done by software team consisting of project managers, business analysts,

architects, finance, HR, developers but not testers

- architect – is the person who tells whether the product can be developed
and if yes, then which technology is best suited to develop it.

- here we check for,

- technical feasibility

- financial feasibility
 - resource feasibility

Design :-

There are 2 stages in design,

HLD – High Level Design

LLD – Low Level Design

HLD – gives the architecture of the software product to be developed and is

done by architects and senior

developers

LLD – done by senior developers. It describes how each and every feature in
the product should work and

how every component should work. Here, only the design will be there and
not the code.

For example, let us consider the example of building a house.

Coding / Programming :-

- done by all developers – seniors, juniors, freshers

- this is the process where we start building the software and start writing the code
for the product.

Testing :-

- done by test engineers

- it is the process of checking for all defects and rectifying them.

Installation :-

- done by installation engineers

- to install the product at a client’s place for use after the software has been
developed and tested.

For example, consider the example of a software to be developed and

installed at Reliance petrol bunk.
Maintenance:-

- here as the customer uses the product, he finds certain bugs and defects
and sends the product back for

error correction and bug fixing.

- bug fixing takes place

- minor changes like adding, deleting or modifying any small feature in the
software product

100 % testing is not possible – because the way testers test the product is
different from the way customers use the product.

Example of the waterfall model

Earlier it was used for the applications such as Human Resource Management
[HRM], Supply Chain Management System, Customer Relationship
Management [CRM], and Retail Chains, etc.

but now in the present time, the waterfall models are replaced by other models such
as Iterative models and Agile Methodology, etc.

Pros and Cons of the Waterfall Model

Pros Cons

In the Waterfall model, the This model has no parallel deliverable, which
requirement should be clear. means that two teams can work together.
 It is suitable for a smaller The waterfall model doesn't provide the
project where needs are requirement changes and requirement review.
well understood.

This model is easy to Previously, when the waterfall is invented, there is

understand, as well as easy no concept of testing, that's why the developer is
to use. used to test the application.

It will allow us to arrange the In between, changes are not allowed because one
tasks efficiently. phase is dependent on another stage.

In this model, release level Backward tracking is not possible.

changes are allowed.

In this model, the procedure It is a time-consuming process.

and the results are well
documented.

2. Spiral Model
The spiral model is a software process model that couples the iterative feature of
prototyping with the controlled and systematic aspects of the linear sequential 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.

The Spiral Model is shown in fig:

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

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.

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 a Spiral Model?

● When deliverance is required to be frequent.

● When the project is large

● When requirements are unclear and complex

● When changes may require at any time

● Large and high budget projects

Advantages

● High amount of risk analysis

● Useful for large and mission-critical projects.

Disadvantages

● Can be a costly model to use.

● Risk analysis needed highly particular expertise

● Doesn't work well for smaller projects.

3. Prototype Model
The prototype model requires that before carrying out the development of actual
software, a working prototype of the system should be built.

A prototype is a toy implementation of the system. A prototype usually turns out to be

a very crude version of the actual system, possibly exhibiting limited functional
capabilities, low reliability, and inefficient performance as compared to actual
software.

In many instances, the client only has a general view of what is expected from the
software product.

In such a scenario where there is an absence of detailed information regarding the

input to the system, the processing needs, and the output requirement, the
prototyping model may be employed.
Steps of Prototype Model

1. Requirement Gathering and Analyst

2. Quick Decision

3. Build a Prototype

4. Assessment or User Evaluation

5. Prototype Refinement

6. Engineer Product
Advantage of Prototype Model

1. Reduce the risk of incorrect user requirement

2. Good where requirement are changing/uncommitted

3. Regular visible process aids management

4. Support early product marketing

5. Reduce Maintenance cost.

6. Errors can be detected much earlier as the system is made side by side.

Disadvantage of Prototype Model

1. An unstable/badly implemented prototype often becomes the final product.

2. Require extensive customer collaboration

○ Costs customer money

○ Needs committed customer

○ Difficult to finish if customer withdraw

○ May be too customer specific, no broad market

3. Difficult to know how long the project will last.

4. Easy to fall back into the code and fix without proper requirement analysis,
design, customer evaluation, and feedback.

5. Prototyping tools are expensive.

6. Special tools & techniques are required to build a prototype.

7. It is a time-consuming process.

*****************************************************************
4. 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 but it looks like in
V shape as you can see in the figure below.

Testing of the device is planned in parallel with a corresponding stage of

development.

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's
expectations and requirements.

So V-Model contains Verification phases on one side of the Validation phases on the
other side.

The Verification and Validation process is joined by a 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 are understood from the customer's side.

a. This phase contains detailed communication to understand customer's

expectations and exact requirements.

2. System Design: In this stage system engineers analyse and interpret the
business of the proposed system by studying the user requirements
document.

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,

a. their interface relationships, dependencies, database tables,

architecture diagrams, technology detail, etc.

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

a. 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.
 a. There are some guidelines and standards for coding. Before checking
in the repository, the final build is optimised 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.

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

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

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

a. System Test ensures that expectations from an application developer

are met.

4. Acceptance Testing: Acceptance testing is related to the business

requirement analysis part.

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

b. It conjointly discovers the non-functional problems like load and

performance defects within the real user atmosphere.
When to use V-Model?

● When the requirement is well defined and not ambiguous/unknown.

● The V-shaped model should be used for small to medium-sized projects

where requirements are clearly defined and fixed.

● 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 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, have to be updated.

*****************************************************************
Software Testing Life Cycle (STLC)
The procedure of software testing is also known as STLC (Software Testing Life
Cycle).

Which includes phases of the testing process.All activities are done to improve the
quality of the software product.

Software testing life cycle contains the following steps:

1. Requirement Analysis

2. Test Plan Creation

3. Environment setup

4. Test Case Creation and Execution

5. Defect/Bug Logging

6. Test Cycle Closure / Sign off

1. Requirement Analysis:

In this phase, the tester analyses the requirement document of SDLC (Software
Development Life Cycle) to examine requirements stated by the client.

After examining the requirements, the tester makes a test plan to check whether the
software is meeting the requirements or not.

2. Test Plan/Cases Creation:

Test plan creation is the important phase of STLC where all the testing strategies are
defined.

Tester determines the estimated effort and cost of the entire project.

3. Environment setup:
Setup of the test environment is an independent activity and can be started along
with Test Case Development.

This is an essential part of the manual testing procedure as without environment

testing is not possible.

Environment setup requires a group of essential software and hardware to create a

test environment.

The testing team is not involved in setting up the testing environment, its senior
developers who create it.

4. Test case Execution:

Test case Execution takes place after the successful completion of test planning.

In this phase, the testing team starts case development and execution activity.

The testing team writes down the detailed test cases, also prepares the test data if
required.

The prepared test cases are reviewed by peer members of the team or Test Lead.

RTM (Requirement Traceability Matrix) is also prepared in this phase (used for
tracking requirements).

5.Bug/Defect logging:

Testers and developers evaluate the completion criteria of the software based on test
coverage, quality, time consumption, cost, and critical business objectives.

This phase determines the characteristics and drawbacks of the software.

Test cases and bug reports are analysed in depth to detect the type of defect and its
severity.
Defect logging analysis mainly works to find out defect distribution depending upon
severity and types.

If any defect is detected, then the software is returned to the development team to fix
the defect, then the software is re-tested on all aspects of the testing.

6. Sign off / cycle closure:

The test cycle closure report includes all the documentation related to software
design, development, testing results, and defect reports.

This phase evaluates the strategy of development, testing procedure, and possible
defects in order to use these practices in the future if there is software with the same
specification.

Bug Life cycle

Here, we will talk about the complete life cycle of a bug from the stage it was found,
fixed, re-test, and closed.

We have some different status of bugs like new/open, assigned, fix, re-open, and
closed.

(T.E - Test Engineer)

As soon as the test engineer finds the bug, status is given as New, which indicates
that a bug is just found.

This new bug needs to be reported to the concerned Developer by changing the
status as Assigned so that the responsible person should take care of the bug.

Then the Developer first goes through the bug, which means that the Developers
read all the navigation steps to decide whether it is a valid bug or not.

if the bug is valid, the Developer starts reproducing the bug on the application, once
the bug is successfully reproduced.

The Developer will analyse the code and do the necessary changes, and change the
status as Fixed.

Once the code changes are done, and the bug is fixed, the test engineer re-test the
bug.

which means that the test engineer performs the same action once again, which is
mentioned in the bug report, and changes the status accordingly:

Close, if the bug fixes properly, and functionally working according to the
requirement.

OR

Re-open, if the bug still exists or is not working properly as per the requirement, then
the bug sends it back to the Developer once again.

This process is going on continuously until all the bugs are fixed and closed.

Note 1: Test Engineer can not tell the bug orally to the developer because of the
following reasons.

● Developers might ignore the bug

● Developer misunderstood the bug

● Forget the bug

● The bug may not be found in the exact location

Whom to assign the bug

The bug can be assigned to the following:

● Developers

● Developers lead

● Test lead

Developers: If we know who has developed that particular module.

Developer lead: If we don't know the Developer who has developed the particular
module.

Test lead: When we don't have any interaction with the development team.

When the bug is fixed and closed or if it is having any impact on the other module,
then we go for a new bug report.

OR

When the status of the bug is Re-open (not fixed) and affecting another module,
then we have to prepare the new bug report.

● Whenever we find a bug and Developers fix it, we have to check one round of
impact areas.

● If the old bug is fixed correctly, change the status to Close.

● And if we find a bug in the impact area, then it is reported as a new bug.

● If the old bug is not fixed properly, then change the status to Re-open.

● Or, if we find a bug impact area, then change the status to New or reported as
a new bug.

Another status of the bug

Once we prepare a bug report and send it to the Developers, the Developer will
accept the bug and start doing the necessary code changes that become the
positive flow of the bug life cycle.

There may be several conditions where Developers may not do the necessary code
changes and depend on the situation, which becomes a negative flow or status of
the bug life cycle.
Following are the different status of the bug life cycle:

● Invalid/rejected

● Duplicate

● Postpone/deferred

● Can't fix

● Not reproducible

● RFE (Request for Enhancement)

Invalid / rejected

When the Test Engineer wrote an incorrect Bug Report because of misunderstanding
the requirements,

then the Developer will not accept the bug, and give the status as Invalid and send it
back. (Sometimes developers can also misunderstand the requirements).
 - Any bug which is not accepted by the developer is known as an invalid
bug.

Reasons for an invalid status of the bug

The invalid status of the bug is happened because of the following reasons:

● Test Engineer misunderstood the requirements

● Developer misunderstood the requirements

Let's see one example where the test engineer and developer misunderstood the
requirements as we can see in the below image:
Duplicate

When the same bug has been reported multiple times by the different test
engineers are known as a duplicate bug.

Reasons for the duplicate status of the bug

Following are the reasons for the duplicate status:

● Common features.

● Dependent Modules
As we can see in the below image, the test engineer wants to compose a
mail, so first, the test engineer needs to login, then only he/she is able to
compose the mail.
If the bug is found in the login module, the test engineer cannot do further
process because the composing module is dependent on the login module.
Not Reproducible

The Developer accepts the bug, but is not able to Reproduce due to some
reasons.

These are the bugs where the developer is not able to find it, after going
through the navigation step given by the test engineer in the bug report.

Reasons for the not reproducible status of the bug

Reasons for the not reproducible status of the bug are as follows:

● Incomplete bug report

The Test engineer did not mention the complete navigation steps in the
report.

● Environment mismatch
Environment mismatch can be described in two ways:

○ Server mismatch

○ Platform mismatch

Server mismatch: Test Engineer is using a different server (Test Server), and the
Developer is using the different server (Development Server) for reproducing the
bug as we can see in the below image:
● Data mismatch
Different Values used by test engineers while testing & Developer uses
different values.
For example:
The requirement is given for admin and user.

Test engineer(user) using the Developer (admin) using

the below requirements: the below requirements:

User name → abc User name → aaa

 Password → 123 Password → 111

I.e., both are using a different value for the same login module.

● Build mismatch
The test engineer will find the bug in one Build, and the Developer is
reproducing the same bug in another build. The bug may be automatically
fixed while fixing another bug.

● Inconsistent bug
The Bug is found at some time, and sometime it won't happen.
Solution for inconsistent bug:
As soon as we find the bug, first, take the screenshot, then developer will
re-confirm the bug and fix it if exists.

Can't fix

When the Developer accepts the bug and is also able to reproduce, but can't do
the necessary code changes due to some constraints.

Reasons for the can't fix status of the bug

Following are the constraints or reasons for the can't fix bug:

● No technology support: The programming language we used itself did not

have the capability to solve the problem.

● The Bug is in the core of code (framework):

● The cost of fixing a bug is more than keeping it.

● If any bug is minor, but the Developer can't fix it, which means that the
Developer can fix, but the bug is affecting the existing technology because it
was present in the core of the code.
 ● Each can't fix bugs are the minor bugs.

Deferred / postponed

The deferred/postpone is a status in which the bugs are postponed to the future
release due to time constraints.

RFE (Request for Enhancement)

These are the suggestions given by the test engineer towards the enhancement of
the application in the form of a bug report. The RFE stands for Request for
Enhancement.
*****************************************************************
Bug Report Template (excel)
The bug report template is as follows:

Let see one example of the bug report:

Bug ID PROJECT_NAME_0001

Module Login
Requirement 1

Test case name Gmail_login_compose _mail

Reporter Test engineer name

Release delta

Version 3.0

Status assigned

Date 02-12-2023

Assign to YY developer

CC Test lead, developer

Severity critical

Priority P2

Platform Window XP, internet explorer7.0

Build no. B02

Test data Username=xyz, password= 123

Brief description

Navigation steps ● Login Gmail application

● Compose mail and confirmation

message should be displayed

observation Mail not found in inbox

 Expected result should also be in the inbox.
Mail

Actual result Mail not found in inbox

Additional ------
comments

Here, we are describing some important attributes of the bug report.

Bug ID: it is a unique number given to the bug.

Test case name: When we find a bug, we send a bug report, not the test case to
the concerned developer. It is used as a reference for the test engineer.

Severity: It is the impact of a bug on the application. It can be a blocker, critical,

major, and minor.

Priority: In this, we have to decide which bug has to be fixed first. It could be
P1/P2/P3/P4, urgent, high, medium, and low.

Status: The different status of the bug which could be assigned, invalid, duplicate,
deferred, and so on.

Reporter: In this, we will mention the name of the person who found the bug. It
could be the test engineer, and sometime it may be a developer, business analyst,
customer, etc.
Date: It provides the date when the bug is found.

Release/Build Version: It provides the release number in which the bug occurs,
and also the build version of the application.

Platform: Mention the platform details, where we exactly find the bug.

Description: In this, we will explain the navigation steps, expected and actual
results of the particular bug.

Attachments: Attach the screenshots of the bug, which we captured because it

helps the developers to see the bug.

The Drawback of a manual bug report

Following are the disadvantages of manual bug report:

● Time consuming
While searching every bug in the bug report, it will be a time taken process.

● Possibility of human error

A bug may be repeated, wrong data mentioned in the bug report, and miss
something to add on the bug report.

● No security
Anyone can change it or delete it.

● Tedious process

● No centralised repository

***********************************************
White Box Testing
Here we will be discussing here white box testing which is also known as glass
box testing, structural testing, clear box testing, open box testing and
transparent box testing.

They tests internal coding and infrastructure of a software focus on checking of

predefined inputs against expected and desired outputs.

The primary goal of white box testing is to focus on the flow of inputs and outputs
through the software.

Developers do white box testing. In this, the developer will test every line of the
code of the program.

The developers perform the White-box testing and then send the application or the
software to the testing team.

Where they will perform the black box testing and verify the application along with
the requirements and identify the bugs and send it to the developer.

Here, the test engineers will not include in fixing the defects for the following
reasons:

● Fixing the bug might interrupt the other features.

● Therefore, the test engineer should always find the bugs, and developers
should still be doing the bug fixes.

● If the test engineers spend most of the time fixing the defects, then they
may be unable to find the other bugs in the application.
The white box testing contains various tests, which are as follows:

● Path testing

● Loop testing

● Condition testing

● Testing based on the memory perspective

● Test performance of the program

Path testing

In the path testing, we will write the flow graphs and test all independent paths.

Here writing the flow graph implies that flow graphs are representing the flow of the
program and also show how every program is added with one another as we can
see in the below image:
Loop testing

In the loop testing, we will test the loops such as while, for, and do-while, etc.

and also check for ending conditions if working correctly and if the size of the
conditions is enough.

For example: we have one program where the developers have given about
50,000 loops.

1. {
2. while(50,000)
3. ……
4. ……
5. }

We cannot test this program manually for all the 50,000 loop cycles.

So we write a small program that helps for all 50,000 cycles, as we can see in the
below program.

That test P is written in the similar language as the source code program, and this
is known as a Unit test. And it is written by the developers only.
Therefore, if there is any requirement of modification or bug in the code, then the
developer makes the adjustment both in the main program and the test program
and then executes the test program.

Condition testing

In this, we will test all logical conditions for both true and false values; that is, we
will verify for both if and else conditions.

For example:

1. if(condition) - true
2. {
3. …..
4. ……
 5. ……
6. }
7. else - false
8. {
9. …..
10. ……
11. ……
12. }

The above program will work fine for both the conditions, which means that if the
condition is accurate, and then else should be false and conversely.

Testing based on the memory (size) perspective

The size of the code is increasing for the following reasons:

● The reuse of code is not there: let us take one example, where we have
four programs of the same application, and the first ten lines of the program
are similar. We can write these ten lines as a discrete function, and it should
be accessible by the above four programs as well. And also, if any bug is
there, we can modify the line of code in the function rather than the entire
code.

● The developers use the logic that might be modified. If one programmer
writes code and the file size is up to 250 kb, then another programmer could
write a similar code using the different logic, and the file size is up to 100kb.

● The developer declares so many functions and variables that might

never be used in any portion of the code. Therefore, the size of the program
will increase.
For example,

1. Int a=15;
2. Int b=20;
3. String S= "Welcome";
4. ….
5. …..
6. …..
7. ….
8. …..
9. Int p=b;
10. Create user()
11. {
12. ……
13. ……
14. ….. 200's line of code
15. }

In the above code, we can see that the integer a has never been called anywhere
in the program, and also the function Create user has never been called anywhere
in the code. Therefore, it leads us to memory consumption.

Reasons for white box testing

● It identifies internal security holes.

● To check the way of input inside the code.

● Check the functionality of conditional loops.

● To test function, object, and statement at an individual level.

Advantages of White box testing

● White box testing optimises code so hidden errors can be identified.

● Test cases of white box testing can be easily automated.

● This testing is more thorough than other testing approaches as it covers all
code paths.

● It can be started in the SDLC phase even without GUI.

Disadvantages of White box testing

● White box testing is too much time consuming when it comes to large-scale
programming applications.

● White box testing is much expensive and complex.

● It can lead to production error because it is not detailed by the developers.

● White box testing needs professional programmers who have a detailed

knowledge and understanding of programming language and
implementation.

Black box testing

Black box testing is a technique of software testing which examines the
functionality of software without coding knowledge.

The primary source (BRD) of black box testing is a specification of requirements

that is stated by the customer.

In this method, the tester selects a function and gives input value to examine its
functionality, and checks whether the function is giving expected output or not.
If the function produces correct output, then it is passed in testing, otherwise
failed.

The test team reports the result to the development team and then tests the next
function.

After completing testing of all functions if there are severe problems, then it is
given back to the development team for correction.

Generic steps of black box testing

● The black box test is based on the specification of requirements, so it is

examined in the beginning.

● In the second step, the tester creates a positive test scenario and an
adverse test scenario by selecting valid and invalid input values to check
that the software is processing them correctly or incorrectly.

● In the third step, the tester develops various test cases such as decision
table, all pairs test, equivalent division, error estimation, cause-effect graph,
etc.

● The fourth phase includes the execution of all test cases.

● In the fifth step, the tester compares the expected output against the actual
output.
 ● In the sixth and final step, if there is any flaw in the software, then it is cured
and tested again.

Test procedure

The test procedure of black box testing is a kind of process in which the tester has
specific knowledge about the software's work, and it develops test cases to check
the accuracy of the software's functionality.

It does not require programming knowledge of the software. All test cases are
designed by considering the input and output of a particular function.A tester
knows about the definite output of a particular input, but not about how the result is
arising. There are various techniques used in black box testing for testing like
decision table technique, boundary value analysis technique, state transition,
All-pair testing, cause-effect graph technique, equivalence partitioning technique,
error guessing technique, use case technique and user story technique. All these
techniques have been explained in detail within the tutorial.

Test cases

Test cases are created considering the specification of the requirements.

These test cases are generally created from working descriptions of the software
including requirements, design parameters, and other specifications.

For the testing, the test designer selects both positive test scenarios by taking valid
input values and adverse test scenarios by taking invalid input values to determine
the correct output.

Test cases are mainly designed for functional testing but can also be used for
non-functional testing.
Test cases are designed by the testing team, there is not any involvement of the
development team of software.

Techniques Used in Black Box Testing

Decision Decision Table Technique is a systematic approach where various

Table input combinations and their respective system behaviour are
Technique captured in a tabular form. It is appropriate for the functions that
have a logical relationship between two and more than two inputs.

Boundary Boundary Value Technique is used to test boundary values,

Value boundary values are those that contain the upper and lower limit of
Technique a variable. It tests, while entering boundary value whether the
software is producing correct output or not.

State State Transition Technique is used to capture the behavior of the

Transition software application when different input values are given to the
Technique same function. This applies to those types of applications that
provide the specific number of attempts to access the application.

All-pair All-pair testing Technique is used to test all the possible discrete
Testing combinations of values. This combinational method is used for
Technique testing the application that uses checkbox input, radio button input,
list box, text box, etc.
Cause-Effe Cause-Effect Technique underlines the relationship between a
ct given result and all the factors affecting the result.It is based on a
Technique collection of requirements.

Equivalenc Equivalence partitioning is a technique of software testing in which

e input data divided into partitions of valid and invalid values, and it
Partitioning is mandatory that all partitions must exhibit the same behavior.
Technique

Error Error guessing is a technique in which there is no specific method

Guessing for identifying the error. It is based on the experience of the test
Technique analyst, where the tester uses the experience to guess the
problematic areas of the software.

Use Case Use case Technique used to identify the test cases from the
Technique beginning to the end of the system as per the usage of the system.
By using this technique, the test team creates a test scenario that
can exercise the entire software based on the functionality of each
function from start to end.

Difference between white-box testing and

black-box testing
Following are the significant differences between white box testing and black box
testing:

White-box testing Black box testing

The developers can perform The test engineers perform the black
white box testing. box testing.

To perform WBT, we should have To perform BBT, there is no need to

an understanding of the have an understanding of the
programming languages. programming languages.

In this, we will look into the In this, we will verify the functionality
source code and test the logic of of the application based on the
the code. requirement specification.

In this, the developer should In this, there is no need to know about

know about the internal design of the internal design of the code.
the code.
Grey Box Testing
Gray Box testing (GBT) is a software testing method to test the software application
with partial knowledge of the internal working structure.

It is a combination of black box and white box testing because it involves access
to internal coding to design test cases as white box testing and testing practices are
done at functionality level as black box testing.

GreyBox testing commonly identifies context-specific errors that belong to web

systems.

For example, while testing, if a tester encounters any defect then he makes changes
in code to resolve the defect and then tests it again in real time.

It concentrates on all the layers of any complex software system to increase testing
coverage.

It gives the ability to test both the presentation layer as well as the internal coding
structure.

It is primarily used in integration testing and penetration testing.

Why GreyBox testing?

Reasons for GreyBox testing are as follows

● It provides combined benefits of both Blackbox testing and WhiteBox testing.

 ● It includes the input values of both developers and testers at the same time to
improve the overall quality of the product.

● It reduces time consumption of long processes of functional and

non-functional testing.

● It gives sufficient time to the developer to fix the product defects.

● It includes the user point of view rather than designer or tester point of view.

● It involves examination of requirements and determination of specifications by

user point of view deeply.

GreyBox Testing Strategy

Grey box testing does not make it necessary that the tester must design test cases
from source code.

To perform this testing, test cases can be designed on the base of, knowledge
of architectures, algorithm, internal states or other high -level descriptions of
the program behaviour.

It uses all the straightforward techniques of black box testing for function testing. The
test case generation is based on requirements and preset all the conditions before
testing the program by assertion method.
Generic Steps to perform Grey box Testing are:

1. Select and identify inputs from BlackBox and WhiteBox testing inputs.

2. Identify expected outputs from these selected inputs.

3. Identify all the major paths to traverse through during the testing period.

4. Task is to identify sub-functions which are the part of main functions to

perform deep level testing.

5. Task is to identify inputs for subfunctions.

6. The sixth task is to identify expected outputs for subfunctions.

7. The seventh task includes executing a test case for Subfunctions.

8. The eighth task includes verification of the correctness of the result.

The test cases designed for Gray Box testing includes Security related, Browser
related, GUI related, Operational system related and Database related testing.

Techniques of Grey box Testing

Matrix Testing

This testing technique comes under Grey Box testing. It defines all the used
variables of a particular program.

In any program, variables are the elements through which values can travel inside
the program.

It should be as per requirement otherwise, it will reduce the readability of the

program and speed of the software.

Matrix technique is a method to remove unused and uninitialized variables by

identifying used variables from the program.

Regression Testing

Regression testing is used to verify that modification in any part of software has not
caused any adverse or unintended side effect in any other part of the software.
 During confirmation testing, any defect got fixed, and that part of software started
working as intended, but there might be a possibility that the fixed defect may have
introduced a different defect somewhere else in the software.

So, regression testing takes care of these type of defects by testing strategies like
retest risky use cases, retest within a firewall, retest all, etc.

Black Box Testing vs White Box Testing vs Grey Box Testing

S.No Black Box Testing White Box Testing Grey Box Testing

1 Knowledge of internal Knowledge of internal Partially Knowledge

working structure (Code) is working structure of the internal
not required for this type of (Coding of software) is working structure is
testing. Only GUI necessarily required for required.
(Graphical User Interface) this type of testing.
is required for test cases.

2 Black Box Testing is also White Box Testing is also Grey Box Testing is
known as functional known as structural also known as
testing, data-driven testing, testing, clear box testing, translucent testing
and closed box testing. code-based testing, and as the tester has
transparent testing. limited knowledge of
coding.

3 The approach towards White Box Testing is If the tester has

testing includes trial proceeded by verifying knowledge of
techniques and error the system boundaries coding, then it is
guessing method because and data domains proceeded by
tester does not need inherent in the software validating data
as there is no lack of domains and internal
 knowledge of internal internal coding system boundaries
coding of the software. knowledge. of the software.

4 The testing space of tables The testing space of The testing space of
for inputs (inputs to be tables for inputs (inputs tables for inputs
used for creating test to be used for creating (inputs to be used
cases) is pretty huge and test cases) is less as for creating test
largest among all testing compared to Black Box cases) is smaller
spaces. testing. than Black Box and
White Box testing.

5 It is very difficult to It is simple to discover Difficult to discover

discover hidden errors of hidden errors because it the hidden error.
the software because can be due to internal Might be found in
errors can be due to working which is deeply user level testing.
internal working which is explored in White Box
unknown for Black Box testing.
testing.

6 It is not considered for It is well suitable and It is not considered

algorithm testing. recommended for for algorithm testing.
algorithm testing.

7 Time consumption in Black White Box testing takes a Test cases designing
Box testing depends upon long time to design test can be done in a
the availability of the cases due to lengthy short time period.
functional specifications. code.

8 Tester, developer and the Only tester and Tester, developer

end user can be the part of developer can be a part and the end user
testing.
 of testing; the end user can be the part of
can not involve. testing.

9 It is the least The entire testing less time consuming

time-consuming process process is the most time than White Box
among all the testing consuming among all the testing.
processes. testing processes.

10 Resilience and security Resilience and security Resilience and

against viral attacks are against viral attacks are security against viral
covered under Black Box not covered under White attacks are not
testing. Box testing. covered under Grey
Box testing.

11 The base of this testing is The base of this testing Testing based on
external expectations is coding which is high-level database
internal behavior is responsible for internal diagrams and
unknown. working. dataflow diagrams.

12 It is less exhaustive than It is most exhaustive Partly exhaustive;

White Box and Grey Box between Black Box and depends upon the
testing methods. Grey Box testing type of test cases
methods. are coding based or
GUI based.