Software Testing

From the first failing unit test to mutation testing, Selenium, the load test before launch day and the leading of testers, the practice as told through the free samples of the Leanpub books about software testing.

Created from the free samples of 27 Leanpub books and the descriptions and tables of contents of 25 more, with every source cited.

Software testing is the work of finding out what a piece of software actually does, as distinct from what its authors believe it does, and reporting that to the people who decide what happens next. One source defines it as checking and exploring a test object and its environment to discover new and relevant information, and insists that testing by itself neither improves nor lowers quality: the defects were already there, and only a change to the product can remove them.[1] The oldest reason for the discipline is the one a beginner's guide opens with: people are poor at noticing their own mistakes, and a programmer who has spent days on a feature will test it along the paths they planned for, a confirmation bias the guide's author illustrates with the craters he saw on early pictures of Pluto that turned out not to be there.[3]

The field divides along two lines. One is who does the testing and at what level: unit tests written by programmers against a single class or function, integration and end-to-end tests that drive the assembled system, exploratory testing by a person with a charter rather than a script, and the leadership that decides how much of each is enough. The other is what is being tested for: correctness, which most of the literature is about, but also performance under load, the testability of the architecture itself and, since the mid-2010s, behaviour in production under monitoring, canary releases and controlled rollouts. Tooling runs through all of it, from JUnit, RSpec, Jest and Pester at the unit level, through Selenium, WebdriverIO and REST Assured for browsers and APIs, to JMeter and browser-based load generation for performance.

This article follows that division: what testing is for, unit tests and test-driven development, automating the browser and the API, performance and load, the deployment pipeline and production, and the agile team, testability and the tester's own craft. Its sources are the free samples of the Leanpub books listed at the end, and the public descriptions and tables of contents of those whose samples were not available; where a sample states something, the sentence cites it, and the rest is general knowledge of the field.

Where to start

Someone new to testing as a job has two short starting points written for exactly that reader. How To Test (2016) is a free guide meant to be worked through in a couple of days by a newcomer, with exercises on public registration and login forms and notes for the mentor who will debrief them,[3] and TESTink Zine Issue 1 is a six-page zine whose first issue asks the reader to write their own definition of testing.[4] A reader who wants the profession's own voice before its technique has Around the World with 80 Software Testers, short essays from testers in 32 countries on effectiveness, trust, automation and careers,[5] and "Dear Evil Tester" (2016), an agony column for working testers that answers real questions with humour and scorn.[6]

A programmer who already writes code but not tests should start with the framework book for their language, because each of those assumes the language and nothing about testing. Everyday Rails Testing with RSpec takes an existing Rails application from untested to tested and states its author's three tests for a test up front, that it be reliable, easy to write and easy to understand;[7] The Pester Book does the same for PowerShell with Pester, from a first failing test to mocking and infrastructure checks;[8] Testing Vue.js components with Jest (2019) and Unit Testing con Jest y Testing Library en Angular cover Vue and Angular components with Jest, the latter in Spanish;[9][10] and Testing Spring Boot Applications Demystified organises Spring Boot testing by its test slices.[11] A tester who needs to learn to program in order to automate has Java For Testers (2015), which teaches Java through JUnit tests instead of a main method and says in its introduction that testers use Java differently.[12] Then come the books that assume the basics: Working Effectively with Unit Tests (2015), for anyone already writing unit tests who finds them hard to read,[13] Test-Driven Development: Extensive Tutorial, a long free tutorial on test-driven development from first principles,[14] and Fifty Quick Ideas to Improve Your Tests (2016), which says of itself that it is not the first testing book to read.[15]

For the web tester, Selenium WebDriver Recipes in Ruby and Selenium WebDriver Recipes in Java are reference cookbooks of about two hundred runnable scripts each, arranged by problem,[16][17] and The Web App Testing Guidebook argues the case for UI automation, and the case against it in some situations, before it shows any code.[18] For load testing, Practical Performance and Load Testing assumes no prior experience,[19] where Master Apache JMeter From load testing to DevOps. warns in its preface that it may be too condensed for absolute beginners.[20] For anyone put in charge of testing without a testing background, Leading Testing Activities was written for that person,[21] and ACT 2 LEAD says in its foreword that it is not a book that teaches you how to test but one for understanding and leading it.[1]

History

Testing is as old as programming, and for its first decades it was hard to tell from debugging: a program was run, its output inspected, and the author fixed what was wrong. The idea that testing is a separate activity with its own goal, finding errors rather than demonstrating that a program works, took hold in the 1970s, and the first full-length treatments of test design, equivalence partitioning, boundary values and the distinction between black-box and white-box testing date from the same period. One of the sources recalls what testing meant on a home computer of the early 1980s, where a game was typed in line by line from a magazine listing and then had to be tested to see whether the code had been copied correctly.[1]

The modern shape of the field arrived with Extreme Programming at the end of the 1990s. Kent Beck's JUnit, and the xUnit frameworks that copied it into every language, gave programmers a cheap way to write automated checks, and test-driven development made writing the test first a discipline rather than an accident. The foreword to a 2015 book could observe that consensus had finally formed around unit testing as a necessity for most projects, even though people still struggled with the design decisions tests force on them.[13] Browser automation followed. Selenium was created in 2004 by Jason Huggins at ThoughtWorks, merged with Simon Stewart's WebDriver in Selenium 2.0 in July 2011, became a W3C standard with support from every major browser vendor, and was followed by Selenium 3.0 in October 2016 and Selenium 4 in October 2021.[17] By 2011 one author found WebDriver the most wanted testing skill in job advertisements on Australia's largest job site.[16]

