T-Shaped Testers and their role in a team

Stick with it….it’s a rambling long essay post.. and I may be way off the mark.

I’ve never been comfortable with the concept of a separate test team and associated “phases” of testing. I spent about 8 years working in these environments and kept struggling to answer questions like:

  • “Why are we involved so late in the project?”
  • “Why are there so many obvious bugs or flaws?”
  • “Why does the product not meet the spec?”
  • “Why do we always follow these scripts and assume the product is good?”
  • “Why don’t we use the questioning skills of tester’s earlier in the process?”
  • “Why are the tester’s skills in design, organisation and critical thinking not valued at the end of the cycle?”
  • “Why do we have some specialist testers, like performance testers, but a load of other testers who just do ‘any old functional script’?”
  • “Why does everyone keep complaining about this way of working, but do nothing about it?”

And a whole load more questions along the same lines.

These questions are common in the industry, check out any forum or conference and you will find many similar questions being asked, and a plethora of tools, services and consultants willing and able to solve these problems.

It’s taken me many years and much analysis to come to an idea about testing that I feel more comfortable with, and in truth, it wasn’t even my idea, but I’ll get to that bit.

The more people I speak to about this, the more I realise that others feel comfortable with it to. Comfortable because they are operating in these contexts, or, more crucially, would love to operate in a context like this. Of course, some don’t agree and many simply don’t care…but that’s another post.

I believe that finding bugs is just one aspect of a testers role.

I don’t think finding bugs is just the responsibility of the tester either.

I also believe that testers should use their skills in other parts of the project cycle, whether that cycle is two weeks or two months or two years.

The idea I am presenting here is the T-Shaped people idea. It’s not mine, I believe Tim Brown (CEO of IDEO) coined it in the 1990s to describe the new breed of worker.

If you imagine the letter T being a representation of a person’s skills (or as a role as I like to use it). The vertical part of the T represents the core skill or expertise. In testing I would naturally suggest this is the core skill of testing (of which there are many variations, and sub-skills). The horizontal part of the T represents the persons ability to work across multiple disciplines and bring in skills and expertise outside of the core skills.

The more I talk to people about T-shaped testers the more I hit a nerve with people. It really does seem to sum up the growing number of testers in the community. Those who are skilled testers, yet are skilled in a number of supporting domains.

Many of my peers in the community are T-shaped testers. They excel at their specific element of testing yet they bring in skills from other areas, or they use their skills to fulfill other roles within the business.

In start-ups or fast moving companies the ability to work across multiple disciplines has some obvious benefits.

One person capable of fulfilling a few roles reasonable well seems like good value and a good asset to delivering value. Even in traditional environments with more structured roles T-shaped people can be found serving multiple roles.

However, a lot of the time people don’t see themselves as contributing to something outside of testing (i.e. fulfilling other roles), or bringing other skills they have to the role. Some simply don’t have the opportunity.

Some great testers in the community fulfill other roles within their business. For example, without naming names:

  • There is a great test manager I know who is also a support manager.
  • There is a great tester I know who is also a product owner.
  • There is a great tester I know who is also a scrum master.
  • There is a great tester I know who is also responsible for market research for the company.
  • There is a great tester I know who also does all of the hiring interviews for **every** role.
  • There is a great tester I know who also runs conferences, sells advertising, builds his own product, markets his own product and consults to big clients. (how many different skills do you need to achieve that?)

These are just some examples. There are countless others.

Then there are those who are testers but have supreme skills out of work that aren’t utilised in their main role. We have musicians, artists, designers, writers, mechanics, engineers, carpenters, social media advocates, printers, net-workers and anything else you can think of that someone might do out of work. Could a company not utilise and encourage the use of these skills to help solve business problems? Of course they could.

Sadly, many people (not just testers) are pigeon holed in to their role, despite having a lot more to offer.

As a short side story I was ready to leave testing a few years back, mainly due to being unable to answer the questions I posed earlier. I was thinking “Is This It?”. What about the skills I had and the passions outside of work? Why can’t I use these? What job could I get that does use them? Would I have to re-train? Why are my other skills ignored in the work place? Then I found blogging, consulting, agile coaching, systems thinking and ultimately people management and it all fell in to place…..Anyway – I digress.

I believe that testers, actually – anyone, can contribute a lot more to the business than their standard role traditionally dictates. The tester’s critical and skeptical thinking can be used earlier in the process. Their other skills can be used to solve other problems within the business. Their role can stretch to include other aspects that intrigue them and keep them interested.

With Acceptance Test Driven Development, Test Driven Development and a whole host of other automation approaches comes the need for testers to be involved earlier but crucially, not so tied down later in the cycle running confirmation checks. Exploration, curiosity and intrigue are what drives testers in these environments. The checks are taken care of, what remains is to understand what the product actually does and provide insights in to risk, uncertainty, user experience and the markets (customer, end user, competition, industry) expectations of the product, plus the stuff we might not have thought about earlier.

They can help to discover what the product is meant to be, not just give judgment on whether it meets the requirements or not.

