
Remind Me Again…

I love a timely reminder. I was at an WRK Digital event on Thursday in Leeds where Katja Obring talked about shifting testing left. She was excellent by the way, great delivery, knowledgeable about quality and the limits of how testing alone can contribute to better quality. The interesting thing about this event is that it wasn’t an audience entirely made up of testers. It wasn’t even a majority of testers in the room. Like many organisations, the testers were in the minority. It was quite spicy, I liked it. I was reminded that those who don’t identify as testers see testing (and testers) differently to our own testers self image.
A few things on the evening brought this reminder home:
Whether or not testers should be on development teams
The question was asked. Should testers be on development teams? Many said yes, some were on the fence, yet others said no. As usual the answer is it depends. Although many places have benefitted from having at least one tester on a development team, although not every tester has benefitted from being alone on a development team. Still other development teams have not benefitted from having a tester on their team, as it skews the view of testing as an activity. Trust me, I have often resembled this remark, painting myself into a bottleneck shaped corner as developers await my testing feedback.
One person said they got rid of their testers (not sparing anyones feelings/careers there) and they have fewer customer issues than ever. Everyone jumped in here, including me, about known vs unknown issues and whether or not customer contact has increased or decreased. All this betrayed my measured it depends
cool as a cucumber attitude about it all. This made me wonder what I really believe on this question. We got into the Quality Coach role as well, which to me has the same abandonment without the skills issues as plopping a lone tester into development team all those winters ago. The skills I speak of are an appreciation of what quality is beyond testing and the ability to coach if you are interested.
As a slight aside, the phrase ’embedded’ when referring to testers being part of a development team always makes me squirm a bit. Testers are part of the team, not an embedded alien entity. If testers don’t know how to be a good team members, thats a different thing.
Another aside, a wonderful paper by Elisabeth Hendrickson, Jennifer Smith-Brock and Cem Kaner (from 2001) exploring developer to tester ratios. Spoilers, it really does depend on things, but emotions run high when the question is asked. Personally, my favourite testing gigs have been those with low ratios (1 or 2 developers to 1 tester), you can get very deep into the product then and context switch less often and deliver better known quality faster.
The wider question is still a work in progress, not too much genuine consensus to be found here yet, in the room I was in at least.
The value of end to end tests
Lots of early questions about how to improve their raft of flakey end to end tests that fail every night. Or how they take 10 hours to run. Also about the top 3 test automation tools. The testers in the room generally said get rid of (most of) them, key journeys only, they will not give you what you seek, move tests down to unit and integration layers. You know, the good stuff. Then when there were more questions at the end, we returned to end to end test automation problems.
It seems the case for being selective on end to end test automation that the testing community makes might not have the traction the automate everything message of many tool vendors has. Or perhaps, we haven’t listened all that well to others about what makes people feel warm and fuzzy about their products. Or testers just aren’t listened to all that often on such topics still.
Return on investment of testing (although I reckon they meant testers really)
I thought everyone was being ironic here, until someone said they had a formula to calculate this. A FORMULA. This someone was a tester as well, some self sabotage there I think. You can ROI yourself out of a job. I felt compelled to say that the TEAM is the unit where we should measure value and return on investment, where the activity of testing is undertaken by said team. I remember having a similar conversation in 2009 when I got started in testing. Here I was 15 years later, having the same conversation with a lot of nice, earnest looking people nodding along like its a good idea to measure an individuals ROI.
Some distance to go still here as well.
End
As usual, it was hard to extricate what testers do, versus what the team does with testing as an activity. The one thing that most in the room agreed on is that adding testers into a team changes the testing dynamic and not always for the better. On the things I explored above, there is still some distance between testers and many others in software development. Perhaps, I’ll ask again in another 15 years.