AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Course Outline
Module1: Software testing concepts (Theory)
Module2: Software testing project (Application of theory on a sample project)
Module3: Agile testing and Jira Tools (Practice)

Module1: Software testing concepts

• What is Software? Types of Software’s?
• What is Software Testing?
• What is Software Quality?
• Project Vs Product
• Why do we need Testing?
• Error, Bug & Failure
• Why the software has bugs?

1|Page
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Chap1: Concepts around software testing

What is a software for software tester?

A software is a collection of computer programs that helps to perform a task.

What are types of software?

We distinguish 03 main categories of software:

• System software:
• Programming software:
• Application software:
System Software
In this category, we can distinguish Device driver; Operating system; Utilities, etc.
These are software without which the computers cannot be used.
Operating system
An operating system is the most important software that runs on a computer. It
manages the computer's memory and processes, as well as all of its software and
hardware. It also allows you to communicate with the computer without knowing how to
speak the computer's language. Without an operating system, a computer is useless. Your
computer's operating system (OS) manages all of the software and hardware on the
computer. Most of the time, there are several different computer programs running at the
same time, and they all need to access your computer's central processing unit (CPU),
memory, and storage. The operating system coordinates all of this to make sure each
program gets what it needs. Its function include:
• Memory management
• Process management
• Security management
• File management
• Device management
• Etc.
Device driver
A device driver is a program without a UI that manages hardware attached to a
computer and supports its functioning. It is a specialized software that operates a
particular computer-connected device; offering a software interface to the hardware,
allows operating systems and other computer applications to access hardware
functionalities. Device drivers operate inside the OS kernel layer. They work in a highly
privileged environment because they need low-level access to hardware operations to
function. They enable the computer’s operating system (OS) to interface with the
hardware for which they were developed. And through a computer bus that links the
device to the computer, the drivers and the device communicate.
Device drivers must receive advice from the operating system to access and execute
device instructions. After completing the job, they transmit the hardware device’s output

2|Page
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

or message to the operating system. Devices such as modems, routers, speakers,

keyboards, and printers require device drivers to operate.
Question: What are the name peripherals that function without explicitly installation of a
device driver? List 02

Utilities
Is a software component that assists the operating system to optimize, maintain,
organize and manage how it functions in all situation. It also supports computer’s
infrastructure which differs from application software that performs tasks to the benefit
of users. We distinguish for example antivirus software; system monitoring software,
debugging software, registry cleaning software, etc.

Programming software
Programming software is a program or set of programs which helps the software
developers by assisting them in creating, debugging and maintaining other programs and
applications. More simply, is a software which helps the programmer in developing other
software. We distinguish in this category compilers; debuggers; interpreters, etc. When
programmers write code, programming software’s are software that process that code
internally to produce some outputs for users.
Application software
There are software’s designed for end user. Application software, software
designed to handle specific tasks for users. Such software directs the computer to execute
commands given by the user and may be said to include any program that processes data
for a user. We distinguish several types of application software: Web application; Mobile
application; Desktop or standalone application; Web service etc.
Question: Differentiate between Web, Mobile and Desktop application by filling the
following table:
Criteria Web application Mobile Desktop Web service
application application
GUI

Find a criteria an according to it, state the particularity of each type of application
software to help differentiate between them.

What is a software testing

Software testing is an activity in the software development process which helps to
detect and identify defects in a software product. The final objective of testing is to release
quality product to end users. It is the process used to determine if a software fill
customer’s requirement or not.

3|Page
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

What is a software quality

Quality is important because the objective of testing is to deliver a quality software. Thus,
we must understand what is a quality software. A quality software is a software that fulfills
the following characteristics:
• Bug-free
• Delivered on time
• Within budget
• Meets requirements and/or expectations
• Maintainable
• Well structure and understandable documentation
This quality of a software can be measure.

What is project and product?

When a software application is developed for specific customer based on the
requirement then it is called a Project. In the other hand, when a software application is
developed for multiple customers based on market requirements then it is called a
product (Word, Excel, Notepad, Gmail, Google etc.). That means when we develop a
product, is to fulfill market requirement while a project is built to fulfill specific customer’s
requirement. Everybody can use a product when just the targeted customers can use a
project. Also, we can say that a project must be adapt to customers while customers have
to adapt themselves to a product.

Why we need testing

Generally, is to ensure the quality of a software especially to ensure that the
software doesn’t have any bugs and meets requirements and/or expectations. Testing will
identify defects, reduce flaws, and increase the overall quality of the system. Everyone can
make mistakes, so testing is necessary because it helps us identify bugs or errors early, so
that they can be fixed before the application is delivered to the client. More clearly, the
following are some important reasons why software testing techniques should be
incorporated into application development:
• Identifies defects early: Developing complex applications can leave room for
errors. Software testing is imperative, as it identifies any issues and defects with
the written code so they can be fixed before the software product is delivered.
• Improves product quality: When it comes to attracting customers, delivering a
quality product is an important metric to consider. An exceptional product can only
be delivered if it's tested effectively before launch. Software testing helps the
product pass quality assurance (QA) and meet the criteria and specifications
defined by the users.
• Increases customer trust and satisfaction: Testing a product throughout its
development lifecycle builds customer trust and satisfaction, as it provides

4|Page
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

visibility into the product's strong and weak points. By the time customers receive
the product, it has been tried and tested multiple times and delivers on quality.
• Detects security vulnerabilities. Insecure application code can leave vulnerabilities
that attackers can exploit. Since most applications are online today, they can be a
leading vector for cyber-attacks and should be tested thoroughly during various
stages of application development. For example, a web application published
without proper software testing can easily fall victim to a cross-site scripting attack
where the attackers try to inject malicious code into the user's web browser by
gaining access through the vulnerable web application. The non-tested application
thus becomes the vehicle for delivering the malicious code, which could have been
prevented with proper software testing.

Errors, bugs/defects and failure

• Error is a human mistake. Is an incorrect human action.
• Bug or defect is the deviation from the normal expectations. An error in the code
due the programmer action can then cause a bug.
• Failure is a deviation from the normal expectation but identify by an end user. A
failure appears in the production environment due to some user’s action. In other
word, a failure is a bug discovered in the production environment.
Question: Differentiate between bug, failure and error by filling the following table
Error Bug/defect Failure
Environment where Development Development Production
it is discovered environment environment environment
Cause by users / developer developer developer
developer
Discover by developer developer user
user/developer
Human action / Human action Consequence of Consequence of
consequence of human action human action
human action

Why the software has bugs?

There is a lot of reason that justify why software has bugs. Among others, we have the
following:
• Miscommunication between developer’s or end users and developer’s
• Software complexity: Number of modules; number of functional requirements;
number of developers around; these are things that help to measure the complexity
of a software
• Programming errors
• Changing requirements: This is the measure cause of bug in a software. Developer’s
team must ensure that the requirements especially functional requirements is
stable as possible to avoid many bugs.

5|Page
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

• Lack of skilled testers

6|Page
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Chap2: Software Development Life Cycle: SDLC

SDLC means Software Development Life Cycle. It is a step-by-step process used by
software industry to design, develop and test the software. If you take any company it is
based on three “P”: People, Process and Product
• People: are employees that work for the enterprise. Without people, there is no
company.
• Process: process represents the path, the various steps which we have to follow in
a company to help people of the company produce product something for
customer.
• Product: Product represents the things that will be deliver to customers.
So, if you want to deliver products for customer, the people in the company should
follow a certain process to serve some quality product.
SDLC is about the process. SDLC contains multiples phases which are:

