The ratio myth

Recently I've been hearing a lot about the developer to tester ratio for agile teams. This is usually evangelised as an ideal of 4:1; four developers to one tester.

Having worked in many different agile teams, this ratio doesn't align with my experience. Here are a few examples of successful teams I have worked in with structures outside the norm.

More Developers [6:1]

In one of my earliest roles within agile development, I worked as the sole tester in a team with six developers. We were tasked with developing a system from scratch that would replace a legacy application.

The business had a clear vision, were engaged in what the team were doing, and sought to provide timely feedback on early versions of new features. Their involvement bought the users' expectations to any new features as soon as practical.

The developers had a lot of infrastructure oriented work to do, as they were setting up an entirely new application stack. In addition to technical stories, the team always carried at least one with a customer focus, to provide continuous delivery of business value. Features were small and well-defined from a business perspective, but usually involved the interaction of multiple systems behind-the-scenes, which meant they took time to develop.

As a tester, my primary focus was developing and maintaining a tidy suite of automated regression checks. The testing I did was either quick and sympathetic, so that simple issues were discovered and resolved before early engagement of the business, or aggressively sought out interesting problems.

In this team I often felt bored. Though I had six developers, it took a lot of programming to produce small pieces of front-end function. Fast feedback from the business reduced the amount of testing I had to do. I didn't feel challenged.

Less Developers [2:1]

In a different organisation, I worked in a team tasked with re-designing an existing purchasing workflow in an online marketplace. The team included two designers, two developers and myself as the sole tester.

In this team, the pace of development was determined by the rate at which the designers could agree on the updated user interface and workflow. Programming changes were to reflect paper prototypes; updating stylesheets, JavaScript and links between pages.

Though development was relatively simplistic, the testing required was significant. The existing workflow included a number of different business rules, which were recorded in varying detail across multiple documents. There were a vast number of variables to consider in purchasing an item, both obvious variables and those that were indirectly accessible. There was no automated checking available in this domain.

In this team I was busy. Due to the financial impact of failure in this workflow, testing had to be comprehensive and meticulous. Proportionally, much more time was spent in testing, so the output of two developers was enough to keep me occupied.

More Testers [4:2]

Finally, in a third organisation, I worked in a team asked to fix a production issue in a complex shared web service. This team included four developers from four specialist areas; mainframe, database, integration and front-end. I was one of two testers.

In this environment, the complexity of development varied dependent on the system. Most changes were isolated to a specific aspect of functionality, which could only be observed when users followed a specific workflow.

From a test perspective there was a lot of work to do. As in the previous team, the code change was in an important area of the application with complex business rules. Unlike the previous team, there were automated regression checks available at multiple layers of the architecture.

In this team I was challenged. Testing had to occur on each piece of development in isolation, then via multiple front-end consumers of the web service. In addition, due to their specialist focus, a large component of testing in this team was to facilitate communication among developers. With a tight deadline, and proportionally more testing than development, we needed two testers to get through everything.

*****

There are a lot of variables in determining the best ratio of developers to testers in an agile team. A ratio of 4:1 may be a good place to start, but inflexibility in resourcing is folly. There is no hard and fast rule.

If you encounter a scrum master that attempts to enforce a ratio at the expense of common sense, perhaps you can remind them of the first principle of the agile manifesto. Individuals and interactions over processes and tools. A ratio is just a tool, so be sure to listen to your people if they tell you it's not working.

Personal Brand

Recently a colleague in Marketing referred to my "strong personal brand". I found it quite a confrontational statement as it was something I hadn't consciously considered before.

That same week, I had someone approach me to speak at a public event. Usually if I want to speak in a public forum I have to slave over a proposal, then wait to find out if it has been accepted. To receive an invitation was an unexpected honour.

These two experiences prompted me to consider my profile, both in my local community and internationally. Upon reflection I realised how far I have come. I thought I would share some key points in my journey, in the hope that it offers ideas or inspiration to others.

