Asking What Would I Do Today?

As a new week started, I was thinking about things to do. I made a little list of changes I knew I would need to spend time on. There were quite a few, which made me think of individual choices I can make on "What would I do today?"

I've been spending a fair amount of time thinking about the fact that time is limited. There's so much to do, so much to learn and not choosing a focus means not making progress on any of them. Everyone has their individual choices of what and how they choose to do.

My Monday list included many choices of what I could do:

• Reflect what happened recently and learn from past
• Analyze the product, in particular business goals/progress and requirements against the product and ideas of where the product is evolving
• Prioritize the backlog with others
• Pairing on production code, or just reading it for ideas
• Working on Selenium tests, could add a few again
• Working on Unit tests, could do something there
• Exploring the application and the new features to find problems quickly
• Updating documentation
• Staying connected with my colleagues in office and outside
• Learning general applicable ideas about testing and software development
• Re-energizing by something

I could learn to be better at any of these tasks, improve my abilities. But I couldn't do all of it at once. 

This brought me back to thinking about short-term vs. long-term gains. Learning is like farming. You plant seeds and pay attention, and you  have lots to eat. On the other hand, we need to eat today and for that purpose hunting keeps us fed now. There's always a balance.

Balance of perspective (short vs. long term gain). Balance of types of tasks. And balance of where I am right now, and what I am able effectively do from that state of mind. 

I made my choices. And made sure my choices this week are different from my choices last week. 

Becoming a Keynote Speaker

There's a few things very close to my heart. Public speaking - delivering talks and training sessions is one of them. It's an area where I have gone well beoynd my comfort zone, transforming myself into something I was not before.

20 years ago, I was afraid of doing presentations. I went through high school optimizing my writing to be as good as it could be, but just bad enough so that the teachers would not make me read them out loud. When I wanted to be in the board of my student union, I almost passed out in front of the audience just for having to introduce myself. Things are now different. I practice a lot to improve. And the end result already now is worth looking at.

I dream big. I dream of having a story worthy of a TED stage. I dream of being a regular invited keynote in software and testing conferences to an extent I have to say no. I dream of being a professional speaker who gets paid to speak. And I work towards this dream.

The work that I do is manyfold. It includes

• being the best possible person in the projects where I work, contributing and learning. I want to be a great tester and a great software specialist, and work on that. I look for understanding to share through doing those things.  
• delivering talks on things I want to talk about and that I think would be of value for others
• studying what makes a great presenter, finding my own style to being great presenter as myself and practicing. 

I work with new presenters, learning from them as much as from anyone. I'm absolutely in support of the Speak Easy initiative, and I find that Speak Easy can also be a home of support for an aspiring keynote speaker.

To find more focus on my studies, I turned to a personal coach. She suggested that since the road I'm traveling is not just mine but there are other women aspiring to keynote eventually, we should set up a Mastermind group. It's not just people who want to keynote on testing, but any women looking into growing into more relevant speaking engagements. There's a strong tech flare to it, but we would welcome women on the path to speaking improvement and greatness. You could be an experienced speaker aspiring to become better, or you could be just starting but set on making fast progress.

Let us know of your interest on peer learning and support by filling in this doodle by Monday 5.10. The first session is just about discussing what we could do on peer support and what is a mastermind group.

Natural laziness and "It works on my machine"

When teaching programming to kids, a first "rule of programming" sinks in well. Telling the kids programmers are lazy, and that you should never write more than a few letters of whatever method you are about to call. Let tools do the work for you when you can.

My personal experience of people in the software industry is though that most of us are far from lazy. Programmers automate the tedium, identifying repetitive (and even potentially repetitive) tasks and turn them into code. That level of effort shows qualities where laziness isn't the first word that comes to mind.

But there's things where programmers are lazy in ways I find sometimes hard to comprehend. The laziness coins to a way of thinking that her own computer is the center of the universe, resulting in the infamous "it works on my machine" phrase.

