Tag: testing

Feminism in the testing bubble

I’ve described myself as a feminist for years and, for many of those years I didn’t take too much time to stop and think about what that meant to me.  My definition was fairly straightforward and one that I’ve seen in many other places.  Feminism meant equal rights for men and women.  My definition didn’t go much further than that.

 

In my earlier days of blogging, I didn’t particularly want to write about feminism.  To an extent that’s still true.  There is a tax for people who are part of any marginalized group.  The tax requires that you will spend your time and energy not on the actual topics you care about and want to write about such as software, but that you will spend time and energy defending your participation in the space and your right to be there.  The tax is so far-reaching and insidious that you will end up paying before you even realize what’s happening.

 

Payment comes in many forms:  your influence, showing actual emotions on twitter, a boss’s anger, exhaustion from explaining yourself (again) and then there are all of the requests people make of you to teach them because they don’t feel like finding answers for themselves.  Eventually you become #thatwoman who has opinions on feminism.  This turns you into a “go-to” whether you want to be or not.

 

There was a time when I was willingly paying all of these various forms of tax.  I’ve done organizing, participated in “visibility” efforts and written about feminism.  At the end of it, I found myself exhausted and needing to focus on my own career rather than continuing to feed the testing community with all of its various requests.

 

I largely disengaged from the testing community a few years ago because I’m pushing my own career in a different direction and it is taking all of the energy I have.  In the meantime, I’ve paid attention to what has been happening in tech around gender and diversity outside of testing.  For the most part, I focus on listening and signal boosting other people because, as a straight, white, cis woman who already has a tech job, I have my own share of privilege.

 

Through all of this listening and signal boosting, my feminism has grown and changed.  It has outpaced my old definition and is now anchored in bell hooks

 

Simply put, feminism is a movement to end sexism, sexist exploitation, and oppression.

 

I’m done arguing, debating and/or discussing the meaning of quality, but I don’t think we talk enough about feminism, what it means to us, how it touches our lives and what it looks like in our communities.

 

The testing community, in particular, seems to operate under this two-headed shadow of a certain leader with mysoginist tendencies coupled with other leaders who don’t seem to have an awareness of what is happening in tech diversity outside the walls of testing.  (Yes, that is a challenge.  I don’t mind if people communicate with me to tell me how wrong I am about that, just don’t expect me to give you a cookie.)

 

One thing I’ve learned in this new world is that if I am part of a marginalized group, it is ok for me to push back on taking responsibility for fixing things.  It is ok for me to voice a frustration or call someone out and leave it at that.  I don’t have to write tons of articles for different testing publications explaining myself.  I don’t have to be the one giving talks about this.  In fact, by not doing these things, it leaves space for other voices.  I’ve noticed that there are some great new voices in software testing who are paving the wave for even more change.

 

My hope is that people in software testing reach outside of the testing bubble for influence on multiculturalism and inclusion.  Prove me wrong. Show me that you are learning and listening.  I am not the person who will say to you that my opinion is the only one and you should blindly follow it. We’ve had enough of that in software testing.

 

Resources:

Testing in a Throwaway Culture

Picture of a Caterpillar 826C landfill compact...
Image via Wikipedia

When was the last time that a prized possession of yours broke before its time? Did it make you angry and disappointed?  Were you surprised or were you half-expecting it to break?

Craftsmanship is a word we no longer associate with many of the things that come into our possession.  This was brought to my attention recently when I had to buy a new motor for my very pricey KitchenAid, Architect II dishwasher.  As software quality professionals, we are all on the other side of this.  How many tests were you able to run?  How well did you really vet that app?  Did you understand the app?  How much of your testing went according to plan, however much planning you had?  Did the plan really matter anyway?

Last week, a good friend of mine wrote about his frustration at not having enough time to execute tests because of other test activities such as shaking out requirements, managing others, etc.  I kind of know how he feels because, as the test army of 1, I am responsible for many of the same activities.  I’ve done all sorts of reports and activities that will pad my resume as a QA resource, but, in the end, this is not why I do the job that I do.

Here is a post from Chris McMahon’s blog that is, in contrast, ALL ABOUT why I am very content as a technical QA.  The utter hack-itude of the exploits described in this post are exactly the domain of the tester I try to be every day.  But then, I have the bug reports to fill out, the test planning to create and the inevitable smoothing over of dev ego.  These things slowly but surely chip away at my day.   My friends blog is a description of how, for more senior test professionals, it becomes their whole job, and my friend isn’t the only tester I’ve noticed lately opining the strategy tasks that take up their time ( you know who you are).

We live in a throwaway culture where breadth is valued way over and above depth, and it seems, to me, that this can heavily influence our careers, sometimes for better and sometimes for worse.  This includes software development AND QA.  I’ve worked in this type of environment, not as a tester, as a CM.  I noticed that for every role, CM, tester or dev as soon as people became technical experts at what they were doing, they were expected to start managing whether they wanted to or not, whether they made a good manager or not.  Am I right or am I right?  What’s missing here is an association depth with value both on the technical side and the management side.

What does this mean, specifically, for testing?  What does it mean to be an expert craftsman in testing?  Does it mean that I can switchblade an app with heuristics, any time, any place? Or does it mean that I will find a way to make some assessment of quality if given the most mountainous of systems to test in extremely adverse conditions?  My personal goal is to work hard at both.  I use test management activities mainly as a way to manage DRY (do not repeat yourself) and to get on with the tests.  It’s almost as if there is a sliding scale with test execution at one end and management of test activity at the other end.  This seems a rather one dimensional approach, and careers are not one-dimensional.

When you are asked to stop testing so much and to start managing more, what will you say?  Are you ready to give up depth as a tester and increase your breadth as a manager?  Is this really a one-dimensional issue?  For some, and maybe even for me at some point, this can be a great decision.  In some places, maybe there is less of a tradeoff than what I’ve seen.  For some, participating more in the management process might mean better quality for an entire team.  If the entire team improves, maybe the software will break less.  If the team is testing KitchenAid dishwashers, maybe the dishwashers will break less, and I won’t have buyer’s remorse for my fancy kitchen appliances.

Love it? Hate it?  Comments are always welcome.

Reblog this post [with Zemanta]