Software Testing Introduction

What is testing? Testing is the process of evaluating a system or its component(s) with the intent to find
that whether it satisfies the specified requirements or not. This activity results in the actual, expected and
difference between their results. In simple words testing is executing a system in order to identify any gaps,
errors or missing requirements in contrary to the actual desire or requirements
Software Testing is a method to assess the functionality of the software program. The process
checks whether the actual software matches the expected requirements and ensures the software is bug-
free. The purpose of software testing is to identify the errors, faults, or missing requirements in contrast to
actual requirements. It mainly aims at measuring the specification, functionality, and performance of a
software program or application. Software Testing is a method to assess the functionality of the software
program. The process checks whether the actual software matches the expected requirements and ensures
the software is bug-free. The purpose of software testing is to identify the errors, faults, or missing
requirements in contrast to actual requirements. It mainly aims at measuring the specification,
functionality, and performance of a software program or application.

Attributes of Software testing

Testability
Improved testability can make the testing process more efficient and cost-effective.
Communication
Software testers should have strong verbal and written communication skills to
communicate with programmers, test managers, and customers.
Portability
Software portability should be considered during the development phase. There should be a
clear abstraction between business logic and system interfaces.
Usability
How easily users can interact with the software to accomplish their tasks.
Maintainability
How efficiently the software can be modified to improve it or adapt it to changes in the
environment.
Security
The system's ability to prevent illegal entry and data breaches.

Software Testing
Efficiency
An inefficient application might consume excessive resources that slow down other applications
or the system.
Reliability
Users should be able to access the system at any time.
Performance
The system should be able to withstand a certain number of active users

Purpose of Software Testing

The purpose of the Software Testing is to ensure that the software product is Bug-Free and to enhance
the software quality.
The purpose of software testing is to ensure that a software product meets its intended purpose and
functions as expected:
 Detecting defects
Software testing uncovers bugs and defects early in the development process, when they are less
expensive to fix.
 Improving quality
Software testing helps to ensure that the software is of high quality and meets user
requirements.
 Enhancing user experience
Software testing helps to identify usability issues and ensure that the software is intuitive and
meets user expectations.
 Reducing risk
Software testing helps to identify and mitigate potential risks associated with the software, such
as system failures and data breaches.
 Complying with standards
Software testing ensures that the software adheres to industry standards, regulations, and other
critical compliance requirements. Software testing is most effective when it is continuous,
starting during the design phase and continuing throughout the development and deployment
process.

Software Testing
Goals of Software Testing

The main goal of software testing is to find bugs as early as possible and fix bugs and make sure that the
software is bug-free.

Important Goals of Software Testing:

 Detecting bugs as soon as feasible in any situation.
 Avoiding errors in a project’s and product’s final versions.
 Inspect to see whether the customer requirements criterion has been satisfied.
 Last but not least, the primary purpose of testing is to gauge the project and product level of quality.

The goals of software testing may be classified into three major categories as follows:
1. Immediate Goals
2. Long-term Goals
3. Post-Implementation Goals

Immediate Goals: 1. Bug Discovery

2.Bug Prevention

Long Term Goals: 1.Quality

2. Customer satisfaction
3. Reliability
Software Testing 4.Risk Management

Post-Implemented Goals:

1. Reduce Maintenance
2. Improved Software Testing Process

Software Testing
1. Immediate Goals:
These objectives are the direct outcomes of testing. These objectives may be set at any time
during the SDLC process. Some of these are covered in detail below:
 Bug Discovery: This is the immediate goal of software testing to find errors at any stage of
software development. The number of bugs is discovered in the early stage of testing. The primary
purpose of software testing is to detect flaws at any step of the development process. The higher
the number of issues detected at an early stage, the higher the software testing success rate.

 Bug Prevention: This is the immediate action of bug discovery, that occurs as a result of bug
discovery. Everyone in the software development team learns how to code from the behavior and
analysis of issues detected, ensuring that bugs are not duplicated in subsequent phases or future
projects.

2. Long-Term Goals: These objectives have an impact on product quality in the long run after one
cycle of the SDLC is completed. Some of these are covered in detail below:

 Quality: This goal enhances the quality of the software product. Because software is also a