Now this is considered as a high level SDLC model. To applied it on various project or
product, there exist multiple approaches among which we have Waterfall model, Spiral
model, V-model etc.

Waterfall model

7|Page
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

It is the very old (the oldest) approach or model of SDLC. It seems like the above high
model of SDLC but the difference between the 02 is on documentation. Each step-in
waterfall model must be documented. Each phase finish with a documentation.
• Requirement analysis: The requirement analysis phase start by requirement
gathering in which a discussion with end users helps to list all the requirements of
the software. This phase end with the delivering of a document called “ SRS:
software requirement specification”. A separate team can achieve this step.
• System design: the entry document of the system design phase is the “SRC
document” released after the first phase. The design is presented in a document
and that design document is released at the end of this phase.
• Implementation: Implementation is the real development phase. It starts with the
system design document and end with the code in which all requirement has been
implemented.
• Testing starts immediately after the implementation phase and tester produce a
testing report.
• After testing report, the deployment phase starts with the installation of the
software in the customer environment. A document that describes the deployment
phases is produce. Documents like installation manual, user manual, etc. are
produced in this phase.
• The process finish with the maintenance phase in which all the above document
will be use to understand and resolve any issues that will be notice by end users.
Every phase then has and input from the last phase and produce an output for the next
phase. So, each phase depends on the previous phase. So, it is not possible to work on 02
different phase at the same time.

Advantages of the waterfall model

• Quality of the end product will be good: because for every phase we have a stable
and clear documentation.
• Since the requirement changes are not allowed, chances of finding bugs will be
reduce: In fact, suppose with some set of requirements, an SRS document is
produced and the design team start to work on the design phase. At that time, any
modification on requirements is not allowed due to the principle of waterfall
model. Then any modification on requirements is not allowed and knowing that
dynamic requirements are source of bugs, we can conclude that with stable
requirements the presence of bugs is reduced.
• Initial investment is less since the testers are hired at the later stages: In fact, each
stage is done by a different team. The initial investment is then decided only on the
size of the requirement analysis team. We don’t need to think about developers,
testers of even designers in that phase. This reduces the initial investment amount.
• Preferred for small project where requirements are not dynamic and limited: In
fact, for a big software, chances of requirement changing are higher and this means
that the requirements analysis phase is less stable.

8|Page
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Disadvantages of waterfall model

• Requirement changes are not allowed:
• If there is defect in the requirement phase, that will be continue in later phases :
This is due to the close relation between phases. Each phase depends on the
previous phase.
• Total investment at the end is more because time taking for rework on defect is
time consuming which leads to high investment: In fact, to correct a defect, we can
restart the whole process to identify and correct the defect.
• Testing will only start after coding means too late in the process: It is not possible
to test each phase to ensure his stability before move forward. We have only one
stage of testing in the process.

When to use the waterfall model

• This model is used only when the requirements are very well known, clear and
fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Many resources with the required expertise are available free of charge
• The project is short.

Spiral of iterative model

To face the disadvantages of the waterfall model, some others approach has been
developed amongst which we have “spiral or iterative model”.
The spiral model looks like the following:

9|Page
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

We have in spiral model 04 global stages: Planning; Risk analysis; Engineering &
Execution; Evaluation. Planning is in the sense is the requirements analysis. After the
requirement analysis we have Risk analysis phase in which we evaluate the requirements
and decide for example the number of developers needed, the number of testers needed,
the project budget and so on. It is called Risk analysis. After it we have Engineering and
execution phase which is in the real sense the design and implementation phase. Now
after design and implementation (engineering and execution) we have the testing
deployment and maintenance phase (evaluation)
Everything starts with a small prototype (A blue print of a mask of the expected
software or even software master plan). The first prototype will be developed and then
some requirements will be added on it at the end to restart the same process. When adding
some requirements, is like the prototype we are developing is different and the process
restart. Means to deliver each prototype, all stages of the waterfall model for example are
executed in the same manner. That is why it is iterative. Each iteration follows the step of
the waterfall model and produce a version of the end software that fill some stable
requirements. The need requirements will be considered in the next iteration and so on.
Every iteration is the version of the software. And after deliver an iteration, requirements
can change. It is like an upgrade version of a software. Every upgrade adds some new
features means new requirements have been added. On every cycle of the spiral, a version
of the software is released and the process restart with requirements analysis (planning)
to take new requirement and prepare the next iteration (an upgrade).

Characteristics of the spiral model

• Spiral model is iterative model: In fact, every cycle in the spiral is an iteration:
• Spiral model overcome drawbacks of the waterfall model: Explain?
• We follow spiral model whenever there is dependency on the modules: In fact, the
new iteration is based on the last. If a requirement is based on one of the last set of
requirements, it is not a problem.
• In every cycle, new software will be released to the customer:
• Software will be released in multiple versions so it is also called “version control
model”:

Advantages of spiral model

• Testing is done in every cycle (for any version or prototype), before going to the
next cycle:
• Customer will get to use the software for every module: Customer don’t need the
last version of the software to start use the software. His point of view is taken in
consideration after each version (iteration). He is using the software when we still
continue to develop it.
• Requirement changes are allowed after every cycle before going to the next cycle:

10 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Disadvantages of spiral model

• Requirement changes are not allowed in between the cycle: In fact, when
developing an iteration, waterfall model is the one use for it. And we know that, in
waterfall model, requirements can’t change when the process start.
• Every cycle of spiral model looks like Waterfall model:
• There is no testing in requirement and design phase for every iteration:
In fact, disadvantages of the waterfall model come into the spiral model at the level of each
iteration.
When to use Spiral model:
• When costs and risk evaluation is important
• For medium to high-risk projects
• Users are unsure of their needs
• Requirements are complex
• Significant changes are expected (research and exploration)

Example: We suppose that we want to build an application to send email. In such

application, Requirements can be:
• Build the authentication process
• Build the inbox page of a user
• Build a compose email page
• Send an email
• Receive an email
In spiral model, the understanding that we have for each requirement is used to build
the first iteration. To build that iteration, the waterfall model is then used. After it, it is
deployed for the users and the new requirement or a modification of some requirement
can now be taken in consideration for the building of the next iteration until the whole
software is obtained. One group of developers can work for one iteration and another one
for the next iteration. Every functionality composes a module and the development can
even start with only one functionality. Means from one iteration to another, the number of
functionalities can be different.

V model also called VV Model (Verification and Validation model)

It looks like

11 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

In V-Model we have 02 mains process in order: Verification process and then validation
process. For verification the question we must answer is “are we building the right
product?” while for validation the question we must answer is “are we building the
product in the right way?” or “the product which is asked by the end users?”. Validation is
then a process that takes place after verification. Verification focusses on documentation
while validation focusses on the software itself. Also, verification is done before the
software is built while validation is done after the software is built.
The main particularity of the V-Model is, in every phase of the software
development cycle, we must conduct a testing. In requirement analysis phase, we conduct
testing; In design phase, we conduct testing; In implementation phase, we conduct testing;
In implementation phase we conduct testing; In the testing phase also, we conduct testing;
In deployment phase we conduct testing; etc.
Indeed, in the waterfall model, we have only one testing phase. In the spiral model
we have one testing phase per cycle or iteration. But in the V-model, we have a testing
phase for each phase of the process.
In SDLC everything starts by the requirements analysis. It is the phase of collecting
and analyzing requirements from the customers. In that phase, we have some documents
called BRS, or CRS or URS which is Business Requirement Specification or Customer
Requirement Specification or Users Requirements Specification. This document is built by
a team called “BU: Business Unit” and those people interact with users or customers to
collect requirements to produce the document. The document is then better understood
by business people not by technical people. That also means only a business people can
verify and validate the document. The test that will be conduct by the use of this document
is called “User acceptance testing”.
For the second phase, we know that the BRS is not more understandable by
technical (developers and testers) people, that is why from that document (BRS) another
document must be edited to give more details about what is needed to technical people.

