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.

Career paths for testing specialists

I believe it is possible to have challenging opportunities and career advancement within the broad field of testing – for all kinds of people and backgrounds.

I’m probably both spoiled and privileged, so see down below for context of the following model. It is a model for career paths that is in active use as of writing. Some might consider it old fashioned or limited, but I do hope that you can learn a bit from it with regards to defining career paths for testing specialists.

Let’s look at the following titles:

• Tester,
  • prepares test cases in a test case management tool
  • performs the testing activity
• Technical Test Analyst,
  • prepares and initiate engineered tests
• Test Manager,
  • prepares test plans, test strategies
  • lead the testing activity

You might have other titles at your place – the point is to identify the titles and not take the work areas too literally. On smaller delivery teams the testing specialist is both the analyst, test manager and the one performing the tests. On larger projects there may be more testing professionals with more defined roles/titles. On other projects the test managers job is more around leading SMEs in testing (and less the testers).

Notice that the test manager manages the testing, they are not a people/line manager of the testing specialists. All the testing professionals may have the same manager or be distributed into the delivery teams. That usually depends on if the company’s focus is on consultancy/projects or on products/deliveries.

There are strong trends that much test engineering is a developers discipline and that management of testing is more about coaching. Still some development organisations strive with having exploratory testers on all teams, where they dig into the specific domain and application. But the field is not all dead yet, and many organisations will have the above titles represented for years.

Based on the titles above you can identify the work usually being done, but not the skill level or span of control. This is where we usually add (promotion) levels like:

• Junior
• Advanced/Associate
• Senior
• Principal

Do use the promotions that your company uses for developers (and similar titles) and other roles! If you have ninja developers as a formal promotion level over lead developers, the by all means add that to your testing titles as well. Do insist and argue! If you fail, move away and let that company deal with not wanting to improve their people. (having the option to turn away can be a privilege too).

The levels of formal training could follow the levels of promotion. ISTQB training is one approach that is similarly scaled. That can be helpful if your organisation has a quest for certificates (for some business reason). Certificates are though just a race to the bottom.

The advancement from one level to the next could be on the basis of independence of the person. A junior level is an entry level and will usually require that the person tries it out and have a skills mentor. Advance and associate levels apply the know-how consistently on one project/delivery team.

The higher up the level, the more teams the person can apply the knowledge to at the same time (span of control, see also the law of raspberry jam). Alternatively it could also be to be able to generalize practices learned in one project and apply it to a project/delivery team that works in a different way. Senior and principal roles is more into the strategic work or work as a adviser. They could be the advisers on bids & tenders for new projects or be more of an test architect working with implementing principles for the testing activities.

Context: I work in the Danish IT outsourcing sector in a global IT company of 3000+ people. The software testing team working across projects is 30+ people (globally). The title “promotions” are used consistently in the company for various job titles: Developers, project managers etc. I have applied a similar model for 20+ testing people at other outsourcing companies and the job titles are consistent with similar software development companies in Denmark.

Denmark is a country where trust in others is very high, where there is a high wealth equality level (Gini) and where privileges are equal privileges. In the company 30% is female, with many female “middle managers” and also high in the technical hierarchy.

Many Bits under the Bridge

I’ve been in the testing business for 14 years – when I started in late 2002 it was all about using HP Test Director 7.6 – in a browser… There was only one model of testing, v-model, and only one book of testing the ISEB (later ISTQB) vocabulary. And only one expected output of testing: Testers designed test cases, executed and perhaps wrote both a test plan document and test report document. Test process improvement was a thing, but even so testing was often a pointy cog…  

Many Bits under the Bridge Later

It is not about the test cases any more, it’s about being part of a team – that delivers an IT solution to the business. First of all, if it’s just about the test cases then it is a race to the lowest paid off-shore location, a run to the bottom in repetitiveness and mechanic activity. Checking! with more focus on crossing the t’s and dotting the i’s. We have tools for that now – the plates are shifting.