product, the user’s priority is its quality. Superior quality is ensured by thorough testing.
Correctness, integrity, efficiency, and reliability are all aspects that influence quality. To attain
quality, you must achieve all of the above-mentioned quality characteristics.

 Customer Satisfaction: This goal verifies the customer’s satisfaction with a developed software
product. The primary purpose of software testing, from the user’s standpoint, is customer
satisfaction. Testing should be extensive and thorough if we want the client and customer to be
happy with the software product.

 Reliability: It is a matter of confidence that the software will not fail. In short, reliability means
gaining the confidence of the customers by providing them with a quality product.

Software Testing
 Risk Management: Risk is the probability of occurrence of uncertain events in the organization
and the potential loss that could result in negative consequences. Risk management must be done to
reduce the failure of the product and to manage risk in different situations.
3. Post-Implemented Goals: After the product is released, these objectives become critical. Some of
these are covered in detail below:

 Reduce Maintenance Cost: Post-released errors are costlier to fix and difficult to identify.
Because effective software does not wear out, the maintenance cost of any software product is not
the same as the physical cost. The failure of a software product due to faults is the only expense of
maintenance. Because they are difficult to discover, post-release mistakes always cost more to
rectify. As a result, if testing is done thoroughly and effectively, the risk of failure is lowered, and
maintenance costs are reduced as a result.

 Improved Software Testing Process: These goals improve the testing process for future use or
software projects. These goals are known as post-implementation goals. A project’s testing
procedure may not be completely successful, and there may be room for improvement. As a result,
the bug history and post-implementation results can be evaluated to identify stumbling blocks in
the current testing process that can be avoided in future projects.

Productivity and quality in software

In software testing, productivity is a measure of how efficiently resources are used to produce
software, while quality is a measure of how well the software meets the needs of the user:
Productivity
The ratio of the functional value of the software to the labor and expense required
to produce it. Productivity is dependent on the effective use of human resources, and can be improved
by reusing code, minimizing rework, and following best practices.
Quality
A high-quality product is one that meets the needs of the user. In software testing,
quality is determined by how well the tests contribute to improving the product. Testers should design
tests that provide meaningful insights into the software's capabilities and limitations.
Some metrics used to measure software testing quality include: Number of tests
run per unit of time, Test design efficiency, Test review efficiency, and Number of bugs per test.

Software Testing
 Productivity and quality are directly related, so increasing quality will also
increase productivity.
Factors of Productivity and Quality software
 Quality assurance
 Risk Management
 Software quality factors
 Effective Management
 Team Communication
 Clear goal settings
 Access to resource
 Employee Motivation
 Support work Environment
Software quality factors:
These include integrity, reliability, usability, accuracy, efficiency, maintainability,
testability, flexibility, interface facility, re-usability, and transferability.
Effective management:
Effective management helps with controlling resources, meeting customer needs,
ensuring on-time delivery, and properly planning, monitoring, and communicating about projects.
Team communication:
Effective communication is important for productivity.

Clear goal-setting:
Clear goal-setting is important for productivity.
Access to resources:
Access to necessary resources is important for productivity.
Employee motivation:
Employee motivation is important for productivity.
Supportive work environment:
A supportive work environment is important for productivity.
Some ways to improve software productivity include:
 Reusing code
 Minimizing rework
 Adopting sound development practices and standards

Software Testing
  Focusing on key aspects of process improvement
 Reducing the need to develop new software
 Integrating specification, design, and implementation

Here are some ways to measure software productivity:

 Size-related metrics
These metrics indicate the size of the outcome, such as the number of lines of code written.
 Function-related metrics
These metrics indicate the amount of useful functionality delivered in a given time period. Function
points and application points are commonly used for waterfall software development, while story
points are commonly used for agile projects.
Here are some ways to improve software productivity:
 Reuse code to take advantage of existing programs
 Minimize rework through reliability initiatives
 Adopt sound development practices and standards
Here are some ways to improve software quality:
 Follow quality control (QC) methods to detect and remove defective devices
 Follow quality assurance methods to ensure that the organization's processes are followed properly
 Follow total quality management (TQM) methods to continuously improve the organization's procedures

