Let’s begin with a special thanks to Benny & Marcel. Where would we ever be without the good help of smart people?
Benny & Marcel making a case for Testing in Production
It’s been 2 years since we launched TestSphere: A card deck that helps testers and non-testers think & talk about Testing.
People keep coming up with wonderful ideas on how to further improve the card deck. Expansions, translations, errata,…
A Security deck! A Performance deck! A Usability deck! An Automation deck!
Well… yes. The possibilities are huge, but it needs to make sense too: Value-wise & business-wise.
The thing TestSphere does extremely well is twofold: Spark Ideas and Spark Conversation – Thinking & Talking
Maja being ‘Business Manager’ for a RiskStorming workshop for DevBridge, Kaunas
RiskStorming is developing to become an incredibly valuable format. It combines the two aspects of TestSphere perfectly.
In its essence it makes your whole team have a structured conversation about quality that is loaded with new ideas and strategies. To be blunt: It helps testers figure out what they are being paid for and it helps non-testers find out why they have testers in the first place.
It’s the learnings and insights of having run continuous RiskStorming workshops for many different businesses in many different contexts that drive the new TestSphere expansion.
The creation of an expansion is driven, not by novelty, but from a clear need.
I present you here the first iteration of all new concepts on the cards. No Explanations or Examples yet. We’ll keep the iterations lean. If you have feedback, you can find me on ‘All the channels’.
Five New Cards Per Dimension
In the first version we had 20 cards per dimension. We noticed that some important cards were missing. The new expansion will cover these.
- Heuristics: Possible ways of tackling a problem.
- Dogfooding
- Stress Testing
- Chaos Engineering
- Three Amigo’s
- Dark Launch
+
- Techniques: Clever activities we use in our testing to find possible problems.
- OWASP Top Ten
- Peer Reviews
- Mob Testing
- Feature Toggles
- Test Driven Development
+
- Feelings: Every feeling that was triggered by your testing should be handled as a fact.
- Informed
- Fear
- Overwhelmed
- Excited
- Unqualified
+
- Quality Aspects: Possible aspects of your application that may be of interest.
- Observability
- Measureability
- Business Value Capability
- Scalability
- Availability
+
- Patterns: Patterns in our testing, but also patterns that work against us, while testing such as Biases.
- Single Responsibility Principle
- Story Slicing
- Mutation Testing
- Strangling Patterns
- Long Term Load testing
+
Two New Dimensions
Dimensions are the aspects of the cards that are divided by represented colors. We felt like some important dimensions were missing. Both of these are mainly operations related, a not to be underestimated part of testing.
Hardening: (working title) Concepts that improve the underlying structures of your software. Compare this dimension to muscle building – You need to strain your muscles until the weak parts get small tears, the tissue can then regenerate and build a stronger, more robust muscle. We test, exercise and strain the product so that we can fill the cracks with smarter ideas, better code and stronger software.
- Blameless Post Mortem
- Service Level Objectives/Agreements
- Anti-Corruption Layer
- Circuit Breaker
- Bulkhead
- Caching
- Distributed systems
- Federated Identity
- Eventual Consistency
- API Gateway
- Container Security Scanning
- Static Code Analysis
- Infrastructure as Code
- Config as Code
- Separation of Concerns
- Command Query Responsibility Segregation
- Continuous Integration
- Continuous Delivery
- Consumer Driven Contract Testing
- Pre Mortem
Post-Release: (working title) Tactics, approaches, techniques,… that improve the ability to see what’s going on – and orchestrating safe changes in your application’s production environment. When something goes wrong, goes well, brings in money, throws an error, becomes slow,… You can see it and its results.
- Fault Injection
- Logging
- Distributed Tracing
- Alerting
- Anomaly Detection
- Business Metrics
- Blackbox Monitoring
- Whitebox Monitoring
- Event Sourcing
- Real User Monitoring
- Tap Compare
- Profiling
- Dynamic Instrumentation
- Traffic Shaping
- Teeing
- On-Call Experience
- Shadowing
- Zero Downtime
- Load Balancing
- Config Change Testing
Wrapping up
I’m out of my water here. There’s so much I need to investigate, learn, put into words for myself before I can make it into a valuable tool for you. I welcome any feedback.
Thank you for being such an amazing part of this journey already.
The winning team of the RiskStorming workshop at TestIT in Malmö
Isle of IT 
I love all the ideas for new cards. It IS a bit overwhelming though, to think of working with a deck that big. I guess I would just have to try it. I’m a big fan of risk storming.
How would these be made available? For those of us with older decks, could we buy just the new cards?
I especially like the ones focused on post release. Monitoring, observability, learning from production use, it is all essential today.
I’d prefer a different name for the “hardening” dimension. So many teams have “hardening” springs by which they mean “OMG let’s freeze the code and do a bunch of testing and fix all the bugs before we shove it out the door”, which is generally an anti-pattern. Could you just call it infrastructure? Or operations? Or DevOps?
LikeLike
Hi Lisa,
Thank you for your ideas!
I agree that it can feel overwhelming. Hell, I’m trying to create the thing and feel like I fell off a new, bigger Mount Stupid of the Dunning Kruger curve. I’m afraid that that mirrors the nature of our craft though.
Maybe that’s the reason we need so many different roles and specialties. If it feels overwhelming when you do RiskStorming it might show that the team needs to learn more, as there are gaps in their knowledge.
We would make them available the same way we have the original TestSphere deck, but as a separate entity. So you could buy the expansion as an add on tot he base deck, but also separately.
I hadn’t heard of the name ‘hardening sprints’ before. But I do know they exist under different names too. I agree it’s an anti-pattern.
That’s why the muscle-building metaphor is useful. If you want a strong, resilient body, you need to practice every day, not one month after the winter holidays.
We could call it Development Patterns or something. I feel ‘infrastructure’ doesn’t cover all the concepts I’d like to have there. DevOps and Operations are much broader as they flow into most of the other dimensions. I feel like I would do the practitioners short.
I’m very open to suggestions, though I’m also extremely careful about the words I want to print for two reasons:
– once printed it’s there forever and therefor might not age well
– When choosing one name for one craft (i.e. testing) you might antagonise another. This is virtually what happened when people said ‘those are just checks’. It made some people very angry who ‘made just checks -but that were extremely valuable’.
I’m trying to be very careful in this and grow TestSphere & RiskStorming that will help Testers really plug into a team.
On the other hand, I’d love for a team without testers to do RiskStorming, learn so much about testing while doing it that they conclude: ‘we need to hire a specialist tester, because we don’t know most of this stuff.’
There’s so much opportunity here that it makes me extremely excited, but anxious at the same time. 🙂
Thank you again, for the support!
Kind regards,
Beren
LikeLike