12 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

This next document is the SRS document which is Software Requirements Specification. It
contains some diagrams like dataflow diagram, use case diagram, etc. to help technical
people well understood what is needed. For this phase, System testing will be conducted
by developers and testers to verify and validate the step. The SRS document must be
prepared by the “project manager”
With the SRS, 02 others documents are produced (HLD and LLD document): High
Level Design Document (HLD) and Low-Level Design Document (LLD). HLD contains the
main modules of the application and the LLD contains for each module sub-modules to
help also the good understanding of the module. The HLD and LLD document must be
prepared by “designers”. After the documents produced by designers, development will
start by developers.
Now, from the BU (Business Unit) to developers, every team conduct first a test
(document review) on their work before release. Testers are not yet in the process. In fact,
each team that prepare the document is responsible of testing or review that document to
ensure the correctness and the completeness of the document.
Correctness (check if all information’s mentioned in the document are correct) and
completeness (check if documents are complete) are known as “verification process” and
it is the responsibility of the member that produce the corresponding document. Note
that, during that verification, we are not exactly testing the software but the
documentation because if the document is correct the next phase will be easy. So, after the
production of the BRS/CRS/URS the BU team verify the correctness and completeness of
the document; After the production of the SRS the PM verify the correctness and the
completeness of the document; After the production of the HLD and LLD documents, the
designers verify the correctness and the completeness of the documents and then after
the production of the source code, developers verify the correctness and the completeness
of the code. These verifications are called “document review” then “review” means verify
the completeness and the correctness of a document. That means, verification include
testing in the form of review.
Instead of using review to test document (verification), we can use other
techniques like walkthrough and inspection. All those testing applied on these documents
consist of verification process and it is called “static testing”. That means document review,
walkthrough and inspection are some techniques used for static testing. Static testing then
means testing the project related documents (verify the correctness and the
completeness).
In the validation part of the process imposed by the V-model, we have also 04
phases: Unit testing, Integration testing, system testing and User Acceptance testing. In
fact, the entire software will not be developed in one shot. It will be developed as indicated
in the document: from low level module to high level module. When we choose the module
by which the development will starts, we first develop the first low-level module of that
module. The testing applied on that module (low level module) is a form of unit testing.
When the module itself will be tested (means all its low-level module has been tested) we
call it also a unit testing because that module is just a small part of the whole system.

13 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Unit testing is then the testing applied in a single module of single component of
the whole software. The person responsible of that unit testing is the developer because
he is the one that have all details about the module and its low-level module.
After the development of all the high-level module of the software, they must be
link together to meet requirements. After linking them together, another test must be used
to ensure that everything is going well. This is the integration testing. And as describe,
integration testing is also conduct by developers itself because of his knowledge about the
internal system. That also mean that unit and integration testing are conduct at the code
level and then it is also called “white box testing”.
White box testing is then the testing made with a good knowledge of an internal
logic of the system. Such to clearly understand where a problem is when it occurs. Unit
and integration testing are then some techniques of white box testing. White box testing
is then conducted by a person that have a good knowledge of the internal logic of the
module of sub module (developers).
After the integration testing, the final system is ready. We already have high-level
developed and tested and then integrated together to meet initial requirement. The
testing team can now start his work. Testers are then responsible of system testing and
User Acceptance Testing. They are not obliged to have knowledge about the internal logic
of the system (code) because they have as objective to ensure that the system meet
customer’s requirements. Because, for system testing and user acceptance testing we
don’t need knowledge about the internal logic of the system, we call it “ black box testing
techniques”. After the system testing done by testers, one other testing techniques must
be achieved also by testers but with some customers: it is the UAT: User Acceptance
Testing.
To achieve the system testing and the UAT, testers must study and understand the
requirement to:
• Write the test plan or the test scenario
• Write the test cases for each test plan
• Discover and notice defect/bug
• Report defect to developers
These are then testers job.
To finish, because during the validation phase, we are testing the real software, it
is called “dynamic testing”. Unit testing, integration testing, system testing and user
acceptance testing are then techniques of dynamic testing.

Questions:
Differentiate between:
Static and dynamic testing; Verification and validation process; Unit and integration
testing; White and black box testing; Integration and system testing; System and UAT; BRS
and SRS; SRS and HLD; HLD and LLD
14 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Prove that SRS is the input document of the system testing in V-model
Prove that in V-model, integration testing can be prepared when HLD and LLD document
are available

Advantage of V-Model
As advantage of V-Model, we can see that, V-model correct problems of the above
model by introduce a testing phase on every phases. Testing is involved in each and every
phase during the development process.
Disadvantages of V-Model
• First investment is more: because for every phase the team must be constitute with
workers and testers. The presence of testers in every team increases the amount
of investment. Also, activities are going parallel. For example, when the BU team is
working on the BRS document, the testers must also start building test plan and
test cases for UAT.
• Documentation is more: In every phase, a document must be release.
• The process is much more time consuming. It is the consequence of the testing
process introduce in each phase.

15 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Chap3: Software testing techniques

Black & white box testing

White box testing means we have to test the internal logic of the program. It is
realized by developers. Black box testing mean we have to verify the functionality of the
software. The objective is to verify if the software is working according to functional
requirements or not. That mean in the black box testing we don’t need to know how
program has been built because the internal logic of the software is not important. It is
done by testers.

Static testing techniques: Review, Walkthrough and inspection

Review
Is a method that consists on reading a document to ensure that it is correct and
complete. Review technics is to ensure the correctness and the completeness of a
document. We distinguish different level of review in SDLC:

• Requirements review
• Design review
• Code review
• Test plan review
• Test cases review

Walkthrough
It is a kind of informal review mean it is also focus on documents. Author reads the
documents or code and discuss with peers. It’s not pre-planned or schedule and can be
done whenever required and that explain while it is informal. To differentiate between
review and walkthrough, we can notice that in the case of review only one person can
perform while in the case of walkthrough, at least 02 persons (members of the team) must
be present. One person read the document and others listen and try to understand. The
objective remains to verify the correctness and the completeness of documents. In
addition, review must be planned while walkthrough can’t be planned.

Inspection
It is the most formal review type in which at least 03 people will sit in the meeting
and follow documents. Inspection will have a proper schedule and the invitation can pass
through email or SMS to the concerned developers/testers. In an inspection, 03 kind of
people can be involved:
• Readers
• Writers
• Moderator
About these 03 roles in an inspection:

16 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Readers are authors of the document. They are the person supposed to read the document
for others.
About Writers, they are persons who listen the reader. When listen to them, they are
supposed to take note, write some questions and clarifications that will be done when the
reading is finished.
Moderator is the one who is in charge of the organization of the exchange or the meeting
between readers and writers.

Dynamic testing techniques

In dynamic testing techniques, we have the following:
• Unit testing
• Integration testing
• System testing
• User Acceptance testing: UAT
It is important to precise that, before start the dynamic testing, the software is already
develop. The software code is available to be more precise.

