#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
Continue reading

A More Advisory Role

Over the last year I have looking to work myself out of the test manager role and into a more advisory role. And by April 2021 I was given the formal title change from Senior Test Manager to Senior Advisory Consultant.

I have had the title “Test manager” probably since 2008, so it’s been a while. In the companies, where I have been employed, the Test manager title has never been with line management (hire/fire). Rather it has been similar to a project manager, with a focus on the testing deliveries of a project, release or program.

I will still be leading test activities, but my role for the future will be more about enabling someone else doing the testing or someone else having a testing problem to solve. There are plenty of test activities done by people in non-testing roles – it’s the activity that matters.

Continue reading

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 they inspired the first post with the 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 them 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 measured, Testing is your sensory nerves, Eating 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 checking,¬†What if ‚Äď and Does it¬†Matter,¬†The small changes in the big¬†scripts¬†Routinized and bespoke¬†activities¬†¬†left and right side of the brain