When testing professionals puts “writing test cases” on their LinkedIn description. It seems to me that they are stuck in the testing world of 10 years ago. Standing still and not seeing that Testers are Knowledge Workers – not workers of producing artifacts. It is much more important to see beyond the visible, Uncovering better ways and seeing testing as an activity to provide information to the stakeholders, based on experiments and observations.

Skill up and be smarter! And don’t listen to old tapes – it’s not worth it :).

See also this from QA Symphony & Ministry of Testing:

The Software Tester: Modern vs. Traditional [Infographic]

Read for your kids – special interest edition

If you are a parent to (early) school children you should know that it is important to read  to your kids. Reading the words out trains vocabulary, recognition, imagination, wondering etc etc. So I read subtitles from movies… because

The kids currently have Star Wars as their special interest [1], and wanted to see the “people” movies. The have played the scenes via the LEGO Video Games (GC) and have a range of the LEGO sets – so they had the basic plot already. Feature movies like Star Wars are usually subtitled in Denmark – while animation movies are dubbed [2]. So in order both to keep up with “PG” [3] and helping them read the titles – I get to watch the movies and read the subtitles…

Poor daddy, it’s almost as hard as when they has to finish the ice cream they can’t 😉

In the last months the (soon to be) 9yo have cracked the reading code and have gone from LIX11 books to the shorter subtitles. The 11yo have rest covered, but some of the longer texts are tricky (I’m looking at you – opening Scroll).

I tried reading Harry Potter (in Danish) but even if the story was very elaborate and detailed it didn’t catch their interest. Neither did classics from when I was a kid (Sorry Bjarne Reuter), so I had to rethink the acceptance criteria for “read for your kids“.

See these two kids are not as easily motivated – it has to tie into something they can see a direct interest in. Their autism makes them very picky on the choice of subject. What I try is to meet them where they are, expand their competencies and give them a lot of positive feedback until they master it on their own.

Links: People are people – despite their labels, They are just people, The yardstick of mythical normality, Acceptance is more than what can be measured

1. special interest, as in overly dedicated into the topic and cannot talk about anything else.
2. The Danish “dubbers” are usually world class, luckily.
3. Episode 3 is still to come, though.

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

The yardstick of mythical normality

Those that accepted me, worked with my neurology not against it. Their yardstick was not a mythical normality but the potential that they felt that I could achieve. They recognized that my way of doing and learning certain things was different. Instead of proceeding from the assumption that was somehow wrong, they worked with it and helped me to find the place where my neurology and the world could safely mix. 