Finding bugs is what we do, but I don’t believe that this should be an end goal. Bugs are a side effect of discovering more about the product…maybe.

I believe everyone has the capacity to do a lot more towards the goal of shipping great products outside of their stereotype role. It’s something we’ve embraced here at NewVoiceMedia.

We have testers who write product documentation, are scrum masters, are building infrastructure to support rapid release, are taking ownership for security and compliance to standards, are presenting the development process to customers, are visiting customer sites to research how people are using the product, are writing social media content, are devising internal communication strategies, are doing agile coaching, are creating personas and are using their natural skills and abilities where they are best suited to help move the business forward.

We’re still working on the balance between roles and expectations, and the balance shifts, typically in response to the market.

Don’t get me wrong. Many people don’t have this opportunity but if you’re in a position to make changes then utilising your wider skills and the skills of those in your team could be a great approach to solving problems.

This is clearly not restricted to testers either. Programmers, product owners, support, sales, accounts etc etc – everyone is a T-Shaped person, or at least has the potential to be T-Shaped.

I think the future of testing is going to be a future of both specialists and generalists. There is always a need to have specialists in security, performance, accessibility etc, but there is also a need to have generalists; testers who can fulfil a number of different roles across the organisation whilst still maintaining a core skill of testing.

Being a T-Shaped person means having skills that can be useful across other domains. Having T-Shaped tester roles means encouraging testers to fulfil a number of roles. Learning the skills needed, or already having the skills in place (i.e. already being a T-Shaped person) means people can either slip straight in to the role, or they may have to seek out learnings, coaching and mentoring. And that’s where good management, teams and community engagement can come in.

I’m exploring around this idea right now, but I know already that T-Shaped people gives me a really good model to describe the testing and testers I feel comfortable with. The testing that I feel suits me, the companies I seek out and the markets I work in.

I believe testing is more than finding bugs; it’s about exploring the product, discovering what the product needs to be, discovering the market needs (i.e. A/B Testing), discovering what the product actually does, working out whether the product is suitable for the context of use, questioning the process, improving the process, helping to design the product, improving the product, helping to support it, helping to promote it and ultimately working with the team to deliver value.

And all of the above might explain why myself (and those peers who appreciate or demonstrate the T-Shaped model) find it so hard to recruit great testers (for our contexts), yet other managers I speak to can find “good” candidates at every street corner.

We demand more than just testing skills. We demand many other skills that complement a testing mindset. Skills that help us deliver value.

Of course, these are just my thoughts based on testing in my context. You’ll work in another context and appreciate other skills. At the moment this is just an idea, and like all ideas, it might be wrong. But I thought I would share it anyway.


Image courtesy of : http://www.flickr.com/photos/chrisinplymouth

Mixing it up with Personas

We had our team wide sprint demo yesterday where each team presented what they have been working on in the sprint.

These meetings are a great opportunity to share and learn about the world outside our immediate teams.

In this meeting one team decided to use personas to present their work.

It is not the first time they’ve used visuals and role play to demonstrate the work, but it’s the first time they’d used print-outs of people and given them names and background details.

Each team has settled in to their own way of presenting. Some are able to use a demo and talk through the stories they have finished whilst others talk through what they have done as their work often has no visuals to show (our test infrastructure team). No way is better than any other as each is characteristic of the work and the teams.

From these meetings, we all learn a lot about the product, the work each team does and to some extent, ourselves, as we share with the wider team what we are doing.

Our product is Contact Centre (Call Centre) software and as such we can use personas to visualise the flow of calls, the states and the interactions. Assigning roles, personalities and context to each person in the scenario allows us to really understand the motives, user story and operational context clearly.

Applying personas in this way allows us to seek empathy with each user in the system and to understand a little more about why the product is working the way it is. After all I’m sure most of us have interacted with a call centre at some point in our lives; some experiences good, some bad and some very much dependent on our own contexts (in a rush, bad mood, upset, angry, anxious)



The demo that the team did (presented by scrum master Dan and tester Andy)  involved the wider team in the demo also.

  • One product owner played the role of Mary (a tech savvy stay at home mum awaiting a call back about an issue)
  • Andy played the role of Claire (a call centre agent who was new to the role and was making the return call to Mary)
  • Another teams scrum master/dev was Clive (a senior call centre agent who was to be transferred to in order to solve the problem)

Getting people playing roles in the demo proved to be a good way of articulating interactions and stories too.  This approach might not be suitable for all, but it went down well with the team yesterday.

Can personas be helpful for testing?


We’ve started to dabble with personas for testing also.

By having a core set of user interactions/capabilities we can start to apply different personas to each interaction shedding a different light on it.

For example, one of the most fundamental aspects of our product is the ability to connect callers to agents.