Software Quality
Software quality product is defined in term of its fitness of purpose. That is, a quality product does
precisely what the users want it to do. For software products, the fitness of use is generally explained in
terms of satisfaction of the requirements laid down in the SRS document. Although "fitness of purpose"
is a satisfactory interpretation of quality for many devices such as a car, a table fan, a grinding machine,
etc.for software products, "fitness of purpose" is not a wholly satisfactory definition of quality.
Example: Consider a functionally correct software product. That is, it performs all tasks as specified in
the SRS document. But, has an almost unusable user interface. Even though it may be functionally right,
we cannot consider it to be a quality product.
The modern view of a quality associated with a software product several quality methods such as
the following:
Portability: A software device is said to be portable, if it can be freely made to work in various
operating system environments, in multiple machines, with other software products, etc.

Software Testing
Usability: A software product has better usability if various categories of users can easily invoke the
functions of the product.
Reusability: A software product has excellent reusability if different modules of the product can quickly
be reused to develop new products.
Correctness: A software product is correct if various requirements as specified in the SRS document
have been correctly implemented.
Maintainability: A software product is maintainable if bugs can be easily corrected as and when they
show up, new tasks can be easily added to the product, and the functionalities of the product can be
easily modified, etc.

Software Quality Management System

A quality management system is the principal methods used by organizations to provide that the
products they develop have the desired quality.
A quality system subsists of the following:
Managerial Structure and Individual Responsibilities: A quality system is the responsibility of the
organization as a whole. However, every organization has a sever quality department to perform various
quality system activities. The quality system of an arrangement should have the support of the top
management. Without help for the quality system at a high level in a company, some members of staff
will take the quality system seriously.
Quality System Activities: The quality system activities encompass the following:
 Auditing of projects
 Review of the quality system
 Development of standards, methods, and guidelines, etc.
 Production of documents for the top management summarizing the effectiveness of the quality
system in the organization.
Evolution of Quality Management System
Quality systems have increasingly evolved over the last five decades. Before World War II, the usual
function to produce quality products was to inspect the finished products to remove defective devices.
Since that time, quality systems of organizations have undergone through four steps of evolution, as
shown in the fig. The first product inspection task gave method to quality control (QC).
Quality control target not only on detecting the defective devices and removes them but also on
determining the causes behind the defects. Thus, quality control aims at correcting the reasons for bugs

Software Testing
and not just rejecting the products. The next breakthrough in quality methods was the development of
quality assurance methods.
The primary premise of modern quality assurance is that if an organization's processes are proper and
are followed rigorously, then the products are obligated to be of good quality. The new quality functions
include guidance for recognizing, defining, analyzing, and improving the production process.
Total quality management (TQM) advocates that the procedure followed by an organization must be
continuously improved through process measurements. TQM goes stages further than quality assurance
and aims at frequently process improvement. TQM goes beyond documenting steps to optimizing them
through a redesign. A term linked to TQM is Business Process Reengineering (BPR).
BPR aims at reengineering the method business is carried out in an organization. From the above
conversation, it can be stated that over the years, the quality paradigm has changed from product
assurance to process assurance, as shown in fig.

Phases in a Tester’s Mental Life:

PHASE 0—There’s no difference between testing and debugging. Other than in support of
debugging, testing has no purpose.

PHASE 1—The purpose of testing is to show that the software works.

Software Testing
PHASE 2—The purpose of testing is to show that the software doesn’t work.

PHASE 3—The purpose of testing is not to prove anything, but to reduce the perceived risk
of not working to an acceptable value.

PHASE 4—Testing is not an act. It is a mental discipline that results in low-risk software
without much testing effort.

Phase 0 Thinking:

I called the inability to distinguish between testing and debugging “phase 0” because it denies
that testing matters, which is why I denied it the grace of a number. See Section 2.1 in this chapter for
the difference between testing and debugging. If phase 0 thinking dominates an organization, then there
can be no effective testing, no quality assurance, and no quality. Phase 0 thinking was the norm in the
early days of software development and dominated the scene until the early 1970s, when testing
emerged as a discipline.

Phase 0 thinking was appropriate to an environment characterized by expensive and scarce

computing resources, low-cost (relative to hardware) software, lone programmers, small projects,
and throwaway software. Today, this kind of thinking is the greatest cultural barrier to good testing and
quality software. But phase 0 thinking is a problem for testers and developers today because many
software managers learned and practiced programming when this mode was the norm—and it’s hard to
change how you think.
Phase 1 Thinking-The Software Works
Phase I thinking represented progress because it recognized the distinction between testing and
debugging. This thinking dominated the leading edge of testing until the late 1970s when its fallacy was
discovered. This recognition is attributed to Myers (MYER79) who observed that it is self-corrupting. It
only takes one failed test to show that software doesn’t work, but even an infinite number of tests won’t
prove that it does. The objective of phase 1 thinking is unachievable. The process is corrupted because
the probability of showing that the software works decreases as testing increases; that is, the more you
test, the likelier you are to find a bug. Therefore, if your objective is to demonstrate a high probability of