Agile methods changed who tests. Where traditional approaches saw testing as a final step after development, iterative delivery made it continuous and shared, with developers writing tests for their code, analysts refining use cases and testers building strategy and automation.[23] Mike Cohn's 2009 article on the forgotten layer of the test automation pyramid, with its unit, service and user-interface tiers, became the standard picture, so widely redrawn that many later versions replaced the middle tier with acceptance tests and confused the whole idea.[15] The agile testing quadrants and the whole-team approach, condensed by Janet Gregory and Lisa Crispin from their 2009 and 2014 books, gave the role its vocabulary.[24] In performance testing, Apache JMeter overtook LoadRunner as the most popular load testing tool by 2018, measured by documents and job advertisements, and its scripts became a de facto standard that commercial services built on.[20]

The 2010s brought DevOps, which moved testing into the deployment pipeline and out the other side into production, where monitoring, A/B tests, canary releases and dark launches became testing practices in their own right.[25] Mutation testing, an academic idea since the 1970s, only became practical in that decade: one author recounts that until a few years before his book the tools were proofs of concept, never built for performance.[26] The newest books carry the names of the 2020s: testability as a team property,[27] quality coaching as a role spanning teams,[28] load tests run in real browsers from a continuous testing server,[19] and, in 2026, the question of how to keep bug rates down while language-model assistants accelerate code generation.[29]

What testing is for

The purpose of testing is contested enough that several of the sources begin by defining it. The leadership handbook's definition rests on information: testing checks and explores a test object to discover new and relevant information, passes it to those who decide the next actions, and is reactive, because the defects already exist when it begins. Its authors tell of a leadership team asked to test a coffee cup, which found that testing had improved only its understanding of the cup's quality.[1] The same book separates two kinds of work, checking, which verifies known cause-and-effect relationships such as a login redirecting to the home page and can be automated, and exploring, which looks for unknown ones and in the authors' experience finds more defects; checking alone, it warns, creates a false sense of certainty.[1] Weinberg's Perfect Software (2014) covers the same ground at book length: testing as sampling, the difference between testing and debugging, how people take in and distort the information tests produce, the fallacies of testing and the scams of tools and reports, with a list of common mistakes closing every chapter.[2] His Why Software Gets In Trouble follows the defect itself, through the failure detection curve, locating faults in large systems and the fault feedback ratio, and the way pressure short-circuits quality procedures,[30] and his Errors treats errors as a management and thinking problem, with chapters on finding and fixing them, on testing as you build and on keeping testing from growing harder.[31]

Because every possible test can never be run, testing is sampling, and the selection rests on expertise, risk and the time available; a medical device is tested far more deeply than a free game.[1] A beginner's guide gives the human reason the sample needs a second pair of eyes: confirmation bias, which makes a programmer test the scenarios they planned for and notice a failure only when it is obvious, so that testing became a career for people good at using software, trying scenarios and describing what went wrong, in the way an author needs a proof reader.[3]

The bugs that the sampling is meant to find are easier to appreciate through cases than through definitions, and Gojko Adzic's Humans vs Computers (2017) is a book of them. Its sample tells of a trader who offered 610,000 Dentsu shares at 16 yen instead of 16 shares at 610,000 yen, and explains why the yen is an edge case: the ISO 4217 standard records yen amounts without decimal places, so the common habit of multiplying by 100 before storing an amount, correct for dollars and pounds, is wrong for yen and for the three-decimal Kuwaiti dinar.[32] Its chapter on test data left in live systems runs from Knight Capital, which lost more than seven million dollars one Monday because test data from a weekend disaster-recovery drill was never removed, to an Atlanta airport evacuated because the X-ray machine failed to label its own test image, a Brooklyn couple raided more than fifty times after their address was used as police test data, and travellers named Test and Sample whose bookings kept being deleted.[32] Weinberg's Exploring Requirements Two turns the same tools the other way, using black box test cases, technical reviews and ambiguity polls to find out whether the requirements are understood before anything is built.[33]

Unit tests and test-driven development

A unit test exercises one function or class in isolation, feeding it inputs and checking outputs, where an integration test runs the assembled program. One source's sketch of the general theory is to unit test each unit as it is written, integrate, run regression tests after any fix, and on occasion add acceptance tests for the desired outcome rather than the mechanics.[8] The books in this section are about the writing of those tests: how to make them readable, how to write them first, how to isolate the code under test, and how to find out whether they test anything at all.

Writing a readable unit test

Jay Fields's Working Effectively with Unit Tests begins from a failing JUnit test the reader has never seen, with a setup method, an ObjectMother and loops, and counts ten steps of digging through test code, none of which runs in production, before the expected value can even be understood.[13] Its argument is that test code and production code are written, maintained and reviewed in drastically different ways: production code collaborates, so duplication is costly, but tests should not collaborate at all, and each can be a tiny independent universe; applying DRY to a group of tests, the author says, is an anti-pattern, and tests should be DAMP, descriptive and maintainable procedures, instead.[13] The refactorings that follow replace the loop with individual tests, expect literals, inline the setup and replace the ObjectMother with a data builder, and the book notes that the final version barely changed the line count.[13] The author also asks why each test is written at all, listing motivators from validating the system and enabling refactoring to "your manager told you to", and recommends deleting a test whose only purpose is to raise coverage.[13]

