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.

Shot, Neglect or Train?

How you treat the bringer of (bad) news tells me a lot about the organisation and potential for business growth. Go Read Accelerate – that book is full of insights. One of the models, is the organisational types from Westrum:

[ Screen capture from the Kindle issue of Accelerate ]

Andy Kelk has a to-the-point description about Westrum on his blog:

To test your organisation, you can run a very simple survey asking the group to rate how well they identify with 6 statements:

https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
  • On my team, information is actively sought.
  • On my team, failures are learning opportunities, and messengers of them are not punished.
  • On my team, responsibilities are shared.
  • On my team, cross-functional collaboration is encouraged and rewarded.
  • On my team, failure causes enquiry.
  • On my team, new ideas are welcomed.

The respondents rate each statement from a 1 (strongly disagree) to a 7 (strongly agree). By collecting aggregating the results, you can see where your organisation may be falling short and put actions in place to address those areas. These questions come from peer-reviewed research by Nicole Forsgren.

https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture

So when a passionate person comes to you with (bad) news, what do you and your organisation do? Do you reflect, ignore or hide the request? Do you say that it’s not a good idea to bridge the organisation? Do you raise an Non-conformity and set in motion events to bring “justice”? Do you experiment to implement the novel ideas and actively seek information?

FAIL = First Attempt In Learning.

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!

Connected online

Apparently my Internet habits are very teenage like… I miss my WiFi and cannot leave the phone in the pocket. What I am is a digital settler, connected to my processional community.

I realized this at a training recently, where it was noticed that I had my phone out DURING CLASS. Was it FOMO – no, I just had a thought about testing to share on twitter. As I would usually do during conferences and my working day. We had a good laugh about me always needing my internet and my phones. I took it as a compliment, as that would mean that I was a YOUNG digital rookie, sharing and collaborating. .. like only the cool kids would do.

young-luke

When I model  myself to the Teaching Trios model – I am a digital settler by age/ introduction time. But collaborating and having an online professional interaction is not based on age, nor should it be frowned upon. Online community interaction is done by all ages, diverse and really nothing new. It’s past hype, and not ground breaking. There are models now of how communities evolve and function. And the business, career and personal benefits explained over and over again.
Yet I have more followers on twitter than the company I work for. Sometimes when someone else at work shares curated testing papers, I have seen it already and have met the people who wrote it. (Read Meet the famous people)
When I model myself towards Simon Wardley‘s three-stage model (Pioneers, Settlers, town planners). I don’t jump anything brand new, but I do want to take the groundbreaking and turn it into a framework for others to succeed… So to my kids Netflix is TV, and my mom follows me on Facebook to see what I’m up to. (no good, I swear).

Testers are Knowledge Workers

Treat your testing people as knowledge workers, not rote industrial resources. The later is a spiral to the lowest value, the former is about giving the business valuable knowledge. A modern tester is a knowledge worker – whose prime area is finding information, filtering information, relating information and presenting information. It is a non-linear process, that requires a touch of both creativity and consideration.

The best testing tool is the brain, and the knowledge worker ponder the problems both consciously and unconsciously. She can work without using the hands or legs, but not with a simple headache. It takes a lot of thinking and collaboration with the stakeholders to identify what questions about the product has value to the business. The (context-driven) knowledge focused tester focus both that it works, and that it adds value to the business.

19ad6-cycle

The business focus are far from the classic mindset of testing established around the millennial (2000). where testing is about finding defects and going through the motion of deriving test cases from specifications. – I know I’ve been there. That era is long gone, even dead at some time to Whitaker and Alberto Savoia. Be provoked or even insulted, but it’s the future.

But wake up – it’s not where the testing world is today. The old tools of design techniques and coverage metrics makes less and less sense to the business. They are old-school and classic approaches, in the not so cool way. The cool kids on the block are poppin’ tags – getting new stuff, sharing and exploring. They know that change is the new normal and that what works in one situation doesn’t work in another. Their primary concern and focus is getting knowledge to the decision makers. They are the knowledge workers

Here – have some of my power

One of the ways I lead the team of testers in my project is through delegation of power from my own role…

1) A test manager in my group asks guidance. The members in the project team does not reply her requests or give her the information she needs. As a test manager in the project she does have the theoretic power, but not the practical power… I send her back with all my powers – to tell them that because I said so, they should respect her. I don’t mind taking “stars” of my shoulders and giving the power of my role and position to someone junior to me.

2) A tester on my project team approaches me to ask for permission to create tasks on our task board. I immediately grant her a “do every thing you need to do, without asking“-permission. By all means take the initiative and ownership. I probably fail to manage everything, so we need to work together on this. By all means go ask the developer, create test cases, find things we didn’t know – think.. and test.

Sometimes I think, this is perhaps a Danish “equality” culture – but then I realize it is a collaborate approach for the modern knowledge worker. It works equally well with people from both India, Denmark, Philippines and China.

My style is not to CONTROL – but to facilitate KNOWLEDGE. In my team the team is the star

vikings

Chicken for Christmas – Tradition is a choice

TL;DR: Testing is always something that we choose to do – and how we test is similarly a matter of choice. As is Christmas traditions. .. it’s just man-made rules, we can choose to change them.

So I was discussing what we should have for Christmas with the stakeholders. One of them wants the traditional rice pudding, the other wants – untraditionally: chicken. And you know what – that’s ok. Traditions are guidelines, not rules – we can make new traditions, just by choosing to.

