"Where do testers fit in" and Team Topologies by Jesper Ottosen

Discussions
,
1

Continuing the discussion from Should testers be part of a squad/feature team?:
From @jesper :

Interesting references, so far I do not fully get the model.
It sounds somehow very specific to me.

Finally it boils for me down to this:
Products/services and their development & operation environments (all people, build server, versioning system, issue tracker, etc.) are a complex web of interwoven systems.

At the very least it is as matrix organisation.
On one axis are the products & services people are working on. On the other the disciplines.
While it is important that the people working on a product are working closely together (including coaches which often jump teams), it is helpful to have an exchanging within a discipline, product-overarching.
Some people may work on multiple products (also devs and testers) others may mostly work on a single one (also coaches). No matter their discipline.

Tailor the tightness of collaboration how it would fits your needs best.
I as tester switch in my product team constantly between testing myself and coaching the devs testing. Also I have from time to time meetings with other testers for exchange.

If one product/service is the base of another product/service it can openly discussed who tests what part at the integration of both. Maybe the using team tests the providing product more deeply, maybe the providing team implements and tests the integration in the using product more deeply.

Finally it is many people which have to do many tasks which needs to be somehow organized. No matter the imagined team or role boundaries.
Teams and roles are simplification to provide a basic structure for orientation.
The (also social, like coaching) needs-to-be-done work don’t care for that.
Many people (can) do work beyond their role.

I have seen many different approaches and it all depends on the context, the needs of the people.
Want to protect testers and see little to no change in cultural change? => make a dedicated test team :person_shrugging:

What do you say?
I have a tendency to see things very abstract while I also can imagine different implementation of this basics.
#ContextDriven

2

What do you say?

I’m going to go ahead and say that because @jesper posted this in the forum as part of a discussion that acts as consent to talk about it. If they want me to remove this reply then I will.

My opinion reflects yours, I think. I have a little to say about the categorisation, first.

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.

I don’t understand. This says that the group does more than testing. Well, testers do more than testing. Developers do more than development. Why does it matter, and what makes this group particularly interesting or unique, or what commonalities do they share that makes them differ from people not in the group?

I’m okay with bundling up some people and saying “where do each of the people in this group fit”, but it’s odd to say that the term exists because other people can test. Non-testers test inexpertly and not from a dedicated position of risk.

Roles are not about what we do that’s the same, it’s about what we do that’s different.

So testers should be…
I’m not sure the topology stuff is helpful to see where test folk should migrate. It does feel fuzzy-edged, and also makes claims without reason or purpose. Just because it’s self-consistent doesn’t mean it’s applicable. I can also apply all the team type definitions to each other and it still basically makes sense.

The problem with codifying business operations like this is that a business is really a bunch of people trying to get things done. We give them roles and groups and teams and people think of this as some sort of hard-edged categorisation system or siloing, but there’s no reason we cannot have our own role and access (and be accessible to) others.

This, I feel, aligns with @sebastian_solidwork’s “a complex web of interwoven systems”.

I think that a good tester is useful anywhere. I can test software, hardware, firmware, wetware, dryware, freeware, shareware and cookware. I can test documents, designs, concepts and ideas.

As such I could test as part of an enablement team. In fact, I have. I could test as part of a complicated subsystem team. I have. I could test as part of a platform team. I haven’t, but I have tested parts of platforms before whilst talking to various operations people, so we could say we made a new team on the fly.

Whenever I feel like it’s really hard to pin down the value of one thing or another it’s usually because the contexts are too variable, and I think this applies here, as @sebastian_solidwork mentioned already.

This doesn’t just apply to the context of each business, its people and their skills, but also what we consider, say, a tester to be. I think of a tester as someone who can apply their skills to test anything, but some people think of them as operating test cases or automatic check tools or some more limited scope, and how we place those people becomes more particular (and probably more evident) because of those limitations.

So we begin with the role, what it is for and who it needs frequent access to and what permissions it has, and then we can look our system and put it in the correct place with all the other roles and what they’re for. We also consider what a “team” really is. Perhaps it’s a grouping in a file in a drawer but the seating chart meets different needs. The lines we draw around people are based on utility - like a map of the streets of Paris vs a map of the main electrical systems of Paris.

Commonly, I’d imagine, all other things being what we need them to be, if I am in the role of an independently-minded tester in charge of my own work then I might be placed with a feature team as I’m going to need to talk to them multiple times a day.