The same concern for readability runs through Everyday Rails Testing with RSpec, whose model spec outline has every example expect one thing, describe it explicitly and begin with a verb, so that a failure points at one validation and the outline reads aloud as a specification.[7] Its author admits to not focusing on speed or on overly DRY test code, and says that in tests that is not necessarily a bad thing.[7] Bad Tests, Good Tests (2015) is built on examples of making existing tests stronger, more readable and more resilient to change,[34] and Everyday Unit Testing covers what the tutorials leave out: the cost and economics of tests, how to organise a team around them, what makes a test good, a nine-step testing strategy and turning legacy code into testable code.[35] What a reviewer should look for in someone else's tests is one of the six sections of What to Look for in a Code Review (2016), alongside performance, data structures, SOLID principles and security.[36]

Test-driven development

Test-driven development writes the test before the code, in the red-green-refactor cycle, and Grzegorz Gałęzowski's Test-Driven Development: Extensive Tutorial is the longest treatment in the library, well over a hundred thousand words and free. Its author opens by asking why the reader wants to learn TDD at all, observing that it is often taken up because it is praised rather than understood and abandoned before it is understood, and, by way of a Tekken analogy, that it is easy to learn and hard to master.[14] The tutorial builds a primitive test framework out of an if statement and an exception, treats each test as an executable specification it calls a Statement, and spends a whole part on object composition before applying TDD with mock objects; its later parts are marked by the author as unfinished.[14] A chapter titled "It's not (only) a test" argues that designing, implementing and reading a test are valuable in themselves, by analogy with students who used past exam papers as the first step of their preparation rather than the last.[14]

Test-Driven Development, Build Automation, Continuous Integration builds a Java application test first through sixteen chapters, from JUnit and TDD through code coverage with JaCoCo, mutation testing with PIT, Mockito, Maven, GitHub Actions, Docker-backed integration tests with Testcontainers, Swing UI tests, Cucumber end-to-end tests and SonarQube; its author states that the main subject is software testing at every level.[37] Modern Software Design in Fortran gives half its length to TDD, building a unit test framework from scratch in Fortran, publishing it as a package and then using it on hard-to-test code and dependency injection.[38] The Software Developers’ Guidebook puts TDD, acceptance-test-driven development and behaviour-driven development side by side in one of its five parts, with testing in production and intermittent tests.[39] The Pester book's description of TDD is the shortest: tests as a code-based functional specification of what a hunk of code should do, which developers run as they go.[8]

Test doubles and testable design

A unit test needs the code under test to be isolable, and much of the literature on testing is really about design. Matthias Noback's Recipes for Decoupling argues that tightly coupled code is more likely to become legacy code, that tests completely tied to a framework cannot be run without it, and that domain logic should be in plain sight with tests executed by only the most basic test framework; its last chapter decouples from test frameworks and mocking libraries, and every recipe is paired with a custom PHPStan rule that fails the build if the coupling creeps back.[40] Clean Architectures in Python, the best-selling book in this set, requires familiarity with TDD, unit testing and mocks before it begins, and builds its layered example with integration tests and database fixtures for PostgreSQL and MongoDB repositories under Docker Compose.[41] Testing Spring Boot Applications Demystified orders Spring Boot's own test slices from cheapest to most expensive, plain unit tests, then sliced context tests with WebMvcTest and DataJpaTest, then full-context tests with SpringBootTest, before a chapter on anti-patterns, test performance and flaky tests.[11]

Fifty Quick Ideas to Improve Your Tests adds a distinction that cuts across the test pyramid: coverage and purpose are separate dimensions, so a business rule localised in one function can have a business-oriented unit test, and the integration between two components can be checked directly rather than through an end-to-end test that needs a dedicated environment; the authors describe a team that insisted on running tax calculation tests through the user interface because it thought of unit tests as developer-only technical checks.[15] Another of its ideas, describe what rather than how, shows a scenario of clicks and page reloads that hides its purpose and can only ever be validated end to end.[15]

Beyond line coverage

Line and branch coverage report which code the tests run through, not whether the tests verify anything; a coverage tool will report full coverage for tests that contain no assertion at all.[26] Mutation testing answers that by changing the source one mutant at a time and asking whether any test fails. Filip van Laenen's Mutation Testing opens with its author's own epiphany: with full line and branch coverage of a Ruby hobby project, a tool called Heckle kept proposing an alternative source that passed all his tests, he set out to prove it wrong, and the alternative turned out to be right, exposing a missing test case and a simpler program.[26] His conclusions are that every statement should contribute to making at least one test pass, that no human reviewer can be as systematic or merciless as a mutation tool, and that over the years it let him delete thousands of lines; he now uses Mutant for Ruby and PIT for Java, writes his examples in language-neutral pseudocode, and warns that full rounds still need a lot of computing power.[26] Test-Driven Development, Build Automation, Continuous Integration puts PIT into its running Java example straight after JaCoCo coverage,[37] and Make Bugs (nearly) Impossible lists coverage, fuzzing and mutation testing in the automated foundation it wants under every project, alongside analysers and a strict source-control process.[29]

Property-based testing takes a different route: instead of examples, a test states a property that should hold for every input and a generator supplies the inputs. Logic for Programmers places it among ten technique chapters that apply Boolean logic, predicates and quantifiers to everyday programming; its sample, the refactoring chapter, shows the rewrite rules, De Morgan's laws and quantifiers that make such properties expressible, and its introduction notes that programmers learn arithmetic at school and logic, if at all, by osmosis.[42]

