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.
Testable Requirements
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.
Metrics That Matter
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.
Focusing on Product Acceptance
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.
Delivery Teams and Popping the What Stack
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.
Product Development Intersections
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.
Product Development Injections
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.
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).
The Copy+Paste Culture
Many companies I’ve been at are in a race to see how much like Spotify they can be and apply concepts of Chapters and Guilds. What I routinely see is companies get this bit wrong. Particularly around so-called “quality guilds.” So let’s talk about this.
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.
Tests – Human Readable, Machine Expressive
In my previous post on human and automated testing working together, I showed an example of test design by humans that could be executed by automation. However, the focus point was making sure that the automation helped the humans adhere to an unambiguous domain model of what is being tested. Here I’ll follow up on that practical example with some of the theory.
Human Test Design, Automated Test Execution
One of the obstacles to covering the gap between principles of testing and the practice of testing is the mechanics of writing tests. This is particularly the case if you work in a business domain with a lot of complex business rules. This is even more particularly the case if you want to use automation. So let’s dig in to this a bit with a case study.
Continue reading Human Test Design, Automated Test Execution
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.