I Know A Developer Can Switch To A Tester Mindset But I Do Not Know If They Will

You can switch…

The above was generated by Bing Image Creator where the prompt was the title of this article. I find the image comical, but disturbing. Why the halo, the blank expressions? What are the buttons doing? So many questions…

A small change in wording can make a big difference, but will it?

You can do something which changes your mindset quickly from a creator, who makes things, to a tester, who challenges assumptions.

Say the following sentence out loud:

The feature changes can meet customer requirements.

The word “can” is the word that shifts our brain to the tester mindset. The word “can” along with other similar words change how we think about product behavior, risk, requirements, and whether we need to do more testing.

When you want to say “The feature changes meet customer requirements.” say “The feature changes can meet customer requirements.” instead. Think of other similar statements where you can do a similar change. They do the same thing to our brains.

You can use other words.

The following words or statements work similar to “can.”

• did: The feature changes did successfully accept a user login when we checked.
• were seen to: The feature changes were seen to block unauthorized users when they did not have member role or higher.
• has/have: The feature changes have met user requirements when the product was subject to a 32 hour stress workload.

There are a lot of other words and phrases that work here, and they are all similar in important ways:

• They describe something that you can know and not just believe
• You know it because you observed it
• They imply there is more we could know
• They do not make predictions about the future that are unknowable
• They do not make statements of fact that cannot be known

Change the way you talk about changes to a product or a system according to these principles and you begin the shift to a tester mindset (maybe I should say “can begin the shift”). How far you go is another matter, but just talking that way is describing things the way a tester does.

Filling in the rest

When we encounter a can in a statement, we want to fill in the details.

• What do you mean can? That suggests uncertainty.
• How do you know it can? What evidence do you have?
• Do you mean there are ways it might not meet requirements?
• How do we know the ways the product might not meet the requirements?

This is because the “can” statement is so unsettling to people wanting more certainty (they want lower risk) that they naturally desire to know more.

Here are some useful phrases that help fill in the rest:

• Because when we checked we found that…
• Since we have not yet looked at the following…
• If we do these things we can know more…
• We believe ways it might fail would be…

All of the above statements either support what you know and why you know it, describe what you might do to know more, or state beliefs you have about other things that can happen.

Anybody paying close attention will realize that if someone talks like this long enough with enough detail, they are describing a test strategy. You know who builds test strategies? People who have shifted, at least partway, into a tester mindset.

The philosophy and psychology section

I put the how-to material at the top because I want to quickly give people something they can use. I believe they will use it better if they understand why the how-to works, and why not using it creates a challenge, but not everyone wants to talk about problems on taxonomic, ontological and epistemological terms (did I see some of you leave already?)

Yes, a word change can do all that.

Let’s compare some word changes and how they affect the way we think about a product, project, or changes in a system.

The feature changes will meet customer requirements.

The feature changes do meet customer requirements.

The feature changes meet customer requirements.

The above statements all imply the first statement, that the feature changes will, every time and in every way no matter how many times the feature change is used, meet customer requirements. That kind of statement aligns with how creators manage their work (I address that below) and is a convenient way to talk about a product, but such statements are unknowable. If we change them to an assertion of knowledge the statement becomes unconditionally false:

I know the feature changes will meet customer requirements.

You cannot know whether the statement above is true. You may believe, you may have high confidence, you may have checked so much you have little doubt, but you cannot know.

Testers focus on things we cannot know, and try to give us things we can know. They insert the “can” into every prediction of the future, and spend their time trying to find ways that provide evidence of very specific, targeted can statements, along with ways that for what the product can do it does not do.

Why I believe creators, and business drivers, use will and do phrasing

A creator such as a designer or a developer usually works from a finite list of things they need to create or conditions the product must satisfy. These are feature behaviors, requirements, use cases, user stories, or any other number of ways we express something we need the creator to make. Business drivers work from this same list.

