The word is out! A new TestSphere expansion is available on the Ministry of Testing Store. I’ll give you the ‘short sell’ first, before going into my personal story of why this deck is a worthy addition.

1. It’s got an amazing box. No longer will your feeble cardboard box break or tear as it tries to contain your TestSphere cards. The new box is stronger, big enough to hold both the orginal as the expansion.
2. There are two new categories. The orignial cards focused much on known test techniques, patterns and heuristics which most testers already knew by name or by concept already. The two new categories venture into Operations and Architecture. Why those two? Because I personally feel they are/will become more relevant than anything else for testers across the globe.
3. 7 Blank bonus cards. For every colour a blank card is added. This means you can customise a bit. We’ll make these empty cards available as a free to print template.
4. 5 New cards for each colour. Each of the 5 existing colours got 5 new cards that further diversifies and deepens the dimension.

This is a pretty cool addition that will take your sphere of knowledge into quite different directions. You’ll be exposed to architectural concepts, observability strategies, increased availability measures and processes that will make your application more resilient.

Remember picking “stability”, “performance”, “operations” or… as a primary Quality Aspect during RiskStorming? Well, you now will have a more diverse set of techniques to tackle its possible risks. More improtantly though, the discussions you will have concerning quality will draw more diverse people in and will go wider, much wider than testing. This brings me to my personal insights…

A Bubbling Cauldron

Three years ago, I was a tester with some experience, launching a TestSphere deck that was largely a culmination of what I learned from others. Someone once said I threw some books and blogposts together into a card deck and resold that. I’d debate that, but then again, what’s the point?
This month, again with Ministry of Testing and the test community’s aid, we launch a very different addition to this deck. One that, in my opinion, is extremely relevant now and for the years to come.
Imagine me carrying around a big cauldron for the past 3 years. Consider all the possible ingredients I put in and where I picked them up:

• Around 50 RiskStorming workshops on various projects all around Europe and one in Africa. 50 workshops, 15+ countries, about 1000 different testers/non-testers. That’s a lot of introspection and feedback.
• Worked as a Product Owner and Quality Coach on top of growing my own business, employing people in my own special vision.
• Supporting and advising the launch of a Europe-wide conference on Diversity & Inclusion and the human aspects in IT.
• Attending numerous Testing Conferences, Development Conferences,…

It’s a lot to digest. Furthermore, because the cauldron has been bubbling so wildly and for so long, the dish wasn’t quite ready up until now.

Some digestible bites

The following are bits and pieces of my thought process, hopefully making clear to you, the reader, why this expansion is relevant.

• ‘Testing’, be it manual, automated, exploratory, mobbed, isolated, executed, performed,… is a word very few people are concerned about. Many people feel burdened that they ‘should’ be concerned about it, but most people don’t want to be. Compare it to having to clean up your room. Some people really like doing it. Some people really like putting in hours automating some tasks, optimising and tweaking them. But most people just want a clean room and don’t need details on how it got there. I’d be the first person to say that this is irresponsible behaviour, degrading and probably a ticking timebomb. Yet after at least to deckades of trying to convince people of the importance, the industry as a whole becomes more and more hostile.
• I was hired on a project as a ‘Quality Coach’ where they were vehemently against hiring testing. They had all the fancy stuff: Kubernetes, all the dockers, Kafka, Grafana, some scaling scrum thingy, communities of practice, SUPER COOL STUFF YO. The project had been running for more than a year when I joined. During the two months I was there the project release vision had yet to take shape. When it did, it changed several times and was eventually communicated to the teamleads. Then everyone assumed it would trickle down and the whole team would know ‘the plan’. Three months later, just before the massively important deadline, everyone is working overtime.

• Test Automation on the UI and sometimes API level, as in the checking off things we already know, is largely a waste of time and in many, many cases a bad trade-off. A great number of projects could save lots of money by delivering with a bit of a delay and having one person check some flows or printscreens or whatever. The time invested in ‘pushing everything all the time and checking all the things all the time’ is exceptionally expensive. Some projects pull this off, most can’t (efficiently).
• A very large portion of software projects are driven by personal wants, such as having the new state-of-the-art fancy thingy on one’s CV. Maybe someone wants to show a new shiny on the next demo. What happens even more often is someone saying at the start of the year: “This year we’ll grow by 10%.” with no plan, no risk assessment, only a feeling. I don’t see too much of that sustainable pace or good, honest communication between individuals from all ‘levels.