Frameworks by language

Each language has its framework book. Adam Bertram's The Pester Book installs Pester, writes a failing describe-it-Should test, makes it pass, and explains how Invoke-Pester found and ran the Tests.ps1 file, before moving to tags that select or exclude groups of tests; its scope note says it is about the tool rather than the methodologies, and its code is written for Pester 4.7.3.[8] Aaron Sumner's Everyday Rails Testing with RSpec, updated for Rails 8.1, Ruby 4.0 and RSpec 3.13 in 2026, works outward from model specs through factories, request and system specs with Capybara, mocks and stubs, to uploads, email and background jobs.[7] Testing Vue.js components with Jest takes one concern a chapter through vue-test-utils, from shallow rendering and props to slots and snapshots,[9] and Unit Testing con Jest y Testing Library en Angular, in Spanish, targets standalone components and signals with Jest and Angular Testing Library and closes with a chapter asking whether the tests protect you or only feel safe.[10] Java Testing Toolbox surveys the Java ecosystem a tool at a time, JUnit, Mockito, AssertJ, WireMock, Testcontainers, REST Assured and Pact among them, with the stated aim of helping readers choose rather than adopt everything, though nine of its chapters are still marked upcoming.[43] Alan Richardson's Java For Testers is the book for the tester on the other side of that fence, teaching Java 1.7 through JUnit test methods because, as its introduction says, testers use Java differently: in the IDE, writing small checks, rarely compiling an application.[12]

Automating the browser, the API and the device

UI test automation converts the clicks and keystrokes a person would make into scripts that run on a schedule, and one author's reminder is that every user of a site in production is testing its UI, so the point is that they should not be the first.[18]

Selenium and WebDriver

Selenium is the free, open-source library that most browser automation rests on, with bindings for Java, C#, JavaScript, Python and Ruby, and both recipe books open by showing the same Google search test in all five to make the point that once one binding is learned the others follow.[16][17] Selenium WebDriver Recipes in Ruby argues that testers represent customers and should have more weight than programmers in choosing the test language, and that scripting languages suit test scripts better than compiled ones; it lists the nine locator strategies, ID, name, link text, partial link text, XPath, tag name, class name, CSS and the relative locators of Selenium 4, before some two hundred recipes on forms, select lists, AJAX waits, pop-ups, data-driven tests, Cucumber, Selenium Grid and DevTools.[16] Selenium WebDriver Recipes in Java is the same author's Java edition, with JUnit 4 fixtures, JDK 21 and Selenium Manager set-up, updated to Selenium 4.34 in 2025.[17] Selenium 4 A Quick and Practical Guide collects what changed in Selenium 4, written while it was still in beta.[22] For finding the locators, Ultimate Productivity Toolkit catalogues SelectorsHub for generating and verifying XPath and CSS selectors inside shadow DOMs and iframes, Bug Magnet for adding problematic values to any input field's context menu, and Counterstring for test data whose length can be read off the string itself.[44]

WebdriverIO and visual regression

The Web App Testing Guidebook says in its first lines that it is not a book about WebdriverIO but about using UI automation effectively, and spends its introduction on the case for and against: four personas whose mistakes a test suite would catch, then the drawbacks, that a basic script loading a page proves little, that the site keeps changing, that no test is future-proof, and that eighty per cent of the time goes on the hard twenty per cent of functionality, databases, third-party services and animations.[18] Its advice on when to skip automation is unusual in a testing book: not for a feature that users have not yet seen, not on a side project nobody uses, not when the existing tests are not run on every push, and not for the parts better checked by a person.[18] Get Started with Visual Regression Testing and WebdriverIO (2017) is a six-day email course turned into a short book: day one defines regression, functional and visual testing and explains that visual tests compare screenshots against baselines and flag the differences, since computers are better than people at spotting pixel changes, and day two installs WebdriverIO, WebdriverCSS and ChromeDriver and writes a first test.[45] Its authors note that the WebdriverCSS library it rests on has since been discontinued.[45]

Beneath the user interface

The test automation pyramid says that GUI automation is brittle and that most tests should sit below it, and Alan Richardson's Automating and Testing a REST API (2017) is a worked case study of doing so. Its author automated the Tracks to-do application beneath the GUI, not because the pyramid told him to but because it is fast and can do things the GUI cannot, and by beneath he means two things: the official API, and what he calls the app as API, sending the HTTP the GUI would have sent without the GUI; working that way meant managing cookie sessions and scraping pages, which the GUI would have made easier.[46] The case study explores the API with cURL, a proxy and Postman and then automates it in Java with REST Assured, starting with crude code and improving it.[46] Continuous Integration for Mobile Apps (2016) puts Appium test automation in Ruby at the end of a Docker, Jenkins, Nexus and SonarQube pipeline for Android, treating the device tests as a stage of the build rather than a project of their own.[47]

Why automation efforts fail

Several of the sources are written by people who have watched automation fail. The Selenium author's diagnosis is that many projects using it get little value, the clear sign being that regression tests do not run daily, and the key factor is that the automation testers lack knowledge of the framework: a few simple cases run in a browser, then one step cannot be automated, the whole case fails, and the project gives up or keeps a handful of scenarios.[16] How to Fail Your Test Automaton (easily!) collects more than sixty such lessons and frames them as organisational habits rather than individual errors, meant to be held up in retrospectives.[48] The agile testing handbook adds the cost side: automation needs implementation, support and integration into CI/CD, and some aspects of a product cannot be tested automatically at all.[23] The quality coach's handbook lists a test automation strategy workshop among the exercises it gives a coach to run with teams.[28]

