On the Shoulders of 112 Giants

In my book “Goal-Aligned Test Strategies,” I draw extensively on the work of others. This is a reference post to further credit my reviewers and to list the 112 references in the book.

Special thank you to Lonnie for my writing evenings and to Simon Wardley for finding a path.

Reviewers and Feedback

Referenced Quotes

“Making work visible is one of the most fundamental things we can do to improve our work because the human brain is designed to find meaningful patterns and structures in what is perceived through vision. Thus, it makes sense that we have difficulty managing our work when we can’t see it.”

Dominica DeGrandis, Making Work Visible: Exposing Time Theft to Optimize Work & Flow, 2017

Today, we are offered a bewildering variety of tools and concepts to aid in analyzing and constructing strategies. Each of these tools envisions the challenge slightly differently. For some, it recognizes advantages; for others, it understands industry structure. For some, it identifies important trends; for others, it erects barriers to imitation. Yet, there is a more fundamental challenge common to all contexts. That is the challenge of working around one’s own cognitive limitations and biases—one’s myopia. Our myopia is the obstacle common to all strategic situations.

Good Strategy/Bad Strategy: The difference and why it matters” by Richard Rumelt, 2017

“Take your strategy. Apply it to 3 random companies. If it sounds like it would be something they would want (“more money,” “more customers,” etc.), then it’s not a strategy,”

Adrian Howard, 2022

“Instead of well-designed strategies plotted out in sealed boardrooms, executives needed strategies dynamic enough to receive market feedback and flexible enough to evolve.”

How to Make Big Old Companies Act Fast, Pia Lauritzen 2021

“Anticipate your boss’ needs before they do. Help them with prioritization as much as possible. In the same way, they shield you from upper management, shield them from details that are not important – a boss that wants insights into every detail needs micromanagement coaching, and you can help too.”

Tristan Lombard, 2022

The way we have always thought about strategy is very centralized and top-down. That’s controlling and directive – and leads to very detailed strategic plans. We need to move towards something lighter driven by a shared purpose.

Rachel Happe, Control Is For Amateurs: Empower The Community To Change The Culture In Your Organization, 2018

“When you learn Wardley Mapping, you may build better situational awareness than your boss has and a better one than anyone in your time. Unfortunately, you are doomed unless you know how to sell your strategy to other people and whether you can sell it in the first place. Nobody will act on your thinking.”

Krzysztof ‘Chris’ Daniel: You need to sell your strategy! 2022

Referenced Links

Referenced Books

Blog posts

#267 – Reminder – it’s about Story Shaping

In agile delivery teams, it’s recommended that stories and features are discussed before being developed. A checklist called “Definition of Done” can be used as a reminder to check that the delivery team has everything needed to prepare the delivery of the feature. A key ingredient is a shared understanding of how to confirm the delivery – for the whole team.

Story shaping requires at least three people to get together. They are not amigos nor amigas. They are often three, sometimes two people, and often more. They represent the different viewpoints needed to deliver: builders mindset, testing mindset, security mindset, operations mindset, business mindset, etc.

No one person can hold all these viewpoints – at least a builders mindset and a requester/business mindset is needed.

If you skip doing story shaping your acceptance criteria and testing activities will be misaligned. And you will either have overdone the effort needed or underestimated the challenges of the story.

Thank you to all who have replied to the tweet below.

One customer, three people to do the story shaping

#265 – Using MTTR to Understand When to Test

It interests me deeply to explore why testing is happening. Often it’s because some decision-maker or framework dictates – “This is the Way“. And off we go on the quest to slay the dragon – or move items from point A to point B. Without much thinking about how the side quests help to move the main risks of the story.

The main risks are usually around something irreplaceable – and hence we test and try our best to shield it. But not all risks are equally dangerous. In IT we can build implicit testing into repeatable deliveries and reduce the time to fix things. The faster things are fixed, the better is time to information for the business needs.

Grogu agrees
Continue reading

Stop Writing Overdone Test Plans

