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!
Category: Testing
The Basis of Testing
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.
Test Shapes
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.
Testing is Like Finding Exoplanets
Astronomers have been finding lots of planets around other stars, which have come to collectively be called exoplanets. And, as part of that endeavor, they also try to think about finding life on those planets. There’s lots of corollaries here in terms of thinking about testing.
What Makes Testing Complex?
Years ago I asked about what makes testing complicated. At that time I didn’t really have a very distinct nuance between “complex” and “complicated.” But I think my instinct was accurate. So here I want to focus on what makes testing complex (which is often inevitable) and that can help frame what makes testing complicated (which is not inevitable).
Applying Test Thinking with Code
I’ve often talked about the idea of tests putting pressure on design. I’ve also talked about this idea in the context of code-based testing. Here I want to revisit those concepts while including a cautionary tale about how testing at the code level has its own interesting challenges.
The Zero Defect Fallacy
Thankfully most testers that I come across do realize that the notion of having “zero defects” is, in fact, a fallacy. But this notion of something being “defect free” still persists in the wider industry. And it’s important to quash that perception. How I frame this when encountering the thought differs a bit. So here I’ll give a brief overview of various ways I respond.
Forgetting How To Test
My original title for this post was “Thinking Clearly About Automation” but I realized there was a wider ambit to that discussion. We have a technocracy that likes to turn testing into a programming problem, suggesting that “manual testing” (testing done by humans) should be automated away as much as possible. That’s a danger. Some testers have combated this by suggesting automation has nothing to do with testing. I believe that’s also a danger.
Testers: Act Like a Developer
We often say testers have to “think like an architect” or “think like a builder” or, perhaps even, “think like a developer.” Here’s the problem: to actually think like any one of these people, you have to try to do something they do. So, really, you have to act like a developer. Let’s talk about this and where the testing relevance comes in.
Recovering Context by Test Thinking
Here I’m going to write one of my posts that I think are the most fun but are probably the ones that many testers struggle with in terms of seeing how (or even whether) I’m being relevant. I want to talk a little about an aspect of testing that I think is consistently underused and consistently undersold in the industry: recovering a context that has been buried under years of major and minor decisions.
Should Testers Own Quality?
I recently participated in a discussion around the idea of whether testers “own quality” in some sense. The answer to me is obvious: of course not. But an interesting discussion did occur as a result of that. This discussion led to my post about what it meant to own quality across the abstraction stack. But there’s a more systemic concern with this level of thinking that I want to tackle here.
Testers and the Technical Abstraction Stack
I had no idea what to call this post. My focus here is on the notion of owning quality. As in: who does so? I won’t tackle all the nuances of that wider topic here. But, due to recent discussions, I did start to think about what it looks like for testers to own even limited bits of quality in our industry that is currently focused on some form of DevOps.
Continue reading Testers and the Technical Abstraction Stack
Testers and the Quote Culture
I find that many testers still like to “talk in quotes.” Meaning, they like to throw out quotes or sentences and then act is if they’ve said something profound. And maybe they have. But I’m seeing more of this lately without, it often seems, the necessary ability to think beyond the quote. Let’s dig in and see if I have a point to make.
The Test Snap
Awhile back I talked about a possible test apocalypse and how you might respond to that. In honor of the current film Avengers: Endgame, I started thinking about this topic again. Here I’ll use the well-known “snap” of Thanos as my starting off point, trusting that this makes the article title a little more clear.
Will AI Perform Testing?
The title of this article is actually a little too simplistic. It’s more about asking: “Will AI Truly Perform Testing?” Or perhaps; “Will AI Perform Actual Testing?”
Do Testers Understand Testing?
I’m asking here: do testers understand testing? By which I mean: do testers truly understand testing? By which I mean … okay, you know what, let’s just dig in to the basis of testing for a moment.
Is My Bug for Developers or Product?
We all know the situation, right? We find an “issue” but in many cases it comes down to determining whether our issue is something for the developers to fix or if it’s something for product to clarify. It’s often a question framed as “Is this a bug?” Hidden within that question is dealing with the protean nature of a “bug” in current software development.
Testing, Integration, and Contracts – Part 2
This post will continue on directly from the first post, where I introduced you to the concepts as well as an application that can serve as a guide to some of the ideas. I highly recommend reading that first post for the context if you haven’t already.
Continue reading Testing, Integration, and Contracts – Part 2
Testing, Integration, and Contracts – Part 1
In this two-part post, I want to cover the distinctions between integration testing and integrated testing as well as the distinction between edge-to-edge and end-to-end testing. I also want to show how this thinking should be leading testers to think more in terms of contract testing. And, finally, so all of this isn’t entirely theoretical, I’ll provide a React-based code example. That’s a lot to cover so let’s get to it.
Continue reading Testing, Integration, and Contracts – Part 1
Don’t Define Testing Around Bug Finding
I still see many testers talking about the number of bugs found as some sort of barometer of success in terms of effective testing. But lately I’ve seen this framed around the “quality” of bugs found, rather than just their quantity. Still, you have to be a bit careful here. Let’s talk about this.