Saturday, May 12, 2018

Slowing Down the Flow

This week Craft Conference saw a second edition of my talk "How Would You Test a Text Field?". Regardless of the boringness of the title, I find that this is the type of talk we should have more. 
The talk was recorded on video and will be available later in its recorded format.

What I find interesting though is the stuff going through my mind post talk, thinking through all the things I want to do differently.

The talk had five sections to it.

  1. Introducing a common model of assessing testers in job interviews: "How would you test a text field?" and one way of judging the responses
  2. Testing a text field without functionality
  3. Testing a text field in product context through UI & filesystem
  4. Testing a text field in code context through API with automation
  5. Testing a text field that is more than a text field
As I will not be going to conferences in the upcoming year, I don't have a place to fine-tune the talk to its next generation. Sounds like a great opportunity for doing videos I've been thinking about for a long time! 

The things I want to do differently are:
  1. When testing a text field without functionality, get people to generate test ideas to the same functionality with GUI present or API present - focus on what functionality is in which layer
  2. Visualize test ideas from the group better - use a mindmup. Map them to the four level model of how a tester thinks. 
  3. Teach the model of testing better: I intentionally create first "phases" of idea collection, idea prioritization, and learning from results before selecting or generating a new idea for the next test in the first exercise. Later exercises I allow for prioritized ideas to action, but force discussion on what the test made us learn. When I test, it all mingles.
  4. Force the focus in code context better to just the text field, blur the frame needed to run things out. 
I've been teaching the model of testing before with a story of my sister coming back from her first driving lesson many many years ago. She asked our brother to show her the ropes in our own car, as she felt that after her first real drive she was finally ready to pay attention to all those details. On her first driving lesson, the teacher had made her drive around the parking lot a few times and then surprised her by guiding her right amongst traffic. Her experience reminded me of mine: not being able to remember a single thing. 

When we are learning to drive a car (or to test in an exploratory fashion), we first need to learn all the individual bits and pieces. In the car, we need to remember the shift, the gear, gas and break, the wheel and all the looking around while maneuvering things we have no routine on. New drivers often forget one of the things. Stopping into a traffic light you see them accidentally trying to go with a gear too high and shutting down their car. As they are slowing and turning the wheel to make a turn, changing the gear at the same time feels difficult. So they make just enough room for themselves to practice. Same applies with testing. 

The actions we need to make space for are different for testing. We need to make room for coming up with a test idea and prioritizing the right test idea out of all the ideas we have in our head. We need to make room for properly executing a test that matches that idea. We need to make make room paying attention to the result against both spec and any other ideas of oracles we could use. And we need to make room to reflect and learn about how what we just saw the application do changes our next idea.

Just like when driving a car, the driver controls the pace. Slowing individual activities down is something the driver can and should do. Later, with routine we can combine things. But when we start, we need to pay attention to every individual action. 

Thursday, May 10, 2018

When Your Mind Fails You

I walked down from my room, through the long corridor to get to the conference venue in a big American hotel. I felt great and was looking forward to meeting people. I walked to the registration desk, and while I know many of the conference organizers, I did not know anyone there. I walked around a bit, seeing lots of people but no familiar faces. And I recognized the feeling of anxiety. I was uncomfortable, turned around and walked back to my room, just in time to collapse in a massive panic attack.

I don't know what panic attacks look like for others, but I know they are scary as hell for me. I hyperventilate, lose feel of first my fingers and then feet so that I cannot stand up. My face tingles, like it was waking up from being numb without it having been numb. And the only way out of it is to find a way to calm down. Hugging a pillow helps. Being angry at people close to me doesn't. But blaming some of the uncontrollable emotion on others feels like a plausible explanation, until it happens enough to realize it is something where my mind just plays tricks on me.