Performance and load testing

Performance testing measures a system's response with one user and load testing its response under many; one author, finding the industry's terminology confusing, settles on that distinction and illustrates it with a sign-up that takes half a second alone, two and a half seconds with ten users and ten seconds with twenty-five.[19] Practical Performance and Load Testing opens with the Beijing and London Olympic ticketing systems crashing on their first days, four years apart, despite dedicated load testing teams and no shortage of money, and lists the common failings: expensive tools, an inability to load-test AJAX-heavy sites, testing done rarely and too late, lack of skill and fragile scripts.[19] Its answer is to run real-browser tests in parallel from the build agents of a continuous testing server, the author's own BuildWise, after a protocol-based tool he built in 2014 proved unable to test AJAX; the benefits it claims include infrastructure savings and the race conditions that only appear with many concurrent users.[19]

Master Apache JMeter From load testing to DevOps. is written by three JMeter committers. Its preface, by the performance engineer Alexander Podelko, makes the case for load testing even in a DevOps world that prefers reactive fixes: the only way to know a system survives heavy load is to apply it, production performance does not predict it, multi-user performance is not proportional to single-user performance and can move the other way, a reproducible workload is what makes optimisation measurable, and auto-scaling can only be verified under load, which blurs the line between functional and non-functional testing.[20] Its chapters run from test design through websites, web services, databases and JMS middleware to Maven, Jenkins and shift-left integration, and the sampled JMS chapter opens with why message brokers exist, on the principle that a realistic test needs an understanding of the technology under test.[20] The cloud changes the economics: Testing in the Sky a Guide to Cloud QA Excellence observes that peak-load testing once required hardware used a few times a year, where cloud resources can be rented for the test and released, and that test environments can be created with Terraform or Ansible and destroyed afterwards.[49] Continuous Delivery Pipelines gives performance and non-functional testing their own stages in the pipeline,[50] and Rethinking Performance Engineering for Agentic AI argues that conventional performance practice fails for AI agents, where one request may make a variable number of model and tool calls, and replaces single targets with latency budgets and a per-trace token budget enforced as a CI gate.[51]

Testing in the pipeline and in production

Continuous integration runs the tests on every commit, and continuous delivery extends the pipeline to the release itself. The books here are about what testing becomes once it lives in that pipeline, and once the pipeline ends in production.

The deployment pipeline

Continuous Delivery Pipelines treats each stage of the pipeline as a test with a time budget, commit stage, artifact repository, acceptance stage and release, with chapters on TDD, acceptance tests, manual, performance, non-functional and data-migration testing as stages, and a case study at LMAX whose commit stage ran in four minutes, acceptance stage in forty and releasability decision in fifty-seven.[50] The Pester book's ideal is a check-in that spins up a virtual machine, runs the tests and publishes the module to a gallery if they pass, with the caveat that passing tests do not guarantee the absence of bugs, only that each bug found and encoded as a test never returns; it calls this testing as institutional memory.[8] Test-Driven Development, Build Automation, Continuous Integration runs its example under GitHub Actions with Testcontainers and SonarQube,[37] Continuous Integration for Mobile Apps does the same for Android with Jenkins,[47] and Recipes for Decoupling uses the build to enforce design rules, since a rule that lives only in developers' discipline will one day be broken, merged, and copied as precedent.[40] The WebdriverIO guide puts the point from the other side: five hundred UI tests that are not run on every push are five hundred useless tests, and writing more will not help.[18] The Software Developers’ Guidebook devotes a guide to intermittent tests,[39] and Make Bugs (nearly) Impossible wants CI, tests, analysers and fuzzers as the automated foundation that catches what reviewers and AI assistants miss.[29]

Testing in production and in the cloud

Katrina Clokie's A Practical Guide to Testing in DevOps (2017) describes what testers do once an organisation adopts DevOps: work alongside automated build and deployment pipelines, extend testing into production through monitoring, A/B tests and controlled rollouts, and test the infrastructure itself. It treats canary releases, staged rollouts, dogfooding and dark launching as exposure control, a testing practice in its own right, and backs the argument with industry examples from King, Capital One, The Guardian, the Bank of New Zealand, Etsy, Spotify and PagerDuty.[25] Team Guide to Software Operability, from the same series as the testability guide, defines operability as how well software works when live and lists deployment verification tests and endpoint health checks among its practices, with a run book template that a team fills in to find operational gaps before go-live.[52] The hazard of testing in production is test data, and the stories in Humans vs Computers of trades, bookings and police raids caused by test records that were never removed are its cautionary tales; the book notes that complex systems are often built to run tests alongside real work, which is cheap and effective oversight only if the test cases are reliably recognised as such.[32]

Testing in the Sky a Guide to Cloud QA Excellence organises QA around what the cloud changes: environments created, modified and destroyed on demand with Terraform or Ansible; auto-scaling that lets a store simulate millions of users before Black Friday; security and compliance testing against GDPR, HIPAA and PCI DSS; CI/CD on Jenkins, GitLab CI or Azure DevOps; and the platforms' own tools, such as AWS Device Farm for real devices and CloudWatch for monitoring. Its later chapters, which the sample does not reach, cover test data, functional, load, security and data testing, chaos and disaster-recovery testing and cost control.[49]