Software Testing
working, that objective is best achieved by not testing at all! Although this conclusion may seem silly to
the conscious, rational mind, it is the kind of syllogism that our unconscious mind loves to implement.
Phase 2 Thinking-The Software Doesn’t Work:
When, as testers, we shift our goal to phase 2 thinking we are no longer working in cahoots
with the designers, but against them. The difference between phase 1 and 2 thinking is illustrated by
analogy to the difference between bookkeepers and auditors. The book keeper’s goal is to show that the
books balance, but the auditor’s goal is to show that despite the appearance of balance, the bookkeeper
has embezzled. Phase 2 thinking leads to strong, revealing tests.
While one failed test satisfies the phase 2 goal, phase 2 thinking also has limits. The test reveals
a bug, the programmer corrects it, the test designer designs and executes another test intended to
demonstrate another bug. Phase 2 thinking leads to a never-ending sequence of ever more diabolical
tests. Taken to extremes, it too never ends, and the result is reliable software that never gets shipped.
The trouble with phase 2 thinking is that we don’t know when to stop.
Phase 3 Thinking-Test for Risk Reduction:
Phase 3 thinking is nothing more than accepting the principles of statistical quality control. I say
“accepting” rather than “implementing” because it’s not obvious how statistical quality control should
be applied to software. To the extent that testing catches bugs and to the extent that those bugs are fixed,
testing does improve the product. If a test is passed, then the product’s quality does not change, but our
perception of that quality does. Testing, pass or fail, reduces our perception of risk about a software
product. The more we test, the more we test with harsh tests, the more confidence we have in the
product. We’ll risk release when that confidence is high enough.
Phase 4 Thinking-A State of Mind:
The phase 4 thinker’s knowledge of what testing can and can’t do, combined with knowing what
makes software testable, results in software that doesn’t need much testing to achieve the lower-phase
goals. Testability is the goal for two reasons. The first and obvious reason is that we want to reduce the
labor of testing. The second and more important reason is that testable code has fewer bugs than code
that’s hard to test. The impact on productivity of these two factors working together is multiplicative.
What makes code testable? One of the main reasons to learn test techniques is to answer that question.
Cumulative Goals:
The above goals are cumulative. Debugging depends on testing as a tool for probing
hypothesized causes of symptoms. There are many ways to break software that have nothing to do with
the software’s functional requirements: phase 2 tests alone might never show that the software does
what it’s supposed to do. It’s impractical to break software until the easy demonstrations of workability

Software Testing
 are behind you. Use of statistical methods as a guide to test design, as a means to achieve good testing at
acceptable risks, is a way of fine-tuning the process. It should be applied only to large, robust products
with few bugs. Finally, a state of mind isn’t enough: even the most testable software must be debugged,
must work, and must be hard to break.
Software testing methods
 Manual, automated, and continuous testing
Manual testing is hands-on and requires human observation, while automated testing uses scripts and
tools to automate the process. Continuous testing combines automated testing with a scaled approach to
achieve reliable test coverage.
 White-box, black-box, and grey-box testing
These approaches describe the tester's point of view when designing test cases. White-box testing
provides access to the source code, while black-box testing only tests the user interface. Grey-box
testing combines aspects of both approaches, providing access to design documents and the database.
 Code analysis tools
Tools like PyCharm, Checkstyle, and SourceMeter can help identify issues in the code.
 Static analysis techniques
These techniques include data flow analysis, control flow analysis, and cyclomatic complexity.
 Load, stress, endurance, and spike testing
These types of load testing evaluate how a software system responds to different types of demand:
 Load testing: Tests how a system performs under real-world load conditions.
 Stress testing: Tests how a system responds to realistic and unrealistic load scenarios, with the goal of
overloading the system until it breaks.
 Endurance testing: Also known as soak testing, this technique analyzes how a system behaves under a
sustained load over a longer period of time.
 Spike testing: A type of load test that determines how a system responds to large bursts of concurrent
