Skip to main content

Do Your Tests Wobble?

Image by delo from Pixabay


“The green reed which bends in the wind is stronger than the mighty oak which breaks in a storm.” 

― Confucius 

I was asked to pair Blog with Lena Weiberg - much to my shock and delight. This was the perfect
opportunity to hear another point of view on something, and share it with the wider community. 

~

Part of being a good tester, to me, is making sure I stay aware of the trends in development. Knowing 
how the team is working can help get comments and questions to them at the proper times, and has 
the information that can be acted on. In this quest, I attended a recent online conversation where the 
topic was primarily on the size of 'steps' taken in software development: making sure each step takes 
a reasonable amount of time, that it leaves the system in a state that isn't worse than it was before the 
change, and that could - if needed - be deployed at this point. 

The concept of “wobble”  (I'm not sure who originated the term)- how much the entire system is going 
to react to a change in one area – was presented, and caught my attention. Thankfully, this was near 
a break time, so I had a few moments to explore what this means to a team. And found several ways 
that this might change how they look at both ‘done’ and stability in a system. Does this fit the model 
they are using? And is the model wrong in this way?

And I wonder how much this concept has shaped the 'normal' path software goes through. Is this one 
of the reasons that testing has traditionally been placed at the end of the process?  Either by those 
writing the code itself, or as a chance to make sure that a release has what it needs to be able to get 
into the user’s hands?

I will use the example from the quote above: a clump of reeds with many points of contact – intentional 
and otherwise – is close to a flurry of tiny changes. This could be produced by having any change 
instantly sent out to everyone. So a button could shift colors several times in one day, or flip into a 
different position – as a deliberately extreme example. None of these are going to ‘break’ the system, 
but would certainly irritate me!

Or it could be more like an older, stiff tree: reacting quickly to a potentially damaging threat just isn’t 
possible. Large changes that appear with infrequent updates happen, but it is a shock to the user's 
workflow  They may have to puzzle out where the information is now accessed – and if the frustration 
of finding and relearning the ‘tree’ is large enough, you may lose that user, or a lot of them!

I mulled this over for a few hours, and got this clarified in my mind. When a system changes during 
coding, it should be easy to see how those changes influence nearby code, as well as the code it 
touches. This is a normal thing for many developers: it allows them a chance to make sure that the 
system isn't going to collapse. A change of something like a variable name will cause waves across 
the application - but this will settle out unless there is a conflict. Changing the way data is collected or 
displayed may cause more reaction, and might lead to a cleaner code base. This, to me, is an area 
of little wobbles: things are deliberately changing, but we minimize the wobble to avoid future work. 

Deliberately causing a large wobble is something that should be thought over carefully. Making sure 
the team knows of potential questions and issues, and a way forward to resolve them opens a chance 
to take time to look at the entire section. The amount of influence on the system as a whole is one 
consideration for how carefully you need to look. Changes like this most often are without problems, 
but they may infrequently cause damage, or at least confusion. And since the code has changed, 
there are the test and automated checks to update, and add to - no better time to make sure that this 
section of the code has more coverage than it did. 

A bunch of small changes can add up to a lot of 'tech debt'. It is very easy to lose focus, in this 
situation, on the larger change we are wanting to make. Changing the name of a variable (a legitimate 
change, and a 'step' of the proper size) shouldn't set off a flurry of tests. The 'flow' of the development 
would be disrupted, and cause even more wobble. But always waiting until the very end of the process 
might cause large wobbles, if a functionality is missing or changed beyond recognition.

Our tests themselves suffer from wobble. Exploratory testing, in some ways, seems to be built on the 
concept of wobble, and where it will take us. The tools we use to help find the errors – even 
something as simple as a set of tester notes – can suffer from changes that might appear simple. 
Those changes may have an effect on more-distant parts of the application, and don't get captured 
in the original set of notes on an area. Future testing and checking might be incomplete, and adds 
to the potential of missing things and ‘tech debt’.

Our developers have a focus on getting through the application for the specific use they see. Users, 
however, will very likely not follow this path, at points - or at all. Letting the system wobble may save 
hours of coding updates, even if it seems to be needless duplication in finding alternate ways to get to 
information. Ensuring that all of these ways work to make the user’s experience easier is not always 
the priority, but it should at least be thought about. This helpful wobble may delight someone who has 
been frustrated by a less flexible “happy path’ that other solutions offer.

Wobble, by itself, isn't bad. Reeds bend in wind, and the resistance they gain makes them stronger. 
Allowing the system to wobble a bit will help reinforce and guide future changes, rather than allowing 
the system to be inflexible. Change will happen, and the whole team is responsible for making sure 
that this is a positive thing.

Popular posts from this blog

30 Days of Postman - for Testers!

  https://www.pexels.com/photo/white-and-brown-cat-lying-beside-a-laptop-and-toys-5468268/ Photo by Karolina Grabowska from Pexels   Working with developer- focused tools can be a challenge for some testers: we may know what the words mean, but haven't used those skills recently enough to make the tasks simple. Or we may not have ever used them, other than at a quick glance to make sure that what we are getting matches what it should be sending. And some give results that require us to go find another team member to help interpret the results. Being a more-independent tester has always been one of my goals - being able to use the tools that are common in the team, and be able to do at least basic tasks that support my tests with them. Our team used Postman for many of the API tasks that we had, so exploring this tool was a natural fit. There are alternatives it there, both graphical and command line, so feel free to explore! The items that you can do, and tools that help

Where Is It? Part 1 - Inputs

Photo by Pixabay from Pexels     I am job-searching, and running into some coding challenges. Most of them are simple - some seem to want one-line solutions that require two cups of coffee and a half-hour to figure out what they want. Others are far above where my skills lie, and these I give a try for, and learn. And then there are the ones that offer, seemingly randomly, a challenge - within my skills (or at least my research skills) - that could be used as part of a larger project that I want to work on. This was the case last week, when I tried for a position that was a bit above what I felt I could do comfortably. The challenge was to let someone enter items, and then give back their location. In a language I am just familiar enough to be a danger to myself in. Happily, and thinking forward about how I could use this as a part of a larger program that would  use something like this to interact with the user. And also, this is command line, and thinking of how to set this up to

Getting to Explore: WSL2!

https://www.pexels.com/photo/black-and-white-laptop-2740956/ Photo by Prateek Katyal from Pexels   Working on a graphical interface system is a delight, but every once in a while, I want to return to the command line style of computing - it's fast, and can have impressive results for a system. Even before Windows came up with a full subsystem, having a virtual machine and a Linux terminal for using some things wasn't uncommon.Thankfully, the Windows Subsystem for Linux (WSL) now exists, and is mature enough to handle most things. And once I experienced this style of computing, and the knowledge that most things were as simple to do with command-line terminals, I want to go back to the command line often.  But being invited to see how much use replay.io would be for a tester helped make this choice easy. Not only did I get a chance to return to a method I enjoy, but a new tool that could help communication between team members. And, now that I think about it, with stakeholder