At work, I was testing a few minor changes to the user interface. I had reported that there was a bit too much of indentation in one particular dialog. I had reported a choice of color in certain places was a bit to gray, making it appear disabled. Simple things. Simple things that stayed in our queue quite a while. So when they finally came through, I was happy with the idea that we'd now have two items less and we could be one step closer to our targeted "stop-and-fix" ideal, that we struggle with as a team on some areas more than others.

So I tested the changes. I opened the two distinct places that had been broken and rightly so, they were now changes. But the first thing I observe is that the thing that used to be grey but was properly indented was now incorrectly indented while black. And looking around a little more, to it seemed like to fix one specific thing, every other place in the program had been broken.

I reminded myself to breath while I was going through what I perceived as the obvious: the developer could not have tested this at all. With a few breaths in and out, I rephrased it in my head: the developer could not have tested this in a production-like environment. That's where the laziness in testing shows. My developers always keep hoping that their development environment is like production. And regularly they learn (from me) that this is not the case.

It turned out that our minified styles were included in version control where they were not supposed to be, overriding old stuff of top of the new. Developers were happy to find a root cause that enforces the idea that they still don't need to go outside their own environments. If it only stays this way, says a little voice in my head. So we have a discussion, resulting in changes to our TFS configuration.

The core problem remains. The developer environment is not the same as the end user environment, even in a ridiculously tiny product development like ours, and more so on anything bigger I've had a chance to work on. If I cannot overcome the natural laziness of the developers on this like my friends keep suggesting, there's another way to solve the problem. Turning the problem into a programming problem of test automation over various environments.

Meanwhile, I'm practicing breathing and encouraging use of other test environments at least for particular types of changes. It had been a while since I had to hear "It works on my machine".  

Seeing what is there, away from the eyes

We made significant changes on how our product handles logins, and I was feeling like it was a whole new feature and approached testing of it that way. You know all the usual stuff of valid and invalid passwords with various contents, looking through allowed character sets and seeing what happens then. And then there's the usual extensions to what you can see, like locking an account after enough trials and scenarios related to that.

As I was testing the login, I got particularly intrigued with the idea of locking / unlocking one's password, and with a little back and forth, I learned that our application counts the failed attempts also while in unlocking mode, and thus one wrong entry gets your password locked after you turn on the locking. Not quite what we meant.

I had a discussion with the developer on this, to learn that this was not new. It was just something neither one of us had felt the urge to test before. I was puzzled on what lead me to it now. Looking into my feelings, it was the risk of being bored. Wanting to see that things could be different than before.

With that idea, I stared at the user interface a while, and let my mind wonder. I realized that when running group testing sessions, people often miss things that are connected, but not visible. And I realized yet another hidden thing I had not paid attention to: audit logs. Kind of obvious thing, something I definitely should be aware of but something that did not remind about its existence visibly.

Software has so much connections that are there, that you need to see even if they were not visible. I'd be really badly off as a tester if I expected to get that kind of information from specs, it's the stuff that I tend to bring to the table thinking about other systems and scenarios in which things can be connected.

I updated my little pictures and checklists, to keep the core insights available for those who come after me. I'm looking forward to someone telling me all the perspectives I'm still missing.

Let me be myself - all testers are not the same

This year, I noticed that on one of the conferences was offering a workshop on Myers-Briggs type indicator for finding out about your natural style / personality, and how that might affect your style of testing. As much as I dislike the idea of thinking as a manager that the type really would tell you what one of the people you coordinate would do, I really like the idea of trying to understand oneself. In your journey to self-understanding, tools like this may be helpful, while they don't give you ready answers.

I was typed as "ENFP". Through those letters, I learned that I have typical patterns of what I lean towards, and I found understanding my stress reactions typical for the type particularly useful over the years in learning to work better with others. I also learned that a "typical tester" would be just opposite, and have tried to keep that in mind when assuming testers should be like me - they typically are not. I also later learned that in strong voices of exploratory testing, there's others who are typed same as me.