Join your community

The first role I had with testing in my job title was not my first role doing testing as an activity, which is a fairly common path into the profession. My journey starts here because it was in this role that I was lucky enough to have Aaron Hodder as a colleague.

It was Aaron who, fairly relentlessly, pestered me to join the Software Testers New Zealand mailing list on Google, and to start asking questions in that forum. It was Aaron who told me I had to go to the Rapid Software Testing course that James Bach was delivering in Wellington. It was Aaron who wrangled my invite to the second Kiwi Workshop on Software Testing (KWST). As a result of Aaron's interfering, I found myself part of a small community of testers spread across New Zealand.

Speak up

Being a passive community member is a good, but being vocal is better. I entered these forums with reluctance and a selfish agenda. I wanted to use these people for help in solving my own problems. However, once I was engaged, I was surprised to realise that I had ideas and opinions to share too.

Participating in a mailing list is one thing, participating face-to-face is an entirely different proposition. Though I didn't plan on saying much at my first KWST peer conference, I found myself in a situation where I was unable to stay silent for fear it would be construed as complicit agreement. I spoke up.

It is only by speaking up that people can gain a sense of who you are, what you believe, and how you behave as a professional. Starting to contribute, even in a small way, is the first step in making yourself known.

@katrina_tester @kengel100 That's when I knew Katrina was a heavyweight.
— James Marcus Bach (@jamesmarcusbach) June 15, 2014

See how far you've come

Around this point, Brian Osman invited me to do a brown bag lunch talk at his workplace. I remember his pitch for this being very understated. "It will be relaxed, a few people, eating food, talking testing". I agreed, then panicked when Brian asked for a copy of my slides in advance!

I think I spoke about test planning; nothing that seemed exciting to me. Yet the small audience viewed my ideas as a radical new way of doing things. I realised that in challenging and being challenged within the community I had joined, my ideas had developed beyond those who were yet to question their work. I realised that I had grown into a position to give knowledge back.

Invite others
I was lucky to have Aaron pester me to take the first step on my journey. When I realised how the community had helped me grow, I wanted others to experience the same.

Though I saw a national testing community in New Zealand, I didn't see a local community in Wellington. I wanted to invite people to something that was ours, so Aaron and I decided to create regular peer workshops in our city. WeTest Workshops was born.

It took weeks for our first event to fill. We asked everyone we knew. Then we asked them to ask people. Then we asked on mailing lists and twitter. I remember how excited we were to finally find 20 people who wanted to talk about testing. [Community Question]

It was, and still is, such a buzz to see other testers discover a community of their peers, find a friendly forum for their problems, and challenge their thinking.

Look further afield

At the third KWST, Erin Donnell inspired me to join Twitter and start a blog. These were two steps that I was incredibly reluctant to take.

In retrospect, I can identify that the primary reason I didn't want to do this was fear. I was comfortable in my own community. I didn't trust who or what was out there in the wider world. People kept talking about "the international testing community". I thought it sounded ominous.

One of my first Twitter followers was James Bach. Though I felt this was a huge honour, I also felt a crushing responsibility to only tweet things that were interesting, unique, and insightful. Many of my first tweets were typed, edited multiple times, then abandoned.

Similarly on seeing people read my blog, I felt paralysed when considering a new post. What could I say that hadn't been said by others before me? How could I show my own thoughts and skills?

Someone told me that the first step was to start writing, the second step was to make it good. So the way that I got past these fears was via self imposed measurements.

On my blog, I decided that I wanted to write at least three blogs per month. I embraced a quantity over quality mentality to grow my confidence and find my writing voice.

On Twitter, I decided that I should write a tweet per follower; for over six months I kept this ratio at 1:1. This allowed me to be measured in what I contributed, but stopped me from adopting an entirely silent presence.

Present a consistent image
I like things to look consistent. When I started to create a professional presence online, I chose to present myself the same way in every platform. Same photo. Same colour schemes. Same choice of background images.

