I recently talked about the idea of testing being part geometry and part topology. What might not have been conveyed through that post, however, is how powerful the notion of shape is. What’s particularly interesting about shape is also how we can determine shape by how we choose to observe something. And testing is very much about observing. So let’s dig into this particular rabbit hole.
I’ve already talked a bit about how testing is a discipline with a wide-angle lens. This means it’s very possible to get “lost in test.” Getting lost in this context means abandoning that wide-angle lens and abdicating responsibility for testing. So let’s talk about getting lost!
I was going to frame this post as “The Ontology of Testing” but, while writing it, the Ship ofTheseus, a thought experiment around the metaphysics of identity, seemed apropos. This is particularly the case in an industry where testing, as a discipline, can struggle to find or retain its identity. I was also going to call this post “The Identity of Testing” but the subject was a little more broad than just that. So let’s dig in!
Epistemology is about the way we know things. Ontology is about what things fundamentally are. Ontogeny is about the history of changes that preserve the integrity of something. What does this have to do with testing? Everything. But let’s talk about it.
In my career I’ve found that the “shape” of testing tends to guide the level of abstraction that we put our emphasis at. But what does that mean? What “shape” am I talking about? Well, let’s dig in.
Modern delivery teams using modern product development methods enable making better decisions sooner by treating requirements as tests, which means creating feature specifications. Let’s talk about this.
I was going to title this post “Things That Matter” but that’s a bit too vague. Further, in the previous post on product acceptance I talked about one aspect that falls out of that acceptance-style thinking, which has to do with metrics that matter. So let’s talk about that a bit.
In my last post in this series, I talked about acceptance testing being a core intersection between product development and engineering. So let’s dig into that a little bit more. Specifically, I want to provide a prescriptive framing device that I’ve found to be helpful when getting delivery teams onboard with these concepts.
Product developers know about the “Why Stack” and it’s important that developers and testers are able to work in this context. So let’s talk about this a bit … although I should note I’m going to refine a little bit about how the “Why Stack” is considered, moving it a bit more into where it intersects with how we think about features that we want to develop and test.
In my previous post I talked about how quality assurance and testing are highly aligned with product management and development. There I talked about some injections; here I want to talk about the intersections.
Recently I had a chance to get back into my product development and product management roots. I do believe that quality assurance, and testing, are highly aligned with product management. So in a series of posts I will talking about some of that alignment, often focused on some key concepts. Here I’ll talk about the idea of “injections” that make sense in the context of product management.