A quality narrative is a qualitative report, expressed in words, on how good something is. It allows us to communicate a more in depth and thorough understanding of a topic. Think of it as a statement or conversation that really focuses on the what: What have I tested? I looked at the /puppies endpoint to pull back and edit a list of the puppies in the database using GET, POST, PUT and DELETE commands with valid JSON and different data. What did I see? The different request types all looked good and worked with expected payloads, however when I used special characters in any field I got a 500 error response. What does this mean? If we have any users with double barrelled puppy names, or honourifics in names like Mr. Fluffy-Bottom then they’ll get errors back from the system. What should we do? Is this something we want to fix? I can raise a bug for that. or if we want to know more about it I can test around this some more today.

A quality narrative is about the way that we can talk about quality holistically. It's a good replacement for, say, a test report. A report usually is like a condensed view of the world that sort of tries to compress down into numbers or a graph or really salient points to go cool. Like here's your parcel fail criteria. Like here's what we found as a result of something. Whereas a narrative is more of a communication around quality. What's the good, what's the bad, and what's the ugly? We sometimes talk about a quality narrative when we're doing debriefs and exploratory testing. So a quality narrative is just a slightly more open, a more wider way of communicating what we what we know about something to help inform divisions and build influence on quality as well.

A type of testing where we basically go around, unplugging things. In the old days, way back in the old days, we use to have physical servers and we'd pull wires out of machines, these days thngs are all hosted. We would switch things off and see what happens. Does it recover? Does data get lost? Have things been queued to transactions?Does it fail part way through? Community commentary from Callum during Software Testing Live.

Chaos Engineering is the discipline of exploring your system to see how it handles turbulent conditions in live. It’s a term that was coined by Netflix to see whether their systems and infrastructure could handle infrastructure failures, network failures, and application failures. Basically Chaos Engineering asks, what would happen if this thing failed?

Test design is a mechanism that we use to ensure that what we're looking at is actually useful for people. It is a way of cutting down what we might explore or test for to ensure that our tests are really useful to people. And that's not just in terms of, exploration. That can be in terms of our automation as well.

The purpose of our test design is to help people understand what it is we're covering, what it is we're testing, and what is it they're going to find out about the system from our testing. Because we want to share that information, that useful information, to help the team understand the quality of what's being built. And the whole reason we design our tests in the first place, it's not necessarily for us. It's to share that with the rest of our team so they can help go, oh, have you thought about this? Or, hey, maybe this isn't a priority for us right now. So that's the key thing to think about there.

Test plans can mean all sorts of different things. It could be our approach. It could be how we're testing, or it could be what we're testing. It could be a series of scenarios or a series of tests as well.

Testing is the activity we use to gather information.

Quality engineering ... is very focused on influencing. Your ability to influence teams, engineers, organisations, managers, other testers, anyone. Quality engineering is about building quality into things.

When I’m talking about Quality Engineering I mean all the things we do to help ensure “good enough” when developing a product throughout its lifecycle. Asking questions, user research, communicating, defining goals and standards, designing and architecting, collaborating, writing code, testing, exploring, identifying and mitigating risks, observability, experimenting… This goes beyond any one phase or individual, it’s a holistic practice that’s everywhere and done by everyone.

Software testing is a way of providing information (and evidence) about something, allowing for a meaningful discussion / decision to be made on its quality*. *Where quality relates to it being fit for purpose or “good enough” for now.