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.

Less Test Managers, More Test Coaches

One of the trends/shifts I experience in testing & test management in particular is the Test Coach as discussed initially here: The Shift-Coach Testing Trend (Oct, 2016). Recently (Aug 2017) it came up again in a Twitter thread, where Stephen Janaway stated the inspiration to the title of this blog post.

Less Test Managers and more coaches. That’s how I see it going.

Fittingly as he inspired the first post with his talk “How I Lost My Job As a Test Manager” presented at Test Bash 2015. This post is a further elaboration of the Shift-Coach test management trend. Here are some of my experiences:

  • I have been assigned to an agile development team to introduce them to 3 Amigos, Test data driven test automation and such things. The purpose of my involvement was to enable the team to continue the practices without me, and without testers besides the business analyst / product owner (See The domain expert is the tester) as they are doing Shift-left. Similar to an agile or scrum coach, my approach was to look at it as a change in the way of working.
  • Another project is an infrastructure project, there are no testers only technicians configuring Cisco routers that by software can replace firewalls, iron ports, VM servers and other network equipment. The project has to implement 80+ of these, so I setup both a test process and an ITIL change request process acting as a test and release manager – another quite frequent trend. I could continue in the project for the duration, but instead I setup guidance and leave when it’s sufficiently in place.

This might be similar to a test architect, a (internal) test consultant activity. It has nothing to do with diminishing testing. Rather I see it as more testing happening, something that would not have been done without the coaching from a test manager. It’s all about finding a test approach that is fit for the context.

Here are some things others have written:

The competence of the test coach is to have enough change management expertise (people skills) and test management expertise (domain skills) to know how to coach and facilitate the change. Should test coaches test too, perhaps when required, but not necessarily. The activity is primarily to up-skill the team to continue on their own.

The “Test Coach” is a trend similar to “shift-left” and all the other shifts in testing and test management. I see it as a pattern, and what I read from the threads and discussions is that many test managers gradually shift towards test coaches.

2017-07-03 13.57.42

Don’t request the kitchen sink

More and more often I see outsourcing contracts that requests 10-15 test phases. It looks like someone has simply thrown the book at it, and not considered if it is an infrastructure project, a software development project or COTS implementation or – what on earth, they actually want to learn from the testing.

These are the phases of a recent project:

  • Environment Acceptance testing
  • Hardware and integration testing
  • Component testing
  • Component- integration testing
  • Installation test
  • System testing
  • Functional testing
  • Regression testing
  • Security testing
  • Performance testing
  • Operational acceptance testing
  • Service Level testing

It’s a challenge in the vendor reply. The vendor will want to reply to all test phases in order to be compliant with the tender, and not loose points. There is no room for elaboration or discussion if you want in on the bid process.

Quite often the requester comes back and say “we didn’t want all those weird testing things, we just want something that works for us”. But when the contract is signed and the work set in motion the project team have challenge to make the testing practical within the framework of the contract. This goes from both sides. Many good hours can be wasted with unwinding cumbersome contractual terms.

What I usually do in such a situation is to bundle the contract’s testing scope into fewer activities, and setup a mapping so that everything is covered. That is if the client allows me to make the activities practical and context-driven. If not – my hands are tied, and we deliver according to spec – even if the chapters of the test plans are set in stone.

Let’s work towards better deals for testing activities. If you are looking to prepare a BID include a test manager – and have a discussion of the value-add and learning of testing up front. There is no one book of how to do testing. Instead spend the time and money figuring out your context. Figure out what phases are on the client side, and what is on the vendor side. Have a test management consultant on retainer for before and after the bid process. Do something to discuss your test strategy and put the guidelines in the contracts, so that the vendors can propose a solution.

Don’t request everything and the kitchen sink too

Everything and the kitchen sink
Everything and the kitchen too

 

 

The Shift-Coach Testing Trend

Shift-Coach is when testers and test managers trends towards being coaches and facilitators of the testing activities. Shift-Coach is more about leading the testing than leading the testers to paraphrase from @DevToTest Joe DeMeyers blog post.

The ground breaker for this trend, is to me, the talk “How I Lost My Job As a Test Manager” presented at Test Bash 2015 by Stephen Janaway. Stephen explains how reorganization of the test manager role forced him to be more a facilitator than embedded in the teams. Similarly many other great test managers talk more and more about people skills and coaching, especially in agile projects. I want to define shift-coach around the facilitation testing activities, and place testers that doubles as scrum masters in the Shift-Deliver trend.

In traditional (v-model) projects testing has often included people that were not professional testers; – in user acceptance tests this has often been business subject matter experts. The testing was done by someone with the best knowledge of the topic, and that may not have been the professional tester. That more and more projects do this – more and more, is a big challenge for many testing folks. But it is a significant trend in testing world of 2016.

Shift-Coach trend is visible when Alan Page  talks at Test Bash Philly 2016:

You’ve heard the rumors, and you’ve seen it happen. An organization or development team decides they don’t need testers, and you have big questions and massive concerns. Is quality not important anymore? Are they irresponsible or idiotic? Are their hats on too tight? Do testers still have jobs?

Alan Page is a career tester who has not only gone through the “no-tester” transition, he’s taking it head on and embracing it. Alan will share experiences, stories, strategies, and tactics (and failures) on how he’s taken everything he’s learned in over twenty years of software testing, and used those skills to have an impact on software engineering teams at Microsoft. Whether you’re going through this transition yourself, think it may be coming, or just want to tell someone what an absurd idea this is, this is the talk for you.