My first thought on noticing the session at the conference was that this is again the same old stuff. But right after that came the realization a friend of mine gave me, that is turning into a bit of a mantra now.

The software industry doubles every five years. It means that half of us have less than five years of experience. 

What's same old and obvious to me, might be something we've stopped talking all in all in the field amongst those who have been around a little longer.

Myers-Briggs is kind of complicated, and I recall reading five books on the topic on my journey back then. I've used a simplification of similar ideas by Lloyd Roden that groups testers into four categories. As I went googling for the reference, I came to realize this is from 1999 and as valid today as it ever was.

Lloyd looks at the then popular writings about personality types, and finds four tester profiles he names Pragmatist, Analyst, Facilitator and Pioneer. Within these, I'm a pioneer.  I went to dig out the summary slides I've done when reading the article while being a researcher.

I recognize myself from what the Pioneer is said to like/dislike, as well as can identify with the list of things a pioneer is good at:

• Be good at exploratory testing / bug-hunting / error guessing 
• Be good at challenging and improving things to make things more efficient and effective 
• Enjoy GUI-type of testing / lateral testing 
• Have good ideas 
• Be good at brainstorming ideas on what to test 
• Share ideas about different ways to approach testing 
• Identify and take necessary risks when required 
• Have creative ideas on how to test to find more bugs

With growth mindset, this does not define what I can do, but it could show what my natural tendency to gravitate towards is. And a working theory of mine is that people who want all testers to be automators most likely are not "like me" in personality and background. If that would be true, with automation emphasis we're redefining certain personality types of out of our recruitment patterns. I can just hope my working theory is incorrect. And if I ever have the time and energy, actually go and research my working theory. 

I named the blog post after a song that played in my head this morning with yet another batch of people encouraging me into automation: Let me be myself. I want to let others be themselves too. There's no one tester. There's a lot of great, diverse people with personalities and interests that compliment the others. With software running the world, we can't leave people out from the revolution, we need to learn to be more inclusive and stop trying to find the one perfect profile that should not exist for the bigger picture. 

Mob Testing at Testival

I'm in the process of working out how to best facilitate exploratory mob testing sessions, and all of my rehearsals don't quite work out as I would hope to. With feeling I failed, I keep trying again. And I tried again a week after the previous, this time in Croatia in an open space conference named Testival.

Introducing the session, I again went with rules, but I added one more to my list of two from CITCON. I decided to explicitly remind people on "kindness, consideration and respect" to work together as a team. And they did. 

The experience with the group was completely different than a week ago. This was a group of smart, a little puzzled individuals where some people found the idea of testing without a specification strange until I promised I'm happy to answer any questions they have about the software. 

They got started learning about use of my Mac, learning how to do right/left clicks and move between windows. Looking at how fast they picked that up, I was happy with how much better I've learned to communicate things like that as I'm noticing that some things I consider muscle memory have finally become things I can voice out. 

There were few observations I made about how this group was learning:

• The group had difficulties noticing bugs while focusing on understanding the software and making a list of things to fix. The third dimension was too much to handle at once, or some of the bugs were too subtle to jump to their view. But they found one that I pointed out to them they did, that none of the people I've tested this application before had run into. 
• The group would easily focus on shallow notes all around over analyzing one piece of what they had in mind. I changed the dynamics by giving them a constraint: "find all you can about the little area of features on lower left corner". With the constraint, we got to talk about things like undo (it's elsewhere, but connected to everything) and multi-select (you can do it but it's not a visible feature). And we found interesting behaviors on not having a menu but certain click combinations revealing features we were looking for in a menu. 
• The group had a special observer, who was uncertain about how to contribute the things he had in mind. He would often say things quietly or say them to me to check their correctness, and I noticed repeating to the group that they might want to pay attention to what he was contributing. 
• Everyone contributed and the group was creating shared understanding. I was feeling I'd love to continue longer than the hour, to deepen what we had learned and to put together more observations. 
• Very little of the things the group learned about the application ended up in the Mindmup document. The group was inclined to understand first and document only then. And since we were time constrained with an hour, we would not get that far. 
• The group was really in the yes, and... state. They would complete the previous navigator's sentences, and deepen where they left off without their ego forcing them to show how they could do best elsewhere. 
• Asking "What are you trying to do?" was a helpful question to clarify intent and keep the group in the yes, and... -mode. 
• With two rounds of rotations, I got to see how people improved. The learning for round 2 was quite wonderful to see. 
• It was nice to hear that people enjoyed doing this. The group was small enough not to have to split into inner circle (the mob) and outer circle (the observers). 

