1000 ways of testing

A subscriber wrote in with a question:

A surprising thing I found in the company I work for, is that the application code is written in a specific repository, and the testing code is written in another. I have a feeling that this leads us to work in silos, instead of in an agile way. I mean, this way, “developers” are responsible for writing features, for example, while “QAs” or “testers” are responsible for writing tests, while this should be a responsibility of the whole team. Or even better, we should look at ourselves as software engineers, without differentiation of roles, even having our areas of expertise.

I’d like to hear from you, what’s your opinion on this and what would be your approach in a case like this?

As usual, I don’t believe there is One True Way for determining who does testing and how it should be organised alongside development work. Each team I’ve worked with has done this differently.

So, rather than giving a generic opinion, I’ll put forward some questions to ask yourself. Puts on agile coach hat.

Question 1. Is the test code in a different repository because testers and developers are separated from each other, or is test and development work separated because their code is in different repositories?

This is a bit of a rhetorical question, but the idea is to think about how team structure and working practices influence and reinforce code structure and vice versa.

I would normally discourage keeping a test suite separate from the code it is testing for no other reason than versioning challenges.

But co-located test and source code is no guarantee that the work will not be siloed. There are deeper concerns here.

Question 2. Is the siloing of development and testing work causing genuine problems? Has the team discussed them?

The questioner states that writing tests ‘should be a responsibility of the whole team.’ I would usually agree with this statement, but instead of imposing this view on the team, I would suggest raising it as a topic in a retrospective, and gather everybody else’s thoughts on it.

After all, their’s is just one perspective, and it’s important to understand how other people see the situation. They may not see it as a problem, or they may be quietly seething about it.

Retrospectives are there to provide a safe space for discussing challenges like this without blame or enmity. If you’re not doing them regularly as a team, you’re missing the opportunity to make continual improvements in how you go about your work together.

Question 3. What’s the impact of changing roles in the team?

Our questioner also paints a preferred organisation of team roles that’s very different from the current separation of developer and tester.

Here are just a few different approaches to this I’ve seen:

• Developers and testers on completely different teams with different sprint cycles - e.g. where the test team is an outsourced company
• The team is responsible for testing collectively and share testing duties, with a roaming test specialist acting as a consultant when needed
• Dedicated specialist testers working in an agile team, with handover of user stories between developers and testers within the same sprint

Each of these working patterns require a different approach to development and testing. And changing from one to another is a big change that shouldn’t be taken lightly.

And their effectiveness depends on all sorts of other constraints, like the overall size of the organisation, the type of product being developed, the risk profile of that product, the compliance regime, the release process, reporting lines, and so on.

Making a big change like this should be done experimentally - i.e. form hypotheses about what you expect, run an experiment and measure what happens. You’ll want to make sure that you don’t just change things based on a hunch without measuring the impact it has.

Question 4. Are you regularly looking for waste and working together to eliminate it?

One of the most useful things to do together as a team (maybe in a retrospective) is to look for waste in your development cycle and try to reduce it.

That’s a big topic, this email is getting long and so I think I’ll leave it for next week.

Have a great weekend!

– Jim