Ben has superpowers. He’s no different to any of us in that way.
I consider my superpowers to be in the area of agile team development. Other engineers on my team have superpowers in mobile web. Another lists javascript whilst someone else counts algorithms and data structures as theirs.
Ben’s superpowers are a little different. They’re something which sets him apart from the rest of us. You see, Ben lists his powers as “software testing and finding fault with stuff”. Ben comes from a group of people sometimes known as testers.
There’s something which I think we all know about having a superpower.
WITH GREAT POWER THERE MUST ALSO COME GREAT RESPONSIBILITY!
The interesting thing about Ben’s superpower is the responsibility he has in our team.
He doesn’t have the responsibility for testing everything the development engineers produce. Nor does he have the responsibility of sign-off for features or releases.
What Ben does have the responsibility for is for ensuring that the rest of the team is paying enough respect to quality.
Getting developers to pay enough respect to testing can be challenging at times. In my team, we’re in a fortunate position to have been able to hire some great engineers. One of the things we look for in the people we hire is their attitude to quality. Because we’ve paid attention to this when hiring talent, there’s less friction and I think it makes Ben’s job easier.
Most engineers understand the concept of code supporting tests. Every (good) developer should be writing unit tests. But when it comes to the product supporting tests, it’s sometimes an area where developers let themselves down. What happens when things go wrong? Are we even building the right thing? Sometimes it’s too easy to get buried in the details. Ben has helped the team to look at the products we build more as a whole.
It’s refreshing to work with somebody who values quality without the feeling that they are trying to catch you out. We all want to build great products, so why have an internal war between testers and developers?
It’s also great that the engineers are responding to this. The attention that testing gets in our planning sessions is testament to the seriousness the team place on this stuff. When we talk about quality, we rarely mention unit tests. They’re a given and we work out the details in pairing. What we do talking about is the users reaction to the product and interesting ways which things can go wrong. Then we figure out how we’re going to address this with testing as a team.
Testing is a continual, combined effort. No one person is accountable for the quality of the products we build. It’s the responsibility of the team as a whole. Because of this, we don’t have the theatre of release testing, and so we don’t have this overhead.
Throwing stuff over the fence for someone else to test just isn’t an option.
We’re not trying to turn our engineers into industry leading testers as I think it requires a special kind of mindset. Unless of course they catch the bug and want to.
What we are trying to do is to make sure that everyone is able to develop as a well rounded engineer. Ben will improve his development skills through pairing and the rest of us will improve in the activity of testing.
Recently Ben published a blog post about what it was like to work in a development team. Unsurprisingly for us, he gave it a big thumbs up. I’d echo this sentiment - especially when you have people like Ben who are willing to put their superpowers to good use in the right way.