Agile teams, testability and the tester's craft

The last group of books is about the people who test and the conditions they test under: the agile team that shares responsibility for quality, the architecture that makes testing possible or impossible, the exploratory tester's craft, and the leading of all of it.

Testing in agile teams

Agile Testing Condensed: (2019), by Janet Gregory and Lisa Crispin, is the short form of the vocabulary agile testing runs on: the whole-team approach, test planning, example-based methods including example mapping and impact mapping, exploratory testing with charters, quality attributes, testing in DevOps and in production, the agile testing quadrants, the automation pyramid and the tester's changing role.[24] Effective Testing in Agile/Scrum: Methodology and Strategy covers the same role at sprint level: the tester plans and estimates with the team, writes test cases, executes manual and automated tests, chooses tools such as Selenium, JUnit and TestNG, integrates automation into CI/CD and takes part in stand-ups and retrospectives; its challenges are short iterations, changing requirements, the breadth of skills needed and the confusion that shared responsibility for quality can cause.[23]

Fifty Quick Ideas to Improve Your Tests, by Gojko Adzic, David Evans and Tom Roden, is for the team that already has the basics and wants to improve: fifty ideas in four parts, generating test ideas, designing good deterministic checks, improving testability and managing large suites.[15] Its sample includes exploring capabilities rather than features, since story-focused exploratory sessions produce tunnel vision, illustrated by a contact form at MindMup whose real risk was users with no network connection at the moment they needed support,[15] and focusing on key examples, with a payment-routing specification of pages of card-number scenarios that gave a false sense of completeness and surfaced its ambiguities only in production as higher transaction costs.[15]

Testability

Ash Winter and Rob Meaney's Team Guide to Software Testability defines testability as how far a system can be observed, controlled and understood, and ties it to predictability, fast feedback and decisions made on data rather than opinion; its introduction describes what hard-to-test feels like, no feedback at all or far too much, and why testability is neglected: no paradigm, no owner, no time, and never a functional requirement.[27] The sampled chapter on testability mapping tells of a replatforming from LAMP to Microsoft SQL Server that split the monitoring across two stacks and moved database control to a separate team, and of a hybrid iOS app where it took two hours of configuration to begin testing, so that exploratory testing was exhausted and shallow and the automated tests were removed from the pipeline as unreliable; its table of risks includes that if it is hard to test it will not get tested, that tests needing I/O will be slow without test doubles, and that logic should be tested as close to its source as possible.[27] The leadership handbook's list of ways to speed up testing begins with the same item, improve testability, before reducing test cases, automating more and improving test environments and test data.[1]

Exploratory testing and the tester's craft

Exploratory testing is testing without a script, where the tester designs the next test from what the last one showed. How To Test teaches its day-to-day skills to a newcomer: the test spectrum, heuristics and oracles, observation, raising defects, exploratory, cross-browser and mobile testing, with exercises on public sites and the suggestion that a new tester debrief with a senior one.[3] "Dear Evil Tester" is the craft's attitude: testers do not need permission, should use and manipulate the system as a system, and should do the things to it that no one else will or can even conceive of, which is what its author's "evil" persona is for.[6] Ultimate Productivity Toolkit is the tester's toolbox, more than 365 extensions, apps and repositories grouped by category on the principle that a tester should know two or three tools in each.[44] The essays in Around the World with 80 Software Testers cover the soft skills, critical thinking, trust and continuous learning that the technique books leave out,[5] and the first issue of TESTink Zine Issue 1 is about nothing but what testing means.[4]

Leading and coaching testing

Three recent books are about leading testing rather than doing it. ACT 2 LEAD, by two Finnish test leaders, one a test engineer at Ericsson since 1994 and the other a co-founder of the Finnish testing association, is thirty-six questions readable in any order, from what testing means to how to manage test data; it separates organisational test leadership, strategy, guidelines and a head of testing, from the operational level, where in an agile team the whole team may lead testing and no test manager is needed, and uses the Shu-Ha-Ri model to argue that detailed test cases suit a beginner and would hobble an expert, as when a group of directors asked for one generic test process for dozens of teams.[1] Its ACT 2 LEAD mnemonic asks for testing added to everything, led in context, made visible, done by both humans and automation, learned from, enabled by a quality culture, adapted to risk and kept diverse.[1] Leading Testing Activities is shorter and for the person with no testing background who finds themselves leading a testing activity as an individual contributor without line management, structured as leading, testing and activities.[21] Anne-Marie Charrett's The Quality Coach's Handbook describes the quality coach, a role across teams rather than a tester on one, with coaching techniques, workshop templates, job descriptions, operating models and career paths for organisations rolling out a quality assistance model.[28]

AI and testing

The sources from 2025 and 2026 share a new question, and none yet answers it at length. The agile testing handbook closes with a chapter on advancing automation with AI and machine learning and on hybrid approaches,[23] the cloud QA guide has a section on AI and ML in testing,[49] and the quality coach's handbook a chapter on using AI in coaching.[28] Make Bugs (nearly) Impossible takes the problem from the other end: with language-model assistants accelerating code generation, it treats AI-written code as an external contributor and pairs deterministic tools, tests, analysers, fuzzers and mutation testing, against non-deterministic humans and models.[29] Rethinking Performance Engineering for Agentic AI is about testing the agents themselves, with evals, LLM-specific metrics and a CI gate on tokens per trace.[51]

