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.

Getting Testing in Early

Even before there is an “system development life cycle” – testing in the form of thought experiments and  evaluation can take place and add valuable information to the context.

My test management tasks are often about the next thing coming up. Bids for outsourcing agreements and application development often comes with a large document of test activities to be answered and elaborated. In this role I am the the subject matter expert (in test), and while have to write the tender reply for my domain. Sometime down the line the bid materials becomes an actual project, but by then I’m onto the next thing.

Sometimes I draw an analogy to the Secret Service advance team arriving two weeks before the president, setting up protection and identifying gaps – while then moving on to the next location before the president even gets there.

Another example of advance work for test people, is where the organisation uses frequent releases of systems. While the majority of the test effort is put into the release currently being tested, some effort must go into looking into the frame of the coming release. In the coming release the test manager can look for headlines to test, review initial high level design and find flaws and conflicts in the release content.

Sometimes I draw the analogy to the blue and gold teams of US nuclear submarines. While one full crew is out sailing/delivering, the shore team prepares, trains for the next big push.

Testing early can also be in the form of running simulations on various business case scenarios. Business simulations is all about experimenting and evaluating. For novel solutions prototyping, wire-framing and user experience activities helps develop minimum solutions to be tested for viability by the customer.

In the article “Continuous Testing in Dev Ops…” we see testing happening during Plan and Branch. In the article “A Context-Driven Approach to Delivering Business Value” testing can help establish viable market, match to vision and in identifying business risks.

testing related to revenue generation may focus on functionality or regulatory compliance; testing related to revenue protection may focus on maintainability or legal defense; testing related to supporting revenue may focus on business process improvement or cost reduction.

Testing is a lot of things – also outside the SDLC.


Mapping testing Competencies

[ Recognise and Acknowledge Your Skills  | Ministry Of Testing – The Testing Planet | June 2013]

The below model is directly inspired by the Vancouver Agile Quadrant introduced in “Agile Testing: A Practical Guide for Testers and Agile Teams” by Crispin and Gregory 2009 based on the original matrix from Brian Marick in 2003. It consists of four primary branches – as seen on the illustration. It is not a matrix or a table, but four directions with each their cloud of buzzwords. For specific contexts a mind-map will be a better choice of illustration – try drawing your own competencies.

Tester Skills Matrix
Tester Skills Matrix

Come join the Context Banquet

We are setting up Dansk Workshop on Exploratory Testing (again) inviting testing people to join the banquet. We all test the software, the hardware, the context, the project, the environment the performance, – to give the decision makers information. We need testing people to have all kinds of backgrounds

| This is what the C-D-T is about |  Also know as the exploratory testing and the muh muh |  further more know as a jam |

Let me tell out about the invitation to the Context Driven banquet in another way: There once was this man who had a great fortune and many talents – and wanted to celebrate. He walked to his friends to invite them to come for the fiesta. One friend just landed a new job – but she was not yet as equal as the others. Another just had a new minivan, and had to test drive it (pun intended). But there where room for more at the banquet – so the invitation is sent to the insecure, to the un-educated, to the start-ups and the emerging thinkers, to the bloggers and the twitters, the black swans, the unicorns and the dancing monkeys….

Wither the test manager?

[ Paul Gerrard | Will The Test Leaders Stand Up | The Testing Planet issue 10, Page 4, March 2013 , Paywall] paraphrased:

There are five broad choices for you to take if you are a test lead or test manager:

  1. Provide advice to the business leaders, as an independent agent cajole project leadership and review performance
  2. Take control of the knowledge required to define and build systems. Demand clarity and precision in requirements
  3. Help agile projects to recognise and react to risks, coach and mentor and manage testing
  4. Manage the information flow between the key groups and continuous integration system, control change and delivery
  5. Manage outsourced and offshore teams, manage relationships

It’s probably 6) All of the above


In a star team – the team gets the stars

If praise, recognition, promotions always come to a few staff members – the usual suspects – you have a hero culture. You have a hero culture – even though you might think you have a team culture. You can call it a star team all you want, if not the team gets the stars but the heroes, you are not walking the talk. Would you build a software relying on only a few persons? “He got hit by a tram” – is a true story, and it is happening again in software projects.  If you only give credit to those that pull out the big fires, you will nurture big fires. You get what you reward….

I did not open it to build it
Something silly

Sure, recognize the stars – but spread the goodwill. Even heroes needs help. Make every team member feel that they contributed. Try when you lead to reach out to everybody over the course of the project/months days. Recognize them all and say thank you.

Once I was a leader at a children summer camp. Every evening we would make a mentioning of the fun stories of the day. Obviously some of the kids where more “fun” than the others, but we kept a rooster to make sure all were mentioned – perhaps just with a little thing. It meant a lot to be mentioned, even for something silly…

