Communicate Curiosity

A “testing mindset” of inquiry applies when you are a principal tester or even a senior advisor in testing. Asking open questions and approaching a challenge with exploration proves better than command and control. People are people – be mindful of where they are.

Currently, I’m involved in an extensive change program for a company. It’s not your usual agile feature factory but more about the technology stack needed to run a 3000 people company (payment, finances, etc). While testing professionals could be onboarded – their learning curve would not scale – not even being equipped with all the heuristics and testing vocabulary in the world. As it is a one-off, automation wouldn’t scale either.

Fortunately, most applications have a system owner (or product owner, or manager in charge) and usually a team around maintaining the application. To some degree, we could frame these teams as stream-aligned teams. The experts in testing the applications are the superuser – hence they do the testing.

Trust must be extended before it is given

Rachel Happe – @mastodon.social/@rhappe

One such team is the XYZ team anchored by a VP-level manager. A colleague and I had been trying to communicate with them to align on the testing needed but had met reluctance. They would not have time to help us. We discussed the matter and realized that we needed to approach them differently. Since the change program was such a fundamental shift for the team, they had already considered the implications. They were already testing and thinking about the impact. We just had to trust them – and build on what they already had instead of imposing specific ways of working.

Without requiring them to earn it first, tell everyone who works for you that you #trust them implicitly. From that point forward, just ask them to never give you reason to withhold it. (In my experience, most won’t).

Mark C. Crowley

Communicating curiosity can be a little thing like “Remind me, how does XYZ work” or simply “sitting on your hands” during meetings that you would previously fill with questions and requests. The tables of the great program test lead are turning, it’s about being an enabling function for others to succeed. Similar to the freedom you should give your growing up kids – it’s about leadership.

#268 – Who Brings in New Knowledge?

Well, if you are reading this – there’s a good chance it’s you. Especially if you read this with the intention of sharing this with your team. I hope you do, obviously 😊. But perhaps it’s unclear whose responsibility it is, to bring new knowledge to the team. Is it always the team manager job – or is it a dedicated person that by role, or by habit, that bring in new knowledge?

Photo by William Fortunato on Pexels.com

#263: There is a Model for your Trouble

Often directors, managers and other decision makers talks about an advanced challenge they have: What can we automate, who should automate and what tools to pick. There more and more I listen, the more I hear – they have not applied any models of the problem at hand. And there usually is a model of the problem space already. Any old model is preferable over no model at all. But it can be hard to see in the middle of chaos.

Conway’s Law for Test Automation?

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Melvin E. Conway via Wikipedia

Conway’s law continues to be one of the hard truths in IT deliveries. It tells us that solutions are shaped – by the shape of the delivery organization. While Conway’s law is usually seen on a macro level (Just Eat UK is an example) – it also applies to smaller units (see the Angel of North anti-pattern).

As software test automation becomes more and more like a software development project – I would hypothesize that Conway’s law indeed predicts the shape of the (test) automation solution. So in other words, if the shape of your automation is a pyramid/triangle, so is your team structure heavy on development tests.

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.

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.

Relations – are about half of IT

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

Automation is for Other Roles Too

Automation of business tasks is no longer for the software developers only. Similarly test automation is no longer for testers and test engineers only. Both these trends help to create smarter testing performed by non-testers.

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.