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.
Interestingly, and purely as a side note, the idea of intersections talked about here at the product level is very distinct from when I talked in the past about conceptualizing test intersections. Yet we’re still conceptualizing intersections here, which I found to be a nice bit of symmetry.
As anyone who has read some of my stuff in the past, you’ll likely know that I feel it’s very important not to confuse or conflate the term “quality assurance” with “testing.” You only perform quality assurance when you intersect testing with product and then that in turn is used to create an intersection with development. Quality assurance is a function that is distributed among the delivery team.
That’s a whole topic in and of itself, but let’s just focus on the intersections for now. Here is the intersection between testing and product …
The solutions a delivery team designs derive value only from the problems they solve that people care about and by producing results that people highly value. Incorporating testing into product means a focus on providing material that is appropriately information-rich and that is not decision-poor. Which means the tests have to be tightly aligned with the requirements. In fact, the tests and the requirements ideally will be the same artifact.
When this happens the delivery team can verify that its product suite adds value in terms of correctly functioning behavior with respect to various types of expectations. Those expectations might be an explicit specification but they might also be a shared understanding, such as that which is shared among the delivery team or that which is shared among customers that the delivery team is providing value for. Here is the intersection between testing and developers …
“Being a developer” is about providing experiences that add value. Those experiences occur as a result of design-based thinking tied to outcomes. (Sounds a little bit like what product development is about, no?) And testing exists (in part) to put pressure on design at various abstraction levels while development thinking helps keep design cheap at all times.
When this happens the delivery team can verify that each and every thing released supports a certain feature, behaves correctly given a certain input and providing a certain output, adheres to a specific contract, or fulfills some constraint.
The injections I talked about in the previous post, and will expand on in future posts, is part of that intersection. There are other components as well that tie more specifically into the intersection of product and testing, particularly in terms of tangible aspects that are drivers to development.
The reason all of this is relevant on a blog that is primarily about testing is hopefully somewhat obvious in terms of the above intersections. But bringing the point home even more, testers are often looking for ways to be more and more relevant in their career. That being a function of an industry that tends to diminish testing as a specialist skill.
I do believe that product development skills are very much in the wheelhouse of an effective tester. And that’s the case whether the tester has product development as part of their career or wants to enhance their interactions with product developers.
In future posts in this series, I will elaborate a bit more on these intersections — making sure the interface between product development and testing is very clear — and we’ll dig into some of those injections I mentioned in the first post, all of which can be used to help delivery teams distribute quality assurance and democratize testing.
To close out this post, I want to make sure it’s very clear where the quality and test specialist role fits in.
The Quality and Test Specialist Role
I’ve already talked about finding specialist testers and, ideally, making sure that you hire test specialists first.
So bringing that around to the theme of this post, quality and test specialists work with delivery teams to stabilize the development process, sustain the development process, and introduce cost-of-mistake curves. The latter point means that specialists will be helping teams figure out how to shorten the duration between when mistakes are made and when they are found.
Quality and test specialists provide a strong influencing force by which the shifting perceptions of quality are made as transparent as possible to the delivery team. Specialists help delivery teams understand that there are external qualities and internal qualities. Both can degrade over time. Thus specialists have to work with the delivery teams to put in place mechanisms that show where, when, and to what extent quality is degrading. Those mechanisms are often going to be some form of test (artifact) or testing (process), even though they might not be called as such and even though a “tester” (role) may not be the one doing anything.
Specialists will help the delivery teams see that automation can scale testing but that automation isn’t actually the biggest driver of such scaling. Specialists will help the delivery teams understand that its the intersection between design and testability that will ultimately scale testing and thus ultimately drive the interaction between product, design, and development.
And that interaction is made up of numerous intersections that a product development process has to have in place. This is how the vision of a product is taken from discovery, to ideation, to elaboration and then, ultimately, to deployment.
At any one of those intersections, decisions about quality are being made — sometimes explicitly, often implicitly. And when decisions about quality are being made, you effectively have experiments going on. You have hypotheses, explicit or tacit, that are being put forward and a delivery team then engages in a process of carrying out an experiment that validates or refutes the hypothesis. But how do you validate or refute a hypothesis via experiment? You test!
That is the heart of the intersection between testing and product development and why, in fact, the quality and test specialist role not only fits within the context of product development but, in my views, requires the skills of a product developer.
