Here's what I keep hearing around agile:
- We just automate all testing - there is no testing we would not automate.
- Only non-programmers in or close to the teams are the product owners. Testers must be programmers (because automation is all there is).
- We can just release and monitor production and fix quickly (there's no other information we can recognise testing would give)
- We don't recruit testers anymore at all and no one else should either
But the ratio has a downside: I've never felt as alone.
I'm social, and I hang out with my team. I listen to them getting very excited about technologies (SignalR is so cool, sure...), I participate in discussions about designs and value to deliver. We work great as a team but I'm not satisfied.
I miss colleagues that would be not only listen to me getting very excited about testing and bugs, but would actually share my excitement. I share my excitement with my team, only to see the same sympathetic look in the developers eyes that I have when we talk about cool technologies. So I go look for other testers that want to talk and share as my means of coping. I participate (and organise) peer conferences on testing. I go for drinks and dinners with my testing colleagues from other companies to share stories. I consume (and create) a lot of testing content online and in conferences. And I realise I'm doing this to cope and to be happy with work, not only to share what I learned as I did in the past.
Whenever testers meet, a common topic is tester-developer relations. I don't see anything being particularly wrong with my relation to developers, we are just interested of different things while sympathetic to the other's viewpoint. I again reread James Bach's A Tester's Commitments (to Developers) -blog post, and starter missing a developers guide to testers. As the single test specialist, the only one who is different in interests (and the only one that happens to be a woman in this team), it would be great if all the advice isn't about how I deal with you, the developers, but also the other way around.
Here's my lone tester's guide to my already wonderful developer colleagues, draft 0:
- Recognise we have different, valuable viewpoints into creating our product. You don't want to think like me and I don't want to think like you, but together we're better. Continue to listen sympathetically, just like I do.
- When I tell you about a bug, keep taking it as a positive thing, a puzzle we're solving together. Don't leave all the sugar-coating work to me, assume I mean well when I'm happy that it does not work quite as we wanted it to. As a stretch, try seeing things my way: finding information we did not know of it kind of cool and we could all together celebrate the fact that it was found and can be fixed.
- When the product works in production, I let you get the fame. You get the thanks for delivering a product that works, I don't deliver any metrics that would make us adversaries to emphasise my contribution. It would be nice that in return you actively recognised my contribution, even to a degree that you would talk about it outside our organisation for people who think that my kinds are not needed.
- Actively pair with me. Pair on your code. Pair on my tests. Pair on test automation. Pair on splitting the features. Don't always leave the invitation to pair as something I need to do. While I'm only sympathetic about your excitement towards details of technology, there's a lot of things I'd like to participate on without turning into a programmer.
- Deliver me software you think that might work. If you did not test it yourself, you're not making me feel special by noticing simple things, you're just wasting time for both of us. If you know of problems, tell me and don't keep secrets just to tell me later that you "checked if I would notice".
- Share with the things you have learned and what you considered difficult in creating our product. You know I will always ask for things like that, volunteer that information, help me work less to get inside your heads.
- Go with me to testing conferences and meetups without me forcing you to do so. Be the rare developer who shows interest in understanding testers. Listen sympathetically and seek to understand what makes us tick. When we accidentally talk in words that exclude you, point that out so that we can be better together. Try to see our good intentions even when sometimes the ways we tell our stories offend you. And when someone talks about testing in a developer conference, go listen and tell me what you learned, show you care.
- Dedicate a year of your life to learning to be good at exploratory testing, understanding organisational systems and dwelling into details of how business works. That way, I will have a colleague that would be interested in the same things I'm interested in for that year. The product owners tend to keep more distance to practicalities and believe in us just getting it to work, so they won't help me much as great as they otherwise are. And if you all do it, one after another, I will have true colleagues for years.
As a minority of one, it could be nice that for just a while, the majority would work more on making the minority feel included and appreciated, welcome. My team tends to do that, while my community - agile - tends to have more challenges in that. If I wanted to stay where I am, I wouldn't feel bad about what happens in the world. But there's still many more places for me to contribute at, as I serve 2-3 years per organisation.
This tweet seemed very appropriate addition:
I am reminded of a line from a Katherine Kurtz novel... "Humans kill what they do not understand"Stop trying to make testing go away when it still delivers relevant value. Checking is not testing. We need both, in a skilled manner.
— Pete Walen (@PeteWalen) February 22, 2015