The story of women in Tech is a big one at the moment. We’re told that the number of women in technical jobs is actually dropping and there’s a lot of concern. I’ve worked in Tech since I graduated, in a variety of roles. I’ve been a developer, a BA, a tester and am currently working as a test manager. I wouldn’t say that I’ve met a lot of blatant sexism, but I’ve definitely felt its subtle effects. One of the things that I’ve been thinking about lately is how my experience as a woman in tech can feed in to my experience of being a tester out-numbered by developers.
The article about the role of women in technology that’s most struck a chord with me has been around impostor syndrome. You can find it here: http://adainitiative.org/2013/08/is-impostor-syndrome-keeping-women-out-of-open-technology-and-culture/
That subtle feeling of not belonging in the room, that your opinions and contribution might not be as relevant, and that if you speak up and ask questions your ignorance might be revealed, is one that I’m familiar with not just as a woman working in tech, but as a tester working with developers. Even in my current, very female friendly company, it’s not that unusual to find myself not only the only woman in a room of men, but as the only testing manager in a room full of dev managers. It’s very easy, under those circumstances, to fall into the trap of just sitting there and keeping your mouth shut. After all, you don’t know as much about the system as the guys that built it, do you? What if you say the wrong thing? Bad enough feeling out of place without other people thinking you’re out of place as well.
It’s taken a while for me to get to the point where I’m bolshy enough not to care. I’m concerned though about impostor syndrome striking my team and other testers that I work with. Every time I hear somebody say that they wanted to test X, but they were told by their devs that it wasn’t necessary, so they didn’t, I know that that’s impostor syndrome at work. When I hear stressed-out testers say that they were shouted down on their estimate for testing a story, I worry that it’s a case of impostor syndrome at work. I worry that those people didn’t value their own testing expertise, their domain knowledge, and their diverse skill set against that little voice in the back of their head telling them that the six developers and the BA that they’re sitting at a table with must know better.
I’m not talking here about devs challenging estimates, or developers providing valuable information about changes for testers to take into account when they’re making risk based decisions. Challenging is good. Discussing risk and impact is good. The bit that worries me is when testers don’t feel that they’re good enough or knowledgeable enough to challenge back. When people talk about increasing the number of women working in technology, they talk a lot about diversity, and the value of having people from different backgrounds and with different perspectives.
I know a great number of developers (and business analysts) who highly value having a testing perspective in meetings, and when they’re designing and planning stories. I also know a lot of companies, teams and developers who don’t see the point, or feel that it’s a waste of valuable testing resource to have testers sitting around in conversations at an early design and development stage. The value of diverse viewpoints and contributions seems to be forgotten under the pressure to deliver. This is the point at which less experienced testers can start to doubt their own contribution. Maybe they do have less to say; after all, they’re not the people who are going to come up with the technical development solution, are they?
I would encourage all testers to dismiss any lingering sense of being an impostor entirely, and I’d encourage all other members of the development teams to be aware of how necessary it is to have testers involved in all of the meetings from the very beginning. Those testers are going to be the people sitting there thinking of all the “what if” scenarios that typically don’t occur to developers focused on producing the happy path. They’re the people who are going to ask how the solution is going to make it simple for a great suite of maintainable, readable, fast-running automated tests to be built around it. Those aren’t foolish questions that show ignorance. They’re extremely important questions. Also, those testers are going to be testing it. Wouldn’t it be amazing if they knew exactly what it was supposed to do and how it was trying to do it from the start? As testers we all know this stuff, but sometimes it’s easy to forget the obvious: that our contribution is always vital. Let’s not forget it. And let’s not let other people forget it either.