On the 15th of January 2026 myself and Ujjwal Kumar Singh joined a call and pressed record. We were curious to see what would happen. A few weeks later I’d done the same with Neil Taylor and Clare ...

Is it time to reframe negative testing?

Checking what a system should not do, not only what it should do. A negative test confirms that under defined conditions the system does not display, allow, or perform something, treating those constraints as a normal function of the system rather than as exceptional or wild and wacky edge cases.So what? Framing tests as "should" and "shouldn't" (and tightening that to "does" and "doesn't") makes constraints explicit and gives stakeholders clearer certainty about how the system is intended to behave.Examples: Confirming a basic account cannot see an admin panel; confirming a read-only field cannot be amended.

Definition: The primary expected flow through a feature where valid inputs produce the intended result. A happy path also includes the things a system should not do under normal conditions, so legitimate "shouldn't" behaviours belong to the happy path rather than being treated as edge cases.So what? Treating "shouldn't" behaviours as part of normal operation, rather than as afterthoughts, widens what counts as the expected path and reduces the chance of leaving constraints untested.Example: A user with the wrong permissions not seeing a restricted menu option is part of the happy path, not an exceptional case.

My first TestBash. Got me out of stake ways of thinking about testing and my place in the team.

Definition: A technique that groups inputs into ranges expected to behave the same way, then tests a representative value from each range rather than every possible input. Alongside boundary checks, it adds a value well inside a range to cover the wider partition.So what? It complements boundary checks by covering the body of a range, not just its edges, helping confirm consistent behaviour without testing every value.Example: Beyond testing values right at a threshold, also testing a value far below the threshold to represent the whole "under" range.

Definition: A technique that tests behaviour right around a defined threshold by checking the value just below the boundary, the value on it, and the value just above. It reflects how a system is meant to operate at its limits, not unusual or invented inputs. Also referred to as Boundary Value Analysis (BVA).So what? The values either side of a threshold are a normal function of a system, so testing them is part of confirming intended behaviour rather than an optional extra.Examples: If something triggers at a threshold of ten, testing 9.99 (nothing happens), 10 (it triggers, if ten is inclusive), and just above ten; asking whether a date boundary is inclusive or exclusive (does it act on day 30, day 31, or day 29?).

At TestBash Autumn 2023

Why engaging with the wider business in particular sales can help with testing.

It wouldn't be a TestBash without our famous 99-Second Talks!

Software Testing Double Header! - Al Goodall and Simon Prior