QA; QC and QE
In software industry, QA stand for Quality Assurance while QC for Quality Control
and QE for Quality Engineering. Our objective in this paragraph is to compare the three
concepts. First of all, the following table will help compare QA and QC:
QA QC
Is process related: An organization is based on Is people related especially testers. Is the
03 pillars as we saw before. The 03 P which are actual testing of the software: QC appear in
People; Process and Product. To produce a each step of the process to ensure the future
product for customers, the enterprise must have quality of the product. The procedure put in
a set of people that follow a certain process. The place by the QA team is then applied to control
people who belong to QA will always define the the quality of the product in each phase of the
process and talk about the process. The process. In waterfall model for example, QC
responsibility of the QA team is to ensure that only appear during testing phase because it is
the rest of people follow the process decided done only once.
properly or not. Their work is to put in place
procedure to ensure it.
Is focused on building in quality. We are trying Is focused on testing for quality. We must test
to build quality product. the product for quality or to ensure the quality
of the product.
Is for preventing defect: If you follow the process Is for detecting defect: If you control the quality
correctly, you can prevent the defect in the correctly, you can detect defects in the
future. It is preventing activities software. It is detecting activities
Is process oriented Is a product oriented.
Is for entire life cycle Is for testing part in SDLC
QC is then a subset of the QA
17 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

About QE, it stands for Quality Engineering. In testing, we have manual testing and
automation testing. For that automation testing, testers must write code also. Those
people who write code for automation testing are part of the QE team and then the QE
comes after the QC. Then QE is the advanced phase after QC. When software engineer
writes the code in programming language to develop the software, Quality engineer also
writes the code but for testing the software. QE team is then for automation testers.

Levels of software testing

In this part, we will discuss about the different level in which we will conduct software
testing. We distinguish 04 level of testing as indicate by the dynamic testing techniques.
We have:
• Unit Testing
• Integration Testing
• System Testing
• User Acceptance Testing (UAT)
Unit Testing
It is done by the developer itself. In unit testing, every small module (or even simple
function) is tested at the code level. Unit in this case is just to talk about small component
or module. Unit testing then comes in the white box testing techniques because developers
who is in charge of it knows very well the internal structure of the function or small
component that will be tested. It is conduct in the single program or in the single module.
To understand a bit what is a component in this case, consider the Gmail
application. Login which is the first step to pass before compose an email is a component
or module. Then composing an email is also another component. After composing an
email, we come to the send box which is also a module. Deleting email is then also a
module. As you can see, the entire application can be divided in multiple sub module until
unit. The test realized on each unit comes into unit testing.
To conduct unit testing, they are using certain techniques among which we have:
• Basis path testing: This technique ensures that, every line of a program should be
cover during testing. The test plan should include test cases such that all lines in
the program will be executed at least once.
• Control structure testing
o Conditional coverage: This technique is to ensure that the program function
as expected for negative and positive condition. Test plan should then
include test cases such that all possible path that comes from conditional
statement will be executed at least once.
o Loops coverage: Sometimes in the programming, to repeat some statements
we use loops. For all those loops we must verify whether conditions to enter
it can be filled of not. And when it is filled, what are the internal state of
variable that have been manipulated inside. We must check the state of

18 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

variables after enter the loop statement and after the loop statement to be
sure that the rest of the program will not be negatively affected by what
happens inside the loop. Test plan must then contain test cases to test all
things describe above for loop coverage.
• Mutation testing: About mutation testing, consider the following code:
If (username = “scott” and password = “123”) then

Allow login

Else

Not allow login

End If.

In mutation testing, we will test the code by passing different combination of

inputs. For example, in our case, we have 04 combinations: valid username and password,
valid username and not valid password, not valid username and valid password and not
valid username and not valid password.

Integration Testing
It comes when multiple unit or module are combined to form a high-level unit
called also module. Checking the data flow or communication between those sub modules
comes into Integration Testing. Integration testing is performed between 02 or more
modules and it focuses on checking data communication between multiples modules. It is
classified as white box testing. In fact, from the end user input, there is one module that
consumes the input and produce an intermediate output that becomes the input of
another module. Integration testing helps to check if all intermediate output to ensure that
every module consumes what it is supposed to consume. Integration testing is then at the
code level and then is conducted by developers. But sometimes, testers also conduct
integration testing at the application level. In fact, by using the application UI, testers must
check if the relation between modules is going normally. Means without the code as
developers, testers also conduct integration testing through the application UI. In
conclusion, incremental testing is an integration testing approach where you can integrate
the software module by module - one by one incrementally. This is a better approach than
the big bang because it focuses on each module and smaller combinations. The only thing
we need to remember here is to draw the diagram with logical modules only, i.e., the
modules that will get connected in the application.

19 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Here, the central module is Module 1, which we will have to reach ultimately, and
the smaller isolated modules are Module 2 and Module 3, and so on. Module 6 may not be
directly connected to Module 1, which we need to be cautious about as it may damage the
complete testing flow.
The main aim of performing incremental integration testing is to reach an
integrated stage (one by one) no matter which way you travel. You can either start from
the central module and move towards the end modules colored in green or vice versa.
We distinguish 02 types of integration testing: Incremental and non-incremental
integration testing.
Incremental integration testing
Incremental integration testing means that, from the first module (the basest one), we add
the other modules one by one, testing communication between the newly added module
and the older modules already added, until all the modules in the system have been added.
We can conduct this incremental integration testing with one of the following approaches:
Top-down; Bottom-up and sandwich or hybrid approach.
Top-down approach
In the top-down approach, we must ensure that the module added is the child of
the previous module. In fact, let us take as example the Gmail application with the
following module: Login, compose email and sending email. The unit testing helps to test
each module individually. After it, because we can’t compose an email without pass
through the login, login becomes the parent module of the compose email module. Sent
email is then the child module of the compose email. That means in the incremental
integration testing top-down approach, we can’t add the sent email module without the
presence of the compose email module.
Top-down integration testing can be done in a couple of ways that resemble the
popular tree traversing techniques in data structures.:
• Depth-first top-down testing
• Breadth-first top-down testing

20 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Depth-first top-down testing

The first type of top-down integration testing is depth-first. As its name suggests,
we move towards depth and first integrate the modules beneath one another. Once the
tree is completely integrated from one side, we again repeat the cycle.
To understand what happens in depth-first top-down approach, consider the following
application:

We get the following integrations in each iteration:

• Iteration 1: Test Module 1
• Iteration 2: Test Module 1 + Module 2
• Iteration 3: Test Module 1 + Module 2 + Module 4
Now we go back up one level, but Module 2 has already been covered, so we go along the
second depth.
• Iteration 4: Test Module 1 + Module 2 + Module 4 + Module 5
• Iteration 5: Test Module 1 + Module 2 + Module 4 + Module 5 + Module 3
• Iteration 6: Test Module 1 + Module 2 + Module 4 + Module 5 + Module 3 +
Module 6
• Iteration 7: Test Module 1 + Module 2 + Module 4 + Module 5 + Module 3 +
Module 6 + Module 7
The final result is the integrated application.

Breadth-first top-down testing

As against moving in the direction of depth of the connected tree, breadth-first integration
testing focuses on moving horizontally, i.e., along the breadth. The final integrated product
remains the same, just the transition to reach there is a little different.
If we consider the same application as in the previous cause, we get the following
integrations in each iteration.

21 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

• Iteration 1: Test Module 1