Keith Klain put’s it this way in The Testing Planet 10 – Leadership issue: “Leadership in Testing – What really Matters”:  I want my team to take ALL the credit because they are the ones doing all the work!  I would rephrase this to: I want to praise the teams I help succeed, but I also need to know that I am part of the team that get’s the praise ;-).  

Strip me of all my power, my titles, my roles – and hand them to those that need it to have the courage to stand up, or that needs it to grow. I know I stand on the shoulders of software testing giants (like Keith), I may not reach high compared to them – but I can still lift someone else up, so that we together reach even further. We all have to start somewhere…

more on http://www.lovisastahl.com/eng_con.html

I know it is your job – but thank you anyway

Praise people, recognize people, say thank you. The trick behind it is a simple application of behavioral analysis – you get what you recognize: Speak about the good deeds, ignore the bad – but set the line on the ugly. Simple example: If you give your screaming kids candy in the supermarket, they scream to get it next time. Say “no” if they take candy. But what ever you do – praise them for helping daddy shopping. And that goes for adults too! 🙂

I lead many kinds of people indirectly – I coach, mentor, suggest, encourage, question, challenge – and test:

  • Skilled people from India and Ukraine
  • Skilled people from the business domains
  • Support staff, sales staff, operations and telco technicians
  • Business subject matter experts and user experience specialist
  • Developers, Project managers and bosses
  • The young people helping out in the family household
  • The kids in the scout (FDF) group I’m a volunteer leader in
  • My two boys

The most important leadership tip I have is to say – Well done, thank you!  I know it is your job occasionally to work on weekends and nights and evenings – but thank you, it made a difference to me. I know you will be helping me for a day, and still have to do your “day job”. I recognize you – I see you. I know Suresh said “Jesper encouraged me to go beyond my regular assigned tasks and contribute more to the organization.” Thank you Suresh – I appreciate your effort. Boys – I know you are supposed to learn to do your home work, but good job anyways on completing it today.


4 Reasons Why Culture Is More Important than Strategy | Om at kunne udsætte sine egne behov | Do what you say – say what you do | They are just people |

And thank you for reading 🙂

Establish yourself as an expert or thought leader

Being a thought leader is not about being a “boss” – neither is it about being a “manager”. Leadership is not only at monthly or weekly meetings. It is leadership to talk openly and often to those you lead, and go “visit their desk” – also just for a chat. Good leaders create a room for dialog, trust, mentoring and practice.

Leadership is about behavior – not attributes – nor properties. Management in itself is a structured process – perhaps very complex, but yet structured around planning, measuring and decisions. You can manage by Excel, but you can never lead by Excel.

Come to think of it, management can be somewhat automated, setup as routines, macros that verify and tricked by events. Management by bean-counting spreadsheets can be executed anywhere and can be setup as a commodity. True story – you can buy “Outsourcing management – as a service

Outsourcing management as a service would require strong blend of skills in areas of program management, service management and relationship management. PMOs must own “outsourcing management as a service” and evolve these skills to implement and mature the competencies, and to derive maximum value from outsourcing initiatives

Leadership in comparison is more bespoke, and require a range of tools, tips and tricks – based on context and on the people in the team. Similar to testing and checking, we need to consider both activities – but also learn the difference between them.

So stand up, apply a little courage and be a thought leader in your own right. Stand on my shoulders if you like – it would be my privilege to support you: Establish yourself as an expert or thought leader!

#BigSelfishPun – the title of this blogpost and the below screenshot is from an internal presentation by Henry Singer, http://henrysinger.blogspot.com/ from September 29, 2011 called “Blogging for business“, where my internal blog was used among others and an example of  good use of a global collaboration tool. 

Testing expert

Do what you say – say what you do

You can get as much overboard in metrics and processes for agile – as in metrics and processes for waterfall projects. Business context demands it’s share of the delivery culture, but don’t confuse being agile with being unstructured – or with waterfall being overly structured. If you do what you say – and say what you do, you are more trustworthy both as organization, team and as person. Hot air, slide-ware and good intentions will quickly be seen through (and you might not even notice…).

[ What Metrics Do You Use in Agile? | FEBRUARY 23, 2012 |  ]

First, I only use metrics to get a 50,000 foot view on what’s going on.
Second, I do not use metrics to compare teams or individuals.
Third, I am much more focused on qualitative than quantitative measures.

Babies 0: Bathwater 1 |  December 28, 2011 | Iain McCowatt, Exploring Uncertainty ]

The common denominator is not the label, it is the team dynamics

Process and documentation can at least provide some base level of information sharing. Rip these out without replacing them with people talking to one another and the baby has gone out with the bathwater. Regardless of methodology and other labels: effective sharing of information helps teams to succeed. Whatever your methodological preferences, please look after your babies.

See also Tracking your testing progress and 4 Reasons Why Culture Is More Important than Strategy

The dog ate my homework
Homework Evidence by GlenNZ