I want to work in a properly cross-functional team. I’ve heard they exist. I’ve never seen one, but I’ve heard that they exist.
In my understanding, this cross-functional unicorn would see all members contributing to all aspects of the delivery, regardless of “speciality” or “discipline” .
But that comes with some prerequisites. Before we all fall under the “developer” title, what must we be able to do?
Developers must understand how to test software, beyond unit testing. Testers must be able to contribute more than just testing. And testing, I realize encapsulates a huge amount of activities.
But consider this; in Agile, we don’t usually consider something done until it’s coded, tested, integrated and deployed to a production-like, if not production environment (or a subset of those).
So does it matter who does the work?
What’s the point in segregating responsibility through explicitly defined roles?
To be blunt, I don’t think it’s possible to contribute to delivery without contributing production code.
Putting a plaster on the developer’s knee when they fall of their skateboard because no one taught them how to skate in the first place is reactive, rather pro-active.
I’m not one of those “do, do, do” guys. But testing is a negative activity. It doesn’t add tangible business value. And by that, I mean that the testing is what most businesses attempt to negotiate on when they want something done quickly. I accept that it’s possible to make testing more visible and valuable to a business owner. I don’t get the feeling that this is a practice in general use. I understand the value that good testing contributes to a project. I also understand the lack of value that bad testing contributes to a project.
If we merged the roles, values, experiences, and mindsets of developer and tester, what would happen?
Well, as I mentioned at the start, I haven’t worked with a team like this before, so I’m just kinda throwing some thoughts out there. It feels like we would catch more problems at the point of writing the code. It feels like when we forecast, we would be more inclined to build testing into our estimates. It feels like we would find better ways to test stuff. It seems like we would implement things with testing in mind, rather than an external “conscience” that testers often become for developers. It feels like testing would merge into development, rather than it being a separate practice.
Does testing add value to a delivery cycle? Yes. Absolutely. At the very least it gives a safety net that allows me to confidently add or amend features if of course it’s done “right”. At most, it “proves” that my application works.
Does a tester add value to a delivery cycle? It depends.
It depends on two things.
Firstly the developers that are involved in delivery.
Secondly, the testers involved in delivery.
Do the developers understand what it is to test something? If they do, what does the tester add? I’d argue not much if they can’t cut some production quality code. But then again I only know a handful of developers I’d trust with testing. Most just don’t think about testing beyond unit tests, because there’s a tester in the team doing the thinking for them.
Do the testers contribute some production quality code, as well as testing? If they do, why aren’t they just a developer? If they don’t what do they add?
The biggest two barriers I see to this happening, at least in the UK, is the general quality of testing done, and the lack of developers who get how and what to test outside of unit tests.
My challenge is to developers; start understanding what the testers in your team do. What do they do that you don’t? Probably the big thing is the amount of context-specific analytical questioning they ask of requirements. They probably rarely accept that what was written is what was meant. They probably think of more than just the “happy path” through an application. They probably think of the “customers” that hold a stake in the User Story you’re building other than the one written on the front of the record card (the guys managing it in production, the training team, the help desk guys etc). What more could you do to get into a mindset of making testing part of development rather than a person in your team?
Testers. A weird challenge. Coach yourselves out of a job? I don’t know. I’m still thinking about it.
Pass on an approach, a mindset, not a role?
Quality is everyone’s responsibility, will we really be in a position to build consistently high-quality software when we segregate responsibility for testing to a single specialist role, instead of a mindset adopted by all?
Is having testing as a mindset rather than a person not quite enough? Are we only really successful in blending developer and tester roles when testing slips into the consciousness of the developer and it becomes a muscle memory of sorts?
Article originally published by Steve Walton