activity.
Testing Vs Debugging
What is Testing?
Testing is the process of verifying and validating that a software or application is bug-free, meets the
technical requirements as guided by its design and development, and meets the user requirements
effectively and efficiently by handling all the exceptional and boundary cases. The purpose of
software testing is to identify the errors, faults, or missing requirements in contrast to actual
requirements.
What is Debugging?
Debugging is the process of fixing a bug in the software. It can be defined as identifying, analyzing,
and removing errors. This activity begins after the software fails to execute properly and concludes by
Software Testing
solving the problem and successfully testing the software. It is considered to be an extremely complex
and tedious task because errors need to be resolved at all stages of debugging.

Testing Debugging
Aspects

Testing is the process to find bugs Debugging is the process of correcting the
and errors. bugs found during testing.
Definition

The purpose of testing is to identify

The purpose of debugging is to fix those
defects or errors in the software
defects or errors.
Purpose system

It is the process to identify the failure It is the process to give absolution to code
of implemented code. failure.
Focus

Timing Testing is done before debugging Debugging is done after testing

Debugging involves analyzing the

Testing involves executing the
symptoms of a problem and identifying
software system with test cases
Approach the root cause of the problem

Debugging typically involves using tools

Testing can involve using automated
Tools and and techniques such as logging, tracing,
or manual testing tools
Technique and code inspection.

Testing is the display of errors. Debugging is a deductive process.

Methodology

Debugging is done by either programmer

Testing is done by the tester.
or the developer.
Team Involve

There is no need of design knowledge Debugging can’t be done without proper

Design in the testing process. design knowledge.
Knowledge

Testing can be done by insiders as Debugging is done only by insiders. An

well as outsiders. outsider can’t do debugging.
Access

It is based on different testing levels Debugging is based on different types of

Categorization bugs.
i.e. unit testing, integration testing,
Basic

Software Testing
 Testing Debugging
Aspects

system testing, etc.

Debugging is not an aspect of the

Testing is a stage of the software
software development life cycle, it occurs
development life cycle (SDLC).
as a consequence of testing.
SDLC

Debugging process seeks to match

Testing is composed of the validation
symptoms with cause, by that it leads to
and verification of software.
error correction.
Process Nature

Testing is initiated after the code is Debugging commences with the

written. execution of a test case.
Initiation

Models of Testing
Testing is an integral part of the software development life cycle. Various models or approaches
are used in the software development process, and each model has its own advantages and
disadvantages. Choosing a particular model depends on the project deliverables and the complexity of
the project.
What Are Software Testing Models?
Software testing models are systematic approaches used to plan, design, execute, and manage testing
activities. They provide guidelines for carrying out testing processes effectively and ensure
comprehensive test coverage.
Each model offers distinct advantages and is chosen based on the specific requirements of the project
and the organization’s preferences. Understanding these models is crucial for selecting the most suitable
approach for software testing in a given scenario.
Now let us go through the various software testing models and their benefits:
1. Waterfall Model
This is the most basic software development life cycle process, which is broadly followed in the
industry. Here, the developers follow a sequence of processes where the processes flow progressively
downward towards the ultimate goal. It is like a waterfall where there are a number of phases.

Software Testing
These phases each have their own unique functions and goals. There are, in fact, four phases:
requirement gathering and analysis phase, software design, programmed implementation and testing,
and maintenance. All these four phases come one after another in the given order.

In the first phase, all the possible system requirements for developing a particular software are noted and
analyzed. This, in turn, depends on the software requirement specifications, which include detailed
information about the expectations of the end user. Based on this, a requirement specification.
A document is created that acts as input to the next phase, i.e., the software design phase. What needs to
be emphasized here is that once you move into the next phase, it won’t be possible to update the
requirements. So you must be very thorough and careful about the end-user requirements.
Advantages
 Easy to implement and maintain.
 The initial phase of rigorous scrutiny of requirements and systems helps save time later in the
developmental phase
 The requirement for resources is minimal, and testing is done after the completion of each phase.
Disadvantages
 It is not possible to alter or update the requirements
 You cannot make changes once you are in the next phase.
 You cannot start the next phase until the previous phase is completed
2. V Model
This model is widely recognized as superior to the waterfall model. Here, the development and
test execution activities are carried out side by side in a downhill and uphill shape. In this model, testing
starts at the unit level and spreads toward integration of the entire system.

