Your Superpower for Successful Testing: Creating a Shared Understanding

Published in

The Startup

6 min readJun 25, 2020

You can avoid a lot of problems in your product development journey when all involved parties have a shared understanding of the product’s goal and requirements. I will show you a simple but powerful tool to achieve this without a technical background.

Creating a shared understanding

Before any code is written, the first thing you should do is to create a shared understanding for the product or release or feature (you can drill this down step by step) that you want to deliver to your users. Only if developers, testers and business representatives know the sweet as well as the weak spots of the product, they can track and test it accordingly. So now we have reached the second quadrant, the business-facing and development guiding tests of the agile testing quadrants (Check out the second article of the series for more details about the agile testing quadrants).

There is a multitude of methods you can apply to specify your tests. An excellent approach to describe the behaviour of a story in different scenarios is Behavior-Driven Development. You can phrase requirements in simple, structured sentences (e.g., Given I am at the sign-in page when I type in the correct credentials, then I am shown the application dashboard.) Acceptance Test-Driven Development uses tests to formulate requirements (which makes your requirements more specific and, therefore, your documentation more effective and efficient). Since you are probably not a developer, you can trigger conversations around these options to help the tech-experts find the best way for the product and team.

To find the right basis for those conversations, you can help your team find out which scenarios are critical and therefore need a respective test. So what does that mean? When you clarify the requirements of a story with your team, you think about the value you want to deliver to the user through a specific functionality. E.g.:

“As a bus driver, I want to be able to open and close the bus doors without leaving my seat, so that I save time and effort by not getting up at every bus stop.”

Now, for the team to be able to deliver a solution for the bus driver in the best quality, it makes sense to think about different scenarios. E.g., What happens if someone is standing in the door? How does the door react?

To trigger valuable conversations that help identify such scenarios or examples, there are several approaches, such as Impact Mapping or the 7 Product Dimensions. I will explain one approach a bit further.

Example Mapping

Since it happens very quickly that people create individual and different images of a product without noticing it, concrete examples are a perfect way to make sure that the team (including the tester) and the business representatives (such as the product owner) are on the same page.

Example mapping helps to create a shared understanding for stories and to slice them down where needed. It assigns specific business rules to a story and specifies these rules with concrete examples. For testing, this is interesting because the examples describe possible test cases that your team should consider.

So, how does it work? You can do this in a workshop session. It is essential to get the right people involved (e.g., UI/UX, product people, customer support people, basically everyone that knows the user). A good approach for this is the “Three Amigos” format. It brings technology, business, and testing representatives together to clarify product requirements. Those can be the development team, the product owner, and the tester of the team.

Choose different post-it colours to differentiate between story, rule, example, and question. That can look as follows:

Start with the rules around the story you’ve chosen. The product owner can bring up some conditions for the beginning, but they can be discussed or complemented by the rest of the team.

Now, to make those rules understandable to everyone, you create concrete examples, describing the happy path (the scenario in which the user does exactly what is expected) and the unhappy paths (How does the functionality react, if the user does something that contradicts the rule?).

To see if there are more relevant rules than the ones you started with, the participants can gather questions that they cannot answer right away. Those questions might be transformed into further rules throughout the session or in the following example mapping sessions. You can begin those questions with “What If…”. By discussing these different aspects of the story, it becomes more evident if the story is too big for one iteration and has to be cut into smaller pieces. Also, it supports fact-driven decisions regarding the prioritization of stories (which functionality must be available first?).

Let’s clarify this by an example of the booking of seats in a coach bus:

Example Mapping — based on an example by Aslak Hellesøy

In the happy path example, the rule, not to fill up more than 70% of the seats, is complied (since only one seat is occupied). In the second example, the bus would be filled by 80% if seven seats would be booked. So the booking request cannot be confirmed. This might raise the question if it makes sense to show the number of available seats upfront to avoid frustrations in the booking process. You can then transform this question into another rule, such as “Customers should see the number of bookable seats.” The example also shows that it becomes more visible if you can cut this story into smaller stories (e.g., one story for the announcement of available seats and one for the booking).

You see, guiding development by examples is not as technical as you might think and has a significant impact on the quality of the product. You can add value by simply keeping these conversations between technology-, business- and customer representatives alive.

Now you have an idea of business-related aspects of testing before and during development. But have you — like me — also wondered often what the difference between unit- and integration tests is? In the next article, I will continue the journey along the product life cycle by guiding you through technology facing tests (quadrant 1), so that you can feel at ease when the topic comes up in the next planning meeting.

References

Articles of the series

Agile Testing Strategy — Graphic by Alexandra Oliveira

About the article series “Agile Software Testing — insights for non-technical people, like me”

During these isolated times I took the chance to learn more about software testing. This can be quite challenging without a technical background. Therefore I read the book “Agile Testing Condensed: A Brief Introduction” by Janet Gregory and Lisa Crispin and worked through the content they describe in the book.

To make it easier for you to quickly get the most important insights, I summarized my learnings from the book and some further sources and want to share them here with you in a series of short read articles. They are structured along the product development phases and you can either read them piece by piece to get a holistic overview or pick the topics, you are interested in most. I believe this will help you, as it helped me to understand a bit more about the world of testing, without having a technical background.