I write this post out of slight frustration, to clear out stuff in my head. The frustration is related to discussions that keep coming up in my tweet stream. There's a few themes there:
- Are we or are we not preventing bugs? (I don't care, except for the part about early and continuous involvement of perspectives for full picture)
- Are we or are we not making decisions on releasing as testers? (I am, and it seems to be working well for me. I have friends in testing who are not because they feel risk-averse. It's not a role thing)
- Are we called quality assurance since we don't assure anything? (I don't care, I prefer being a tester but would hardly want to focus my energy on just a term without relevant practical implications)
I love the products and making them great and valuable. Testing is a means to that end. Testing for me is something I'm really good at (and not so humble about), and I love working with people who are good on the programming bit because together, we're magical for the products. The longer I am in this industry, the more I break out of the boxes of the "tester role". I code. Not test automation, but just regular production code. I work on technical designs and architectures. I make decisions on those, just as much as people in my team.
Today was a great example of me driving through a collaborative decision-making process where we'd hear from every team member before I eventually summed up what we decided. Consensus is something the Swedes do well, and Finns struggle with, but we seem to be a lot better at that culturally than e.g. Americans who seem to assume hierarchy to extents I never experience. (Sorry for the boxes, I realize they are incorrect and stereotyping but I can't resist using them anyway) Most decisions work well with consensus decision making, except for e.g. firing. Release decisions are typical consensus decisions for my agile team. We've been delegated the full decision power.
So, I'm all around the roles. I identify as tester. Sometimes I identify as a programmer. Sometimes I'm a UX person or a product owner. Sometimes I'm a manager talking to managers outside my team's scope. Sometimes I'm a facilitator and a catalyst for improvement.
I used to care a lot about the identity of a tester, I wanted to be called a tester. The more of the "defining tester" arguments I see, the less I care to identify with that straightjacket. But I wanted to talk about why I think the boxing is useful.
The software industry doubles every five years. This means that half of us have less than five years of experience. I think this idea comes from Uncle Bob, even if it reached me through other people in the programming community. When we have less experience, we need a clearer box to learn to cover first, before breaking through the box and finding a bigger habitat.
I've worked with newbie testers, who were made developers just as any others, and as newbies, they would seek their colleagues for models of what to do. They did not have senior tester colleagues, and within a year, they became programmers who don't question the customer requirements and who can't identify that the software isn't working or delivering as much value as it could. When they sought training, they took same kinds of training as the rest of the team. When they looked for idols, they never found the testing idols. They never became testers.
I started off with a strong tester identity. I learned from Cem Kaner, James Lyndsay, Elisabeth Hendrickson, James Bach, Michael Bolton - people my programmer colleagues have never heard of. It became important to be a tester, because with that label I found hundreds of people to learn from. The tester communities are powerful. The oppressed are coming together and helping each other. Together we're strong. My programmer colleagues have never experienced the level of community I've lived through in the last 10 years.
The community has negative aspects. I don't like the fact that we bash programmers, but the communities are often places where we let out steam to find constructive solutions to hard problems we're facing at work. That don't always feel safe for programmers to join and I'd love that to change. I'm all for diversity, testing over testers. I don't like that we're so strong in defining the right words and thoughts, but I try to dismiss that to work on something more productive - failing regularly. And some general behaviors leave people feeling unsafe, even with the tester role.
I believe the labels are important when we start. The labels help us find our peers and communities to learn from. They bring us together. But as we grow, we need to actively break out of our boxes.
But you do realize there is, easily, a full 20 years (and more) of intensive study on just to do great testing? It's not a thing you get in a few years. If you are everywhere with your skills, you are nowhere yet. Less than 5 years of experience for half of us - we should start from different corners, and just work together to bring the knowledge to paint a fuller picture as a group than any of us have individually.