Testing in production used to be a great no-no. I’m still feeling odd when we do it, but I have come to see it as another tool of the trade. It has a name now “testing in the wild” TTitW as has been presented at EuroStar 2015. Also this is how Netflix have been testing for years, from GitHub, as it is open source too (!).

You might argue that changing testing (in the wild) is not allowed. I will challenge that assumption – being allowed to do something is a choice too. You choose to follow the the process frameworks, requirements, rules… and you can choose not to. The tradition of manual predefined testcases are so four years ago!

Sometimes it’s just a matter of saying up-front, that you are tailoring the process. So choose an approach that actually gives meaning and value to the stakeholders and context. Deconstruct the traditions and commercial bodies of knowledge and make some new!

http://www.eurobricks.com/forum/index.php?showtopic=64241
http://www.eurobricks.com/forum/index.php?showtopic=64241

What is the purpose of meeting?

If all you bring to the meeting is what you have prepared in advance – what new do you learn by meeting?

I once was at a company that should have the motto “always prepared”, “semper fi” and “errors are not an option”. Every meeting had a check sheet, a resume form and a registration of preparation time. Because if it wasn’t measured it didn’t count. If it wasn’t in the play book it didn’t count either.

So one day we sat at the meeting reviewing a development story – the developer, an architect, me and the other roles required by the check sheet. Some had prepared written comments: everything from simple rephrasing, code changes and test case headlines. Some had not prepared a tangible thing – I had not.

So the interesting question came up: why meet at all, if the only purpose of the meeting was to go through the written changes. These could be sent directly to the developer or discussed bilaterally, and not heard by all five. The answer to this was not in the play book, and the meeting was puzzled.

I had prepared nothing in advance, yet I had prepared myself in advance to listen, think and wonder during the meeting. To me the purpose of meeting* was the joint collaboration of the participants.

The sum of the whole. That 1+1+1+1 can be five.

closurelaw-sm
—-
*: meetings can have other purposes. Sometimes I hold orientation/elaboration meetings, when things cannot be elaborated sufficiently digitally.

Bug Return Policy

We find bugs, irregularities, this that should be there, and things that shouldn’t. From that we create a bug report, and from that someone looks into it, and then it’s a wrap. Unless the information is not returned, an no-one is the wiser. A bug report to me is a representation of an observation of the system, usually something that’s wrong. Some tools and vocabularies calls this “defects”, “bugs”, “tickets”, “incidents”. A bug report can be an email, post-it, or even a mentioning in passing [2].

Here are some recent sample headlines:
– The design is unclear, please elaborate
– With this role, I can access this, which I shouldn’t
– When I compare the requirements to the delivery list, I find these ..
– There is no data here, but there should be
– We thought we wanted this, but now we want something else
[3]

Notice that a bug report usually originates with a person, making an evaluation. This person is the tester, no matter the functional hat (SME, SDET, PO, VP). This may be tool supported, coming from a log of automated checks, or from BDD or Jenkins or what not. No matter the amount of tools, a person is making an informed decision, and raising the bug.[4] Come to think of it, she could choose to do nothing. But something is bugging her [5].

Here are some recent replies to my bug reports:
– it is by design
– it works on the development environment
– that’s how the COTS (or framework or platform) handles it
– ok, got it. seems like an easy fix
– awrh, now we have to rethink the whole thing
– Defferred, FixedUpStream, Rejected,
– Hmm, I see what you mean. Let me look into it

These replies come from some other person than the tester – let’s call him the fixer. First of all the fixer evaluates the report – he makes a decision, based on his context and his available information. Sometimes it’s an easy fix, sometimes it cannot be reasonably fixed. Sometimes the fix have diminishing returns. And everything in between.

What is very important to me, is that the fixer communicates his immediate evaluation to the tester. As quickly and transparent as possible. The fixer, to me, does not have the option to close it [1] alone. Nor can he fix the bug without letting the tester know. In the end the tester calls whether it is resolved or acceptable given the updated information. If the tester and fixer cannot agree, then call for outside help. And only then, let the two people work it out first.

The bug report and “fixer reply” has to be returned to the tester. Either the fix has to be tested, or the no-fix has to be tested too. It’s all part of the game – and it’s all integral to improve the quality in the short run – by fixing this specific project. It is an integral part in improving the quality in the long run, by adding knowledge and collaboration to the solution of the bugs found. Every bug, every clarification, every wish from the test to investigate something about the product counts towards collaborating about the quality of the solution.

TL;DR: Always direct the reply to a bug back to the person who found it.

1: Closure http://www.ministryoftesting.com/2014/11/closure/
2: Mentioning in passing, aka “mipping” http://www.satisfice.com/blog/archives/97
3: 3 types of bugs http://cartoontester.blogspot.dk/2010/06/3-types-of-bugs.html
4: How to raise a bug http://cartoontester.blogspot.dk/2012/10/3-steps.html
5: Something that bugs someone whose opinion matters. http://www.satisfice.com/glossary.shtml#Bug

minecraft_creeper_wallpaper_by_lynchmob10-1440x900

Lego Role Models for Girls

Who had the family’s largest LEGO set his Christmas – not the boys (age 8-10), neither the “boys” (age 40 and up) – it wasn’t me* – but the 11-year-old girl and her 8 wheel 42008 Service Truck – 1276 pieces, power functions, pneumatic, gears and 44 cm forcefulness. There was no boy band merchandize, no glitter or similar gender framing. Quite a project – as is the story about the “Research Institute” mini-figure set.

42008-121110 Continue reading