Saturday, June 16, 2018

Balancing with our time

I made a fascinating observation on something that unites me and my team's 16-yo trainee while preparing for the talk we did at Nordic Testing Days. Neither one of us seems to be afraid of spending significant portion of our day-to-day in learning new stuff. And we are both learning and going forward.

With that observation, I looked deeper. I realized there seems to be a difference in how or why we do it. I do it with intention of creating a balance. They do it because I (nor anyone else in the company) has taught them they couldn't.

There's an exercise I plan to go through with the trainee next week to figure out if they indeed do actively balance using their time or if it emerges from interests. I know I track a balance, continuously.

In thinking of the way I track my balance, I realized I have two dimension I think in. The first dimension is in where the results of my work show: are my results productive in nature (I do something) or generative in nature (others do something better because of me). The second dimension is the payback time, when the benefits are available: right about now or next week (short-term) or later in life (long-term). The long term in the context of a company is a year or two, and in life decades, but thinking around using my work hours, I'm quite aware of looking of reaping the benefits for this company.
Putting these two dimensions together, I get four quadrants and I try to do work for all of these on a regular basis. I don't want to be skewed too much on any corner, but notice that many colleagues feel the pressures of day-to-day so much more that their work-time is skewed on being short-term productive.

The things that make us short-term productive are the immediate tasks we are asked to do. Would you test this and report if it works? Would you create an automated test? Would you go ask if the UX spec is correct on this?

The things that make us short-term generative are things around team work. With me in the room, do the developers remember to test their things better? When they fixed a bug, did they learn deeply about that type of bugs so that they can next time do more around those types of issues? Did a test I automated fail for a real reason, giving timely feedback for the developers making changes?

The things that are productive with long-term focus are things around learning things that make me better at what I do. If I spend the effort to learn to type without looking at my fingers and continuous typos, am I going to be faster every day from now on? If I learn a new way of testing a particular thing, is that going to make me more productive over time?

The things that are generative with long-term focus are things that change organizations, often slowly.  What if I got us all to learn actively new things, would everyone be happier and more productive? If I learned details of the language we're working on, would devs hear me better and care about stuff I say more? Would that make them be better with me around?

Many times we separate the four quadrants here to different people. Managers are supposed to pay more attention to generative and long-term aspects. But many seniors amongst us do all of this, with intent.

Make sure you are not just going through the moves of today and yourself. Pay attention to the balance in how you use your time. Make sure you are growing.

Friday, June 15, 2018

Applying Tyranny of Structurelessness to Exploratory Testing

I was in a call with an upcoming keynote speaker, listening to the key points of the experience they will draw lessons from. Amongst all the great stuff related to the core of the contents, they shared an experience on moving from testers automating to developers automating and testers exploratory testing: many of their testers reported being unhappy, not finding it easy or possible to figure out what to test in a world with tens of releases every single day.

At first, I found myself thinking "How interesting. I must be better at exploring because I don't find it so hard to provide valuable feedback in that setting." Then I read an article about a completely different topic, that forced me to go back and reconsider. The article I read is a feminist piece that I did not read as such. I read Tyranny of Structurelessness as a consideration for those who have less power. And I realized that instead of me being better at exploring, I was probably holding more power than an average tester.

Exploratory Testing, for me, is essentially a manifestation of structurelessness in testing. Obviously there is structure but the structure is of informal nature. The key points the article made for me are:

  • The most powerful advocate structurelessness
  • With informal structures, rules to making decisions are known to a few and power is limited to those who know the rules
After a quarter century of deliberate practice in testing, communicating and integrating into software development, I can't claim lack of power. What I had not considered before is that those with less power may feel lost at the implicit rules that make my world seem clear and straightforward, and allow me to navigate complex spaces of dependencies, changes and decisions of what are the right things to spend time on as a tester. 

The article of Tyranny goes to suggest some principles for inclusion (well, they say "democratic structuring"):
  • Delegation - to be allowed to feel ownership
  • Being responsible after delegation - to be accountable for results for people who they now represent
  • Distribution of authority - to have everyone take their share
  • Rotation of tasks - to learn, to have the knowledge to get to power
  • Allocation of tasks - to be able to focus, to have clear field of delivering value, being fair
  • Diffusion of information - to share information actively
  • Equal access to resources - to share more than information
These principles are helpful in thinking in innovating structures that enable greatness. Leaving people with "exploratory testing" without drilling down is a form of tyranny. What I need and enjoy is only one part of the picture. We have teams around us, different personalities and backgrounds. My comfort level with structurelessness comes from a position of privilege I need to work on. 

Thursday, May 24, 2018

More on Jira story to pull request ratio

Today, just as I was blogging away my previous post, one of my team members send me a quick message: "Would you accept my pull request?"

I don't get many of those. There's so many of us working on the shared 'internal open source codebase' that mostly other people get there before me. I've been given rights just as everyone else even if I don't use them exactly as everyone else.

So I follow the link to the pull request, check the repo name and wonder a little, and check the diff to realize it is a one line change. For a small moment, I stop to appreciate how nice the tooling is, showing me exactly what is changing. I appreciated the description giving me context of why the one line was changing. So I pressed the Approve-button.

A minute later, I get a second ping. "Can you merge the pull request? My rights don't seem to be high enough.". I go back, see that my rights are high enough, stop to think about the ridiculousness that someone has again introduced different rights and assigned them this way, and click on the Merge-button.

A minute later, I get a third ping. "I checked downstream things, all worked out well".

Between each minute, I was testing already the exactly same thing the change would have impact on. After all, we were working together, on the same thing, as a team.

