In this blog, I’ll share the different learnings from Janet Gregory workshop done via ministry of testing

99-Minute Workshop: Exploring Requirements with a Tester’s Mindset

I really enjoyed it and I got new ideas how we can test before the code is written, that’s why I wanted to share my learnings in this blog and I’m looking forward to apply them in practice.

Introduction (mindset and level of details)

People usually forget the big picture and get stuck in agile teams, every team member is different and has his own biases which can cause lots of misconceptions.

What client wants form consultants? | The Business of Trust
Example of misunderstanding

When we write requirements and we don’t have the chance to talk about them, there are more chances these misconceptions happen.

In some approaches the test is done after development, the mindset requires a shift and making test continuously.

Janet mentioned Discover to Deliver by Ellen Gottesdienner which show how important is the collaboration and involving the whole teams and how to collaborate continually to discover and deliver an evolving product.

Discover to deliver by Ellen Gottesdienner

We should think about testing before the code is written, make it continuous as janet describes Testing From A Holistic Point Of View.

And the focus of this workshop was about the left side Understand-Plan-Discover indeed it’s the place where we can explore requirements from a tester mindset as the workshop name !

We have to think about all those Levels of precision, but what we need to know for each level ?

Requirements and Testing Essentials

In this part, Janet mentioned the importance of structured conversations using 7 Product Dimensions while thinking about testing.

How can we start such conversations ? Think about coding / testing in different ways ?

  • Functional attributes: an aspect of a product that expresses product capabilities or things the product must do for its users.
    • User dimension: product partners
      • Who interacts with the product?
      • Who are the stakeholders ?
    • Action dimension: what do we want the system to do, what we offered the user
      • What should it do ?
      • What actions are needed?
    • Data dimension: the data and information the product retains
      • What data is needed ?
      • How do we keep it ?
      • What is the most important ?
    • Control dimension: the business rules/ regulations/ policies
      • What are the constraints?
      • Who can access ?
  • Non-functional attributes: “aspects of a product that express properties that the product must have”
    • Interface dimension: How the users connect with the system?
      • What will the interfact look like ?
      • Are there dependencies ?
    • Environment dimension: the physical properties of the product
      • Desktop app or could or mobile ?
      • What are support needs ?
    • Quality Attributes dimension: properties that describe the product’s operation and development
      • Security, reliability, performance, load, testability ….

Looking at each dimension, we may find an overlap between dimensions and that’s ok!

Big Picture Release & Feature Levels

You may get confused what level I’m at ? although we are looking at the big picture but what we need for each story ?

How to link each technique to the dimension and help our understanding?

The below picture is a great summary, it provides different techniques to elicit requirements for the different dimensions we have.

We can use some flows, maps, prototype, diagrams, decision table, tree .. as tools to help us

example: when we think about data we may ask what data ? how can we track it ?

  • State diagram helps us understand about data and the changes that could happen,

Explore with Examples

Now it’s time to go deeper not just high level but on story level, we want to think about exploring the story with examples (Specification by example, BDD, ATDD, example mapping..)

Example Mapping

  • when you start using it you may consider there is more business rules, so you add it and
  • helps you think about more examples which bring business rules. It’s a good way to slice stories.
  • Examples are a way of getting shared understanding.

Acceptance tests

  • Help evaluate the product we are testing from a user’s perspective
  • Provide the scope via the story and big picture of the story or feature
  • Results are accepted or not accepted.

Conclusion

Examples, requirements and tests are all together and think about how they interact, think about it from the 7 dimensions mentioned earlier to avoid rework it helps you and the the team prevetn defect via the early testing.

It’s also a great way to encourage the team to collaborate together.

Special thanks to Janet for the quality of this workshop, and to ministry of testing for organizing such interesting 99-minutes workshops with lot of learnings.

  • References and more learning resources:

Gottesdiener, Ellen and Gorman, Mary, Discover to Deliver, 2012
β€’ Wynne, Matt, “Introducing Example Mapping”, http://bit.ly/1iw19w4

β€’ Lisa Crispin: https://www.onlinetestconf.com/sessions/lisa-crispin-
example-mapping

β€’ GΓ‘spΓ‘r Nagy and Seb Rose, The BDD Books: Discovery, LeanPub, 2018
β€’ Wynne, Matt and Aslak Hellesoy, The Cucumber Book: Behavior-Driven Development for Testers and Developers, Pragmatic Programmers, 201
β€’ Adzic, Gojko, Specification by Example: How Successful Teams Deliver the Right Software, Manning, 2011
β€’ Adzic, Gojko, Bridging the Communication Gap, Neuri Limited, 2009