For next learning sessions, I will play more with what type of assignment I give the group. While I like mapping out the application / feature often as the first task, I was am truly this time constrained at work, I would not waste it on documenting much of anything else but bugs. There's always the choices with no right and wrong. I wish there was a way of getting them fast-forward into the application, starting from where some of my other participants had already learned. I could try also showing an existing map and seeing how that changes what happens. I also still want to start the exploration from the code instead of the UI. 

Women (like me) in Testing

Long time ago, I was sitting with my university presentation skills teacher discussing feedback I needed to give on a presentation of mine she just forced me to watch on video as part of the course. The experience was painful, but life changing. That discussion made me start my journey to become a public speaker.

There was another bit that she said that I brushed off and only thought about again recently. She told me I’m a feminist. I laughed and kindly declined the label. I did not need to stand up for women’s rights; there were no issues I had experienced. If I did not experience them, perhaps others did not either. I held this belief a long time.

Last autumn I met a lady, who woke me up to think about this again. She was a programmer, younger than me but with plenty of experience and she said exactly what I had said two decades ago: she’s not a feminist. There’s no need to work particularly on women in tech. I realized that as time had passed, I had started to accept other people’s genuine experiences that were different than mine. And I had run into some myself.

The discussion made me realize I had grown used to the idea of being a feminist. A woman who thinks equality is important. It’s about caring to do something about equality. I realize all feminists are not the same, and I don’t care so much about the label that I’d like to go into long discussions about it.

Since then, I’ve been picking up on cues of what I’m experiencing. I find the courage to share these ideas, since nowadays there’s an amazing group of women in testing and through getting to know this large group of wonderful testing professionals, I find that sharing my lessons might be of value to others. So let me share a few stories on the theme of being a woman like me.

I work too hard to be excellent

I’m the oldest of 6 children in my family. Two of us have ended up working with software. For years and years, my siblings that were not in this industry laughed at the geeky hobbies and work, making remarks of unsocial aspects of staring at the screen all day. The two of us that share the passion of the industry, infiltrate the realities of our work on many family meetings. It’s not uncommon for me and my brother to get into a heated argument of “can all testing be automated” in Christmas table. And the others endure our geeky ways, when we go into details of cool bugs and difficult things we’ve had the pleasure to work with.

As the difference in our geeky ways was established already a long time ago, I haven’t really talked about it so much with my non-software siblings. A week ago I did, and I learned something I consider profound.

My non-software sister has recently studying programming as an option of future work. She’s had a great coach working through some basic materials, and making nice progress on seeing how all this programming stuff isn’t that impossible after all. With changes in her current work, she needed to take time off from learning programming, so she came to talk to me about some joint learning efforts we had been thinking. We talked about teaching kids (girls in particular) programming and the world of computers, and I was asking for her advice on how to make progress on that. And her advice was surprising, but very honest.

“You’re a bad role model”, she explained. “Looking at what you do to succeed in the industry gives the impression that you have to work twice as hard, and be extraordinary, and driven”, she continued. “You need role models who are just normal, average. Like some of the guys you work with”.

With her telling me this, a lesson sank in. I live with a double standard. I expect more of myself than of others. And my gender just might have something to do with it.

I’m afraid of gender issues

