Introduction
This article is based on Eeva Pursula’s talk at the Agile Testing Days (Potsdam, Nov. 13. 2018). It sums up her realizations on how feminist mindset supports the testers mindset, and how feminist concepts and feminist thinking can help us identify problems in the work environment and fix them to make our teams work better. At the end she will also share about what feminism can teach us about defining a testers role.
Target audience: Anyone
Why a tester would relate to a feminist?
Testers and feminists have surprisingly much in common. We cherish a questioning mindset. We notice things that others don’t pay attention to. And sometimes we feel a need to do things that some people find disturbing. We may seem angry as we see a lot of structural problems and feel that we do not have power to change the things that need to be changed. And we meet resistance by people who don’t want to dig deeper into things.
Many things (like women’s right to vote) that were considered radical when the first feminists started to speak about them, are taken for granted today in many parts of the world. Some people have it difficult to understand that this does not mean that all relevant goals of feminism would already be achieved. Or they feel that since things are worse somewhere else, we shouldn’t point out problems at home.
Similarly, a tester may face pleas to stop finding new problems, as so much has already been done. But having fixed the worst bugs that were found on the first test rounds does not guarantee that we had a decent product in our hands.
The mindset of curiosity and suspicion
Feminism is about noticing what things are taken for granted and what is assumed, and questioning those things, the conventions and priorities and the frameworks of our thinking, to find out, which ones of them hurt us more than help us.
For example, I used to work in a smallish company where project managers were supposed to substitute the assistant when she wasn’t available. About 90% of the time it was a woman filling in for her even though about 90% of the project managers were men. Nobody meant it to be that way, but since we didn’t do anything to change this, we actually created a company culture where women’s work was less important than men’s work.
Similar situations are seen in many places, as women tend to do tasks for the common good just because these tasks need to be done, while men seem to be better at taking only tasks that benefit their personal careers [1]. If we want more women on leading positions, we have to notice these patterns and start valuing this work, or divide it more evenly, or hire someone for it.
Questioning is also the basis of a testers mindset. We get the best results if we are able to notice the hidden assumptions and forgotten points of view before any code is written, and communicate in a way that has a positive impact. But often times it would not (yet) pop into our minds at the whiteboard, or we fail to notice that our discussions leave people with different interpretations. So we bump into problems when we start testing.
I’ve seen many carelessly formulated requests that have lead into fixing wrong things. For example, when we want to get rid of some error messages, there can be confusion about whether the fix is about hiding the error message or about finding what caused it and fixing that. And sometimes the first suggestion for solving a problem only solves that one step, leaving the workflow unusable. Or the side effects of the fix make the product worse than what it was before.
There can be problems even if the functionality is able to do what it’s supposed to do. I’ve reopened features that could not be found by a user, or gave them false expectations. And I’ve seen a system freeze when the second user logged in.
Even if we try to think about an issue from all possible perspectives, some blind spots easily remain, so we should always be skeptical about whether all real workflows have really been thought through, and whether everything is done that needs to be done. If something seems trivial or avoided it’s probably good to look at it more thoroughly. And when we see risks or are confused over what has been done, we have to have courage to say it out-loud, even if we are not sure whether there really is a problem or not.
Making pain visible
Feminism is about making pain visible and sharing it so that it can be turned into a force that changes things. That’s what #MeToo campaign is about, as well as many human rights campaigns, sharing painful stories. It is not nice, but it seems to be necessary, because the ways we protect our minds from the threats around us, produce victim blaming. We easily close our eyes from the suffering of the others, whether they be refugees or transgenders or what ever group we alienate ourselves from, making up excuses why we should not care, and why they are to blame for their own despair. Nothing changes if we don’t see how much pain there really is, and how little power the victims have for avoiding it. Fixing things starts by seeing and understanding the problem.
As testers we also need to point out things that are sort of hidden below the surface. In a software project, there are many questions that need to be solved, and we need to find the ones that have been forgotten or given up with.
Once I was asked to test a product that had proven to be difficult to develop further without breaking old features. I read through the requirements, and in addition to simple user workflows, there were a bunch of small but important features with tricky time dependencies and other stuff that made them impossible to be tested by just using the software. So we had a meeting with the people responsible for the product and I asked how are these things tested. To one of my questions the answer from the developer was: “We don’t have an environment where that could be tested, and it worries me.” Apparently nobody had ever before asked him about that, and he had never found time to raise this issue by himself. But once he got it out, he continued the discussion telling some other rather worrying things that I would not have known to point out. So sometimes the best testing is about finding the ways to make developers speak.
Breaking illusions to enable deliberate choices
Feminism is about breaking illusions. For example, in the University of Kansas, they created an exhibition named “What were you wearing?” to break the illusion of too sexy clothes causing women to be raped [2].
Testers also break illusions, mostly illusions related to the quality of the system under test, but it’s not just about finding bugs.
I used to test a rather old and big software that had three development teams that were responsible for different modules in it. But there were things that were common for all the modules, like some of the user roles. In that product, there was a tiny checkbox that gave superuser rights for a user. As I worked with different people in different projects, I found out that the meaning of this checkbox was seen quite differently in different teams and by different developers. Some seemed to think that no customer should ever be a superuser, while others coded customer requested features behind it. So I raised a question about this to allow us to make deliberate choices. That lead into some quite interesting discussions as well.
Making corner cases visible
Inter-sectional feminism raises awareness of corner cases that affect many lives of true, living people. The point is that our work for giving oppressed groups decent possibilities in life does not always help people who are at the intersections of these groups, marginalized in more than one way. We tend to see people from minority groups as solely representations of that particular minority group, so for example in Europe it’s easy to think that depressed muslims or black trans women would not exist. When we talk about European values, we often think about thinks like justice, equality and human rights. These can only be achieved if we give a voice also for the people who are normally neglected.
Similarly a tester sometimes needs to find stories to justify that a bug needs to be fixed even though the developer thinks that no real user would ever really encounter that problem. I’ve found it helpful to be able to name a particular customer, who would most probably see the situation from my perspective. Sometimes it’s of course difficult, and we may have to settle for waiting for user feedback. In those cases it would be good to make sure that we have a way to get some user feedback, because minor problems in software can become costly as they affect which services our customers choose to use.
Check your privilege
But if we talk about feminism, it’s not really enough to question things out loud.
What makes feminism unique as a philosophy, is that it also wants to make privilege and power structures behind the conventions visible. Privilege means things you don’t have to deal with, things you basically do not need to see nor understand [3]. It’s quite easy to see things where we are less privileged than others. If you are left handed or from a poor family, or you have any other disadvantage in your life, you probably see how most people around you are more privileged than you are. The challenge is to see, how I am privileged myself, and how my struggles are less than someone else’s. And we tend to make assumptions about the privileges of others, even though many of them we cannot see. We should be more aware of these assumptions and be able to question them. That can only happen if we learn about lives of different people.
From a testers point of view the concept of privilege is quite self evidently useful when we talk about accessibility. One reason why computers and robots are so great is because thanks to them physically disabled people can have normal jobs, but only if the digital tools that we build for our customers are accessible.
User roles are another point related to privilege. Many testers have heard a developer say “works on my machine” as they use administrator access rights when testing the feature, and the problems are only encountered with more limited access rights.
Tools are also a privilege. Many of us work with huge fancy screens our customers can only dream of. After the workday we may use just a phone or laptop for our personal needs. When my first child started school, for the first year we didn’t get any notifications from the schools electronic communication system. That was because I had filled our contact information to their web form using my laptop, and the check-boxes for giving permission for sending notifications did not fit onto my screen, so I didn’t know that they existed.
So there are quite many things where we have to remember that our users do not have all the information and tools and options that we have.
Leadership is about making people want to follow you
In addition to understanding our privileges compared to our customers, it’s also good to be aware of the power structures at work.
As testers, we are the ones who bring the bad news and spoil the joy of others by reminding them about inconvenient realities. Someone else has to worry about how difficult it is to fix the things we find. From a developers point of view that might feel like we use our power to be mean. So even as we need to be rather merciless in shedding light on problems, we also need to show some empathy and ability to evaluate the significance of our findings. Pick up your fights, and you will more likely be taken seriously when it’s time to fight.
And fighting generally is not the way I want my job to look like. I want to build collaboration, an environment where all roles support each other. It is important because there are many things where I really do not have a power. A tester does not get to decide what improvements are done and how the code is written, and this kind of things can cause frustration for us.
So we need to see, what are the things that we can change, who do we need to convince in things that are not ours to decide, what is the information we need to give them to make them see the significance of the things that we see, and how to tell about our findings in a constructive way. Testing does not add quality to the product, quality is added by giving developers better possibilities to do their work well, and testing is one crucial tool for that. The way we communicate about problems, and how we are seen as humans, has a huge impact on how the problems are issued, and whether our work is seen as something that takes us towards the teams goals or not.
References
[1] Harward Business Review: Why Women Volunteer for Tasks That Don’t Lead to Promotions (Linda Babcock, Maria P. Recalde, Lise Vesterlund, July 16 2018) https://hbr.org/2018/07/why-women-volunteer-for-tasks-that-dont-lead-to-promotions
[2] Huffington Post: Art Exhibit Powerfully Answers The Question ‘What Were You Wearing?’ – The installation proves that clothing has nothing to do with sexual assault. (Alanna Vagianos, Sep. 14 2017) https://www.huffingtonpost.com/entry/powerful-art-exhibitpowerfully-answers-the-question-what-were-you-wearing_us_59baddd2e4b02da0e1405d2a
[3] Everyday Feminism: What Privilege Really Means (And Doesn’t Mean) – To Clear Up Your Doubts Once and For All (Maisha Z. Johnson, Jul 21 2015) https://everydayfeminism.com/2015/07/what-privilege-really-means/
Author bio
Eeva Pursula has been in the software industry for 8 years, mostly doing exploratory testing. She has worked with many development teams practicing different blends of waterfall and agile, testing many kinds of browser-based solutions.
Eeva has a wide range of interests that have taken her to study topics from physics to philosophy to arts and social psychology. For her testing at its best is about questioning and opening eyes to avoided subjects. She is a storyteller who likes building collaboration instead of confrontation.
Twitter @EevaPursula
LinkedIn – https://bit.ly/2SgtRnz