• Iteration 2: Test Module 1 + Module 2
• Iteration 3: Test Module 1 + Module 2 + Module 3
• Iteration 4: Test Module 1 + Module 2 + Module 3 + Module 4
• Iteration 5: Test Module 1 + Module 2 + Module 3 + Module 4 + Module 5
• Iteration 6: Test Module 1 + Module 2 + Module 3 + Module 4 + Module 5 +
Module 6
• Iteration 7: Test Module 1 + Module 2 + Module 3 + Module 4 + Module 5 +
Module 6 + Module 7
And this sequence can be continued if there exists another level of modules.

Advantages of top-down approach

• High-quality system: Because each child module is added only when all problem
with the parent modules has been resolved.
• No need to develop complete software:
Disadvantage of top-down approach
The top-down testing may offer one minor disadvantage. In fact, the final software
is tested at the end of the cycle. If any bugs were in the integrated software and required
disintegrating the modules to develop and test again, it could result in a lot of time
consumption. However, if the requirement is to test major defects in the integrated system
first, the tester might not face any problems.

Bottom-up approach
So, in the bottom-up approach of incremental integration testing, we must ensure
that the module added must be a parent of the previous modules already added. For
example, with the same Gmail application, in top-down approach we test if after
composing an email it come into sent email box. In bottom-up approach, we verify if every
email present in the sent email box was in the compose email box first.

Hybrid or sandwich approach

Finaly, sandwich or hybrid approach is just the combination of the 02 approaches.

Top-down integration testing vs. Bottom-up integration testing

The top-down integration testing and bottom-up integration testing work contrary
to each other in almost every aspect. If we could summarize their behaviors and work in
a table for quick reference, we would get something as follows:
Top-down testing Bottom-up testing
How to perform? Move from the top-level Move from the lower-level module
module to the lower level. to the top level.

22 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Module-priority in The main module is Submodules are given preference in

development. developed before the the development over the main
submodules. module.
When to perform? When the likelihood of When the likelihood of defects on
defects on the top modules the lower modules are higher.
is higher.
What to use? Stubs are used to perform Drivers are used to performing
top-down testing. bottom-up testing.
Which scenarios If the program is If the program is constructed in an
demand it? constructed structurally object-oriented style, bottom-up
or procedure-wise, top- testing seems favorable as it
down testing seems facilitates the development of
favorable. smaller modules first.
The difficulty level Top-down testing is found Bottom up is a bit complex and may
in learning and to be simpler than its take a little more time to learn and
execution counterpart. perfect.

Non-incremental integration testing

In non-incremental integration testing, we integrate all modules as one before
testing. So, if we have 10 modules in the application, we combine first the 10 modules
before start testing the data flow between them. It is also called big bang Integration
testing. This approach has some disadvantages:
• We might miss data flow between some of the modules
• If you find any defect, it is difficult to understand the root cause of the defect.
This approach is easier and faster but does not explore all the complicated areas of an
application. If the application is small in size, this could work.

23 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

System Testing
In system testing, we are testing the overall functionality of the application whether
it is working according to customer requirements or not. Is every requirement mentioned
in the software requirement working? Testers check it during the system testing. It is
conducted by the testing team and for it, it is a black box testing technique. After
completion of component and integration level testing’s, the system testing can start but
before it the customer requirements must be well understood by the tester’s team. In the
system testing, the code will not be tested but functionalities. It focuses on the below
aspects:

• User interface testing (GUI testing)

• Functional testing
• Non-functional testing
• Usability testing

UAT
At the last level, after finish with system testing, end users with testers going to
continue the test for user acceptance. UAT is conducted in 02 levels: alpha and beta testing.
In alpha testing, the users conduct the test in the development environment where in beta
testing the test in conduct in production environment.
Remark: These levels of testing explain why we cannot skip a level to fall directly in
another one. For example, we cannot start integration testing without finish with unit
testing. We cannot jump to UAT if unit testing, integration testing and system testing have
not been consecutively done before.

24 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Chap4: Details about System testing

Initially, we don’t need to know something about the code to test a software
according to customer’s requirements. That is the main aim of the system testing. The
customer’s requirements must be well documented and understandable to ease testers at
the system testing level. With that documentation, testers will prepare test plan with test
cases to conduct the system testing. This testing level is exactly where testers are involved
in the software testing process. System testing consist of the following types of testing:

In addition of the following, we must add the “robustness testing” which helps to test the
software in front of non-awaited entries.

GUI testing
Graphical User Interface testing or GUI testing is a process of testing the user
interface of an application. A graphical user interface includes all elements such as menus,
checkbox, buttons, colors, fonts, size, icons, content, images, etc. Every application develop
in the direction of users is divided into backend and frontend application. Users always
interacts with the application through the frontend. GUI testing is then the test of the
frontend part not exactly the applications requirements. Multiple things must be tested
on the frontend to ensure that it will helps users as much as possible to ensure the
acceptance of the software. The following list present example of what will be tested
during the frontend testing.
GUI testing checklist
We have for example to do the following:

• Testing the size, position, width, height of the elements

• Testing of the error messages that are getting displayed: In this part we must
ensure that all error message appear normally exactly when it is suppose to appear.
Also, we must be sure that there is no error message that can be a security
vulnerability like “the password must contain exactly 8 characters”.
• Testing the different sections of the screen
• Testing if the font is readable or not
• Testing of the screen in different resolution with the help of zooming in and
zooming out
• Testing the alignment of the texts and other elements like icons, buttons etc. are in
proper place or not

25 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

• Testing the colors of the fonts

• Testing whether the image has good clarity or not
• Testing the alignment of the images
• Testing of the spelling
• Testing if there are no grammatical errors in the different text displayed.
• The user must not get frustrated while using the system interface
• Testing whether the interface is attractive or not
• Testing of the scrollbars according to the size of the page if any
• Testing of the disabled fields if any
• Testing of the size or images
• Testing of the headings whether it is properly aligned or not
• Testing of the color of the hyperlink
• Testing UI elements like button, textbox, text area, check box, radio buttons, drop
downs, links, etc.
Before start any other test in this testing level (system testing) we must test the GUI.
We prepare some check list in the excel file for example in which for every line that
correspond to a test, we just tick of not if the frontend fulfills the test condition. In fact,
before the development of the frontend, a prototype has been developed and that
prototype can be used to evaluate the current frontend develop for the application.

Usability testing
Is to test how easy is to use the application. In this testing part, the helping
documents and menu will be tested. It is to test how easily the end users are able to
understand and operate with the application.

Functional testing
Functionality represent the behavior of the application. Then functional testing
means to test if the software behaves as the end user expectation. It talks about how
software features should work. The focuses of testers are not on the GUI but on the
application functionalities. In that functional testing, we have to verify the following:

• Object properties testing: That is to ensure for example that when a text box is
enabled then users can enter text inside and when it is disabled, nothing can be
enters inside. About radio button for example, there is only 02 states and, in the
group, only one can be checked while for check boxes multiples can be selected.
Etc. It is then also a frontend testing
• Database testing: It is a backend testing. We are going to use DML (Data
Manipulation Language) to test the database. For example, we are going to insert
data, update data, select data and delete data through UI to test if every behave
normally in the application backend and then frontend. We use the UI to launch an
operation, and then we connect directly on the DBMS and check if the operation
launches on the UI succeed or not. Testers must provide test plan that contains test

26 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