Software Testing
So, SDLC is divided into five phases – unit testing, integration testing, regression testing, system testing,
and acceptance testing.

Advantages
 It is easy to use the model since testing activities like planning and test design are done before
coding
 Saves time and enhances the chances of success.
 Defects are mostly found at an early stage, and the downward flow of defects is generally
avoided
Disadvantages
 It is a rigid model
 Early prototypes of the product are not available since the software is developed during the
implementation phase
 If there are changes in the midway, then the test document needs to be updated
3. Agile model
In this SDLC model, requirements and solutions evolve through collaboration between various
cross-functional teams. This is known as an iterative and incremental model.
Advantages
 Ensure customer satisfaction with the rapid and continuous development of deliverables.
 It is a flexible model as customers, developers, and testers continuously interact with each other
 Working software can be developed quickly, and products can be adapted to changing
requirements regularly

Software Testing
Disadvantages
 In large and complex software development cases, it becomes difficult to assess the effort
required at the beginning of the cycle
 Due to continuous interaction with the customer, the project can go off track if the customer is
not clear about the goals
4. Spiral model
It is more like the Agile model, but with more emphasis on risk analysis. It has four phases:
planning, risk analysis, engineering, and evaluation. Here, the gathering of requirements and risk
assessment is done at the base level, and every upper spiral builds on it.
Advantages
 Risk avoidance is enhanced due to the importance of risk analysis.
 Its a good model for complex and large systems.
 Depending on the changed circumstances, additional functionalities can be added later on
 Software is produced early in the cycle
Software Testing
Disadvantages
 Its a costly model and requires highly specialized expertise in risk analysis
 It does not work well in simpler projects
5. Rational Unified Process
Rational Unified Process Methodology
This model also consists of four phases, each of which is organized into a number of separate iterations.
The difference with other models is that each of these iterations must separately satisfy defined criteria
before the next phase is undertaken.
Advantages
 With an emphasis on accurate documentation, this model is able to resolve risks associated with
changing client requirements.
 Integration takes less time as the process goes on throughout the SDLC.
Disadvantages
 The biggest disadvantage is that the team members must be experts in their niche.
 In big projects such as continuous integration, it might give rise to confusion
Software Testing
6. Rapid application development
This is another incremental model, like the Agile model. Here, the components are developed parallel to
each other. The developments are then assembled into a product.
Advantages
 The development time is reduced due to the simultaneous development of components, and the
components can be reused
 A lot of integration issues are resolved due to integration from the initial stage
Disadvantages
 It requires a strong team of highly capable developers with individual efficacy in identifying
business requirements
 It is a module-based model, so systems that can be modularized can only be developed in this
model
 As the cost is high, the model is not suitable for cheaper projects
7 Iterative Model
The iterative model does not require a complete list of requirements before the start of the project. The
development process begins with the functional requirements, which can be enhanced later. The
procedure is cyclic and produces new versions of the software for each cycle. Every iteration develops a
separate component in the system that adds to what has been preserved from earlier functions.
Advantages
 It is easier to manage the risks since high-risk tasks are performed first.
 The progress is easily measurable.
 Problems and risks that are labeled within one iteration can be avoided in subsequent sprints.
Software Testing
Disadvantages
 The iterative model needs more resources compared to the waterfall model.
 Managing the process is difficult.
 The final stage of the project may not entirely determine the risks.
8. Kanban Model
The Kanban Model is a visual and flow-based approach to software development and project
management. It relies on a visual board to represent work items, which move through different process
stages. These stages include backlog, analysis, development, testing, and deployment.
Each work item in a Kanban system has a card on the board to represent it, and team members move
these cards through the stages as they complete them.
The board provides a real-time visual representation of the work in progress and helps teams identify
bottlenecks or areas for improvement.
Continuous improvement is a key principle of Kanban. Teams regularly review their processes, identify
areas of inefficiency, and make incremental changes to enhance workflow. This adaptability and focus
on improvement make the Kanban Model well-suited for projects with evolving requirements and a need
for continuous delivery.
Advantages of Kanban Model:
 Visual Representation: Provides a clear visual overview of work items and their progress.
 Flexibility: It is adaptable to changing priorities and requirements, making it suitable for
dynamic projects.
 Continuous Improvement: Encourages regular process reviews and enhancements for