This trend goes along with Shift-Right, Shift-Left and Shift-Deliver discussed separately. I discussed these trend labels at Nordic Testing Days 2016 during the talk “How to Test in IT operations“ and coined the labels on the EuroStar Test Huddle forum.

legocoach
Drive the Testing – Coach!

Give me your testing worries

In testing we handle risks, concerns, challenges, worries – we put the sore spots in the spotlight….

“Give me your tired, your poor,
Your huddled masses yearning to breathe free,
The wretched refuse of your teeming shore.
Send these, the homeless, tempest-tost to me,
I lift my lamp beside the golden door!*

Have the courage to stand tall and be the beacon where worries go to

ladylego

 

See also: Acceptance is more than what can be measuredTesting is your sensory nervesEating wicked problems for breakfast

FYI conference – workshop om ET

[ FYI IT QUALITY & TEST MANAGEMENT conference | 12.6.2013-13.6.2013 Hotel First Copenhagen ]

WORKSHOP: Sådan kommer du i gang med Exploratory Test – uden at miste overblikket!
Exploratory Test er på dansk også kendt som udforskende test. Man kan nemt forledes til at udføre den ustruktureret og uden overblik. Med få teknikker kanman dog lede en Exploratory Test, så indsatsen bliver en aktiv valgt tilgang med fokus på det, der giver ny viden. Nogle af de teknikker, der er vigtige at kende i regi af exploratory test er: mindmaps, heuristikker og session-based test management.
Workshoppen tagersigtemod at give dig nye ideer til, hvad der kunne være relevant at teste af det, du sidder med til dagligt. Ligeledes får du input til, hvordan du undgår at miste overblikket, når du konkret står overfor at skulle vælge, hvad det giver mest værdi at teste i en given situation.
Dette er en praktiskworkshop – såmedbring din laptop!

Om workshop underviseren:
Jesper Lindholt Ottosen har i 10 år arbejdet med struktureret test i Systematic, CSC og TDC. Han har siden 2009 haft interne og eksterne blogs om softwaretest og følger de seneste trends på den globale scene indenfor Exploratory Test og context-drevettest. Jesper harfokus på, at tests skal gøre en forskel ved at være værdi-drevet og finde information om projektets egenskaber.

ETinanutshell_png

Testing is like connecting the dots

there is more to it, than just following a script.dot2dot

Very much related

Black or white – it is the same box

Fell in the trap of total coverage

It’s a matter of finding the pieces that make the picture

Seriously joking or joking seriously

Black or white – it is the same box

blackandwhite

  • Exploration, Finding, Testing, Setting up hypothesis, Manual, Bespoke, Check lists, What if
  • Steps, Confirmation, Checks, Proofs, Automated, Routine, Test cases, Does it matter

Does it indeed matter …

The “box” is a solution – if the box doesn’t fit the problem, it doesn’t work. (period) 

See also: Testing and checkingWhat if – and Does it MatterThe small changes in the big scripts Routinized and bespoke activities  left and right side of the brain

A Rumsfeld Rectangle for test strategies

Donald Rumsfeld is famous (to me) for talking about the known knowns [1]. It was in 2002 where he talked about the absence of evidence on mass destruction weapons in Iraq. Add to that the angle of the unknown known, and I can call it the “Rumsfeld Rectangle“.

You could apply it in test strategy setting like this:

Rumsfeld Rectangle:

What do the stakeholders want from this test activity?

What do they Know

they want to Know

What do they Don’t Know

they want to Know

What do they Know

they Don’t want to Know

What do they Don’t Know

they Don’t want to Know

I have used the Rumsfeld Rectangle previously in The unknown unknown unexpressed expectations and How to spot defects. The tricky problems are (as always) in the areas of “there are things we do not know we don’t know” spot – as for Rumsfeld. Combing the desert showed the absence, not the presence of weapons (to rephrase Dijkstra [2]).

I – equally ignorant – do not believe [that I know anything] [3]

1: [ There are known knowns United States Secretary of Defense, Donald Rumsfeld |

[T]here are known knowns; there are things we know that we know.There are known unknowns; that is to say there are things that, we now know we don’t know.But there are also unknown unknowns – there are things we do not know we don’t know.”

2: Dijkstra 1969: Testing shows the presence, not the absence of bugs

3: Piet Hein Seriously joking or joking seriously

Workshop facilitation using LEGO

As well known, LEGO is synonymous with “Play well” – for both kids and AFOLs. But seriously, LEGO is more than that, consider:

[LEGO Serious Play]

LEGO SERIOUS PLAY uses LEGO bricks and elements and a unique method where people are empowered to “think through their fingers” – unleashing insight, inspiration and imagination. In a very direct way, you will be able to see what everyone knows inside the company – and what they don’t know they know! Within a surprisingly short time, an organization can have a clear, shared direction with people who are confidently aligned and committed to a course of action.

Lean LEGO – The red brick cancer ]

If you would build a LEGO time line of your processes, would they be mostly red and yellow? Or would they be mostly green?

Besides the   where I elaborated on how LEGO mini figures could facilitate a discussion on both tester types and team skills. Recently I have had the personal opportunity to participate in a facilitation training, where LEGO bricks and figs was used to illustrate team members, represent user personas and user innovations. So the thing is – what do you need to get started? Choose your pieces by context: Customised Minifigures, city people or a huge pile of bricks?