cases to test all operations (data insertion, data updating, data selection and data
deletion) on all tables and views presented in the database. As we can constant, in
database testing we have at the same time black box and white box testing
technique. We use the UI on one time to launch an operation (black box) and we
explicitly opened the DBMS to verify if the operation succeeds or not (white box).
This is classified in gray box testing technique. Gray box testing is then the
combination of black and white box testing technique. What we must also test on
the database is:
o The number of tables in the database
o The number of columns per table
o The data type of each column
o The size of each column
o The columns accessible for each type of users
o The relations between tables
o Triggers
• Error handling testing: There we mostly focus on error messages. Testers verify
error messages while performing incorrect action on the application. Error
messages should be readable and easy to understand by users
• Calculations/manipulations testing: Any computation in the application must be
tested. For each calculation, a test case must be provided to test if it is well done by
the application. About manipulation testing, it is to check if after an action, the
application behave exactly as it is supposed to behave.
• Links existence and links execution testing: In this part, it is to verify exactly if links
appear where it is supposed to appear. That is about the link existence. About the
link execution, it is to test if each link helps to reach exactly to proper page or not.
About links we distinguish internal, external and broken links. Internal link means
when a user clicks on it, he should navigate in the same page but in the different
section; while for external link, is to navigate to another page and for the broken
link, is the one with any target page or section. Brokens links is normally for a
future implementation. This type of testing is especially for web application.
• Cookies and sessions testing: It is done only for web application. Cookies are the
temporary files created by browser while browsing pages through internet while
sessions are time slots created by the server and will be expired after some time.
Cookies are created at client side while sessions are created at the server side. This
testing consists of verifying the cookies and session stored in the web browser. To
ensure that, the browser only saved what it is supposed to saved and in the form
that it supposed to saved it. No more no less. In fact, it can consist of some security
breaches and it must be verified to ensure that it can’t be usable by attackers also.
For every cookie or session, we must understand very well why it is saved and
decided if saving it is compulsory for the application. If the application can work
without, it is recommended to erase it. We also test if cookies and sessions are
erased when it is supposed to be for example after closing a session, the session ID
must not be usable again.

27 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Non-functional testing
After functional testing is done, non-functional testing can start. It focuses on the
following:
• Performance testing
o Load testing
o Stress testing
o Volume testing
• Security testing
• Recovery testing
• Compatibility testing
• Configuration testing
• Installation testing
• Sanitation/Garbage testing
Performance testing
Non functional testing is not focused on functional requirements but in functional
expectations. It is done generally for web application because for desktop application, the
application speed depends on the desktop computer. In fact, if algorithms implemented
have the good complexity, the application speed will then be more related to the desktop
computer while with web application, there is another factor that can influence the speed
of the application.
Indeed, expectation is a belief about what will happen in the future or what should
happen in a particular situation in other application. It is often based on past experiences
or assumptions on the same kind of application. Expectations can be realistic or
unrealistic, and they can be influenced by a variety of factors, such as culture, and personal
beliefs. Requirement, on the other hand, is something that is necessary or mandatory. It is
a condition that must be met in order to achieve a particular goal or outcome.
Requirements can be legal, contractual, or ethical in nature. The following table helps to
point out the subtle difference that exist between expectation and requirement:

Expectation Requirement
Voluntary Mandatory
Subjective Objective
Flexible Rigid
Variable Fixed
Emotional Practical
For example, an application can fulfill all requirements but users can refuse it due to
security failure or time taking to answer a request. That means non-functional testing is
also very important to conduct on a software product or project to ensure its acceptance.

28 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Non-functional testing starts with the performance testing. In this testing phase,
we test the time consume by the application to respond. What is the speed of the
application. Performance testing can be divided in 03 testing categories: Load testing;
Stress testing; and Volume testing.
Load testing
In load testing, we are going to allow multiple users to load the application but
gradually at the same time and observe the speed of the application. Means we increasing
the load of the application slowly and then check the speed of the application. For it, we
need also the customers requirements because in that document, the number of possible
users that can be connected at the same time can be deduced. We test the load of the
application according to it to validate the application. We come out of this testing by the
number of users that can used simultaneously the application without considerably
reduce the speed of the application. This information will serve users on the field to ensure
a good functioning of the application.
Stress testing
In load testing, the load of the application is gradually increase. But in stress testing,
that load is suddenly increase or decrease. The behavior and the speed of the application
is now observed. For example, in load testing, we start by one user, then 2, 3 and so on
until 100 for example. But in stress testing, we start by 10 then 50 then 100 and then we
turn back to 1 and observe the behavior or the application.

Volume testing
That is to test how much data the application can manage. When we have a lot and
a lot of data in the application database, how the application displayed it, what is the speed
of the application in that case and how the DBMS manage it. Volume testing is to check
how much data is able to handle by the application.

Security testing
There we are going to test how our application is secure. Especially, we have to test
the authentication, the authorization or access control because all the other security
aspects are based on these 02 (confidentiality, integrity and non-repudiation).
Authentication is the process through which we verify if users are valid or not. And then
when a user is valid, does he have the authorization to do an operation? That is now the
authorization. And for each action on the system, we have an access control list or role
management that helps to know if a user has the authorization to do some operation or
not. Authorization is the process through which we verify the permission of the valid user.

Recovery testing
Recovery means if we lost something, are we able to recovery it. In recovery testing,
we are going to test if the application has recovery feature. Is it possible or in which

29 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

condition is it possible to recovery data after loosing it? When the system shutdown
suddenly or something get bad, how the application behaves?

Compatibility testing
The aims of the compatibility testing are to check the environment with which the
application is compatible. We have at least 03 aspects of combability which are: Forward
compatibility; Backward compatibility; and hardware compatibility.
Forward compatibility or upward compatibility means, for 02 versions of the same
software, the newly or the latest version can normally accept an input of the oldest
version. In fact, every thing that work on the oldest version should also work on the newly
version.
Backward compatibility means, if we upgrade the software, the newly version
remains compatible with the current environment on which the last version was working.
About hardware compatibility, is to test if the software will be installed and
working normally on multiple hardware environment. As hardware environment, we talk
about the operating systems (Linux, windows, etc.) and also the amount of RAM, the
processor speed, etc. Hardware compatibility is also called configuration testing. From the
hardware compatibility, we have the minimum hardware characteristics needed to
normally execute the software.

Installation testing
In installation testing, we have to test the installation process define. We verify if
the installation process defines executed step by step as define help normally to install the
software. It is also to decide if that process should be changed or not. We have to change
it if that process is complicated to follow by an end user. Also in installation testing, we
have to test the uninstalling process.

Sanitation/ garbage testing

This testing is a testing that help to ensure that only the requirements asked by
customer are presented in the software produce. If any other functionality is present, that
must be removed before put the software in production. That means we ensure that a
software has only the functionality that is supposed to have through the sanitation of
garbage testing. In fact, if any application provides extra functionalities or features, it is
considered as a bug/defect and it should be removed.

30 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Functional testing vs non-functional testing

31 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Chap5: Some other software testing terminology

In software testing domain, they are some other terms that is used and must be well
understood when we want to work. Among those terms we have:
• Regression testing
• Re-testing
• Smoke & sanity testing
• Exploratory testing
• Adhoc testing
• Monkey testing
• Positive & negative testing
• End-to-End testing
• Globalization/Localization testing
• Etc.

