The Periodic Table of Testing hadn't been updated for seven years. As well as updating the table itself I've created a text list version to make it more accessible.

What do you get when a large group of QEs walk into a bar? Spike testing in production.

Huge kudos to Ady for an amazing testing song he brought into MoT 4.0 meet up to London yesterday. Watch the video and sing with Ady. Also Ady travelled 450 miles round trip to join the meet up ...

I made the journey from Yorkshire to London for the London MoT meetup. The instructions said bring ID. So I brought my new hat with my name on. It worked! PS. Temptare Omnia is test all the things ...

The Product Under Test, or PUT, refers to the complete, entire piece of software or the whole system that is being delivered for testing. Product is broader than "system" and might refer to the entire deliverable, including documentation, services, etc.' It is the finished article, the full package you are putting through its paces before it goes out to your users. Think of it as the whole house, ready for inspection. This term encompasses everything that makes up the final deliverable. It can get confused with the System Under Test (SUT), as those two terms can be, in rare circumstances, used interchangeably. Most often, they are mixed up by mistake. While the PUT is always the overarching software being worked on, the SUT is typically about the specific component, feature, or slice of that product that you are currently focusing your testing efforts on. Remember that the SUT is about the scope of what you are testing right now, which might only be one small part of the entire product. For instance, if you are building an online shopping website, the entire website is your PUT. When a tester is specifically testing the checkout process, that module or flow becomes the SUT for that particular session. Understanding this distinction, even if the terms get blurred in daily life, helps us be clear about the scope of our work and what we are doing.

The System Under Test, or SUT, is quite simply the specific piece of software, or the particular part of a larger system, that we are currently focusing our testing efforts on. It is the bit that's "in the spotlight" for our current investigation. It can be, but it is fairly rare for a whole system or network to be under test at the same time. Defining your SUT clearly is very important. It helps us to scope our testing better and to understand exactly what we are looking to confirm or understand. If you are testing a whole banking application, the SUT might be the entire application, which is a lot. But, if you are just checking if a new feature like "transfer money" works, then the SUT could be that specific transfer module, or even just the API endpoint that handles the transaction. It could be a single function, a particular screen, or even just a set of interactions. This, of course, needs to be supported by some form of regression testing for the rest of the system. For us testers, pinpointing the SUT for any given test or scope of testing helps us a lot. It makes sure we are all on the same page about what is actually being tested, which helps in designing relevant test cases, identifying necessary test data, and understanding the boundaries of our investigation. It also helps when reporting bugs, as we can clearly state which part of the system exhibited the unexpected behaviour. It is about being precise with our testing focus, so we know exactly what we are talking about and can communicate it in the best way for the project. An SUT can sometimes be referred to as a Product Under Test (PUT). While they, in rare circumstances, can be used interchangeably, more often they are mixed up by mistake. Remember that the SUT is about the scope of what you are testing right now, which might only be one small part of the entire product.

The role of a quality coach is growing. But what might the future look like.

I was considering updating this, but in the six years since I wrote it, not a lot has changed. I have done a lot of the things I talked about and the reasons are as valid as ever.

Behind every great community… are people who laugh, learn, and lift each other. Grateful to be in this room of passionate and serious testers.

Good times were had. Here with Gwen Diagram, Kat Obring, Emily O'Connor and Ady Stokes.

Create concise test plans that get read and understood by busy people

About Me: I’m coming from: near Leeds in West Yorkshire, UK My role is: freelance IT and accessibility consultant I’d love to meet others who are into: accessibility, quality engineering, teach...