increased efficiency.
 Reduced Waste: Minimizes unnecessary work by focusing on completing tasks based on actual
demand.
Disadvantages of the Kanban Model:
 Limited Planning: Less emphasis on detailed planning may be a drawback for projects
requiring extensive upfront planning.
 Dependency on WIP Limits: Ineffective management of work-in-progress (WIP) limits can
lead to bottlenecks.
 Complexity Management: This may become complex for large-scale projects or those with
intricate dependencies.
 Team Dependency: This relies on team collaboration and communication, which can be
challenging if not well coordinated.

Software Testing
9. The Big Bang Model
 No Formal Design or Planning: The Big Bang Model is characterized by an absence of detailed
planning or formal design before the development process begins.
 Random Testing Approach: Testing is conducted randomly, without a predefined strategy or
specific testing phases.
 Suitable for Small Projects: This model is often considered suitable for small-scale projects or
projects with unclear requirements.
Advantages of the Big Bang Model:
1. Simplicity: The model is simple and easy to understand.
2. Quick Start: Quick initiation, as there is no need for elaborate planning.
Disadvantages of the Big Bang Model:
1. Uncertainty: Lack of planning and design can lead to uncertainty and chaos during
development.
2. Testing Challenges: Random testing may result in inadequate test coverage, and missing critical
issues.
3. Limited Scalability: Not suitable for large or complex projects due to a lack of structured
processes.
10. Scrum Model
 Framework within Agile: Scrum is a framework operating within the Agile methodology,
emphasizing iterative development and collaboration.
 Sprints for Short Development Cycles: Development occurs in short, fixed intervals known as
sprints, typically lasting 2-4 weeks.
 Adaptability and Rapid Releases: Scrum promotes adaptability to changing requirements and
aims for rapid, incremental releases.
Advantages of Scrum Model:
1. Flexibility: Allows for flexibility in responding to changing project requirements.
2. Customer Satisfaction: Regular deliverables enhance customer satisfaction and engagement.
3. Continuous Improvement: Emphasizes continuous improvement through regular
retrospectives.
Disadvantages of the Scrum Model:
1. Lack of Structure: Some teams may struggle with flexibility and lack of a structured plan.
2. Dependency on Team Collaboration: Success heavily depends on effective collaboration
within the development team.

Software Testing
 3. Limited Predictability: It may be challenging to predict the exact outcomes and timeline due to
the iterative nature.
Bugs:
Software bugs are errors, flaws, deficiencies, or defects in a computer program or system that
cause it to produce an incorrect or unexpected result or to behave in unintended ways.
Different Types of Software Bugs
Here are the most common types of software bugs or defects encountered in software testing so that
developers and testers can deal with them better.
1. Functional Bugs
Functional bugs are associated with the functionality of a specific software component.
In simple terms, any component in an app or website that doesn’t function as intended is a functional
bug.
Such bugs are often detected when testers conduct comprehensive functional testing for their apps or
websites in real user conditions. Teams need to ensure that all the functional bugs are resolved in the
early stages so as to avoid delivering bad user experiences in the production environment.
For example, a Login button doesn’t allow users to login, an Add to cart button that doesn’t update the
cart, a search box not responding to a user’s query, etc.
2. Logical Bugs
A logical bug disrupts the intended workflow of software and causes it to behave incorrectly. These
bugs can result in unexpected software behavior and even sudden crashes. Logical bugs primarily take
place due to poorly written code or misinterpretation of business logic.
For example of logical bugs include:
 Assigning a value to the wrong variable.

 Dividing two numbers instead of adding them together resulting in unexpected output

3. Workflow Bugs
Workflow bugs are associated with the user journey (navigation) of a software application.
Let’s consider an example of a website where a user needs to fill up a form regarding their medical
history. After filling the form, the user has three options to choose from:
 Save
 Save and Exit
 Previous Page

Software Testing
From the available options, if the user clicks on “Save and Exit,” the user intends to save the entered
information and then exit. However, if clicking on the Save and Exit button leads to an exit from the
form without saving the information, it leads to a workflow bug.

4. Unit Level Bugs