This was so painless. So easy. And then I thought about what another team wanted to require of our processes.

For each pull request, there must be a matching Jira ticket "for documentation purposes", because "support needs to read it". The change we just introduced was part of a bigger things we were building, and the bigger thing would require changes to at least 10 different repositories - meaning 10 different pull requests. And the pull request had already all the relevant info. A one-liner of it would end up in the detailed release notes in case someone wasn't into hunting down the info across repositories.

I sighed and thought about stupidity of processes, and decided to write this down.

Don't come telling me that this is needed for a bigger company. This is particularly detrimental for a bigger company. Know more options.

There's a great way of learning about options: listening. There are so many awesome people who speak about this stuff. Pay attention. I try to.

Sticking Your Nose Where It Does Not Belong

There's the things I'm responsible for, and then there's things I choose to insert myself into, without an invite. I have numerous examples, and many experiences on how at some point of my career this became ok and even expected behavior. In the famous words of Grace Hopper paraphrased: Don't ask for permission, apologize if needed. It's been powerful and I can only hope I learned it sooner.

Today, I wanted to share a little story of one of those times I was sticking my nose where it does not belong: another team, another team's choices of how to run their "agile process".

It all started from seeing a written piece defining, as testers, what are the tester requirements for a story to be accepted for testing. This whole vocabulary is so strange to me. As a tester, I am not a gatekeeper. I don't define *my* requirements. Teams negotiate whatever requirements they may have across roles when they are any good. And I would do a lot of things to avoid building the "development" and "testing" phases, even within a change - including mob programming. But the contents of the list were what ticked me on a trajectory this time.

The contents, paraphrased again, were saying that there must be code review, unit tests, functional tests, parafunctional tests, static analysis, documentation in general and in Jira story tickets in particular. But the idea that this was a requirement for being "ready for QA" seemed so off I did not even know where to start.

So I started simple - with a question.
I wanted to ask how you think of this a little more. Some context: here we do continuous integration through pull requests, meaning that a typical Jira ticket could have anything from 1 - 100 pull requests associated with it. We also do releases continuously, meaning that what goes out (and needs testing) is a pull request content not a Jira ticket. Is there something relevantly different in how you work in this case?
Asking this, I learned that *obviously* there must be a Jira ticket for every pull request. It was so obvious that I was cringing because it wasn't. So while I think there are a ton of things wrong with that idea from looking at how developer work flows naturally and incrementally when feature toggles are available, I had one thing I felt the urge of saying out of all the things I was thinking.
If writing a ticket takes 2 minutes, and reading it by various stakeholders takes 10 minutes, I might argue that you could actively think of opportunity cost. The time you use on those tickets is time away from somewhere. Where is the value on documenting on that level? Many teams here have come to the conclusion that it isn't there.
I should have realized to just step out at this point, because I was in for a teaching of how I don't know software development.
Maybe it is not obvious, but things like 'developer checklist' could help to deliver high quality code.. which means less bugs and less cost. If someone would like to discuss about this, let's show him/her "How much do bugs cost to fix during each phase" graph.
 And it continued:
  • Writing documentation - in Jira tickets of pull request size - is essential because R&D is not alone but there are other parts of organization AND we get blamed if we don't deliver as ordered.
At this point, I realize there are fundamental differences not worth going into. There is no interest in hearing opposing views. They are optimizing for a customer - contractor relationship while I'm optimizing for working as a single product company. I've lived years of blameless life that enables me to focus on actually delivering value, they are afraid where I am not. 

Good thing my manager knows that I can stir up some trouble. I may step out, but I never ever give up. The best way to show this is to focus on how awesome my team is at delivering. Nose back where it belongs, until another dig.

Lessons Learned on Two First Weeks as Manager

A few weeks ago, after a long battle, I gave in and applied for a new role: Senior Manager, Windows Endpoint Development. That means I work with two full development teams, handling their line manager duties.

When considering the shift (actually, when looking for reasons to not make the shift) a friend reminded me:
You have always job crafted your tester role to barely recognizable. Why should this manager role be any different in how you end up doing it?
I almost understood what they meant. Now I understand fully.

I've been now in this new role for two weeks, and I barely see any difference. That is how much I had crafted my previous role.

I still test and I still love it. I'm still finding time boxes to test whatever I feel like, and I'm still not taking  tasks from "the backlog" but identifying the most valuable thing I could be doing.

I still look at systems beyond the perceived team / components divisions, following all flows of change into the system we are building.

I still guide us all in doing things incrementally, and the testers perspective is perfect for that.

I still listen to my team mates (now direct reports) for their concerns and walk with them to address things. 

I was as powerful as a tester (with my network of people to do the work with). I might claim I was even more powerful, because I did not have to deal with the "yes, manager - of course we do what you asked" and got to dig into the best solutions defending my perspectives, turning them reality without assigned power.

I never cared for the hierarchy when getting things done. If I learned something now, I learned that others should learn to care less about hierarchy. And that "escalating through hierarchies" is an organization worst practice on the level of actual practical work. I thought others also saw problems and felt they could just go solve them, seeing all obstacles they can get through as potential things for themselves to do.

I always knew many people's salaries. Because I talked with people one on one and made sure it was fair. Well, I told people joining the company my salary for them to know what they can try negotiating on. I also have moved my own bonuses on others who in the bigger scale of things deserved it more because that is what my sense of justice told me to do. I have fought for other people's raises, as well as my own before.

The only thing that is sort of new is the many quirks of recruitment - relocation processes and the work managers do there.

I'm surprised that my new job is my old job.

And talking with the friend again:
I told you you were already doing that job.

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.