Regression testing
Regression testing is the testing conducts on modified build to make sure there will
not be impact on existing functionality because of changes like
adding/deleting/modifying features. In fact, during testing, when a defect is discovered in
a module, fixing that bug can be the source of another bug in the same module or in some
other dependent modules. That is why after any bug correction or when a functionality is
added or remove or even modify in a software, the regression testing must be conducted
to ensure that the software continue to work normally as before the operation. So, existing
functionalities should no be broken because of bug fixing of added or removed
functionalities. It can be done in 03 different levels: Unit regression testing; Regional
regression testing; and Full regression testing.
Unit regression testing means testing only the changes/modifications done by the
developer during fixing bugs or adding/removing a functionality. That means in a
software, when a bug is reported in a module, after fixing that bug, only the modify module
is tested. All test plan for that module must be executed again.
Regional regression testing means testing the modified module along with the
impacted modules or dependent module. A meeting called Impact analysis meeting must
be conducts to identify impacted modules with QA & dev team. In fact, bug fixing,
functionality added or removed can impact some dependent functionalities. In front of a
bug or a functionality to add or remove, the QA & dev team must identify all the impacted
modules. All those modules after the unit regression testing must also be tested in the
phase called regional regression testing.
After the regional regression testing, full regression testing must now be
conducted. Full regression testing is testing the main feature & remaining part of the
application. It is done normally when multiple modules of the application have been
modified. So, when development team has done changes in many modules, instead of
identifying impacted modules, we perform one round of full regression testing.

32 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Re-testing
Re-testing mean test again, a functionality after some bug fixing to ensure that the
reporting bugs have been fixed normally. In fact, when testers discover a bug a report it to
the developer team, they will correct that bug and release a corrected build for the module
or the application. The modifying module should be test again to confirm the correction
of the reported bug. So, whenever the developer fixed a bug, tester will test the bug fix is
called Re-testing. Tester closes the big if it worked otherwise re-open and send to
developer. Then re-testing is to ensure that the defects which were found and posted in
the earlier build were fixed or not in the current build. It is different than unit regression
testing in the fact that, in the case of the unit regression testing, is the entire module in
which the bug has been reported that going to be test again not only the reported bug. So,
re-testing comes before the unit regression testing. Only the test case that helps to
discover the bug going to be executed again in the new release.
Example:
• Build 1.0 was released. Test team found some defects (defect Id 1.0.1, 1.0.2) and
posted
• Build 1.1 was released, now testing the defects 1.0.1 and 1.0.2 in this build is re-
testing.

Smoke & Sanity testing

This testing come into the picture after build release. The following table will explain what
they are and also help to differentiate.
Smoke testing Sanity testing
Smoke test is done to make sure the build Sanity test is done during the release to
we received from the development team is check for the main functionalities of the
testable/stable or not. Is it installable or application without going deeper. For
nor; the navigation is going or not; the example, login is working or not?
home page appears normally or not. So, we
don’t need any specific test case to do it. In
fact, the detailed test will be done after. A
build is stable when all those questions
can be answered yes.
Smoke testing is performed by both Sanity testing is performed by testers
developers and testers alone
During smoke testing build may be either During sanity testing, build is relatively
stable or unstable stable
Smoke testing is done on initial builds Sanity testing is done on all stable builds
Smoke testing is then a part of basic testing Sanity testing is a part of regression testing
Usually, smoke testing is done every time Sanity testing is planned when there is no
there is a new build release enough time to do in-depth testing
Indeed, when developers release a build, smoke testing is realized and then sanity
testing. When the 02 testing is successfully done, the remaining test can now continue.
This happens from system testing to UAT. In fact, all those tests are realized on a release
build of the software. The following figure explain what happens for every build during
the development process:

33 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Exploratory testing
To understand the exploratory testing, imagine that we are in the case where we
have already an application without any document. No design document, no requirement,
etc. We have to test the application by exploring to discover its functionalities. Exploratory
testing is the type or test that helps to discover the functionalities of an application. As
explained, we have to explore the application, understand it completely, identify all
possible scenario, document it and then use all those information to applied another test.
This process happens generally when you join a new company and there you have
a software which is already develop but without any document. We have some problems
that must be notice for this kind of testing:
• You might misunderstand any feature as a bug or any bug as a feature since you do
not have requirement

34 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

• Exploratory testing can be time consuming always because of requirements

missing
• If there is any bug in the application, you will never know about it

Adhoc testing
Like exploratory testing, this happens when we don’t have any document about a
software but we have already a build for the software. But in the case of adhoc testing, we
take in consideration the experience of the testers. They need to have some experience
about the same kind of application. Based on that experience, testers can test randomly
the application without any test cases based on assuming requirements for the software
but with the aim to break the system. Is an informal testing type and an unplanned activity.

Monkey/Gorilla testing
It is exactly like adhoc testing but with gorilla testing, testers don’t have any
experience about the application. Testers can’t then assume requirements for application.
It is suitable for gaming application. It is like a child which in front of a new game. He tests
the application randomly to discover all functionalities without any experience about.

Adhoc vs Monkey vs Exploratory testing

Adhoc testing Monkey testing Exploratory testing

No documentation No documentation No documentation
No plan No plan No plan
Informal testing Informal testing Informal testing
Testers should have Testers doesn’t have any Testers doesn’t have any
experience about such experience about such experience about such
application functionalities application functionalities application functionalities
Random testing Random testing Random testing
Intension is to break the Intension is to break the Intension is to discover the
application application functionalities of the
application
Suitable for any application Suitable for gaming Suitable for any application
application which is new for testers

Positive/negative testing
Testing the application with valid inputs is called positive testing. It checks whether
the application behave as expected with positive inputs. For example, consider a test box
in which the application only expects numbers. If we test now that text box by providing
number, it is a positive test and the text box should allow it.
In the other hand, testing the application with invalid input is a negative testing. It
also checks if the application behaves as expected with negative input. In the last example

35 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

used for positive testing, negative testing happens when we test the text box with
characters. Characters is an invalid input in this case and with it the text box should not
allow it and throw an error message according to requirements.
Examples of positive and negative test cases:
Suppose we have the following requirements: A text box should accept only alphabets and
6-20 characters.
Positive test cases:
• Textbox accepts 6 characters
• Textbox accepts up to 20 chars’ lengths
• Textbox accepts any value in between 6-20 chars’ length
• Textbox accepts all alphabets
Negative test cases:
• Textbox should not accept less than 6 chars
• Textbox should not accept more than 20 chars
• Textbox should not accept special characters
• Textbox should not accept numerical
For all those tests cases, the answer should be “YES” even for negative test cases.

End-to-End testing
Is the process of testing the overall functionalities of the system including the data
integration among all modules. In fact, to achieve an end-to-end testing, the test case
should be designed such that all modules (or must of them) should be tested in one flow
from the base module to an end module. In end-to-end testing, all road from the base
module to all end module should be tested. For example

Globalization/Localization testing or internationalization (i18N) testing

Globalization testing is performed to ensure that the system or software
application can run and is adapted in any cultural or local environment. In this testing,
different aspects of the software application are tested to ensure that it supports every
language and different attributes. It tests if the different currency formats, mobile number
formats and address formats are supported by the application. For example,

36 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

“[Link]” supports many of the languages and it can be accessed by people of

different countries. Hence it is globalized product.
Localization testing is performed to check if a system or software application can
run and is adapted for a specific geographical and cultural environment. Localized product
only supports the specific kind of language and is usable only in specific region. It testes if
the specific currency format, mobile number format and address format is working
properly or not.

