A Story About Lifting People Up

This article is a parable, it’s not a traditional testing post. But as with all parables, this is a story to reflect on. It comes with all the best and noble intentions. [TW: semi-religious content].

There once was this person named Zach. Well, the name is really not so important. It could have been Dilek, Kim, Brie, or Latoya. Zach’s job was to collect fees among the community members – a service job for the benefit of the community. It could, as well, have been removing spam, sorting, and organizing content. And onboarding new people to the community. Menial work, which could be a hassle to the others – yet important for the community to run.

Reflection: What glue work gets taken for granted where you are?

But, there is no doubt Zach had cut some corners along the way. After all, that’s just the way business was done sometimes, thought Zach. And because of that, the fancy people of the community ignored and dispised Zach even more.

To make matters worse, Zach was not as tall as the others. You could say, that Zach didn’t have the same attributes as many of the others. And that made Zach feel further diminished and small in the eyes of the community. And that probably added to Zach’s cheating. Nothing Zach did was ever really recognized.

Reflection: who is putting in an extra effort to be seen?

One day a superstar and thought leader was present in the community. Everyone in the community gathered around and engaged. There was a buzz going on and Zach wanted to be a part of it. But it was still a burden for Zach to engage. Zach had to make an extra-extra effort just to catch what was going on.

Suddenly the superstar called out: Hey Zach! I see you. I will come to join you where you are. And so he did. The superstar joined Zach, the menial fee collector. Zach pledged to be a better person and has been since. Zach is now sharing surplus energy with the others in the community and has made up for the wrongdoing previously done.

Reflection: Are you meeting people where they are? How can you lift people up that are not seen?

What About Expected Results?

TL;DR: We should know better than to require expected results in test case steps.

Welcome to 2022 – where old wisdom surfaces yet again. Recently I considered expected results in test cases. It seems the topic is still relevant – I wrote about it in “The Expected” back in 2015.

As always we have to backup a bit and consider: What purpose does the detailed steps have to our stakeholders. How visible is the value provided? We have to start from their viewpoint – not build a chain of reasoning up from our own wishful thinking.

Currently I’m working on a project for payments of benefits. We have daily CI/CD and loads of classic manual testing. The key message from the stakeholders is that they expect things to be tested and evaluated. They generally trust us and collaborate with us on the work, so there is not so much discussion on the details as in other projects. Yet the discussion of expected results did come up in our internal dialog: What is the reasoning behind expected results on the test case steps – besides coming from an old book.

Testing is a performance

One of the usual arguments is that it enables hard-over from person to another. While handover can be relevant to consider if the team members changes often. It seems to me just to create redundant information based on requirements and other oracles. I mean where does it it end, why should we add every project information into the test cases and into the test plan. Stop it already.

Let the test cases be evaluated by the person performing the test – to see the whole picture. And not get biased by expected results. I want the persons performing the tests to use their brain and based on the oracles available evaluate the system under test. Also if everything can be planned – why would there be a need for retakes of movie scenes? It turns out even simple instructions are not possible:

Exact Instructions Challenge – THIS is why my kids hate me. | Josh Darnit

Let people do what they are best at

Let’s have testing being a balanced approach, where people evaluate and scripts confirm.

When the confirmation can be determined by an algorithm or by assertions towards an oracle we can code a test for it – and test it continuously. Adding as much automation as (practically) possible, aids the delivery in multiple ways. It aids to build regression testing and help us test that things not only worked once somewhere, but that it works again and again.

On the other hand when there’s no algorithm or explicit oracle in the form of specifications, acceptance criteria or similar authority we can only do a subjective evaluation: at that point in time – given the information available. do not neglect the wisdom of subject matter experts testing.

And in the later situation expected results hinder the exploration of whether the system under test fulfills not on the explicit requirements but also the implicit. We really should know better.

Photo by Karolina Grabowska on Pexels.com

#268 – Who Brings in New Knowledge?

Well, if you are reading this – there’s a good chance it’s you. Especially if you read this with the intention of sharing this with your team. I hope you do, obviously 😊. But perhaps it’s unclear whose responsibility it is, to bring new knowledge to the team. Is it always the team manager job – or is it a dedicated person that by role, or by habit, that bring in new knowledge?

Photo by William Fortunato on Pexels.com
Continue reading

Implementing Change – First Steps

TL;DR: Stepping into the deep water – have a few supporting first steps.

Photo by Francesco Ungaro on Pexels.com

Inspiration: Ministry of Testing Bloggers Club August Challenge and My three step recipe for overcoming procrastination

Continue reading

Relations – are about half of IT

You can’t have IT projects without relations. Relations matter more than it seem.

Continue reading

Test Master S1:E1

In Taskmaster (the TV show) celebreties are rated on solving challenges. At Test Bash Manchester 2020 the participants got a challenge too. A good interactive challenge, where you had to think outside the box. Encore MoT Team!

Continue reading

Testing is like … vacuuming

  • It’s better to do it often, than to let it pile up
  • It’s a tedious task that robots can do (partially)
  • Automation can catch some base level hairy stuff
  • Bigger hairy catches should be hand-picked
  • It’s always involves using tools
  • It’s better when it’s a whole team approach to cleaning
  • If everybody does their area, it all adds up
  • There’s always the usual spots …
  • .. And the spots to see after you thought you were done
  • In a hurry, you use the snow-plow method
  • It catches bugs

This is an analogy blog post – consider it an experiment, not a wholesome truth, but rather a model. And a model is always false, but sometimes useful.

This blogpost is also coming from a community outreach from the  Bloggers Club on the Ministry of Testing. There are regular challenges that aim to share community thoughts. This month, the challenge is to share the personal perspective about “Testing is like…”

The analogy is inspired by Heathers post about their new vacuum robot below. If you want to consider how to test a robot vacuum, go see the club post: How to Test a Robot Vacuum?

[Image of “Floor-a” with permission from Heather]