Though these choices were driven by my peculiar personality, they had the unintended consequence of giving me a very clear "personal brand" (to retrofit the phrase from my marketing colleague). It's something I would recommend to others who want to develop a recognisable identity in the community.

Take opportunities to participate
Having found my feet on Twitter, I discovered a world of opportunities for contributing. The lessons I had learned in my local community applied to an international context; to be known you must speak up.

I wrote for Testing Circus [Is That Testing?] and Testing Planet [Popping the Bubble]. I realised that there was an opportunity for the New Zealand and Australian test community to have a collective voice on the international stage and launched Testing Trapeze, a new software testing magazine, with help from a lot of awesome folk.

I started to advertise my writing. I listed my blog on Ministry of Testing. I asked people I knew to link back to my blog from their own. Over time, people I didn't know started to link back to my blog too.

I wrote conference proposals for EuroSTAR, Let's Test, CAST2014, Agile 2014, and Let's Test Oz. I found writing a proposal a great experience for clarifying my ideas, even when I was ultimately rejected. Of the five proposals I've written, I'm excited to be heading to New York and Sydney this year.

There are a lot of people out there who want to hear what you have to say; start taking these opportunities.

Read widely and share selectively
The people that I see as leaders in the international community have a particular approach. They create good content themselves, and they share the best content of others. This is something that I try to emulate.

Twitter can be a noisy platform, so being known as a reliable filter of information is another way to grow your following. Where a retweet is sparingly given, I believe it holds greater credibility. Complement your voice with others of value; have people trust you as a gateway.

Additionally there's an individual benefit in being widely read. You see themes in the types of problems that testers are facing. You see communities of thinking appear within the whole. You see a variety of opinions and thoughts that help to shape your own.

Be generous
Community is reciprocal. Be generous in promoting the achievements and events of your local and international peers. Demonstrate your pride. Show you care about the problems that people have overcome. If you're generous to others, then your work will be shared with the same enthusiasm.

The occupation question

I have been away on holiday. As I left New Zealand I had to complete immigration paperwork. One of the prompts on immigration forms is for occupation. Before you can enter or leave a country, their government would like to know what you do.

I have done a fair bit of international travel and used to diligently write 'software tester' in this space. I would hand my paperwork to a bored official for them to scan their eyes across, only to have them pause in their process and look at me through narrowed eyes. "Software tester" they would question, "What is that?".

Without fail, I would end up in a long conversation about what my occupation actually was. A conversation that usually concluded with the official saying dismissively "Oh, you work in IT", stamping my passport, and sending me on my way.

Because of this, I've changed my strategy. Now when I fill in the form, I just write 'IT'. This annoys me as it seems so general and sweeping. But the officials are satisfied and there are no questions asked.

Why doesn't everyone know about software testing?

A job exists to fulfill a need. In most cases, the need is obvious when you think of the alternative. For example, a bus driver is employed to drive a bus. Without the driver, the bus would not go. The need for a person to fill this role is very clear.

Without doctors we would stay sick or injured. Without plumbers our toilets would not work. Without electricians we couldn't use our lights. Without dairy farmers we wouldn't have milk, cheese or butter.

Without software testers, then what? My first instinct is to claim that software quality would degrade. To people outside of the software industry that means very little. Computer users are conditioned to expect their software to be imperfect. Though the degree of imperfection would change in the absence of testing, without seeing the better solution many would just assume that what they were given was how it had to be.

How do others within software development avoid this problem? Programmers write code, so it's easy to understand that without them the software would not exist at all. Architects and Project Managers have strong parallels to similar roles outside of our industry, which makes them easier to grasp.

Those with an understanding of software development will, generally, see the need for and value of testing. They have expectations of software and can identify when these expectations are not met. I think it would be nice to see this knowledge spread to a wider audience.

I'd like to be specific about my occupation without having to explain what it is. Wouldn't you?