Sources

Every source is a Leanpub book. The note after each says which part of it was read; where no sample was available, only the public description and table of contents were used.

1.
ACT 2 LEAD, Marko Rytkönen, Kari Kakkonen: Software Testing Leadership Handbook Free sample: contents, acknowledgements, the foreword, the two authors' paths into test leadership, chapter 4 on what testing means and the start of chapter 5 on test leadership and the ACT 2 LEAD heuristic. 2025. Free sample: PDF
2.
Perfect Software, Gerald M. Weinberg: and other illusions about testing No sample: from the description and table of contents. 2014.
3.
How To Test, Mike Talks Free sample: introduction, how to use the book, and chapter 1 on why the world needs testers. 2016. Free sample: PDF · EPUB
4.
TESTink Zine Issue 1, Stephan Kämper No sample: from the description and table of contents. 2026.
5.
Around the World with 80 Software Testers, Viv Richards No sample: from the description and table of contents. 2020.
6.
"Dear Evil Tester", Alan Richardson Free sample: reviewer blurbs, introduction, acknowledgements and the first letters of the column. 2016. Free sample: PDF · EPUB
7.
Everyday Rails Testing with RSpec, Aaron Sumner: A practical approach to test-driven development Free sample: preface to the Rails 8.1 edition, chapter 1 on why test and the author's testing philosophy, chapter 2 on setting up RSpec and the start of chapter 3 on model specs. 2026. Free sample: PDF · EPUB
8.
The Pester Book, Adam Bertram Free sample: about the book, the introduction on kinds of testing and why test, executing a basic test, and tagging. 2021. Free sample: PDF · EPUB
9.
Testing Vue.js components with Jest, Alex Jover Morales: A concise guide to testing Vue.js components using Jest and the official library vue-test-utils No sample: from the description and table of contents. 2019.
10.
Unit Testing con Jest y Testing Library en Angular, Bezael Pérez No sample: from the description and table of contents; the book is in Spanish. 2025.
11.
Testing Spring Boot Applications Demystified, Philip Riecks: Write Better Tests, Ship Faster: A Practical Guide to Spring Boot Testing No sample: from the description and table of contents. 2026.
12.
Java For Testers, Alan Richardson: Learn Java fundamentals fast Free sample: welcome, introduction, chapter 1 on the basics of Java and chapter 2 on installing the software. 2015. Free sample: PDF · EPUB
13.
Working Effectively with Unit Tests, Jay Fields Free sample: foreword by Michael Feathers, preface on why test, and the first chapter's JUnit example, the thoughts on those tests, the domain code and the refactorings towards readability. 2015. Free sample: PDF · EPUB
14.
Test-Driven Development: Extensive Tutorial, Grzegorz Gałęzowski Free sample: front matter with a Java-to-C# cheat sheet, the motivation chapter, the essential tools and the opening of the chapter on a test as more than a check. 2024. Free sample: PDF · EPUB
15.
Fifty Quick Ideas to Improve Your Tests, Gojko Adzic, David Evans, Tom Roden Free sample: introduction and several ideas, among them exploring capabilities, focusing on key examples, describing what not how, and decoupling coverage from purpose. 2016. Free sample: PDF · EPUB
16.
Selenium WebDriver Recipes in Ruby, Zhimin Zhan: The problem solving guide to Selenium WebDriver in Ruby Free sample: preface, the introduction with the same test in five languages, cross-browser set-up, RSpec basics, and the start of the chapter on locating elements. 2024. Free sample: PDF · EPUB
17.
Selenium WebDriver Recipes in Java, Zhimin Zhan: The problem solving guide to Selenium WebDriver in Java Free sample: preface, the introduction with Selenium's history and the same test in five languages, cross-browser and JUnit set-up, and the start of the chapter on locating elements. 2025. Free sample: PDF · EPUB
18.
The Web App Testing Guidebook, Kevin Lamping: UI Testing of Real World Websites Using WebdriverIO Free sample: the introduction on why read the book, what UI test automation is, its benefits and drawbacks, when to skip it, and the start of the installation chapter. 2023. Free sample: PDF · EPUB
19.
Practical Performance and Load Testing, Zhimin Zhan Free sample: contents, preface and chapter 1 on performance versus load testing, benefits, why it matters now and real-world crashes. 2025. Free sample: PDF · EPUB
20.
Master Apache JMeter From load testing to DevOps., Antonio Gomes Rodrigues, Philippe Mouawad, Milamber: Prefaced by Alexander Podelko Free sample: copyright notices, the preface by Alexander Podelko, author and reviewer presentations, and the start of the chapter on load testing message-oriented middleware over JMS. 2025. Free sample: PDF · EPUB
21.
Leading Testing Activities, Jesper Ottosen: [ A Guidebook for New Leaders of Testing ] Free sample: front matter, reviewer quotes, author note, contents and the opening page on who the book is for. 2026. Free sample: PDF
22.
Selenium 4 A Quick and Practical Guide, Aditya Garg, Pallavi Sharma: Selenium 4 Practical Guide No sample: from the description. 2021.
23.
Effective Testing in Agile/Scrum: Methodology and Strategy, Anatolii Tymoshchuk Free sample: contents, introduction on testing in Agile and Scrum, and chapter 1 on the tester's role, its importance, benefits and challenges. 2025. Free sample: PDF
24.
Agile Testing Condensed:, Janet Gregory, Lisa Crispin: A Brief Introduction No sample: from the description and table of contents. 2019.
25.
A Practical Guide to Testing in DevOps, Katrina Clokie No sample: from the description and table of contents. 2017.
26.
Mutation Testing, Filip van Laenen: Better Code by Making Bugs Free sample: preface with the author's Heckle story, how and who should read the book, and chapter 1 on why coverage is not enough. 2026. Free sample: PDF · EPUB
27.
Team Guide to Software Testability, Ash Winter, Rob Meaney: Better software through greater testability Free sample: series page, the introduction on why testability matters and what hard-to-test feels like, and the chapter on testability mapping with its risks, symptoms and testing smells. 2021. Free sample: PDF · EPUB
28.
The Quality Coach's Handbook, Anne-Marie Charrett: Mastering the Quality Coach Role in Organisations No sample: from the description and table of contents. 2025.
29.
Make Bugs (nearly) Impossible, Jason Turner: Resisting human and AI slop in an LLM age. No sample: from the description and table of contents. 2026.
30.
Why Software Gets In Trouble, Gerald M. Weinberg: Software Quality Series: Vol. 2 No sample: from the description and table of contents. 2016.
31.
Errors, Gerald M. Weinberg: Bugs, Boo-boos, Blunders No sample: from the description and table of contents. 2017.
32.
Humans vs Computers, Gojko Adzic: Wrong assumptions, computer bugs, and people caught in between Free sample: introduction and the stories 610,000 JPY and Mr Test, on currency edge cases and test data left in live systems. 2017. Free sample: PDF · EPUB
33.
Exploring Requirements Two, Gerald M. Weinberg: First Steps to Design No sample: from the description and table of contents. 2014.
34.
Bad Tests, Good Tests, Tomek Kaczanowski No sample: from the description. 2015.
35.
Everyday Unit Testing, Gil Zilberfeld No sample: from the description and table of contents. 2020.
36.
What to Look for in a Code Review, Trisha Gee: Effective tips for reviewing code No sample: from the description and table of contents. 2016.
37.
Test-Driven Development, Build Automation, Continuous Integration, Lorenzo Bettini: with Java, Eclipse and friends Free sample: the book-structure overview of its sixteen chapters and front matter; no chapter text. 2026. Free sample: PDF · EPUB
38.
Modern Software Design in Fortran, Matthias Noback No sample: from the description and table of contents. 2026.
39.
The Software Developers’ Guidebook, David Farley, Bernard McCarty (Editor): A Collection of Modern Engineering Practices No sample: from the description and table of contents. 2025.
40.
Recipes for Decoupling, Matthias Noback Free sample: the introduction on why coupling is bad, how to decouple, staying decoupled with PHPStan rules, and the overview of the chapters. 2022. Free sample: PDF · EPUB
41.
Clean Architectures in Python, Leonardo Giordani: A practical approach to better software design No sample: from the description and table of contents. 2023.
42.
Logic for Programmers, Hillel Wayne Free sample: the introduction and the chapter on refactoring code with logic. 2026. Free sample: PDF
43.
Java Testing Toolbox, Philip Riecks: 30 Testing Tools and Libraries Every Java Developer Must Know No sample: from the description and table of contents. 2025.
44.
Ultimate Productivity Toolkit, Rahul Parwal, Ajay Balamurugadas: 365+ Resources to be a Super Productive Tester Free sample: authors, contents, introduction and the browser extensions chapter, including the testing and automation tools. 2021. Free sample: PDF
45.
Get Started with Visual Regression Testing and WebdriverIO, Kevin Lamping, Micah Godbolt Free sample: preface, day one on regression, functional and visual testing, and day two on installing WebdriverIO, WebdriverCSS and ChromeDriver. 2017. Free sample: PDF · EPUB
46.
Automating and Testing a REST API, Alan Richardson: A Case Study in API testing using: Java, REST Assured, Postman, Tracks, cURL and HTTP Proxies Free sample: the note on the sample, introduction on automating beneath the GUI, introduction to APIs, the Tracks case study set-up and the chapter on its REST API. 2017. Free sample: PDF · EPUB
47.
Continuous Integration for Mobile Apps, Pradeep Macharla: A Feedback loop pattern for build, deploy and test automation No sample: from the description and table of contents. 2016.
48.
How to Fail Your Test Automaton (easily!), Masoud Bahrami: 60+ Lessons I’ve Learned (and Unlearned) from Failed Test Automation No sample: from the description. 2025.
49.
Testing in the Sky a Guide to Cloud QA Excellence, Anatolii Tymoshchuk Free sample: contents and sections 1 to 4, on cloud platforms, the role of testing in cloud environments, what cloud computing is, and the features of testing in the cloud. 2025. Free sample: PDF
50.
Continuous Delivery Pipelines, Dave Farley: How to Build Better Software Faster No sample: from the description and table of contents. 2025.
51.
Rethinking Performance Engineering for Agentic AI, Kandasamy Selvaraj: A Practitioner's Guide to Performance, Latency Budgets, and Production-Grade Observability for Scalable Enterprise Agentic AI No sample: from the description and table of contents. 2026.
52.
Team Guide to Software Operability, Matthew Skelton, Alex Moore, Rob Thatcher: Proven techniques for making software work well Free sample: series page, the introduction on what operability is, and the chapter on run book collaboration; the foreword and chapters 1 and 2 are not in the sample edition. 2021. Free sample: PDF · EPUB