37 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Chap6: Test design techniques and STLC (Software Testing Life Cycle)
Test design techniques
Test design techniques will be used to prepare the test data. Test data are data use
during the testing process. Those data should be selected such to ensure the coverage of
all using scenarios (each and every area) of the application. Data should be selected such
that all combination are present. With test design techniques, we reduce the number of
test cases to be executed but increase the coverage. To achieve this goal, we can use the
following design techniques:
• Equivalence Class Partitioning (ECP)
• Boundary Values Analysis (BVA)
• Decision Table
• State transition
• Error Guessing
Equivalence Class Partitioning (ECP)
It consists of partition data into various classes and select test data according to class. It
reduces the number of test-cases and help to save a lot of time during testing. Consider
the example shown in the following figure:

The normal set of valid input are from 1 to 500. Before 1 we must also test an ensure that
the value will be refused also for values above 500. This allows us to divide test data into
03 classes at least:
• Value before 1 (negative value up to 0) which are invalid data for example: -50
• Value between 1 and 500 which are valid data for example: 30; 160; 250; 320 etc.
• Value above 500 (positive value) which are also invalid data for example: 550
In each class, we can just choose randomly one value and use that value to test but we
are sure that, with the resulting 03 values all possible class of data will be cover. Then for
this case we come out with the following test data: -50; 30; 160; 250; 320; 550 but we can
even just used -50; 250 and 550 to ensure the coverage of all possible test data.
Consider the following another example:

In this case, valid data are characters from A..Z, a..z only. To ensure the coverage and well
test the text box, we are going to divide all possible test data into the following classes:
Equivalence class Test data using ECP
A..Z (valid) XYZ
a..z (valid) zyz
Special characters (invalid) @#$%
Spaces (invalid) Xy Z

38 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

Numbers 1234
Boundary value analysis (BVA)
This technique is used to check boundaries of the input. Then only boundaries values will
be chosen as test data. For example, consider the following example:

Remark: ECP and BVA are techniques used to prepare test data in “input domain testing”.
Input domain testing is testing domain in which value enters in input text box or input
fields will be verified.
Decision table
It is also called “Cause-Effect table”. It is a technique used if we have more
conditions and corresponding actions. In some scenarios, we have to verify a lot of
condition. Test data should be prepared such to test all the conditions and cover all the
corresponding actions. In decision table technique, we deal with combinations of inputs.
Example: let us take an example of transferring money online to an account which is
already added and approved. The conditions to transfer money are:
• Account already approved
• One time password (OTP) matched
• Sufficient money in the account
And the actions performed are:
• Transfer money
• Show a message as insufficient amount
• Block the transaction in case of suspicious transaction
For this example, we can build the following table:

39 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

In the table, we have all conditions and all possible actions. Now, we can now add a column
for each possible action. And each of those added column is a “test case”. For example:
• For “TC1” (Test Case 1), is for the case where condition1, condition2 and
condition3 are all verified (TRUE). In that case, normally “action1” must be
executed.
• For “TC2” is for the case where condition1 and 2 are verified (TRUE) but condition3
is not verified (FALSE). In that case “action2” must be executed.
• With 03 conditions, because each one have only 02 possible state (true or false) we
have 2^3 = 8 possibles combinations:
C1 C2 C3 Action required
1 1 1 Action1
1 1 0 Action2
1 0 1 Action3
1 0 0 Action3
0 1 1 X
0 1 0 X
0 0 1 X
0 0 0 X
X
Now for each combination, what is the corresponding action required.
By consider the Boolean result of each condition, we can build test case that going to
test all conditions and cover all action provided. With this technique, we are going to
obtain the minimum number of test cases that going to ensure the overall coverage of the
requirement.

State transition
State transition technique is used for input that the conditions change the state of the
application. 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 behavior.
For example, consider the following requirement: If the user fails to connect 03
time consecutively, the system should block the account and display a message to invite

40 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

the user to consult the administrator. In that case we can consider 05 states (S1, S2, S3, S4
and S5) for the application:
• S1 the state in which the system (or the login module) is when the first attempt is
tested. The first couple of value (username and password) is entering for
connection.
• S2 the state in which the system (or the login module) is when the second attempt
is tested.
• S3 the state in which the system (or the login module) is when the third attempt is
tested.
• S4 the state of the system when an attempt of value succeeds.
• S5 the state of the system when the targeted account is blocked
As we can see, from requirements, we can move from S1 to S2; from S1 to S4; from S2 to
S3; from S2 to S4; from S3 to S5 and from S3 to S5. All possible transitions according to
requirements are then present. Wr can drow the following state transition diagram:

From the state transition diagram, the table beside can also the draw to illustrate
it. We prepare now test data for each possible transition in the state transition diagram.
For our example, we need at least 06 test data to ensure the overall coverage of the code
and then test the requirements.

Error Guessing
Error Guessing technique is one of the testing techniques used to find bugs in a
software application based on testers prior experience. In this technique, we don’t follow
any specific rules. It depends on tester analytical skills and experience. Some examples
are:
• Submitting a form without entering values

41 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

• Entering invalid values such as entering alphabets in the numeric field.

All test cases of this type depend on the tester’s experience. They think about
combinations of input that generally produce a bug for application of the same kind.

STLC (Software Testing Life Cycle)

We know that SDLC talk about all the software development process. Here, we are
going to talk about STLC which means Software Testing Life Cycle. SDLC divide the
development of a software in the following phases: requirement analysis; design; coding;
testing; deployment and maintenance. STLC is also divide in some step but applied during
the testing phase of the SDLC process. That means STLC is a part of SDLC. The step or
phase in STLC are:
• Requirement analysis
• Test planning
• Test case design or development
• Environment setup
• Test execution
• Defect/bug reporting and tracking
• Test closure.

These are in order the different step that STLC suggest to follow during the testing
phase in SDLC. As we discuss about each phase in SDLC we are going also to discuss about
each phase of STLC to make every thing clear.
Requirement analysis
Testers must in that phase understand functionalities of the application. This is also
the first phase in SDLC and that explain why, when possible, testers should also work on
that phase with developers but in 02 different team such to compare the 02 reports

42 | P a g e
 AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

produce at the end and then be sure of what is needed by customers. This increase the
chance to reduce any ambiguity on what is really needed by end users.

Test planning
Before any action of testers, they need to have a plan. In test planning, we have to answer
to 03 main questions that also involve activity that will be done. These questions are in
order:
• What to test: Which scenario are we going to test? What are test data?
• How to test: Are we going to use a tool to automatize the test? If yes which one and
why?
• When to test: Is to define the order in which all test scenario going to be executed.
To start the test planning, we need 02 documents: Project plan and functional
requirements.
Project plan is the document prepared by the project manager (PM). Is a very high
document which include the time line so when exactly the customer requirement is
approved, when the application must be deliver, the budget, the environment constraint
in which the application should be used etc. With all those information we can decide now
what to test, how to test and when to test. That is why this document is important for test
planning.
About Functional requirements, it is important to define all scenario that will be used
to test each requirement. This document is used to answer the question “what to test”. The
answer of this question is the set of all scenario that will be tested for each requirement.
For each of those scenarios, test data will be then defined through test design technique
to ensure the coverage with a minimum set of data.
In conclusion about test planning, we have as input the project plan which contains
all information to conclude how to test and when to test. Now, functional requirement will
help to know what to test. This phase of test planning must be done by very experiment
testers and at the management level. Activities done in order in test planning phase are:

• Identify resources
• Team formation
• Test estimation
• Preparation of test plan
• Reviews on test plan
• Test plan sign-off
In the activity of identifying resources, hardware and software resources that will be used
for testing will be decided.

43 | P a g e
AZOBOU KIADJEU CEDRIC SOFTWARE TESTING NOTE 2024

44 | P a g e