Unknown Series on Testing E01: The Needs

In our first episode about unknowns, we will go to the starting point, i.e. to our big bang in software development: the needs. We will probably need to distil this in additional articles; but that’s exactly what happens whenever you deal with the unknown: it’s something that you need to keep exploring.

Feedback loops can be lengthy and error-prone

Having worked around product development all my professional life, I dealt with requirement elucidation and analysis for some years. Writing or reviewing an extensive and detailed specification for a system or even for a specific feature of a product is hard.

This scenario is normal in waterfall projects where the release date is normally several months ahead and it's seen as a deadline, to you and to your team. After having the specification sorted out, to a point, we start creating some other documentation for the architecture of what we're going to build. Then, implementation starts and verification is performed in bulk before the release is moved to an acceptance-testing phase with the customer. But that moment can be too late to receive feedback from customers or stakeholders. Maybe you just built the wrong product: it happens.

Agile aims to shorten the feedback loops, namely the one between the customer and the development team. By delivering small pieces of value continuously, customers can provide feedback and features can be better tailored to the actual needs. Clearly this process is more dynamic than waterfall; however, do you think it's immune to problems around what is being built versus actual needs? Well, no.

One underlying "problem" is that we as humans use language to communicate, express feelings or needs. As the communication chain increases, it also increases the noise level within it. I remember playing a funny game as a kid: a bunch of us stood together and started saying a message (e.g. a gossip) to the kid next to each other. The message would be said in very low tone and passed from kid to kid until reaching the one that originally said it. When the message was received at the starting point and was expressed loudly, we would laugh for a while. In fact, most times it had nothing to do with the original one.

Uncovering unknowns in communication

How we express ourselves is noisy and so is its interpretation. And this happens everytime we communicate, and not only at a given moment in time. One way to deal with it is by having frequent customer interactions along with the team right before the project starts and also during its lifetime. Why is it important?

Well, for several reasons:

• It helps create a shared understanding and uncover many unknowns
• It helps clarify concepts, terms and needs
• It helps identify and assess risks
• It helps prioritization and understanding what’s important and what is not

At a project's start, you can do a “three amigos” session... well, you can involve more than 3 people representing business, development, and testing units. I think having someone from UX and support is important, independently of whether you have them as separate roles or not. Probably you may have experienced design thinking before; “design sprints” are built on top of this concept. Design sprints provide a well-defined approach to have prototypes that can be tested by users, even before they’re implemented.

I tried a smaller variant of the design sprint concept but the idea is the same: Have customer present with the team Understand concepts, needs, where’s the real value and what is the ultimate purpose Diverge to get some ideas of possible solutions Converge to evaluate if some solutions are functional viable

During the project implementation and rollout, we should have frequent interactions with our stakeholders or the customer. Customers can be present in daily Scrums; I've worked in Agile-based projects with frequent (almost daily) customer interactions. I also know how it hurts whenever you can’t have that feedback on-time or even until the “last minute” of your deadline. No matter if we’re starting the project or you’re mi , questioning is really the.

Needs vs Solution(s)

Most of the time, people will come to you with the solution. And they can even give you that as a “requirement”.

Hey, we need a button here that does this. Hey, we need to generate a report with these columns.

Humans are creative and you know what? Everyone likes to “innovate” and have that “I had this amazing idea” feeling.

The problem is that ideas are like cocoa: we need to process them to have chocolate (i.e. highlight the needs).

The 5 whys technique provides a way of getting to the root cause, or in our case - the need. Questioning is in fact a skill testers have, and we all have, that can help us uncover what’s behind some closed door. Remember that we aim to optimize our overall effort building and testing the right product.

Pains are also Needs

It’s not just about uncovering and delivering “new features”; it’s also about discovering the pains and the gaps.

Pains are blockers to deliver value: they take time, effort, and costs. They distract us from thinking about ideas that could improve our product and increase the value provided by it. So, we need to discover these pains, which involves on-going conversations with the stakeholders/customers. Pains are gaps or background noise in our “requirements”, if we’re working on an existing product.

Some ways of uncovering these are:

• ask what the different personas do in their daily product usage
• if you can, observe (or monitor) people using the product.

How is all this related to testing?

It’s really important that we uncover unknowns from the start or else we begin to generate assumptions or misconceptions that will guide our implementation and our testing to paths. Only if we understand the actual needs, what is the ultimate goal, we can implement and test what we’re building properly. Many times we get excited implementing unnecessary features that will just increase our tech and test debt… and also the “needs debt”, if we can call it that. Having different perspectives from the start, helps clarify concepts, needs, concerns and thus uncover unknowns. Testing is about looking for information and understanding which starts at the big bang: right at the moment the universe of unknowns around your product begins. Please feel free to share your thoughts on how you uncover needs and help build a better-tailored product.