[ What Acceptance Means to Me | Published on April 20, 2013 by Lynne Soraya in Asperger’s Diary on http://www.psychologytoday.com ]

TYING IT ALL TOGETHER…

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

What you know and what you do is an important part of being you. Often it is required to rethink: What do I know? What are my skills? How strong are they? It can be about you personally, or it can be about your organisation or testing unit. I have used the below approach in the context of identifying “testing competencies” among 120 testing professionals and in relation to my own skills in times of refocusing.

Acknowledge the level of your skills

First let me tell you about the skill of tying a square lashing to connect two poles of wood. It is a fundamental building block of the scouting activity Scout Pioneering. Tying together poles let you build all kinds of scout camp equipment: tables, benches and other constructions.

To make a square lashing you tie a loop knob around the first pole. The rope is then taken around the two poles, crossing them first one way and then the other – thus making a cross diagonally across the poles. The end of the rope is tied to the other pole using a specific fastening knot.

I have specifically selected this to find something that you have probably never heard of – to illustrate how to approach skill levels. Prior to reading the description and seeing the illustrations you probably never heard of it, you were at level 0. But after reading about it, you have at least heard about the term – or perhaps searched the web for it. From here (Level 1) you need training and mentoring to tie any of the knots. When you can tie a square lashing without help – independently, you can up your rating one more level (2). Later on by writing books about lashings and knots, you can become a mentor, a trainer of others (Level 3). Ultimately you may master the skill at level 4 – you wrote the book, but also studied the craft to know where even the books are insufficient.

This 5 level rating of skills is nothing new, and perhaps you use a rating with more or less steps in your context. Perhaps it’s very detailed, with very discrete steps – or perhaps it’s just a guideline, a floating value between “a little” and “a lot”.

If it squeaks it will hold

Yet even master builders forget to keep the skill alive. For doing the square lashing and riding a bike, it’s usually up and back on track in a few rounds. Some of the tricks come back quickly, others require a hint or a “now – how did we do this” moment in order to recall the theories and practices. There are various means of doing this within the software testing field and elsewhere:

Heuristics: the term heuristic is introduced, as a fail-able method to aid in decision-making. Scout pioneering have a very used one: If it squeaks it will hold. That is applying pressure and weight to the lashing, if the lashing makes small noises it will usually hold.

Backtrack: Another way to get back on track in skills formerly used (at levels 1-4), is to step one level down. If you used to write the book on the topic – practice. If you knew how to do it confidently and individually – ask for help and training. Scout pioneering builds constructions in triangles; they focus on building a solid base first. Returning back to basics, and building a good base in software testing is equally important.

Just Do It: Jump onto the bike and learn. There is a learning curve building back skills again – it might as well be tested, tried and experienced. My experience is that recalling knowledge will come back instinctively and faster than expected. It doesn’t matter so much how long ago it was. As long as the brain is stimulated, it will come back instinctively. If the brain gears start squeaking – it’s usually a good sign.

Recognize and Organize Your Skills

In Scout Pioneering as well as software testing, there are many heuristics – and many areas of detailed knowledge that can be learned: Knots, techniques, theories and applications. These are the competencies and the skills – and we have to name them in order to manage and develop them. It is important to find out what we know – what we know as a company, group and personally. We live in an age of abundance of information – the key driver of introducing knowledge management systems is to find out “what we don’t know we know”.

[WayBackMachine: https://web.archive.org/web/20131109225946/http://www.ministryoftesting.com/2013/06/recognise-and-acknowledge-your-skills/]

Even a self-acclaimed guru breaks the rules

The similarity between a guru and a newbie is that they both break the rules. The difference is that the guru knows he’s breaking the rules.

A Newbie, a Trainee, an Independent, an Expert and a Guru enters a bar….

The LEGO Death Star Canteen #EddieIzzard

• The Newbie doesn’t know what a bar is, orders a cup of coffee  
• The Trainee knows what a bar is, orders a beer
• The Independent repeats a successful experience and orders a beer
• The Expert, having written the drinks list orders a whisky
• The Guru orders a  cup of coffee, because they needs a go***** cup of coffee

In this model the difference between a guru and an expert is – that the expert thinks they knows everything, while the guru knows they know nothing. Even this model falls to the relative rule about X. If the Newbie doesn’t know what a bar is. Then how can they enter it?

Newbee	Never heard of X	No skill – no training or experience
Trainee	Heard of XContext-oblivious	Basic training has been received. The only experience gained has been in a classroom and/or experimental scenarios or as a trainee on-the-job. You would be expected to need some help when performing the skill.
Independent	Can do XContext-specific	Repeated successful experiences have been completed. Help from an expert may be required from time to time, but you can usually perform the skill independently.
Expert	Wrote the X bookContext-imperial	You can perform the actions associated with this skill without assistance. You are certainly recognized within your immediate organization as “the person to ask” when difficult questions arise regarding this skill. You have extensive experience and could teach the subject if you had teaching skills. You are probably also known outside your organization as an expert.
GuruMaster	Know the limits of XContext-driven	You can answer any question about the skill and most any question related to the field where the skill is used. The “expert” would come to you for advice. You have probably published a paper on the subject.

See also: Establish yourself as an expert or thought leader, All oracles are fail-able