While I have previously talked about writing down expectations and alignments – I would much prefer a more lean and up-to-date approach to test plan documents. Looking at what we know now, an separate test is more of a sign of missing trust between parties than a collaborative value add for the business needs.

Continue reading

Trends for the Tester Role

YMWV – this is a model for reflection not to a 1:1 scale of everything in the universe. It might be useful.

The space for the testing professional is under pressure – for my own role and even more for the “traditional” testing professional. At least since 2017 there has been a shift and ongoing disruption. I finally have a form to visualize some of the trends that puts the role of the tester under pressure:

  • SIT / UAT debate
  • Low-code trend
  • Modern Testing
  • Quality Engineering and whole team approach

I still see two key areas (stars below) for the classic tester to move into: exploratory testing based on weak signals and supporting the end-users low-code activities (test tool smith). For the more managerial and coordinating role I will have to get back to you in a future blog post.

Continue reading

Darlings, Pets, Cattle and GUID’s

Kill your darlings and treat your tests more like cattle than pets, are among some of the heuristics currently around for managing your environments and automation test suites. These heuristics tells me that the environments and automation are in a state of product or even commodity, while previously the tests and environments where like darlings and pets – named and nurtured.

Continue reading

The Testing, not the Testers

Occasionally I see posts and discussions, where testers are indignated that this and this company has no testers. How could they! Or similarly when a product is released publicly with significant issues: See – it’s because they have no testers! Or that the testers are not taken seriously. OMG!

Continue reading

Relations – are about half of IT

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

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]

Where Does Testers Fit In?

We often discuss where the “testing people” fit into the organisation – are they part of a delivery team or an enablement team independently of the delivery teams? The Team Topologies model enables a discussion about this challenge and a guidance on what goes where and why.

I can see the benefits of having a central Test Center of all the testing people – and, on the other hand, having them spread out in the delivery units. I work in an IT services company, sometimes a project does not require full-time test attention. So we work on a range of customers, at the same time. On the other hand, sometimes projects lasts for years and years – and the testing people become dedicated towards a specific company IT stack and delivery team.

Notice that I use the term “testing people” to cover testing specialists, test analysts, automation specialists, test engineers and test managers like myself. Besides the moniker “testers” in the blog title, I try to avoid calling us “testers”. First of all, “testing people” do more than testing and secondly other people do testing too.

The Test Center I’m in is an organisational unit of “test consultants” of various of the mentioned roles working for various of projects. But considering the “whole team approach to quality“, the Test Center unit sounds a bit .. off. Would it be better to assign everyone to a delivery unit? – What would be the reasoning behind what goes where where and why?

I have found the Team Topologies model, which identifies these teams:

  • Stream-aligned team: aligned to a flow of work from (usually) a segment of the business domain [yellow]
  • Enabling team: helps a Stream-aligned team to overcome obstacles. Also detects missing capabilities [cyan]
  • Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed [red]
  • Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams [purple]
The 3 interaction modes of the Team Topologies model

The model identifies three modes of interaction during the flow of change:

  • Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)
  • X-as-a-Service: one team provides and one team consumes something “as a Service”
  • Facilitation: one team helps and mentors another team

Based on this model the dedicated testing staff should be part of the stream-aligned delivery unit. While everyone working ideally to enable the team – testing coaches etc – should be part of an enablement team, aka. a center/unit/group/staff team for enablement (Accelerate the Achievement of Shippable Quality). I read into it, that the enablement team’s primary focus would be to build self-reliance in the team and get out of dodge. A key principle in Modern Testing.

How “testing people” could fit into the other two teams (Subsystem & Platform), I would have to consider a bit more. The testing activity is in both, and the Enablement team also facilitate (testing) into those two team modes/units. So perhaps it’s not that different. What do you think?

The findings of the model also aligns with the “Product Team” and “Competence Team” of this article (in Danish): Hvilke karakteristika og udfordringer har dit team?

Reality, though, is a bit more complex. Even the Team Topology Model – is just a model, and wrong a some point. It is though still useful in enabling a discussion on where the testing people fit it, and why.