When a developer is given a user story to implement, their activity is organized around getting to the point where they can say “the product does that now.” The accomplishment is a positive assertion of progress.

Business drivers watch the project, and check status in a similar way. To them, progress is reflected in statements like “The following user stories have been completed, the following have not.”

When a developer says “The product meets requirements,” it is a shorthand way of saying “I completed that task.” The developer cannot know if the product will meet requirements in all cases at all times and under all circumstances, but we overlook that epistemological error because what they are really talking about is having completed a work item on their list.

This is natural, and not a problem when we know we are referring to a finite list of tasks to complete. It is a problem when we let that slide into convincing us we know something about reality that we cannot.

The shifting from the unknown to the known and how that loops back to will and do thinking

Somebody changes the “The new user picker meets customer requirements” assertion to “The new user picker has been seen to meet customer requirements, but not yet under these conditions…” and builds a test strategy around which address “…under these conditions…” They find some bugs. Those bugs are assigned to the developer.

How does the developer talk about those bugs when they fix them? Usually with language like this:

“_The product handles the case when the bug we found on the user picker does…_"

They sometimes slide back into will and do language. I believe this is because we made the bug we found into another concrete, known, part of a finite list of requirements to meet and tasks for the developer to complete. They will probably still talk about it the way they talk about all their other feature work.

But they might, and I have seen many, say it this way, and think about it like a tester:

“The product handled the condition described in the bug for the user picker _when I tried the following things described in the bug report…_”

When we use “can” language instead of “will” language, it puts everything we say in a tester framing. We are introducing the limits of what we know, suggesting what more we could do to push those limits further. We are admitting the epistemological limits of our struggle with ontological realities (that was a pretentious thing to say, wasn’t it?).

Why “can” makes us think like a tester

Using “can” language introduces necessary skepticism and doubt.

Read between the lines in the how-to section where I talk about filling in the gap. Testers fill in the gap. The remainder of tester mindset is about being very good at filling in the gap, but that gap is the first important step.

That said, “can” is not a magic word. I believe using this language helps us adopt a tester mindset, but it does not guarantee. Careful readers will see the parallel here to what the rest of the article is saying. Using “can” language can helps us shift to a tester mindset, but we don’t know if it will.

Sometimes testers talk in "_will_" and "_does_" language

When a person who works as a tester acts and talks about testing in terms of will and does language that is absolute (e.g. “Ensure the product meets requirements…”, “Eliminates bugs…”, “Check that the requirements have been met…”) they are no longer talking and acting within the tester mindset. I believe my “AND” above is important, because sometimes we use language that does not really convey our thoughts, so our actions are the true tell. If a tester spends all their time looking for positive confirmatory checks, digs no deeper, and does not use “can” type language, then I would say they are not really behaving or thinking like a tester.

I can offer guesses as to what leads to this behavior. I suspect testers who talk in “will” and “do” language are either placating or learning from non-tester stakeholders that have not learned of the “can” way of talking about testing. I know of no work in the large body of testing literature that strays from the “can” way of talking about products and system. Read Myers, Beizer, Kaner, and even the ISTQB syllabus, all of those sources frame testing the way I describe it here. Testers who use “will” and “does” language presents a puzzle.

A bit about automated tests and “can” language

There is a distinction I like to make with automated tests, checks, assertions - call them what you will. People who talk about those checks from a non-testing viewpoint, from a developer or business driver viewpoint, will often describe them as

“Ensure that the product requirements are met before we deploy.”

I prefer a different way of saying it.

“Tell us if we have found a way the product fails to meet requirements.”

Or more to the point:

“Tell us if we need to stop the deployment.”

I almost put a “might” in the above statement, but modern CI/CD practices leave no room for uncertainty. If the automated tests detect failure, the deployment stops, no questions asked (or the build is rejected or anything else that prevents the failure from moving forward).

Summary

I will close with a return to how-to. It is your reward for reading everything to this point. It is a short summary you have seen already.

Say the following out loud:

The feature changes can meet customer requirements.