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.

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.