My story with my teacher long ago shows I did not consider myself a feminist. I stayed with my beliefs of feminism being unnecessary for a long time, dismissing conflicting evidence. I did not want to believe gender could be relevant. It’s all hard work, right? It’s what you do what matters?
I’ve been treated very equally at work. The negative parts about how I get treated I’ve always attributed to being a tester. I remember one manager giving me feedback on being too abrasive, and that I needed to pad my messaging about issues and bugs better. That is a typical thing to hear as a tester, after all we tell developers regularly that their babies are ugly. I learned to communicate better, and took the feedback as typical tester feedback.

On two occasions, I’ve had a developer come and reveal to me after finding some particularly nasty bugs that they knew of those and left them in intentionally to try out if I would find them. Doing things like that is just stupid, even irresponsible, after all I do not find all of the bugs and tricking me isn’t really the thing collaboration is about. But again, I take that as the stupid things people do to testers.

As a tester, I’m really good at what I do. And I love my work, the joy of hunt for the bugs that so often are things no one would code in intentionally.

Recently with more programming tasks, the style of comments has started to change. People around me slip out sexist remarks and recognize my reaction: extreme discomfort. It creates two counter-reactions: I step away back into my comfort zone and wish I would never enter the world where people are treated differently based on their gender; and it makes me find my fighting spirit, telling myself I’ll show them all.

Where testing energizes me, the fear of being treated differently (with special attention, or belittling what I can or want to do or what I have done) drains me. Testing is safe. Programming is not. And when these issues arise, I’ve learned that managers will have hard time dealing with them. The best they seem to be able to do is to silence them, but they remain in people’s minds even if they learn to keep it to themselves.

I’ve come to realize that choosing testing comes partly from being safe of that difference I cannot change: my gender. Not that I would want to change it even. I love being me.

Realizations of some of the differences

I’m not a fan of generalizations, and don’t want to make one here on women. But I wanted to share some insights on gender differences I’ve picked up recently that resonate with me.

On a talk by Coraline Ada Ehmke on “He does not work here anymore”, she shares an idea on how women and men communicate differently. She describes this in a geeky way that resonated well with me. While men’s style resembles a straightforward request-reply protocol (“I ask, you respond to what I asked”), women tend to communicate with metadata in addition to the request-reply. The metadata encodes information about what kind of a response would be appropriate right now. If you miss that, the communication fails. I recognize that in so many cases of miscommunications, both at home and at the office.

Another difference that I started noticing is in how we deal with rejection and getting a no. I realized this from a personal point of view first, in the dating scene. Men might have to grow to become used to getting no and still asking for things. Like a friend pointed out, without asking and probing for relationship statuses, it would be hard to find that someone special. And we do spend a lot of time in the professional circles. Women might get used to, especially when working in tech, not having to ask even when they might want to. I started recognizing how much work I’m willing to do work around things where the answer, when asked directly, could be a No. For me at least, a bit more of training on being told No and still asking for things would do a lot of good. I suspect there might be a gender tendency here. Perhaps that tendency shows in why women don’t end up keynoting, because in the field of testing, “lack of merit” does not really explain the inequality there. I’ve learned that a lot of men that keynote ask to do so. They’re told no a lot of times. Quoting the “Talk like TED” book, “Every ‘no’ means you’re one step closer to yes”. A new friend in twitter is almost as wise:

If you want something, consider asking for it. Sometimes, it's that simple.

— Bryan Beecham (@BillyGarnet) September 18, 2015

Great advice, but sometimes unbelievably hard to follow. At least for me.

To end this with

My fear with posting this blog post is that the trend of labeling me on my gender just increases. My earlier commentaries on not finding keynoting women already make me sad, when meeting people in conferences that now only recognize that bit about me. I post this with the hopes of some of this somehow resonating, to share my stories. Posting this I consider a step on a personal journey of growth, learning to trust that I different sides of me can exist.

Writing about my experiences does not mean it’s my duty to drop all other work to engage in a debate about true nature of e.g. feminism. But I’m happy to have civilized discussions that aim for better understanding in the scope of what I’m experiencing and thinking.