Introduction To Software Testing A Practical Guide To Testing Design Automation and Execution 1St Edition Panagiotis Leloudas Full Chapter

Introduction to Software Testing: A
Practical Guide to Testing, Design,

Automation, and Execution 1st Edition
Panagiotis Leloudas
Visit to download the full and correct content document:
https://ebookmass.com/product/introduction-to-software-testing-a-practical-guide-to-te
sting-design-automation-and-execution-1st-edition-panagiotis-leloudas/
Introduction to
Software Testing
A Practical Guide to Testing,
Design, Automation,
and Execution
Panagiotis Leloudas
Introduction to Software Testing: A Practical Guide to Testing, Design,
Automation, and Execution
Panagiotis Leloudas
Ilioupoli, Greece
ISBN-13 (pbk): 978-1-4842-9513-7 ISBN-13 (electronic): 978-1-4842-9514-4

https://doi.org/10.1007/978-1-4842-9514-4
Copyright © 2023 by Panagiotis Leloudas

This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or
part of the material is concerned, specifically the rights of translation, reprinting, reuse of
illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way,
and transmission or information storage and retrieval, electronic adaptation, computer software,
or by similar or dissimilar methodology now known or hereafter developed.
Trademarked names, logos, and images may appear in this book. Rather than use a trademark
symbol with every occurrence of a trademarked name, logo, or image we use the names, logos,
and images only in an editorial fashion and to the benefit of the trademark owner, with no
intention of infringement of the trademark.
The use in this publication of trade names, trademarks, service marks, and similar terms, even if
they are not identified as such, is not to be taken as an expression of opinion as to whether or not
they are subject to proprietary rights.
While the advice and information in this book are believed to be true and accurate at the date of
publication, neither the authors nor the editors nor the publisher can accept any legal
responsibility for any errors or omissions that may be made. The publisher makes no warranty,
express or implied, with respect to the material contained herein.
Managing Director, Apress Media LLC: Welmoed Spahr
Acquisitions Editor: Divya Modi
Development Editor: James Markham
Coordinating Editor: Divya Modi
Cover designed by eStudioCalamar
Cover image by Freepik.com
Distributed to the book trade worldwide by Apress Media, LLC, 1 New York Plaza, New York, NY
10004, U.S.A. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@springer-sbm.com,
or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole member
(owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance
Inc is a Delaware corporation.
For information on translations, please e-mail booktranslations@springernature.com; for
reprint, paperback, or audio rights, please e-mail bookpermissions@springernature.com.
Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook
versions and licenses are also available for most titles. For more information, reference our Print
and eBook Bulk Sales web page at www.apress.com/bulk-sales.
Any source code or other supplementary material referenced by the author in this book is
available to readers on GitHub (https://github.com/Apress). For more detailed information,
please visit www.apress.com/source-code.
Printed on acid-free paper
To my family
Table of Contents
About the Author��xi
About the Technical Reviewer��xiii
Acknowledgments��xv
Introduction��xvii
Chapter 1: The Importance of Software Testing��1

Summary��4
Chapter 2: Software Testing Types and Techniques��5

Functional Testing��5
Unit Testing��7
Integration Testing��9
System Testing��11
User Acceptance Testing��11
Nonfunctional Testing��13
Performance Testing��14
Security Testing��17
Usability Testing��20
Compatibility Testing��21
Scalability Testing��22
Reliability Testing��23
Availability Testing��24
Installability Testing��24
v
Table of Contents
Maintainability Testing��26
Compliance Testing��27
Static Testing��29
Code Reviews��29
Requirement Reviews��30
Design Reviews��31
Walk-Throughs��32
Inspections��33
Summary��34
Chapter 3: Software Development Life Cycle��35

Planning Phase��36
Requirements Gathering Phase��39
Design Phase��42
Development Phase��45
Deployment Phase��48
Maintenance Phase��51
The Role of Testing in the SDLC��54
Summary��55
Chapter 4: Test Planning��57

Defining Testing Objectives��57
Determining the Scope of Testing��59
Selecting the Testing Approach��59
Identifying Testing Resources��61
Developing the Test Schedule��62
Defining Test Cases��63
Identifying Test Data��65
vi
Table of Contents
Defect Management Process��66

Stop Testing Criteria��67
Reviewing and Approving the Test Plan��67
Benefits of Test Planning��68
Test Plan Document��69
Test Planning Tools and Techniques��71
Summary��73
Chapter 5: Test Design Techniques��75

Black-Box Testing��75
Equivalence Partitioning��78
Boundary Value Analysis��82
Decision Table Testing��84
State Transition Testing��88
Use-Case Testing��93
Pairwise Testing��95
Error Guessing��98
Exploratory Testing��100
Random Testing��103
Ad Hoc Testing��105
White-Box Testing��107
Statement Coverage��109
Branch Coverage��112
Path Coverage��115
Condition Coverage��118
Decision Coverage��121
Multiple Condition Coverage��123
Modified Condition/Decision Coverage��127
vii
Table of Contents
Loop Testing��130
Data Flow Testing��132
Static Testing��133
Summary��135
Chapter 6: Test Execution��137

Getting Started��137
Test Execution Process��138
Test Environment Setup��139
Defect Reporting and Retesting��141
Regression Testing��144
Test Case Status Reporting��146
Test Case Completion��148
Techniques and Tools Used in Test Execution��149
Quality Metrics��150
Defect Density��150
Test Coverage��151
Code Complexity��152
Code Maintainability��152
Fault Slip Through��153
Coding Standards��154
Code Duplication��155
Dead Code��156
Lines of Code��157
Fan-Out��158
Compiler Warnings��159
Summary��159
viii
Table of Contents
Chapter 7: Test Automation��161

Benefits of Test Automation��161
Record and Playback Tools��162
Scripting Tools��163
Hybrid Tools��164
Frameworks��165
Automated Testing Tools��167
Automated Test Scripts��169
Summary��171
Chapter 8: Testing in Agile Environment��173

Agile Testing Principles��174
Agile Testing Quadrants��175
Test-Driven Development��177
Behavior-Driven Development��179
Acceptance Test-Driven Development��181
Continuous Integration and Continuous Delivery��183
Test Automation in Agile��184
Agile Testing Best Practices��186
Summary��187
Chapter 9: Challenges and Solutions in Software Testing��189

Lack of Clear Requirements��189
Impact of Lack of Clear Requirements on Testing��190
Mitigating the Impact of Lack of Clear Requirements��190
Time Constraints��191
Impact of Time Constraints on Software Testing��191
Strategies for Managing Time Constraints in Testing��192
ix
Table of Contents
Lack of Skilled Resources��193

Impact of Lack of Skilled Resources on Software Testing��193
Strategies for Managing Lack of Skilled Resources in Testing��194
Automation Challenges��195
Common Automation Challenges��195
Strategies for Addressing Automation Challenges��196
Communication and Collaboration��197
Change Management��197
Testing Across Platforms��199
Future of Software Testing��200
Risk-Based Testing��202
Summary��204
Afterword��205
Index��207
x
About the Author
Panagiotis Leloudas is a software quality
assurance engineer with more than 10 years of
working experience in the industry. He holds
several ISTQB certifications and is an expert
in testing principles, methodologies, and
techniques.
He decided to write this quick guide to
software testing because he needed a go-to
document for all the decisions he had to make
every day on the job and there wasn’t one. He
tried to write down everything that he would
have liked to know when he started his career.
xi
About the Technical Reviewer
Sourabh Mishra is an entrepreneur, developer,
speaker, author, corporate trainer, and
animator. He is passionate about Microsoft
technologies and a true .NET warrior. Sourabh
has loved computers from childhood and
started his career when he was just 15 years
old. His programming experience includes
C/C++, ASP.NET, C#, VB .NET, WCF, SQL
Server, Entity Framework, MVC, Web API, Azure, jQuery, Highcharts, and
Angular. Sourabh has been awarded Most Valuable Professional (MVP)
status. He has the zeal to learn new technologies, sharing his knowledge on
several online community forums.
He is a founder of IECE Digital and Sourabh Mishra Notes, an online
knowledge-sharing platform where people can learn new technologies.
xiii
Acknowledgments
Writing a book is a significant undertaking, and I couldn’t have done it
without the support and assistance of many people along the way. I want
to express my gratitude to everyone who contributed to the creation of this
book and helped me throughout the process.
First and foremost, I want to thank my family for their unwavering
support, encouragement, and patience during the many months of writing
and editing. Your love and support mean the world to me, and I couldn’t
have done this without you.
I also want to thank my editors, Divya Modi and James Markham, for
their insightful feedback, guidance, and support throughout the writing
process. Your expertise and attention to detail were invaluable in shaping
this book into its final form.
I am grateful to Apress Media LLC for believing in this project and
providing the resources necessary to bring it to fruition.
I am indebted to the many experts, researchers, and consultants who
generously shared their knowledge, insights, and expertise to help me
with my research. Your contributions have added depth and richness to
this book.
Finally, I want to thank my readers for their interest in this book and
for taking the time to read it. Your support and feedback mean the world to
me, and I hope this book can make a positive difference in your life.
Thank you all for your support, encouragement, and contributions to
this book. I am forever grateful.
xv
Introduction
A collection of notes, thoughts, and experiences written down to be shared
with the world: this is how I see the creation of this book. It is not meant
to be the ultimate truth about software testing; there is no such a thing
after all. I have taken several courses about software testing from different
organizations, in numerous countries, and I have spent weeks studying
testing material, but most of my knowledge comes from trial and error in
the industry. It is true that in the end you learn only what you practice.
This book takes you on a journey around the software testing world,
covering the basic principles and techniques and showing examples
of how to apply them. Software testing is a safeguard of the quality
of a software product, and a tester is responsible for reporting on the
quality status. Keep in mind that the quality of the product is not the sole
responsibility of a tester; rather, it’s a collective effort from every individual
in the organization. A chain is only as strong as its weakest link.
Different types of testing are applicable to every phase of the software
development life cycle; of course, the priorities and the risks are not the
same in all the products. Testing is all about identifying those risks and
setting up a mitigation plan by executing the necessary tests and analyzing
the results.
In this book, I will demonstrate some of the most important software
testing types and techniques that exist and how to apply them. You will
find out what testing activities take place during every phase of software
development, how to plan the testing activities, how to design the test
cases, how to execute them, and how to report defects and the status of
your activities. It is meant to be easy to understand for everyone, even
with only the slightest technical background or involvement in a product.
I hope you will enjoy the process and pick up a thing or two!
xvii
CHAPTER 1
The Importance
of Software Testing
Software testing is a crucial part of the software development process. It is
the process of evaluating a software system or application to find defects,
errors, or bugs, and verifying that it meets its intended requirements and
functions correctly. Software testing is essential because it ensures that
the software performs as expected, meets user needs, and is reliable and
efficient.
Testing is not a one-time event, but rather a continuous process that
begins in the early stages of development and continues through the
software’s life cycle. The process involves planning, designing, executing,
and evaluating tests to identify and fix issues and to improve the quality of
the software.
There are various types of software testing, each with a unique focus
and objective. Some of the common types include unit testing, integration
testing, system testing, acceptance testing, regression testing, performance
testing, and security testing. Each type of testing has a specific purpose and
is conducted at different stages of the software development life cycle.
One common misconception about software testing is that it is just
about finding defects or errors in software. While detecting defects is an
essential part of software testing, it is not the only goal. Testing is also
about verifying that the software meets user requirements, is easy to use,
and performs as expected. Testing also involves ensuring that the software
is scalable, secure, and efficient.
© Panagiotis Leloudas 2023 1

P. Leloudas, Introduction to Software Testing,
https://doi.org/10.1007/978-1-4842-9514-4_1
Chapter 1 The Importance of Software Testing
Another misconception is that testing can be eliminated by writing

perfect code or using the right tools. However, testing is an integral part
of software development, and there is no way to guarantee that software
is completely free of errors. No matter how skilled the development team
is or how advanced the tools and technologies used, there is always a
possibility of errors or unexpected outcomes. Therefore, testing is essential
to identify and fix issues early in the development process before they
become major problems.
Black-box testing is a testing technique that examines the
functionality of an application without knowing its internal code structure.
The tester focuses on the inputs and outputs of the system and tests the
application based on the specifications or requirements. The goal of
black-box testing is to identify defects in the functionality, usability, and
performance of the application.
White-box testing, on the other hand, is a testing technique that
examines the internal structure of the application. The tester focuses on
the application’s code structure, internal logic, and algorithms to test the
application. The goal of white-box testing is to identify defects in the code
structure and ensure that the application functions correctly.
Gray-box testing is a combination of black-box and white-box testing.
The tester has some knowledge of the internal code structure, but not
full access. The goal of gray-box testing is to identify defects in the code
structure and ensure that the application functions correctly.
Exploratory testing is a testing technique that involves testing the
software without predefined test cases or scripts. The tester explores the
software and tests it based on their intuition and experience. The goal
of exploratory testing is to identify defects that may not be found using
traditional testing techniques.
In addition to testing the software’s functionality, it is also essential to
test nonfunctional aspects, such as performance, security, and usability.
These types of testing ensure that the software meets its nonfunctional
requirements and provides a positive user experience.
2
Software testing is an ongoing process that continues throughout the

software’s life cycle. It is essential to conduct regular testing, even after
the software has been released to production, to ensure that it continues
to function correctly and meets the users’ needs. This is known as
maintenance testing.
This book will provide a simple overview of the testing activities, tools,
and techniques. By the end of it, you will have all the basic knowledge you
need in a day as a tester.
I have tried to assemble all the knowledge I have accumulated so far
into a small practical guide on how software testing is. The purpose of
this book is not to enforce processes and tools in your organization, but to
give you some ideas and best practices you might find useful in your daily
activities.
It is the responsibility of the tester to report on the quality of the
product, but the quality of a company relies on every single individual.
Software quality is the responsibility of everyone involved in the software
development process, including developers, testers, project managers,
business analysts, and other stakeholders. Here are some ways that each
individual can contribute to software quality in a company.
Developers play a critical role in ensuring software quality by writing
high-quality, well-designed, and maintainable code. They can also
contribute to software quality by adhering to coding standards, performing
code reviews, and writing automated tests.
Testers play a crucial role in ensuring software quality by designing
and executing test plans and test cases to verify that software products
meet the requirements and expectations of end users. They can also
provide feedback to development teams to help improve the quality of
the code.
Product owners are responsible for defining and prioritizing product
requirements. They can contribute to software quality by ensuring that
requirements are clear, concise, and testable, and that they meet the needs
of end users.
3
Project managers are responsible for managing project timelines,

resources, and budgets. They can contribute to software quality by
ensuring that projects are adequately resourced, that timelines are
realistic, and that projects are well-planned and executed.
Business analysts can contribute to software quality by ensuring
that the business requirements are clear, complete, and testable, and that
testing teams have the information they need to design effective test cases.
They can also validate the requirements with stakeholders and subject-
matter experts to identify any gaps or inconsistencies in the requirements
early in the development process.
User experience designers are responsible for ensuring that software
products are user-friendly and meet the needs of end users. They can
contribute to software quality by conducting user research, designing
intuitive user interfaces, and ensuring that products meet accessibility and
usability standards.
Operations teams are responsible for deploying and maintaining
software products. They can contribute to software quality by ensuring that
software is deployed in a reliable way.
Technical writers can contribute to software quality by ensuring
that user documentation is clear, concise, and easy to understand. This
can help to reduce the risk of user errors and improve the overall user
experience.
Summary
To summarize, software quality is a collective effort, and the
responsibilities are distributed among the various members of a company.
There are plenty of software testing types and techniques for the core
testing team of a project, and the next chapter will dive into the details of
each and every one.
4
CHAPTER 2
Software Testing
Types and Techniques
Software testing is a complex process that involves various types and
techniques to ensure that the software is working correctly and meets its
intended requirements. In this chapter, we will discuss the different types
of software testing and the techniques used in each type, starting with
functional testing and the four levels it involves. We will continue with
nonfunctional testing, which can include performance testing, compliance
testing, and all the different types of -ility testing (usability, compatibility,
availability, etc.). After that, we will see the benefits of static testing, where
we can detect potential defects just by carefully examining the code
without even executing it.
Functional Testing
This type of testing is performed to validate that the software is working as
expected and meets the user’s requirements. The primary focus is on the
software’s functionality and includes various levels of testing such as unit
testing, integration testing, system testing, and acceptance testing. These
levels are widely known as the testing pyramid, a concept introduced by
Mike Cohn.
© Panagiotis Leloudas 2023 5

P. Leloudas, Introduction to Software Testing,
https://doi.org/10.1007/978-1-4842-9514-4_2
Chapter 2 Software Testing Types and Techniques
The lower we go on the testing pyramid (Figure 2-1), the faster and
more isolated the tests are. On the contrary, as we go higher on the testing
pyramid, the tests become slower, and more components are integrated.
Figure 2-1. The testing pyramid
Unit testing involves testing individual units or components of the

software. The objective is to validate that each unit functions correctly and
meets its intended requirements.
Integration testing involves testing the integration of individual units
or components to ensure that they work together correctly.
System testing involves testing the entire system to ensure that it
meets the user’s requirements and functions correctly.
User acceptance testing involves testing the software from the
user’s perspective to ensure that it meets the user’s expectations and
requirements.
6
Unit Testing
Unit testing is a software testing technique that focuses on testing
individual units or components of a software system. A unit is the smallest
testable part of any software application, usually a function, method,
or class. The purposes of unit testing are to verify that each unit of the
software performs as expected and to catch errors as early as possible in
the development process.
During unit testing, the individual units of the software are tested in
isolation from the rest of the system. This is achieved by using stubs or
mock objects to simulate the behavior of other parts of the system that the
unit depends on. Unit tests are typically automated, which enables them
to be run frequently and easily, ensuring that changes to the code do not
break existing functionality.
Unit tests are typically written by developers as part of the
development process. Here are some key characteristics of unit tests:
• Isolation: Unit tests are designed to test individual units

of code in isolation from the rest of the application.
This is typically achieved by using mock objects or
stubs to simulate the behavior of other parts of the
application.
• Automation: Unit tests are typically automated using
testing frameworks such as JUnit or NUnit. This allows
developers to run tests frequently and quickly and
to identify and fix defects early in the development
process.
• Coverage: Unit tests should provide coverage for all

possible execution paths through the unit of code being
tested. This helps to ensure that all possible scenarios
are tested and that defects are identified early in the
development process.
7
• Independence: Unit tests should be independent of

each other and should not rely on the results of other
tests. This helps to ensure that defects are identified
and fixed in a timely manner and that tests do not
interfere with each other.
• Maintainability: Unit tests should be easy to maintain

and update as the code evolves over time. This can help
to ensure that tests continue to provide accurate results
and that defects are identified and fixed early in the
The following are the main benefits of unit testing:
• Early detection of bugs: By testing individual units in

isolation, unit testing can detect errors early in the
development process, which makes them easier and
cheaper to fix.
• Faster debugging: Unit testing allows developers to

isolate and identify the cause of errors quickly and
efficiently.
• Better code quality: Unit testing forces developers to

write modular, well-structured code that is easier to
understand and maintain.
• Improved design: Unit testing encourages developers

to design their code with testability in mind, which can
lead to better software design.
Overall, unit testing is an essential practice in software development

that helps ensure the quality of software applications.
8
Integration Testing
Integration testing is a type of testing that focuses on testing the interaction
between different software components, subsystems, or modules. The
purpose of integration testing is to verify that the integrated software
system works as intended and that the individual components are able to
work together without errors or issues.
The main goal of integration testing is to identify any defects or issues
that may arise when multiple software components are combined. The
objective is to detect problems early in the software development cycle,
before the product is released to the customers. This helps in reducing
the cost and effort required to fix issues in later stages of the software
There are different approaches to integration testing such as top-down,
bottom-up, and hybrid. In the top-down approach, testing starts from the
highest level and works its way down to the lowest level of the software
hierarchy. In the bottom-up approach, testing starts from the lowest level
and works its way up to the highest level of the software hierarchy. The
hybrid approach combines the top-down and bottom-up approaches.
In integration testing, individual units of code are combined and tested
as a group. Integration tests can be performed at various levels, such as the
following:
• Component-level integration: This involves testing the

integration of individual components or modules of an
application. Component-level integration tests ensure
that individual components work together correctly
and can communicate with each other.
• System-level integration: This involves testing the

integration of multiple components or subsystems of
an application. System-level integration tests ensure
that the application functions correctly as a whole and
that different subsystems work together seamlessly.
9
• End-to-end integration: This involves testing the

integration of the entire application, including all
subsystems and external systems that the application
interacts with. End-to-end integration tests ensure
that the application meets the needs of end users
and stakeholders and that all the components work
together correctly.
During integration testing, different types of testing techniques are

used such as functional testing, performance testing, security testing, and
usability testing. The testers ensure that the different software components
are integrated correctly and that they work together as intended.
The following are some common types of integration testing:
• Big Bang integration testing: In this type of testing, all

the software components are integrated together and
tested as a whole.
• Incremental integration testing: In this type of testing,

the software components are integrated incrementally,
one at a time, and tested as they are added to
the system.
• Top-down integration testing: In this type of testing,
testing starts with the highest level modules and works
its way down to the lowest level modules.
• Bottom-up integration testing: In this type of testing,

testing starts with the lowest-level modules and works
its way up to the highest-level modules.
• Sandpit integration testing: In this type of testing, a

new module is integrated with the rest of the system in
a separate environment called a sandbox or sandpit.
This allows the new module to be tested in a controlled
environment without affecting the rest of the system.
10
System Testing
System testing is a type of software testing that is performed on a complete,
integrated system to evaluate the system’s compliance with its specified
requirements. It is generally a black-box testing approach, which means
that testers are not concerned with the internal workings of the system.
Instead, they focus on testing the system as a whole to ensure that it meets
the functional and nonfunctional requirements of the stakeholders.
System testing is typically conducted after integration testing, which
tests the integration of different components or subsystems of the system.
The objective of system testing is to verify that the integrated system satisfies
the requirements and behaves as expected in the target environment.
User Acceptance Testing

User acceptance testing (UAT) is a process to validate whether a system
meets the specified requirements and works as expected in the real-world
scenario. UAT is performed by end users, business stakeholders, or domain
experts to ensure the system’s functionality and usability.
The following are some key characteristics of user acceptance testing:
• User involvement: UAT involves end users or

stakeholders testing the software product, providing
feedback, and ensuring that it meets their needs and
requirements.
• Real-world testing: UAT involves testing the software

product in a real-world environment, using real
data and scenarios, to ensure that it meets the user’s
business processes and workflows.
• Validation of business requirements: UAT ensures that

the software product meets the business requirements
and goals of the user or stakeholder.
11
• Acceptance criteria: UAT defines acceptance criteria

for the software product, which are used to determine
whether the product is ready for deployment.
• Sign-off: UAT requires the sign-off of the user or

stakeholder to indicate that they are satisfied with the
software product and that it is ready for deployment.
The primary objectives of UAT are as follows:
• To validate the system’s functionality from an end

user’s perspective
• To check whether the system meets the business

requirements
• To ensure that the system is user-friendly and

easy to use
• To find defects that were not detected in previous

testing stages
• To reduce the risk of system failure in production
There are three types of UAT:

• Alpha testing: It is performed in-house by the
development team or a group of testers before releasing
the product to the end users.
• Beta testing: It is performed by a group of end users in

a real-world scenario before releasing the product to
the market.
• Acceptance testing: It is performed by the end users

or business stakeholders to validate whether the
system meets the specified requirements and works as
expected in the real-world scenario.
12
Nonfunctional Testing
This type of testing focuses on the software’s nonfunctional aspects, such
as performance, security, and usability. The objective is to ensure that the
software meets its nonfunctional requirements and provides a positive
user experience. Here are some examples of nonfunctional testing:
Performance testing involves testing the software’s performance
under various conditions, such as load, stress, and scalability.
Security testing involves testing the software’s security features to
ensure that it is secure from various types of attacks and vulnerabilities.
Usability testing involves testing the software’s user interface and user
experience to ensure that it is user-friendly and easy to use.
Compatibility testing is testing whether the system can work with
different software, hardware, and operating systems.
Scalability testing is testing whether the system can handle increasing
amounts of data and users.
Reliability testing is evaluating how well the system performs under
different conditions and over time.
Availability testing is testing whether the system is available to users
and can be accessed at all times.
Installability testing is testing how easy it is to install and configure
the software and whether it meets installation requirements and
specifications.
Maintainability testing is testing the software’s ability to be updated,
maintained, and supported over time, and whether it meets maintenance
requirements and specifications.
Compliance testing is testing whether the software meets specific
regulatory or industry standards, such as HIPAA, GDPR, or PCI DSS.
13
Performance Testing
Performance testing measures how well a system or application performs
under a given workload. It helps identify bottlenecks and problems in the
application’s performance, and it can also help determine whether the
application can handle expected volumes of data or users. In this section,
we’ll discuss the different types of performance testing, how to plan for and
execute performance tests, and tools and techniques used in performance
testing.
There are different types of performance testing that can be used to
evaluate the performance of an application.
• Load testing: This type of testing evaluates how an

application performs under normal and peak load
conditions. It involves testing the application with a
large number of users, requests, and data to determine
its performance under different workloads.
• Stress testing: This type of testing is performed to

determine the application’s stability under extreme
loads. Stress testing pushes the application beyond
its normal operating conditions to evaluate how it
responds to these conditions.
• Spike testing: This type of testing is used to evaluate

the application’s performance when there is a sudden
and significant increase in traffic. It is designed to
determine the application’s ability to handle sudden
and unexpected spikes in traffic.
• Endurance testing: This type of testing is used to

evaluate the application’s performance over an
extended period of time. It is designed to test the
application’s ability to maintain its performance over a
long period.
14
• Volume testing: This type of testing is used to evaluate

how well the application can handle large volumes
of data. It is used to determine the application’s
performance under varying data volumes.
• Scalability testing: Scalability testing involves testing

the system’s ability to handle an increasing amount of
users or data without a decrease in performance.
• Soak testing: Soak testing involves testing the system

under a normal load for an extended period to
determine if there are any issues that arise over time.
• Configuration testing: Configuration testing involves

testing the system under different configurations to
determine how performance is affected by different
settings.
• Isolation testing: Isolation testing involves testing

individual components of the system to determine
their performance under specific conditions.
• Comparative testing: Comparative testing involves

comparing the performance of different systems or
configurations to determine which one performs better.
There are different tools and techniques that can be used in

performance testing.
• Load testing tools: These tools are used to simulate a

large number of users, requests, and data to evaluate
the application’s performance under different
workloads.
• Performance monitoring tools: These tools are used

to monitor the application’s performance during the
testing to identify bottlenecks and issues.
15
• Profiling tools: These tools are used to identify

performance bottlenecks in the application’s code.
• Cloud-based performance testing: This approach

involves using cloud-based infrastructure and services
to simulate real-world usage scenarios.
• Performance monitoring tools: Performance monitoring

tools are used to monitor the application’s performance
and identify any issues that may arise during the
testing phase. These tools can be used to monitor
various metrics such as CPU usage, memory usage, and
response time.
• Profiling tools: Profiling tools are used to analyze

the code and identify areas that can be optimized
to improve performance. These tools can be used
to identify memory leaks, deadlocks, and other
performance issues.
• Log analysis tools: Log analysis tools are used to analyze

the log files generated during the performance testing.
These tools can be used to identify any errors or issues
that may have occurred during the testing phase.
• Statistical analysis tools: Statistical analysis tools can

be used to analyze the performance test results and
identify any trends or patterns. These tools can be used
to determine the application’s performance under
varying loads and identify any bottlenecks.
• Root-cause analysis tools: Root-cause analysis tools

are used to identify the root cause of any performance
issues that may arise during the testing phase. These
tools can be used to drill down into the application
code to identify the underlying cause of the issue.
16
• Benchmarking tools: Benchmarking tools are used

to compare the application’s performance against
industry standards and best practices. These tools
can be used to identify any performance issues that
may arise and help to improve the application’s
performance.
Security Testing
Security testing is a type of software testing that focuses on identifying
vulnerabilities and potential security risks within an application or system.
Security testing is an essential process for ensuring that an application or
system is secure and safe from potential attacks or malicious activity.
There are various types of security testing techniques and tools
available that can be used to identify and address potential security issues.
The following are some of the common techniques:
• Penetration testing: Penetration testing, or pen-testing,

is a security testing technique that involves simulating
an attack on a software system to identify and exploit
vulnerabilities in the system. Penetration testing tools
include Metasploit, Nessus, and Wireshark.
• Vulnerability scanning: Vulnerability scanning tools are

used to identify vulnerabilities in a software system by
scanning for weaknesses in the system. Some examples
of vulnerability scanning tools are Nmap, OpenVAS,
and Retina.
• Fuzz testing: Fuzz testing is a technique that involves

feeding large amounts of random data to a software
system to identify vulnerabilities in the system.
Fuzz testing tools include Peach Fuzzer, JBroFuzz,
and SPIKE.
17
• Code review: Code review is the process of analyzing

source code to identify and fix potential security
vulnerabilities. Code review tools include SonarQube,
Codacy, and CodeClimate.
• Authentication testing: Authentication testing involves

testing the login process of a software system to ensure
that it is secure and resistant to attacks. Authentication
testing tools include Burp Suite, ZAP, and Acunetix.
• Authorization testing: Authorization testing involves

testing the permissions and access control of a software
system to ensure that users have access only to the
resources they are authorized to use. Authorization
testing tools include OWASP WebScarab, IronWASP,
and IBM AppScan.
• Security configuration testing: This type of testing

checks the configuration of the system and identifies
vulnerabilities in the configuration of the operating
system, network devices, firewalls, and other security
devices.
• Encryption testing: This type of testing involves testing
the effectiveness of encryption mechanisms in the
application. It evaluates the strength of the encryption
algorithms and checks if the data is being stored and
transmitted securely.
• Input validation testing: This type of testing checks if

the application is protected from malicious inputs. It
tests if the application validates user input and does not
accept malicious input from users.
18
• Security code review: This type of testing involves

reviewing the application code for security
vulnerabilities. It can be done manually or using
automated tools.
• Security compliance testing: This type of testing checks

if the application meets the security standards and
guidelines. It includes testing against regulatory
compliance requirements such as HIPAA, PCI DSS,
and GDPR.
• Disaster recovery and business continuity testing: This

type of testing is done to ensure that the application
can continue to operate during and after a disaster. It
includes testing the backup and recovery processes and
the effectiveness of the disaster recovery plan.
There are numerous security vulnerabilities that can exist in a

system, and detecting them requires knowledge of the common ones
and the techniques used to find them. Here are a few common security
vulnerabilities and how they can be detected:
• SQL injection: SQL injection is a type of attack in which

an attacker tries to inject malicious SQL code into a
database. This can be detected by testing inputs for
SQL keywords or special characters.
• Cross-site scripting (XSS): This is a type of vulnerability

that allows an attacker to inject malicious scripts into
a web page viewed by other users. XSS can be detected
by testing inputs for special characters, such as < and >,
or by using an automated scanner.
19
• Cross-site request forgery (CSRF): This vulnerability

allows an attacker to force a user to perform an action
on a website without the user’s knowledge or consent.
CSRF can be detected by checking the HTTP Referer
header or by using an automated scanner.
• Broken authentication and session management: This

vulnerability allows an attacker to gain access to a
user’s account or session. It can be detected by testing
for weak passwords, session hijacking, or using an
automated scanner.
• Buffer overflow: This vulnerability occurs when a

program tries to write more data to a buffer than it
can hold, which can cause memory corruption and
other security issues. Buffer overflow can be detected
by performing boundary value testing or using an
automated scanner.
• Information disclosure: This vulnerability occurs when

sensitive information is exposed to unauthorized users.
It can be detected by performing security audits or
using an automated scanner.
These are just a few examples of common security vulnerabilities, and
there are many more that can exist in a system. It’s important to use a variety
of tools and techniques to detect and prevent security vulnerabilities.
Usability Testing
Usability testing is a type of testing performed to evaluate how user-
friendly a product is. The objective of usability testing is to determine how
easy it is for users to learn and use the product, how efficient they are at
completing tasks, and how satisfied they are with the product.
20
Usability testing typically involves selecting a group of users who

represent the target audience for the product. These users are then given
a set of tasks to perform using the product, while the tester observes
their behavior and records their comments. The tasks are designed to be
representative of the kinds of tasks that the product is intended to support.
The usability tester may use a variety of techniques to gather feedback
from users, including questionnaires, interviews, and direct observation
of user behavior. The feedback gathered during the testing process is
then used to identify problems with the product’s usability and to suggest
improvements that can be made to the design.
Usability testing can be conducted at various stages of the product
development life cycle, from early prototypes to finished products. It can
be performed in a lab setting, in the user’s own environment, or online.
The results of usability testing are used to inform design decisions
and to improve the overall user experience of the product. By identifying
usability problems early in the development process, usability testing can
help to save time and money by avoiding costly redesigns and rework.
Compatibility Testing
Compatibility testing is a type of software testing that is performed to
ensure that an application is compatible with various hardware, operating
systems, browsers, databases, and other third-party software components.
The purpose of compatibility testing is to identify compatibility issues
between the software application and the systems on which it will be
deployed. The goal is to ensure that the application functions properly
across a variety of environments and configurations.
To perform compatibility testing, the testing team needs to identify
the hardware, software, and other components that the application will be
required to work with. Based on this information, the testing team creates
a test plan that outlines the specific tests that need to be conducted to
ensure compatibility.
21
Compatibility testing can be conducted in a number of different ways,

including manual testing, automated testing, or a combination of both.
The testing team may use a variety of tools and techniques to simulate
different hardware and software configurations and to automate the
testing process where possible.
The following are some common areas of focus in compatibility
testing:
• Operating system compatibility
• Browser compatibility
• Database compatibility
• Mobile device compatibility
• Third-party software compatibility
Scalability Testing
Scalability testing is a type of nonfunctional testing that evaluates the
ability of a system or application to scale up or scale down in response to
changing workload and data volume. The purpose of scalability testing is
to identify the maximum capacity of a system or application and to ensure
that it can handle increasing levels of load without compromising its
performance or stability.
Scalability testing is particularly important for systems that are
expected to handle a large number of users, transactions, or data volume.
It is typically performed in a controlled environment, using a combination
of manual and automated testing techniques to simulate different levels
of load and measure the system’s response time, throughput, and resource
utilization.
22
Reliability Testing
Reliability testing is a type of software testing that aims to determine the
reliability of a software application by measuring its performance in various
conditions over a certain period of time. The goal of this testing is to identify
any defects or issues that could affect the overall reliability of the system.
Reliability testing typically involves subjecting the software to a series
of tests that simulate real-world scenarios and stress conditions. These
tests may include load testing, performance testing, and endurance
testing. The software is also tested for its ability to recover from errors or
failures and its ability to maintain its performance levels under varying
conditions.
The following are some common techniques used in reliability testing:
• Stress testing: This involves testing the software

application under extreme conditions, such as high
loads, to see how it behaves and whether it is able to
handle the stress.
• Endurance testing: This involves testing the software

application over a period of time to see how it performs
over a long period of use.
• Performance testing: This involves testing the software
application under normal and peak loads to measure
its performance and identify any bottlenecks or issues.
• Fault tolerance testing: This involves testing the

software application for its ability to continue
functioning even in the event of a system failure or
hardware malfunction.
• Recovery testing: This involves testing the software

application for its ability to recover from errors or
failures and return to normal functioning.
23
Availability Testing
Availability testing is a type of nonfunctional testing that is performed
to measure the ability of a system or application to remain available
and accessible for use by its users over a specified period of time. The
primary objective of availability testing is to identify and mitigate any
factors that could lead to service disruptions or downtime, such as
hardware or software failures, network connectivity issues, or system
configuration errors.
During availability testing, testers simulate various failure scenarios
and measure the system’s ability to recover from them in a timely manner.
Availability metrics are used to measure the system’s performance.
These metrics may include the percentage of uptime, the mean time
between failures (MTBF), the mean time to repair (MTTR), and the
recovery time objective (RTO).
Installability Testing
Installability testing is a type of software testing that evaluates how easy
it is to install, set up, and configure the software. This type of testing is
essential to ensure that the installation process is straightforward, reliable,
and consistent, and that the software meets installation requirements and
specifications.
Installability testing involves testing the software installation process
on different hardware, operating systems, and configurations, and
verifying that it meets the following criteria:
• Installation instructions: The installation instructions

should be clear, concise, and easy to follow, with step-
by-step guidance on how to install and configure the
software.
24
• Installation process: The installation process should be

straightforward, with no unexpected or confusing steps,
and should not require any specialized knowledge or
expertise.
• Installation options: The software should provide users

with installation options, such as custom installation,
silent installation, or network installation, to suit their
specific needs and preferences.
• Compatibility: The software should be compatible

with different hardware, operating systems, and
configurations, and should not cause conflicts or errors
during installation.
• Resource requirements: The software should meet the

minimum resource requirements for installation, such
as disk space, memory, and processor speed, and
should not require additional resources that are not
readily available.
• Error handling: The software should have appropriate

error handling mechanisms in place to handle
installation errors and failures and should provide clear
and helpful error messages to users.
• Uninstallation: The software should provide a

straightforward and reliable uninstallation process,
with no residual files or registry entries left behind, and
should not cause any system instability or conflicts.
Overall, installability testing is essential to ensure that the software

is easy to install, configure, and use, and that it meets user expectations
and requirements. By testing the software installation process thoroughly,
testers can identify and address any installation issues and can ensure that
the software is of high quality and meets user needs.
25
Maintainability Testing
Maintainability testing is a type of software testing that evaluates the software’s
ability to be updated, maintained, and supported over time. This type of
testing is essential to ensure that the software can be modified or enhanced
easily and that it remains stable and reliable after updates and changes.
Maintainability testing involves testing the software’s maintainability
by evaluating the following criteria:
• Code quality: The code quality should be of high

quality and maintainable. This includes variables
and functions being named appropriately, modular
code that is easy to understand and reusable, code
comments, and so on.
• Documentation: The software should have clear,

concise, and up-to-date documentation that explains
how the software works, how it should be maintained,
and how to modify it.
• Code complexity: The software should have a low code

complexity, which means that the code should be
simple, easy to understand, and easy to modify. This
makes it easier for developers to add new features or
fix bugs.
• Testability: The software should be easily testable, and

the test cases should be well documented and easy
to execute. This helps in identifying bugs and fixing
them faster.
• Version control: The software should be under version

control to keep track of changes made to the software,
who made the changes, and when they were made.
This helps in troubleshooting and identifying issues.
26
• Error handling: The software should have appropriate

error handling mechanisms in place to handle errors
and failures. This helps in identifying and fixing
issues faster.
Overall, maintainability testing is essential to ensure that the software

can be updated, maintained, and supported over time, and that it remains
stable and reliable. By testing the software’s maintainability thoroughly,
testers can identify any issues and make recommendations to improve the
software’s maintainability. This helps ensure that the software remains of
high quality and meets user expectations over time.
Compliance Testing
Compliance testing is a type of software testing that ensures that software
applications meet certain regulatory, legal, and industry-specific
standards. This type of testing is essential to ensure that the software meets
legal and regulatory requirements and is safe and secure for users.
Compliance testing involves testing the software for compliance with
the following criteria:
• Legal and regulatory requirements: The software should

comply with applicable laws and regulations, such
as data privacy laws, security standards, accessibility
standards, and other industry-specific regulations.
• Security: The software should be secure and protect

sensitive data and information from unauthorized
access, theft, or misuse. Compliance testing should
evaluate the software’s security features, such as
encryption, access control, and secure communication
protocols.
27
• Data privacy: The software should be designed to

protect user data and comply with data privacy laws
and regulations. This includes the collection, storage,
and use of personal data, such as names, addresses,
and financial information.
• Accessibility: The software should be accessible to all

users, including those with disabilities. Compliance
testing should evaluate the software’s accessibility
features, such as keyboard navigation, screen reader
compatibility, and alternative text for images.
• Industry-specific standards: The software should

meet industry-specific standards, such as healthcare
standards, financial services standards, or government
standards.
• Documentation: The software should have clear and

up-to-date documentation that explains how the
software meets compliance requirements, how it
should be used, and how to handle any compliance
issues that may arise.
Overall, compliance testing is essential to ensure that the software
meets legal and regulatory requirements and is safe and secure for users.
By testing the software’s compliance thoroughly, testers can identify any
compliance issues and make recommendations to ensure that the software
meets the required standards. This helps ensure that the software remains
of high quality and meets user expectations.
28
Static Testing
Static testing is a software testing technique that involves the examination
of code or software documentation without actually executing the
program. The goal of static testing is to identify defects in the code,
requirements, or design before the software is actually executed. This type
of testing is also known as nonexecution testing or verification testing.
Code reviews involve a team of developers and/or testers reviewing
each other’s code to identify any defects or potential issues.
Requirements reviews are about reviewing the requirements
documentation to ensure that they are complete, clear, and accurate.
Design reviews where the team is reviewing the design documentation
to ensure that it meets the requirements and is technically feasible.
Walk-throughs usually are a team of developers looking through the
code or documentation to ensure that it meets the required specifications
and standards.
Inspections are a formal process of reviewing the code or
documentation to identify and document defects.
Code Reviews
Code review is a form of static testing that involves reviewing the
source code of a software application to identify defects, bugs, or other
issues that may impact performance or functionality. Code reviews are
typically performed by one or more individuals who have expertise in the
programming language, design patterns, and coding standards used in the
software application.
The goals of a code review are to identify any defects or issues that may
impact the quality or functionality of the software and to provide feedback
to the developer so that they can make improvements. Code reviews can
be performed manually, using a document or spreadsheet to track issues,
or via specialized software tools that automate the review process.
29
The following are some key benefits of code reviews:
• Improved code quality: Code reviews can help to

identify and address defects or issues early in the
development process, leading to improved code
quality.
• Knowledge sharing: Code reviews can help to share

knowledge and best practices among development
teams, leading to improved collaboration and
productivity.
• Reduced development time and costs: Code reviews

can help to identify defects or issues early in the
development process, reducing the time and costs
associated with testing and debugging.
• Improved maintainability: Code reviews can help

to ensure that the code is maintainable and easy to
update, reducing the risk of introducing new defects or
issues in future development.
Requirement Reviews
Requirement reviews are a form of static testing that involves reviewing the
software requirements to identify defects, errors, or inconsistencies. This
type of review is typically performed by stakeholders, including business
analysts, project managers, developers, testers, and end users.
The goal of a requirement review is to ensure that the software
requirements accurately reflect the needs and expectations of the
stakeholders and that they are complete, unambiguous, and consistent.
During the review process, stakeholders may ask questions, clarify
requirements, or suggest changes or additions to the requirements.
30
The following are some key benefits of requirement reviews:
• Improved software quality: Requirement reviews

can help to ensure that the software requirements
accurately reflect the needs and expectations of the
stakeholders, leading to improved software quality.
• Early defect detection: Requirement reviews can help

to identify defects or issues early in the development
process, before the software is executed.
• Reduced development time and costs: Requirement

reviews can help to ensure that the software
requirements are complete and accurate, reducing the
time and costs associated with rework or changes to the
requirements later in the development process.
• Improved stakeholder communication: Requirement

reviews can help to promote communication and
collaboration among stakeholders, leading to a shared
understanding of the software requirements.
Design Reviews
Design reviews are a form of static testing that involves reviewing the
design documents of a software application to identify defects, errors,
or inconsistencies. The design documents may include architectural
diagrams, flowcharts, data models, and other design artifacts that describe
how the software will be implemented.
The goal of a design review is to ensure that the software design meets
the requirements of the stakeholders, and that it is efficient, maintainable,
and scalable. During the review process, stakeholders may ask questions,
suggest improvements, or identify potential issues or risks in the design.
31
Another random document with
no related content on Scribd:
It is wonderful to me how I could have been so easily cast
away at such an age. It is wonderful to me that, even after my
descent into the poor little drudge I had been since we came to
London, no one had compassion on me—a child of singular
abilities, quick, eager, delicate, and soon hurt bodily or mentally
—to suggest that something might have been spared, as
certainly it might have been, to place me at any common school.
Our friends, I take it, were tired out. No one made any sign. My
father and mother were quite satisfied. They could hardly have
been more so if I had been twenty years of age, distinguished at
a Grammar School, and going to Cambridge.
Terrible words those: the more terrible for being, after long
repression, uttered so judicially.
And again:
I suppose my lodging was paid for by my father: I certainly

did not pay it myself, and I certainly had no other assistance
whatever—the making of my clothes, I think, excepted—from
Monday morning until Saturday night. No advice, no counsel, no
encouragement, no consolation, no support, from anyone that I
can call to mind, so help me God!
Nor did his parents’ neglect end with starving his heart’s affection,
his brain’s activity. It starved the weak little body into spasms through
malnutrition. He had a boy friend in the warehouse, one Bob Fagin.
Dickens writes of this time:
Bob Fagin was very good to me on the occasion of a bad

attack of my old disorder. I suffered such excruciating pain that
they made a temporary bed of straw in my old recess in the
counting-house, and I rolled about on the floor, and Bob filled
empty blacking-bottles with hot water, and applied relays of them
to my side half the day. I got better and quite easy towards
evening; but Bob (who was much bigger and older than I) did not
like the idea of my going home alone, and took me under his
protection. I was too proud to let him know about the prison; and
after making several efforts to get rid of him, to all of which Bob
Fagin in his goodness was deaf, shook hands with him on the
steps of a house near Southwark Bridge on the Surrey side,
making believe that I lived there. As a finishing piece of reality, in
case of his looking back, I knocked at the door, I recollect, and
asked, when the woman opened it, was that Mr. Robert Fagin’s
house?
O caeca pectora! Dickens had hard streaks in him, and I confess to

a curious wonderment how, afterwards, he could have used that
name of Fagin—how he could have used it as he did—in Oliver
Twist.
But I end by repeating my question—Is it any wonder that this
street-boy of genius, coming to his own, invoked out of the theatre a
new world, to redress the balance of his old?
Of that new world I propose to say something, Gentlemen, a
fortnight hence.
DICKENS (IV)
PREFACE
I THINK it meet, Gentlemen, that before we resume our subject to-day,
a word should be said on a loss that has befallen English letters in
general and our sister-University in particular, since I last addressed
you.
Walter Raleigh was an authentic son of Cambridge: and although
he spent the most of his life teaching in other places the better
understanding of a literature—our own literature—which in his
undergraduate days had not found adequate recognition here, yet
Cambridge had been his pasture, and he carried everywhere the
mettle of that pasture: yes, and unmistakably, and although by the gay
sincerity of his nature he would win men to like him, wherever he went.
Personal affection may count for too much in my faith that he will
some day be recognised, not only for a true son of Cambridge, but for
a great one in his generation. I put, however, that reckoning on one
side. He did, very gaily and manfully and well, all the work that fell to
his hand; and his end was in this wise. He had, in the first and second
weeks of August, 1914, been eye-witness at Oxford of one of two
amazing scenes—the other simultaneously passing here—when in
these precincts, in these courts of unconscious preparation, by these
two sacred streams, all on a sudden the spirit of youth was a host
incorporate.
Χρυσῷ δ’ ἄρα Δῆλος ἅπασα

ἤνθησ’, ὡς ὅτε τε ῥίον οὔρεος ἄνθεσιν ὕλης.
“Then Delos broke in gold, as a mountain spur is canopied in
season with the flowering bush.”
“The mettle of your pasture” ... “Multitudes, multitudes in the valley of

decision” ... and the host, so suddenly gathered, as suddenly in
motion, gone, for their country’s sake challenging the scythe. Raleigh
saw that with his eyes, and could not forget.
* * * * *
The Dean of St. Paul’s returned, the other day, to a rightly
respectful Cambridge, to deliver a Rede Lecture to us on The Victorian
Age. Now he is a fool who denies or doubts Dean Inge to be a great
man of our time—though he may now and then be a little too apt to
regard himself as the only widow of another. Dean Inge, at any rate,
felt himself strong enough to tell you he had no doubt that, to the
historian of the future, the Elizabethan and Victorian Ages will appear
as “the twin peaks in which English civilisation culminated.”
Now I have been talking to you—already through three lectures—
upon the best-beloved writer of that Victorian Age—its most
representative writer, perhaps—and preaching his eminence. But I
should be nervous of claiming quite all that! It seems to me, if I may
put it so without offence, a somewhat complacent view for us to take of
an Age in which we were born—he, to unseal the vials of prophecy, I,
just to happen along with the compensation of a more sanguine
temperament. He admits that he has “no wish to offer an unmeasured
panegyric on an age which after all cannot be divested of the
responsibility for making our own inevitable.” He admits that “the
twentieth century will doubtless be full of interest, and may even
develop some elements of greatness.” But as regards this country, “the
signs are that our work on a grand scale, with the whole world as our
stage, is probably nearing its end.” Well, I dare to say that such talk
from a man of the Dean’s age or mine is more than unhopeful; is
ungrateful:
Difficilis, querulus, laudator temporis acti....
Would he but go back in memory to the tempus actum of August,
1914, it may dawn upon him that “fears may be liars” and the likelier
for that some hopes were not dupes: that some men less gifted, less
eloquent, than he, in those August days of 1914 saw this vision as of a
farther Pacific:
Silent, upon a peak in Darien.
Raleigh at any rate saw it: I would not use extravagant language,
but I verily believe Raleigh, from that hour, saw the assembled chivalry
of those boys of 1914 as a meadow of cloth-of-gold spreading past all
known or prophetical horizons—a prairie, the scent over which was a
scent of sacrifice, at once holy and intolerable. Let me repeat—for one
does not ring changes on the loss of a friend—the mourning bell
strikes once and repeats itself—let me repeat some words written, the
other night, under durance on returning from his funeral:
In his last few years, under an invincible inward compulsion,

he turned from his life’s trade, in which he had vindicated himself
as one of the best few, to become a child again and learn to be a
valiant soldier. The sacrifice of the young in 1914–18, about which
so many talk so easily, was a torture to him: it cut to the bone, the
marrow. It was matter for indignation that he should survive these
many boys.... Some of us, who noted, almost from the first, the
operation of the War upon Raleigh’s soul, foreboded that in some
way or other it would cut short his span, or, at least, that it
menaced him. His converse again and again would wander away
from the old writers, once his heart-fellows, to machinery, air-
fights, anything.... When I last talked with him he was full of his
History of the Air Service in the War, the first volume of which is in
the press, I believe. For the second he went out to survey, from
the air, the fields of campaign in Mesopotamia, took typhoid in
Baghdad, and came home just in time to die.
It is a purely simple story: of a great teacher who saw his pupils go

from him on a call more instant than his teaching, and followed their
shades with no thought of
So were I equall’d with them in renown
but the thought only to overtake them in service.
* * * * *
Forgive the length of my discourse, Gentlemen. It is right, I think,
that our sister-Universities should feel one for the other’s pride, one for
the other’s wound.
I
To take up our tale—
It has already been objected against these lectures on Dickens—or
against such parts of them as the newspapers honour me by quoting—
that they treat Dickens as a genius of the first class. That term has little
meaning for me who seldom or never think—can hardly bring myself to
think—of great men in class-lists, in terms of a Tripos. (I reserve that
somewhat crude method of criticism to practise it upon those who are
going to be great men; and even so—if you will credit me—derive
scant enjoyment from it.) But I foresaw the objection, and forestalled it
by quoting a famous saying of Tasso, and I take my stand on that: as I
take not the smallest interest in weighing Chaucer against Pope,
Shakespeare against Milton, Scott against Burns, or Dickens against
Thackeray. Chaucer, Shakespeare, Scott, Dickens—their other
qualities apart—are grand creators, lords of literature all, by this
specific virtue; and, were there sense in challenging, with this quadriga
alone we could securely challenge any literature in any living tongue.
Note you, moreover: it is to this creative power that other artists less
creative, but great and therefore generous, instinctively pay homage:
Dryden, for instance, or Byron:
’Tis to create, and in creating live

A being more intense that we endow
With form our fancy, gaining as we give
The life we image, even as I do now.
What am I? Nothing: but not so art thou,
Soul of my thought!...
(Childe Harold, iii. 6.)
Or again:
The mind can make

Substance, and people planets of its own
With beings brighter than have been, and give
A breath to forms which can outlive all flesh....
(The Dream, st. 1.)
Note you particularly, if you will, the words “planets of its own....” We
talk too often, perhaps (I have talked in this fashion myself
unheedingly), as if these men had been makers of picture-galleries,
lining their walls with lively characters, brilliant portraits. But in truth
neither Chaucer’s Prologue nor Shakespeare’s succession of women,
neither Redgauntlet nor David Copperfield, is a gallery of characters;
but a planet rather, with its own atmosphere which the characters
breathe; in which as proper inhabitants they move easily and have
their natural being: while for us all great literature is a catholic hostelry,
in which we seat ourselves at the board with Falstaff, Dugald Dalgetty,
Sam Weller, the Wife of Bath, Mrs. Gamp and Mrs. Quickly, and
wonder how soon Don Quixote, My Uncle Toby, or The Three
Musketeers will knock in to share the good meat and the wine.
II
So, between a discussion of Dickens’ plots—which we examined a
fortnight ago and found wanting—at once stagey and ill-knit and, at
that, repetitive, poor in invention; and of his characters, which teemed
from his brain in a procession closed only by their author’s death, so
inexhaustibly various and withal so individual, vivid and distinct, that
the critic can scarcely help telling himself, “Here, and only here, must
lie the secret of the man’s genius”; I shall interpose to-day a few words
upon this world of Dickens, with its atmosphere.
For it is a strange world, with an atmosphere of its own, as strange
as itself.
I have already noted some things of that world of his—that it was a
crowded world: a world of the city, of the streets; that his novels, when
they visit the country, take us at a violent rate in post-chaises to find,
with Shenstone,
The warmest welcome at an inn.
For one moment, at the term of Little Nell’s wanderings, in the quiet of
the old schoolmaster’s garden, we almost touch a sense of country
rest and repose. But of real country, of solid growth in rest, of sport, of
gardens, of farms and tenantry, of harvests, of generations rooted,
corroborated in old grudges, old charities; of all that England stood for
in Dickens’ day and, of its sap, fed what Cobbett had already called the
“Great Wen” of London, our author had about as much sense as Mr.
Winkle of a horse, or a snipe.
Now I wish to be rather particularly scrupulous just here: for we are
dealing with a peculiarly, an unmistakably genuine, English writer; who,
himself a child of the streets, acquainted, by eyesight and daily wont,
with an industrial England into which the old agricultural England—
what with railway and factory, gas, and everything extractible from coal
—was rapidly converting itself; did yet by instinct seize on the ancient
virtues. Take away the hospitality, the punch and mistletoe, from
Dingley Dell, and what sort of a country house is left? Why, the
Handley Cross series, for which Messrs. Chapman and Hall intended
Pickwick as a stale challenge, could give Pickwick ten and a beating
from the first. As the season comes round you play cricket at Dingley
Dell, or you skate, or you mix the bowl and turn the toe. But the
stubble-fields are not there, nor the partridges; nor the turnips, nor the
gallops to hounds, nor the tillage and reaping, nor the drowsed
evenings with tired dogs a-stretch by the hearth. Of all this side of
England Dickens knew, of acquaintance, nothing. I am not speaking,
you will understand, of any Wordsworthian intimacy with natural
scenery tender or sublime, of anything imparted or suggested to the
imagination by a primrose or in the “sounding cataract” haunting it “like
a passion.” I am speaking rather of human life as lived in rural England
in Dickens’ time and in some corners yet surviving the week-end habit.
Of these Sabine virtues, of these Sabine amenities and hardships, of
the countryman’s eye on the weather-glass for “snow and vapours,
wind and storm, fulfilling His word,” Dickens (I repeat) had no sense,
having no tradition, of field life, of that neighbourliness which existed in
quiet places and persisted around ancient houses:
The summer air of this green hill

’Va-heaved in bosoms now all still,
And all their hopes and all their tears
Be unknown things of other years....
So, if ’twere mine, I’d let alone
The great old House of mossy stone.
Dickens loved the old stage-coaches and travel by them. What he

thought of the new railways and their effect upon landscape, you may
read in Dombey and Son. He lived, moreover, to undergo the
chastening experience of a railway collision. But his actual sense of
the country you may translate for yourself from the account, in Bleak
House, of the country life of Sir Leicester and Lady Dedlock. It is worse
than stupid: it is vapid: or, rather, it is not there at all. Will you conceive
Dickens, closing one of those Adelphi-Dedlock chapters and running
his head suddenly into Mr. Wilfrid Blunt’s ballad of The Old Squire?
I like the hunting of the hare

Better than that of the fox;
The new world still is all less fair
Than the old world it mocks....
I leave my neighbours to their thought;

My choice it is, and pride,
On my own lands to find my sport,
In my own fields to ride....
Nor has the world a better thing
Though one should search it round,
Than thus to live, one’s own sole king
Upon one’s own sole ground.
I like the hunting of the hare;

It brings me, day by day,
The memory of old days as fair
With dead men past away.
To these, as homeward still I ply

And pass the churchyard gate
Where all are laid as I must lie,
I stop and raise my hat.
I like the hunting of the hare;

New sports I hold in scorn.
I like to be as my fathers were
In the days e’er I was born.
For a figure like that—hopelessly conservative, if you will, but

conceived of truth, Dickens could only substitute a week-ender (as we
should say nowadays) and make him a pompous ass. By one touch or
two, of understanding what “the stately homes of England” really stood
for—their virtue along with their stupidity—by one touch of Jane
Austen’s wit, shall we say?—Dickens might have made some sort of a
fist of it. As it is, when he wanders anywhere into the country, he is a
lost child, mooning incuriously along the hedgerows with an
impercipience rivalling that of a famous Master of Trinity who once
confessed that his ignorance of botany was conterminous with all
Solomon’s knowledge, since it ranged from the cedar of Lebanon to
the hyssop that grows in the wall. Dickens’ favourite flower (we have it
on record) was a scarlet geranium!
Still, I would be fair, and must mention a fact which I have
experimentally discovered for myself and tested of late in the slow
process of compiling a Book of English Prose (an “Oxford Book,” if you
will forgive me), that, while our poetry from the very first—from “Sumer
is icumen in; Lhude sing cuccu!”—positively riots in country scenes,
sounds, scents, country delights:
—all foison, all abundance,
and soothes us with the deep joy of it, with music and “the herb called
heart’s-ease,” of all such joy, even of all such perception, our prose,
until we come to the middle of the last century, is correspondently
barren. Consider what a unique thing, and unique for generations, was
The Compleat Angler! Try of your memory to match it. An Essay of
Temple’s? a few pages of Bunyan, of Evelyn? The Sir Roger de
Coverly papers?—charming; but of the town, surely, and with
something of Saturday-to-Monday patronage not only in pose but in
raison d’être? Fielding understood the country better—witness his
Squire Allworthy. But on the whole, and in fairness, if Dickens’ pages
exhibit—and they do—a thin theatrical picture of rural England, without
core or atmosphere, against his childhood’s disinheritance—against
the mean streets and the Marshalsea—we must balance (if I may use
a paradoxical term) the weight of traditional vacuity.
III
But I fear we have a great deal more to empty out of this world of
his.
To begin with, we must jettison religion; or at any rate all religion
that gets near to definition by words in a Credo. Religious formulae I
think we may say that he hated; and equally that he had little use for
ministers of religion. I can recall but one sympathetic portrait of an
Anglican parson—the Reverend Septimus Crisparkle, Minor Canon of
Cloisterham—and that in his last book, and with scarcely a shadow of
a quality impinged upon it by his vocation, by Holy Orders: Crisparkle,
Minor Canon and muscular Christian, well visualised, is a good fellow
just as Tartar in the same story is a good fellow: nothing more. George
Eliot and Charlotte Brontë, who disliked ecclesiastics, have to give
them understanding, even sympathy, in some degree. Dickens merely
neglects them. Unaccredited missionaries of the Gospel are humbugs
all, in Dickens; uneducated Pharisees, Stiggins’s, Chadbands;
devourers of widows’ (and widowers’) houses; spongers on the
kindness and credulity of poor folk just a little more ignorant than they,
while far more innocent. As for sacred edifices—cathedrals, churches
—Dickens uses them as picturesque, romantic, mouldy, just as suits
his convenience—a last harbourage for Little Nell or an object with a
steeple suggesting to Mr. Wemmick—“Hullo! here’s a church!... let’s
get married!” If Dickens ever conceives of a church as a tabernacle of
any faith, I have yet to find the passage.
You must remember that, while Dickens wrote, Tractarian
Movements, Unitarian Movements, Positivist Movements—Wiseman’s
claim, Newman’s secession, the Gorham judgment, Bishop Colenso’s
heresies—Darwin’s hypothesis, Huxley’s agnostic rejection of doctrine,
and so on—that all these were agitating men’s thoughts as with a
succession of shocks of earthquake. But all these passed Dickens by,
as little observed as felt by him: simply disregarded.
IV
Of political thought, again, his world is almost as empty. He was, in
his way, an early-Victorian Radical. When he saw a legal or political
hardship which hurt or depressed the poor, conventions injurious to the
Commonwealth—the Poor Laws, Debtors’ Prisons, the Court of
Chancery, the Patent (or Circumlocution) Office and so forth, with the
people who batten on such conventions, taking them for granted as
immutable—Dickens struck hard and often effectively. But he struck at
what he saw under his own eyes. Beyond this immediate indignation
he had no reasoned principles of political or social reform. I have to
hand, at this moment, no evidence to confirm a guess which I will
nevertheless hazard, that he hated Jeremy Bentham and all his works.
Certainly the professional, bullying, committee-working philanthropists
—Mrs. Jellaby and Mr. Honeythunder, whose successors pullulate in
this age—were the very devil to him. His simple formula ever was—in
an age when Parliament carried a strong tradition of respect—“Yes, my
Lords and Gentlemen, look on this waif, this corpse, this broken life.
Lost, broken, dead, my Lords and Gentlemen, and all through your
acquiescence, your misfeasance, your neglect!” To the immediate
reader his message ran simply, “Take into your heart God’s most
excellent gift of Charity: by which I mean let Charity begin at home, in
that kingdom of God which is within you, let it operate in your own daily
work; let it but extend to your own neighbours who need your help; and
so—and only so—will the city of God be established on earth.”
V
I perceive, Gentlemen, that in my hurry I have let slip a great part
of the secret, and so will add but this in hasty summary, catching up,
before retreat, my cloak of advocatus diaboli:
(1) In the first place, Dickens’ world was not a world of ideas at all,
but a city “full of folk.” Compared with the world as Carlyle saw it, or
Clough, or Martineau, or Newman, or Arnold, it is void of ideas, if not
entirely unintellectual.
(2) Moreover, and secondly, it is a vivid hurrying world; but the
characters in it—until you come to Pip, say, in Great Expectations—are
all quite curiously static; and, as the exception proves the rule, I am not
afraid to back this assertion against Martin Chuzzlewit, for example, in
which young Martin is, of set purpose, to be converted out of the family
selfishness. Things happen to Mr. Pecksniff, to Little Nell, to Mr.
Micawber, to Mr. Dombey, to Bradley Headstone and Eugene
Wraybourne, to Sally Brass and her brother: but, as the rule, these
things do not happen within them, as such things happen in the soul of
any protagonist in a novel by Tolstoy or Dostoievsky, or as they are
intended and traced as happening (say) in Romola. Dombey’s
conversion is a mere stage-trick; and, for Micawber’s apotheosis as a
prosperous colonist, let him believe it who will.
VI
Further—and to conclude on this point—over and beyond its
infertility of thought, Dickens’ is a world in which technical or
professional skill never comes into play to promote anything on earth.
We have spoken of his clergy. His innumerous lawyers, from the Lord
Chancellor to Messrs. Dodson and Fogg (assisted by his own personal
experience in the Law’s service), draw their money for exculpating the
guilty or slowly killing the righteous through hope deferred:
The oppressor’s wrong, the proud man’s contumely,

The pangs of dispriz’d love, the law’s delay,
The insolence of office—
Equally with lawyers (readers of epitaphs and of David Copperfield will

take the allusion) “physicians are in vain.” It would be interesting [I do
not suggest it as a subject of research for a Ph.D. degree] to count the
number of births in Dickens’ novels and discover an accoucheur who
did not contrive to lose either the mother or the child, or both.
VII
What remains, then, of a world thus emptied of religion, thought,
science?
I reserve the answer for a minute or two.
But I start my approach to it thus: Be the world of Dickens what
you will, he had the first demiurgic gift, of entirely believing in what he
created. The belief may be as frantic as you will: for any true artist it is
the first condition. Well, this remains: nobody has ever doubted that, in
the preface to David Copperfield, he wrote the strict truth:
It would concern the reader little, perhaps, to know how

sorrowfully the pen is laid down at the end of a two-years’
imaginative task; or how an Author feels as if he were dismissing
some portion of himself into the shadowy world, when a crowd of
all the creatures of his brain are going from him forever. Yet I had
nothing else to tell, unless indeed I were to confess (which might
be of less moment still) that no one can ever believe this Narrative
in the reading more than I believed it in the writing.
Well, there, Gentlemen—just there, and so simply—you have the first

condition of a work of art—its own creator is so possessed that he
thoroughly believes in it. As Henry James once said to me (I recall the
words as nearly as I can), “Ah, yes, how jollily the little figures dance
under the circle of the lamp, until Good-bye, and off they go, to take
their chance of the dark!”
VIII
Having that, you have artistic sincerity: of which I wonder, as
experience enlarges, how many faults it cannot excuse—or indeed
what is the fault it cannot excuse.
All that remains of the merely artistic secret has been summarised
by Mr. Saintsbury:
It cannot have taken many people of any competence in

criticism very long to discover where, at least in a general way, the
secret of this “new world” of Dickens lies. It lies, of course, in the
combination of the strictest realism of detail with a fairy-tale
unrealism of general atmosphere. The note of one or the other or
both, is sometimes forced and then there is a jar: in the later books
this is frequently the case. But in Pickwick it hardly ever occurs;
and therefore, to all happily fit persons, the “suspension of
disbelief,” to adopt and shift Coleridge’s great dictum from verse to
prose fiction, is, except in the case of some of the short inset
stories, never rudely broken. Never, probably, was there a writer
who knew or cared less about Aristotle than Dickens did. If he had
spoken of the father of criticism, he would probably have talked—
one is not certain that he has not sometimes come near to talking
—some of his worst stuff. But certainly, when he did master it
(which was often) nobody ever mastered better than Dickens, in
practice, the Aristotelian doctrine of the impossibility rendered
probable or not improbable.
Well, there you have the artistic secret of Dickens’ world accurately
given, and not by me. It lies in the combination of the strictest realism
of detail with a fairy-tale unrealism of general atmosphere.
Let me give you, to illustrate this, a single instance out of many. In
his Christmas story, The Perils of Certain English Prisoners—an
adventurous story of the sort that Stevenson loved and some of you
make the mistake of despising—a handful of a British garrison with
their women and children in a stockaded fort in South America tensely
await an attack of pirates hopelessly outnumbering them. Now listen to
one paragraph:
(It is a corporal of Marines who tells it.)
“Close up here, men, and gentlemen all!” said the sergeant. “A

place too many in the line.”
The pirates were so close upon us at this time that the
foremost of them were already before the gate. More and more
came up with a great noise, and shouting loudly. When we
believed from the sound that they were all there, we gave three
English cheers. The poor little children joined, and were so fully
convinced of our being at play, that they enjoyed the noise, and
were heard clapping their hands in the silence that followed.
Defoe within his limits does that sort of thing to perfection: but then
Defoe’s world observes the limits of the “real” (as we absurdly call
everything that is not spiritual), has little emotion, scintillates scarce a
glimmer of humour. Dickens handles it in a phantasmagoric world,
charged even to excess with emotion, and is not in the least afraid to
employ it—I quote Mr. Saintsbury again:
Of invading those confines of nonsense which Hazlitt proudly

and wisely claimed as the appanage and province of every
Englishman.
I need but to instance a writer whose acquaintance Hazlitt had not
the joy to make, nor Lamb—woe upon these divisions of time!—Lewis
Carroll, in whom both would have revelled for his insane logicality of
detail—or, if you prefer it, I will fall back upon Lear’s Nonsense Books
or even upon A Midsummer-Night’s Dream—to convince you that, as a
nation, we have this appanage: and if it bewilder a foreigner, or he
deride it, why then we will give him a look, and pass.
IX
Yes, but there is something else.
What else—no mere artistic secret—ties this phantasmagoric
world to ours and makes it universal with ours, conterminous, and so
real?
It is no dodge or trick of artistry that can work so incredible a feat—
that can open our hearts to such beings as Dick Swiveller and Mrs.
Gamp (whom in private life you or I would avoid like the plague)—to
enjoy their company, to hang on every word they utter. It must be some
very simple catholic gift, thus to unite the unreal with the real, thus to
make brothers and sisters of all men and women, high or low.
It is: nor shall I delay you by elaborate pretence to search for it. For
I know; and you know, or will recognise it as soon as I utter the word. It
is Charity; the inestimable gift of Charity that Dickens flings over all
things as his magic mantle: so that, whether there be prophecies, they
shall fail; whether there be tongues, they shall cease; whether there be
knowledge, it shall vanish away; and whether there be little critics
tormented about Dickens’ style, in the folds of that mantle they shall be
folded and hushed:
That it may please Thee to preserve all that travel by land or

by water, all women labouring of child, sick persons, and young
children; and to shew Thy pity upon all prisoners and captives.
That it may please Thee to defend, and provide for, the
fatherless children, and widows, and all that are desolate and
oppressed.
That is the last secret of Dickens: and that is what George Santayana
means when he writes:
If Christendom should lose everything that is now in the

melting-pot, human life would still remain amiable and quite
adequately human. I draw this comforting assurance from the
pages of Dickens.
DICKENS (V)
I
“I REMEMBER,” says Henry James in a wise little Essay on The Art
of Fiction—
I remember an English novelist, a woman of genius, telling

me that she was much commended for the impression she had
managed to give in one of her tales of the nature and way of life
of the French Protestant youth. She had been asked where she
learned so much about this recondite being, she had been
congratulated on her peculiar opportunities. These opportunities
consisted in her having, once, in Paris, as she ascended a
staircase, passed an open door where, in the household of a
pasteur, some of the young Protestants were seated at table
round a finished meal. The glimpse made a picture; it lasted only
a moment, but that moment was experience.
I wish I could make you promise, Gentlemen, to bear this little

story in mind whenever some solemn fellow assures you that a man
rustically born and bred could not have written Hamlet or The
Tempest; “he would never have seen this, learned or experienced
that” and so on: the simple answer being that under such
disadvantage they would never have written Hamlet or The Tempest.
They are, in fact, not even Shakespeares to the extent of
understanding how an artist creates, how the imaginative mind
operates.
Henry James, who was an artist and understood that operation,
simply comments on his anecdote that the lady had caught her direct
personal impression and it was enough:
She knew what youth was, and what Protestantism: she also
had the advantage of having seen what it was to be French, so
that she converted these ideas into a concrete image and
produced a reality.
Above all, however, she was blessed with the faculty which
when you give it an inch takes an ell, and which for the artist is a
much greater source of strength than any accident of residence
or of place in the social scale. The power to guess the unseen
from the seen, to trace the implication of things, to judge the
whole piece by the pattern, the condition of feeling life in general
so completely that you are well on your way to knowing any
particular corner of it—this cluster of gifts may almost be said to
constitute experience, and they occur in country and in town,
and in the most different stages of education.
Yes, Mr. James, for the purpose of your immediate argument

“this cluster of gifts may almost be said to constitute experience.” But
for our argument it does, and accurately, constitute imaginative
genius. It is the gift that taught Xenophanes, watching the stars, to
catch the whole piece from the pattern and cry out “All is one—” the
gift that suddenly hitches the particular upon the universal and gives
us a Falstaff, a Don Quixote, a Tartuffe, My Uncle Toby, the Vicar of
Wakefield—
Forms more real than living man.
You know—you must know—that none of these is a
photographic portrait of a living person—of a certain eccentric lodger
whom Dickens had studied in Goswell Street, of a certain bibulous
nurse resident in Kingsgate Street, High Holborn, “at a bird-fancier’s,
next door but one to the celebrated mutton-pie shop”—but children
of imagination begotten upon it by some such observant moment as
was vital to Mr. James’s lady novelist. What, in fact, was the genesis
of Mr. Pickwick? Dickens, you recall, was to write the letterpress
accompaniment to a series of humorous sporting sketches by
Seymour. The publisher Mr. Chapman, of Chapman and Hall, has
left this uncontradicted record:

Introduction To Software Testing A Practical Guide To Testing Design Automation and Execution 1St Edition Panagiotis Leloudas Full Chapter

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Introduction To Software Testing A Practical Guide To Testing Design Automation and Execution 1St Edition Panagiotis Leloudas Full Chapter

Загружено:

Авторское право:

Доступные форматы

Introduction to Software Testing: A

Practical Guide to Testing, Design,

ISBN-13 (pbk): 978-1-4842-9513-7 ISBN-13 (electronic): 978-1-4842-9514-4

Copyright © 2023 by Panagiotis Leloudas

About the Technical Reviewer�����������������������������������������������������������xiii

Chapter 1: The Importance of Software Testing�����������������������������������1

Chapter 2: Software Testing Types and Techniques�����������������������������5

Chapter 3: Software Development Life Cycle��������������������������������������35

Chapter 4: Test Planning���������������������������������������������������������������������57

Defect Management Process������������������������������������������������������������������������������66

Chapter 5: Test Design Techniques�����������������������������������������������������75

Chapter 6: Test Execution�����������������������������������������������������������������137

Chapter 7: Test Automation��������������������������������������������������������������161

Chapter 8: Testing in Agile Environment������������������������������������������173

Chapter 9: Challenges and Solutions in Software Testing����������������189

Lack of Skilled Resources���������������������������������������������������������������������������������193

© Panagiotis Leloudas 2023 1

Another misconception is that testing can be eliminated by writing

Software testing is an ongoing process that continues throughout the

Project managers are responsible for managing project timelines,

© Panagiotis Leloudas 2023 5

Figure 2-1. The testing pyramid

Unit testing involves testing individual units or components of the

• Isolation: Unit tests are designed to test individual units

• Coverage: Unit tests should provide coverage for all

• Independence: Unit tests should be independent of

• Maintainability: Unit tests should be easy to maintain

The following are the main benefits of unit testing:

• Early detection of bugs: By testing individual units in

• Faster debugging: Unit testing allows developers to

• Better code quality: Unit testing forces developers to

• Improved design: Unit testing encourages developers

Overall, unit testing is an essential practice in software development

• Component-level integration: This involves testing the

• System-level integration: This involves testing the

• End-to-end integration: This involves testing the

During integration testing, different types of testing techniques are

• Big Bang integration testing: In this type of testing, all

• Incremental integration testing: In this type of testing,

• Bottom-up integration testing: In this type of testing,

• Sandpit integration testing: In this type of testing, a

User Acceptance Testing

• User involvement: UAT involves end users or

• Real-world testing: UAT involves testing the software

• Validation of business requirements: UAT ensures that

• Acceptance criteria: UAT defines acceptance criteria

• Sign-off: UAT requires the sign-off of the user or

The primary objectives of UAT are as follows:

• To validate the system’s functionality from an end

• To check whether the system meets the business

• To ensure that the system is user-friendly and

• To find defects that were not detected in previous

• To reduce the risk of system failure in production

There are three types of UAT:

• Beta testing: It is performed by a group of end users in

• Acceptance testing: It is performed by the end users

• Load testing: This type of testing evaluates how an

• Stress testing: This type of testing is performed to

• Spike testing: This type of testing is used to evaluate

• Endurance testing: This type of testing is used to

• Volume testing: This type of testing is used to evaluate

• Scalability testing: Scalability testing involves testing

• Soak testing: Soak testing involves testing the system

About the Technical Reviewer��xiii

Chapter 1: The Importance of Software Testing��1

Chapter 2: Software Testing Types and Techniques��5

Chapter 3: Software Development Life Cycle��35

Chapter 4: Test Planning��57

Defect Management Process��66

Chapter 5: Test Design Techniques��75

Chapter 6: Test Execution��137

Chapter 7: Test Automation��161

Chapter 8: Testing in Agile Environment��173

Chapter 9: Challenges and Solutions in Software Testing��189

Lack of Skilled Resources��193

User Acceptance Testing