The trigger to my anxiety seems right now seems to be conferences, particularly large ones with lots of people I don't know or things not flowing as I imagined. The first one I remember I got from the very first developer conference I ever volunteered to speak at. For the last two years, panic attacks have been a frequent companion to every developer conference, but lately also creeping into testing conferences.

Conferences are too rough on me, so I will be taking a break. Not only because I can't deal with my mind, but also because my presence is needed at home.

I used to be afraid of public speaking, and I trained myself out of it by taking a job that required regular speaking: teaching at university. I still remember what drove me into starting the practice: physically not being able to stand in front of a crowd just to introduce myself. It was crippling.

The panic attacks are more frightening, but also feel harder to control than the good-old fear of public speaking. Over time, I'll figure out a way of working this out. Time teaches things we can't expect or see. It always has.

Monday, May 7, 2018

Changing jobs, setting goals

As I return to office after a week in conference, I come back to a new job. Yours truly is now "senior manager" of two R&D teams. And it was a position I resisted for quite a while until yet another 180 turn to see how things I believe in are when lived for real.

Before I was "just a tester" - with the reminder that no one is just anything. My title was "Lead Quality Engineer" and it meant that my responsibility in the teams was to be a senior senior tester. As someone who has been around a while, I knew that I wasn't serving only my team's developers as the tester, but working on the system to which my team contributed. And just as any other senior senior team member in a self-organized team, I could manage my work, propose improvements for the entire team and drive through changes across what ever organizational limit I felt like tacking.

As "just a tester" who just so happened to also be capable of all things management, requirements, programming and testing, I could model what a team member looks like. I could do things that needed doing, not things that I was told that I need to do. I could show that it is a normal case to have "just testers" who talk to all levels of management and consistently get heard. I could show that "just testers" care deeply for developers ability to focus and work. And I could show that "just testers" change the world on aspects that people believe cannot be changed.

So, now I am a manager. I intend to experiment with a few major things in my new position:
  1. Don't change. As a non-manager, I believed in team self-organization and decision-making. I intent to stick to my beliefs and resist the "managers decide" power tripping that is all too common. I intend to see how much I can do things just as I used to, spending most of my days testing happily. I was available to every one of my now direct reports as a tester, and I am available to them as their manager. Not changing things for worse will be a major effort, and require some candid discussions.
  2. Game the Annual Reviews to Tolerable. As manager, I have to run the company appointed annual review processes with my direct reports. I have hated the process, especially  the part that ends up with emails saying things like "your performance evaluation for last year set during review discussion remained the same after the company-wide calibration process.". I hate stack ranking. And I hate trying to fit people into the same mold over finding their unique strengths, allowing and encouraging job crafting. I have no idea what I do with those, and how much the process allows leeway, but I will figure it out. 
 Not changing will be hard. Already my usual request of "let's make sure we can easily automate tests against  the new GUI technology" was taken more seriously with devs immediately coming back with Proof of Concept on testability in addition to just the prototype, with the half-serious joke of "must do when the soon to be our manager tells us". And a dev just came to me asking to pair test tomorrow - never happened before.


Thursday, May 3, 2018

A lesson from my brother, the developer

"You never talk about your brother!", I was told yesterday as I mentioned I have a lovely brother who is a developer, just a little younger than me that he always needs to keep on competing with me and never quite catch up and who just do happens to work at the same company as I do. 

We don't really work together. Work gives me just as much excuses to call him up as the fact that we're related, and both require conscious effort. My brother is lovely, and really really good developer. He works with identity management systems and I work with end-point protection, so he's on a component and I'm on a product. Recently, he's on a component that has been failing a lot in production and that gets easily blamed even when it isn't, and some of the illusions around that are so much easier to address because I can call him up whenever. 

A few months back, I called him as I was preparing a talk I wasn't particularly into doing. I had originally committed to the talk to support a developer who was new to speaking. They backed out, and left me delivering the talk by myself. So I called my brother to think through what had changed in the last 10 years. 