Unit level bugs are very common, and they are typically easier to fix. Once the initial modules of
software components are developed, developers perform unit testing to ensure that the small batches of
code are functioning as expected. Here’s where developers encounter various bugs that get overlooked
in the coding stages. Unit level bugs are easier to isolate as developers deal with a comparatively small
amount of code. Moreover, replicating these bugs takes less time, so developers can track the exact bug
and fix it in no time.
For example, if a developer creates a single page form, a unit test will verify whether all the input fields
are accepting appropriate inputs and validate buttons for functionality. In case a field doesn’t accept the
appropriate characters or numbers, developers encounter a unit-level bug.
5. System-Level Integration Bugs
System-level integration bugs primarily pop up when two or more units of code written by different
developers fail to interact with each other. These bugs primarily occur due to inconsistencies or
incompatibility between two or more components. Such bugs are difficult to track and fix as developers
need to examine a larger chunk of code. They are also time-consuming to replicate. Memory overflow
issues and inappropriate interfacing between the application UI and the database are common examples
of system-level integration bugs.
For example: An online booking system integrates with multiple third-party service providers (e.g.,
airlines, hotels). If one of the service providers experiences high latency or timeouts, the entire booking
process may fail, resulting in incomplete bookings or incorrect availability information.
6. Out of Bound Bugs
Out of Bound Bugs show up when the system user interacts with the UI in an unintended manner. These
bugs occur when an end-user enters a value or a parameter outside the limits of unintended use.
For example, entering a significantly larger or a smaller number or entering an input value of an
undefined data type. These bugs often pop up in form validations during functional testing of web or
mobile apps.
7. Security Bugs
Security is a major concern for software development. Security Bugs are a major risk for users and
should be taken very seriously and resolved. Due to their high severity and vulnerable nature, security

Software Testing
bugs are considered among the most sensitive bugs of all types and should be handled with criticality
and urgency.
These bugs might not hinder the operation but can compromise the whole system. These should be
checked thoroughly at regular intervals.
A common example is SQL injection, where an attacker can manipulate a database query to gain
unauthorized access.
8. Performance Bugs
Performance bugs occur when a software application fails to meet the expected performance
benchmarks, such as load times, response times, or throughput. These bugs can significantly degrade the
user experience, especially in high-traffic or resource-intensive environments.
For example: An e-commerce website experiences a performance bug where the page load time exceeds
5 seconds during peak traffic hours, causing frustration for users and leading to a high abandonment
rate.
9. Compatibility Bugs
Compatibility bugs arise when a software application does not function correctly across different
environments, devices, or platforms. These bugs can lead to inconsistent user experiences and reduced
accessibility.
For example: A mobile app works perfectly on Android devices but crashes or displays incorrectly on
certain iOS devices, leading to a compatibility bug that impacts a significant portion of the user base.
10. Usability Bugs
Usability bugs affect the overall user experience, making it difficult or confusing for users to interact
with the software. These bugs do not necessarily prevent functionality but can lead to poor user
satisfaction and increased user error rates.
For example: A web application has a complex navigation structure that makes it difficult for users to
find essential features, leading to a usability bug that frustrates users and reduces engagement.
11. Concurrency Bugs
Concurrency bugs occur in software systems that involve parallel processing or multi-threading. These
bugs arise when multiple threads or processes interact in unintended ways, leading to unpredictable
behavior, data corruption, or system crashes.
For example: A banking application experiences a concurrency bug where two users attempt to transfer
funds simultaneously, leading to incorrect account balances or duplicate transactions.

Software Testing
Impact of Bugs on Software Development
Bugs can have significant impacts on software development, affecting everything from project timelines
to user satisfaction. Here’s how:
1. Delays in Project Delivery: Bugs, especially critical ones, can delay the release of software as
developers need to spend time identifying and fixing them. This can lead to missed deadlines and
increased costs.
2. Increased Development Costs: The longer a bug goes undetected, the more expensive it
becomes to fix. Early-stage bugs might be resolved with a few lines of code, but later-stage bugs could
require extensive rework, leading to higher costs.
3. Reputation Damage: If bugs make it into production, they can lead to a poor user experience,
causing users to lose trust in the software. This can damage the reputation of the company and result in
loss of customers.
4. Security Risks: Bugs that involve security vulnerabilities can be exploited by attackers, leading
to data breaches, legal liabilities, and financial losses.
5. Lower Productivity: Frequent bugs can lead to a more reactive approach to development, where
developers are constantly fixing issues rather than building new features. This can lower overall
productivity and slow down innovation.

Software Testing