This works for the most of us. We can do cool things, earn a decent wage and most of us are bathing in luxuary nobody in the course of history could have ever imagined, anyway. So what’s the problem? … we’ll get to that.
I can only conclude that sweeping the dirt under the rug, or stashing all the garbage in the cellar is a good tactic to sell more, as long as the outside is shiny. This saddens, angers even, the idealist in me.

• People with good testing knowledge, who can also transfer this knowledge to especially managers, leaders, anyone calling shots are worth their weight in gold. Your projects are an endless series of trade-offs. Investing in one thing means neglecting or breaking another. People with a testing mindset, who also know architecture systems or running an application in production, are in a unique position to point out these tradeoffs and can actually point out what is at risk.
• Marcel Gehlen, a tester/developer/architect/.. turned manager says that Testing is a skill that is very difficult to sell. It is, however, a skill that will help people be loved. His advice is: get a skill, any skill, that gets you through the door. Then do testing.
  Following  the above clean-your-room analogy; customers buy roombas by the dozens. They pay good money for them. When the roomba starts cleaning up a lot more than just dust from the floor, there’s no way they want anything else.
• Architects & Operations people are the closest people to us who are also focused and reliant on risks. We need to work together, not only mitigate risk, but also accept, tranfer and sometimes ignore risk.
  Only by discussing quality, risks and measures to improve our chances of success, can we do our jobs most effectively. Everything else is a waste of time and money.
• Testing is an amazing skill. Testing is an amazing mindset. Testing itself isn’t that hard, but being a tester often is. (This is true for many roles in software development)

My Advice

Expand your knowledge and your vocabulary. No, I’m not telling you you need to code or learn some whatever UI automation tool that’s just a shell on top of Selenium.
I AM telling you to play to your tester strengths:

• Understand, explain, advocate for- and find holes in systems. Architectural systems, systems that Operations people use to ensure the application runs carefree. You’ll be surprised about the posibilities.
• Find Allies. You are not the only one concerned about risks. Most people just lack the vocabulary and skills to advocate for measures to be taken. Find people who have those skills and learn how to advance conversations into plans.
• Have a project-wide conversation on Quality. I’m super biased when it comes to RiskStorming, but in all honesty: I don’t are if you use TestSphere or any other tool. Just please, please, for the love of all the deities: have a conversation and prioritisation on quality aspects, risks to these quality aspects and come up with a plan that manages these risks and measures. It’s not easy, but it’s your job!

And that’s why this expansion is so relevant.

A Heartfelt Thank You to:

The Ministry of Testing, Abigail Bangser, Benny Hofman, Benjamin Fellows, Marcel Gehlen, Melissa Eaden and Thomas Harvey

---

Still not convinced? Here are a few examples:

Examples

This card is a result from a RiskStoming workshop. Questions started arising such as:
What if the person sat in a wheelchair?
What about facial types?
What about people of colour, different genders…

With the new rage of ‘Artificial Intelligence’ that is being taught by ‘data on the internet’, or whatever subset we feed it, this ‘new’ Quality Aspect is growing ever important.

Will your product amplify our biases & prejudices, or will it enable us to do something about it?

 

 

“Releasing a project shouldn’t be a big deal anymore, certainly not a reason to party.”

Using Dark Launch, you can minimise risks in releasing by greatly lowering the target sample. Combined with several monitoring techniques, this can be a very cost-effective way to mitigate risk.

 

 

 

 

 

 

I guess this would qualify as a ‘new shiny’. Microservices have been on the rise for some time now and they certainly have their use in a great many products. Not all of them, mind you, but many.

They add a layer of complexity that rises exponentially with each added system. They come with their own risks. Risks you better know about when testing these systems as a whole.

In my experience, very little people are actually testing ‘the whole, connected system’, but are content to make suretheir own small microservice does what it should.

 

 

Another staple in ‘new ways of releasing’. Feature toggles lets you (theoretically) test safely in production. They allow for very, very cool tactics in releasing software.
Just make sure you don’t overdo it.

There’s usually not a good case to keep feature toggles for a long time. If they have fulfilled their use, remove them.