What he shared was foundational. He talked about how as a young programmer, he got to take a requirement and turn that into code. How most of his time went into writing code. How code he wrote was predominantly Java. And how now when someone joins in as a young programmer, they enter a whole different world. 

Most of a new joining programmer's life is no longer writing code. It is writing code in multiple languages. It is configuring environments (as code). It is tweaking parameters, usually not well documented, to get the third party components to work your way in your environment. And it's not that writing code is enough. You need to write tests. Unit tests. Integration tests. System tests. And as you're writing the tests, you need to explore to figure out all the things you need to test. 

Expectations for a young programmer has skyrocketed. We expect them to start more ready, and cover more ground. 

As a tester, I'm often worried of my mindspace, ability to track different levels of abstraction and keeping quality of my work on a level I can be happy with. Not as perfectionist, but as someone who aspires to be better every day. My brother, as a developer, isn't that different. The world is changing around us for us all. 

We're both asked more each day in our respective professions. The entry level requirements are going up. And with the next generations of future professionals growing through the elementary school now being taught programming from grade 1 onwards, it starts to make sense that programming is an entry level requirement for testers. 

It's more about the foundation, than the active use of it. Seeing the possibilities. Knowing to ask help instead of fighting alone. 


Tuesday, May 1, 2018

Building up to a Treshold

For 1.5 years, I've been with my team as a vocal supporter of mob and pair programming. Getting my team, or any of the nearby teams to mob has been a challenge. We've mobbed a few times on functional testing, once on performance testing, once for purposes of learning TDD together but that is about it.

Being a vocal supporter doesn't mean that I couldn't accept a no. I will not force people into doing things they don't want to do. But I keep on mentioning problems that just would go away if we paired or mobbed. And that people who really like each other wouldn't make the others waste so much time working alone towards a pull request where their early contributions would have made a world of difference.

I see problems of many sorts. Lack of empathy. Not understanding one another. Waiting and building queues. Being less happy, less efficient. Making excuses. Blaming. Avoiding necessary feedback when it is delayed. And I keep believing that we could do differently. We can be ok now, but awesome if we find better ways.

In particular with my teams, there has been one vocal person against the whole idea. When someone everyone else is supposed to look up to is vocally saying what they hate about pairing, it makes it hard for others who are conflict averse to step up and say they disagree.

A week ago things started changing, finally. First one new person joined the team, emphasizing how much pairing and teaching people more junior would impact their happiness. They, for the first  time, stood up as the second strong voice, in disagreement.

It was obvious which side I stood on. Discussions in team emerged, and one by one, people started saying they'd love to pair regularly or pair sometimes. The last joiners clearly joined the now "popular belief" that this was worth doing even if they weren't originally strong proponents.

There's this idea of threshold. That when one person does something, that someone may just be peculiar. But when the group grows big enough, the ones not doing it are the peculiar ones. And as social creatures, we tend to want to be with the in-crowd.

Glad I got to this before they made me a manager. Proved me that long term work and kinds reminders push through without assigned power.

Looking forward to pairing with my team more. And making it a great experience that includes us all. 

So, you're a consultant?

I had just finished teaching a half-day training on Exploratory Testing at StarEast. The group was lovely and focused, 18 individuals with different backgrounds and experiences.

Group on my StarEast Tutorial

We were just about to start a speed meeting event, and I talked with someone I had not met before. They saw that I had a speaker badge, and asked immediately: "So, you're a consultant?". I looked puzzled for a moment before I explained, like so many times before that I was a tester in a team, that majority of my working days went into testing with a wonderful team and delivering features to production on pretty much a continuous cadence. 

The question, however, crossed a personal threshold. It was that one too many to think that I wasn't out of place and fighting against the stream. The default setting was to be a consultant, not an employee in a product development company. It was yet another one of those things that made me happy that I had decided to stop speaking at conferences for now. 