We could break this capability out in to many different scenarios for testing, for example:

  • There is no agent available immediately, the call is queued, then an agent becomes available and takes the call. (testing – queuing, dequeuing and call allocation, stats, call recording, etc)
  • The agent can deal with the call immediately. (testing – straight forward two party call, stats, call recording, etc)
  • The agent cannot deal with the call immediately and needs to consult a colleague (testing – hold, consult, retrieve, 3-party call, call recording, stats etc)
  • The agent cannot deal with the call at all and has to transfer to a colleague (testing – hold, transfer, retrieve (by second agent), call recording, stats etc)

I could go on with many different scenarios….

Now let’s apply personas.

For each scenario we could approach the interactions with different personas.

  • We could have agents who are experienced, stressed, new to the job, coming to the end of a shift, working under strict call handling times, etc.
  • We could have callers who are relaxed, angry, frustrated, fed up of being transferred, knowledgeable in the subject of the call, not knowledgeable in the subject of a call.
  • We could be in a large consumer driven call centre, or a small inbound support desk.

I could go on.

What do personas bring to the testing?

Well personas allow us to understand how and why someone is using the system.

They allow us to seek empathy with the agent, caller, supervisor and any other persona in the mix. It allows us to think clearly about waiting times, queues, effective use of routing, call quality, expectations, sub systems that support the interaction (stats, call recordings, audit) and it allows us to fine tune our own exploration to look for aspects of the interaction we might not have considered previously.

There are some fundamental expectations that the system must meet.

The expectations though will vary in their scope depending a lot on the context. Personas allow us to look at the product differently and see if it’s still meeting expectations from that view.

Elisabeth Hendrickson, in her excellent book Explore IT! (What? You’ve not read it yet?), refers to personas as a great tool for exploring the product and gives a really neat insight:

Just as personas are useful for designing systems, they’re also useful for exploring systems. Adopting the mantle of a persona prompts you to interact with the software with a self-consistent set of assumptions, expectations, desires, and quirks.

We’re finding Personas useful for design, testing and now presenting work back to the team.

As with anything though, there is no silver bullet solution; personas are another tool and technique we can use to achieve our goals, not the only one.

Some things are best presented and tested in other ways, but sometimes personas can be quite helpful.


Further Links http://www.cooper.com/journal/2008/05/the_origin_of_personas.html

http://pragprog.com/book/ehxta/explore-it http://janetgregory.blogspot.co.uk/2011/05/power-of-personas-in-exploratory.html http://www.uxbooth.com/articles/personas-putting-the-focus-back-on-the-user/

Tester’s need to learn to code

Tester’s need to learn to code…. and any number of other way of paraphrasing Simon Stewarts comments in his Keynote at EuroSTAR 2012.

I’m not entirely sure on the exact phrase he used but I heard a number of renditions after.

They all alluded to the same outcome:

“Testers need to code or they will have no job”

Speaking with Simon briefly after the event it’s clear his message was somewhat taken out of context.

I get the impression he was talking about those testers who simply sit and tick boxes. Checkers, as I think they are becoming known.

Simon suggested that these people should learn to code otherwise they will be replaced by a machine, or someone who can code. There were some who took great distaste to the general sentiment, and those who are in total agreement, and of course probably some in between and some who don’t care.

Simon himself was greatly pragmatic about it and suggested that learning to code will free people up to do good testing, a sentiment I can’t imagine many arguing with.

Those who know me have often commented that I often sit on the fence and try to see the positive in each side of an argument. It will therefore come as no surprise that I agree, and disagree about the message Simon was communicating.

I agree that Testers who do purely checking will (and should) be replaced by machines to perform the same action. Some of these people, (with the right peers and support, the right company and willing market conditions) could become great “Testers” whilst the machines automate the tedium. Some won’t and may find themselves out-skilled in the market.

But I don’t believe that all Testers have to learn to code. I know of a great many who don’t but are doing exceptional testing. Saying that, I think each team needs to have the ability to code. This could be a programmer who helps out, or a dedicated “technical tester” who can help to automate, dig deep and understand the underlying product.

I’m an advocate of encouraging Testers to learn to code, especially those new to the industry who are looking for early encouragement to tread down certain career paths. I’m also an advocate of using the wider team to solve team wide problems (and automating tests, reducing pointless activities and having technical assistance to testing are team wide problems).

When you hear a statement like “Testers need to learn to code” don’t always assume it tells the whole story. Don’t always assume it means learning enough code to build a product from scratch. Don’t always take these statements at face value. Sometimes the true message can become lost in the outrage in yours (or someone else’s) head, sometimes it might not have been communicated clearly in the first place and sometimes it might just be true; but too hard for people to accept.

  • Learn to understand code and your job as a Tester may become easier.
  • Learn to understand how the world around us works and your job as a Tester may become easier.
  • Learn to understand how you, your team and your company works and your job as a Tester may become easier.
  • Learn how to sell, convince, persuade and articulate problems to others and your job as a Tester may become easier.

There are many things which could help you become a good, reliable, future proof(ish) tester. You can’t learn all of them. You can’t do everything. Coding is just one of these elements just like understanding social sciences, usability, performance or critical thinking are some others.

Learning to code can be valuable, but you can also be a good tester and not code. It’s not as black and white as that.