Being a consultant is a great thing. But consultants are a different species. They are more self-certain. They're ok being always on the road. They often live off their analysis of other people's work. They carry a risk that I can only admire they cope with, believing there will be more clients. They get different value out of doing (usually an unpaid) talk at a conference because they have something to sell.

I'm here because I have a strong need to sharing what I have learned, in hopes of finding people who can help me accelerate my learning. I'm not a consultant, but I care. And I'm particularly lucky in being non-consultant with an employer who truly supports me doing this as long as I want to do it. It's just that I no longer really want the travel. Maybe again when my kids are past their teenage years. Meanwhile, my helping presence is online, not in conferences. 


Power dynamics in pairs and mobs


Four years ago, I wasn't pairing or mobbing. Frankly, I found both of those intimidating. Instead of expressing that I was scared, I talked about needing alone time, being introverted and not being able to think when others are too close.

I came back to think about all this today for a great thread of power dynamics in pair programming and TDD from Sarah Mei.


If you ever get a chance of watching a mixed gender group of teenagers, you see some of the gender-based power dynamics at their worst. Teaching programming to teenagers in a mixed group results in the girls giggling, downplaying their abilities and focusing on letting the boys shine. It's easy to think of this as characteristic of the girls up to the point you teach the same girls in a separated gender group. The girls are still bubbly, but now concentrating and doing their best. And their best is often much better than the best in mixed gender groups in general.

The problem isn't men's fault, it's structural. Years of belief systems on how men and women interact. And for women in IT, it often takes years (or a lifetime) to overcome the structures that keep them listening rather than contributing. That keeps them apologizing. That causes them to feel they are not good enough.

We see the same dynamic in conferences. We have loads of speakers who are identified as men. We have all male lineups. And when we talk about including women, we hear that we cannot lower the bar. Yet for conferences doing good work on inclusion and blind review, the shortlists end up being very equal or women dominated. There may be less of women, but quality they produce seem to not lower the bar, quite the opposite. But to get considered, you have to listen to some people's hostility in assuming that you're not up to the bar.

Four years ago, I started first mob programming and then pair programming (and testing). I still think of mobbing as the gateway to pairing in situations where the power dynamics are hard or next to impossible like in my team. Imagine having to pair with a man who tells you "women only write comments in code". The pain of having to sit with that person, alone, is enough for many women to walk out. Their attitude shows in the mob too, but a group of people can help moderate, correct or even punish in ways that an individual on the lower end of the dynamic cannot.

I also remember well the first time I paired with Llewellyn Falco. This is a story we've told many times in our shared talks, yet it was a story that I would have never shared with Llewellyn unless we ended up working on a share talk. I came back to think of this time for one of the Sarah Mei's subtweets:
We had agreed to pair on exploratory testing a new functionality added to the software I was working on.  So we sat down together, I guided him first to get to the functionality just to see it was there. The functionality included a new dialog, and as it popped open, my first words were "I wonder what size it is...". It wasn't intended a question, but very much taken as one. What I meant is that we have an agreement on the resolution where things still must be usable on the screen without scrolling. We were clearly on a higher resolution, and still the dialog was big and clunky. But before I got in another word, Llewellyn picked up on the cue and started showing me tools that enable me to measure the dialog size in centimeters, pixels you name it.

I didn't even understand right there and then that I was uncomfortable. That I felt overridden. That none of the stuff I was trying to show - my work in exploratory testing - got done. Moreover, I'm sure I acted like one of those teenagers, just telling myself that my contributions weren't expected for real. I tried enjoying the results we ended up with, not miss the results that were hijacked from me by a power dynamic.

After this experience unfolded in prepping the talk, we have had great pairing sessions and learned to explore in a pair and mob a lot better. He actively worked against the power dynamic, paying attention to listening instead of talking over me, thinking their way is always correct.

Thanks to Sarah Mei's tweets, I remembered again how far I've come. And how far there is still to go now that my whole team is expressing openness to pairing - finally after 1.5 years.