Saturday, July 22, 2017

A Team Member with Testing Emphasis

Browsing Twitter, I came across a thought-provoking tweet:
Liz Keogh is amazing in more ways that I can start explaining, and in my book she is a programmer who is decent (good even) at testing. And she understands there's still more - the blind spots she needs someone else for. Someone else who thinks deeply and inquisitively. Someone else who explores without the blind spots she has developed while creating the code to work the way it's supposed to.

Liz is what I would call a "team member with programming emphasis". When asked to identify herself, no matter how much she tests, she will identify as a programmer. But she is also a tester. And many other things.

Personally I've identified as a "team member with a testing emphasis". That has been a long growth from understanding why would someone like Ken Schwaber years and years ago suggest to my manager that I - who want to be a tester - should be fired. Over thinking about it, I've come to the conclusion that this is one of the ways to emphasize two things:

  1. We are all developers - programmers, testers and many others 
  2. We need to work also outside the focus silos when necessary or beneficial
For years, I did not care so much for programming so I found a way to call myself that I was more comfortable with than a "developer" which still is loaded heavily on programming. I became a self-appointed team member with a testing emphasis.

This works still, as I've grown more outside my tester box and taken on programmer tasks. It means that while I code (even extensively, even production code not just test code) the tester in me never leaves. Just like the programmer in Liz never leaves. 

Liz can be a brilliant tester she is in addition. And I can be a brilliant programmer I intend to be. And yet she can still be the programmer, and I can still be the tester. 20+ years of learning allows growth outside the boxes.  But it's still good to remember how we got here. 

If software industry doubles every five years, half of us have less than five years of experience. Perhaps it makes sense to learn a good foundation, starting from different angles and build on it. 

Individuals make teams. And teams are stronger with diversity of skills and viewpoints. 

Automation tests worth maintaining

A retrospective was on it's way. Post-it's with Keep / Drop / Try were added as we discussed together the perspectives. I stood a little on the side, being the loud one, leaving room for other people's voices. And then one voice spoke out, attaching a post-it on the wall:

"It's so great we have full test automation for this feature"

My mind races. Sure, it's great. But the automation we have covers nothing. While creating it for the basic cases, we found two problems. The first one was about the API we were using being overly sensitive to short names, and adding any of those completely messed up the functionality. I'm still not happy that the "fix" is to prevent short names that otherwise can  be used. And the second one was around timing when changing many things. To see things positively, the second one is a typical sweet spot for automation to find for us. But since then, these tests have been running, finding nothing.

Meanwhile, I had just started exploring. The number of issues was running somewhere around 30, including the announce of the "fix" that made the system inconsistent and I still deem as a lazy fix.

I said nothing but my mind has been racing ever since. How can we have such differences of perspectives on how awesome and complete the automation is? The more "full" it's deemed, the more it annoys me. I seek useful, appropriate and in particular over longer time not just on time of creation.  I don't believe full coverage is what we seek.

I know what the automated tests test, and I often use those as part of my explorations. There's a thing that enables me to create lists of various contents in various numbers, and I quite prefer generating over manually typing this stuff. There's simple cases of each basic feature, that I can run with scripts and add then manually aspects to what I want to verify in exploration. I write a lot of code, extend what is there but I rarely check in what I have - only if there was an insight I want to keep monitoring for the longer term future.

Cleaning up scripts and making them readable is work. Maintaining them when they exist is work. And I want to invest in that work when I believe the investment is worthwhile.

The reason I started to tell this story is that I keep thinking that we do a lot of harm with the "manual" vs. "automated" testing dichotomy. My tests tend to be both. Manual (thinking) is what creates my automation. Automation (using tools and scripts) is what extends my reach in data and time.

Tests worth maintaining is what most people think with test automation. And I have my share of experience of that through experimenting with automation on various levels. 

Wednesday, July 12, 2017

Is Mob Programming just Strong-style Randori?

Back in the days before Mob Programming was a thing, there was a way of deliberate practice referred to as Randori. The idea there was pretty much similar to what the mechanics of mobbing are. There would be a pair out of a group working at a time on a problem, and then you'd rotate.

My first Randori experience was a long time before I ever heard someone was working in this "mob programming" style, and on a shallow level, the difference I saw from my first introductions to mob programming was the use of strong style navigation. So the question emerged: is mob programming really just a strong-style Randori?

I'm blogging since I listened in to a discussion where Llewellyn Falco was explaining a saying he likes:
Pool is not just a bigger bath tub.
Surely, pool is a container with water in it. So is a bath tub. But the things you can do with a pool are significantly different from the things you can do with a bath tub.

Examples popped out: there's such a thing as a pool guard, but it would make no sense to have a tub guard. Pool parties are a thing, but you might argue that a tub party is a very different thing. The physical exercise aspects of pools are non-existent in tubs, you wouldn't really say you swim in a tub.

While it is a fun word game to make one think, it is a good way of illustrating why mob programming is not just a Strong-style randori. What mob programming as Woody Zuill and his team introduced it brings in is hundreds of hours of learning while continuously collaborating, and with that communication some of the problems we see no ways of making go away just vanishing.

Doing things over long time to grow together make it different. Mob Programming is different.

And the same applies to many of the things where we like to say that this "has been around for ever". Test after and test first are essentially different. The things we can do with continuous delivery are essentially different to just continuous integration.

Tuesday, June 27, 2017

Incompatible cultures

A few weeks back, I started a talk on introducing myself as someone who is not officially responsible for anything, which makes me unofficially responsible for everything. I also talked about how with working in self-organized teams, I find myself often identifying the gaps and volunteering for things that would otherwise fall between.

I'm a big believer in self-organization, and people stepping up to the challenges. I know self-organized teams make me happy, and I wouldn't care to work in any other way.

A lot of communication is one on one, so to talk to my team, I've come to accept that the discussion can come through any of my team mates. There's no "I must be invited to a meeting", but there's "the team representation needs to be present in the meeting". We learn from each other a lot on what questions the others would like answered, and a lot of times whoever acts on the information is the best person to be in the discussion, over someone with assigned power.

I've seen what assigned responsibilities do: they create silos and bottlenecks, that I spend time bringing down. And yet, culturally some people just can't believe there is such a thing as self-organized team - there must be a responsible individual.

I run into this collision of ideas today, as I was seeking a bigger research->delivery task for my team to complete during the difficult summer period when some are here and some are away, and lack of shared responsibilities really shows its ugliest side. As I was asking, I heard that one of my team members has been "assigned responsible" for the research, and the rest of us just do tasks he assigns.

I felt the urge of fleeing. Instead, I wrote this down as a reminder for myself to work more on what I believe an efficient R&D to be: self-organized, with shared responsibilities.

I wonder if that will ever fit the idea of "career advancement" and "more assigned responsibility". Time will tell.

Minimizing the feedback loops

As summer vacations approach, I'm thinking of things I would like to see changed where I feel a recharge is needed before I can take up on those challenges. And I'm noticing a theme: I want to work on minimizing the feedback loops.

The most traditional of the feedback loops is to have the feature just implemented in the hands of the users. I keep pushing towards continuous releasing and related cultural changes in how we collaborate on making the changes that get published.

But it's not just pushing the changes for the end users to potentially suffer from. There's a lot of in-company feedback that I'd like to see improve.  I get frustrated with days like yesterday when all test automation was failing and I still fail to get introduced the changes that would stop the automation from failing from a single prerequisite outside my teams powers. People like walking on roads travelled before, when there would be opportunities for better if we seek out ways to do things differently.

The feedback loop that seems the hardest is the one of collaboration. We co-exists, in very friendly terms. But we don't pair, we don't mob and we don't share as I would like to see us share.

Maybe after the vacations, I will just push for experimenting while making others uncomfortable, in short time boxes. It's clear there are things to do that will make me uncomfortable alone as well, but the ultimate discomfort for me seems to be making others uncomfortable.


Monday, June 12, 2017

From avoiding tech debt to having tech assets

The question I always get when talking about mob programming is how could that be a better / more effective way of working than solo work. The query often continues with do you have research results on the effectiveness? 

As someone with a continuous empirical emphasis on my work as a tester, and someone with background in research work at university, I'm well aware that the evidence I care to provide is anecdotal. I have other things to do than research nowadays, and having done that I realize the complexities of it. And while anecdotes are research results, I can work with anecdotes.

One of the themes I like collecting and providing anecdotes on around mobbing is that to me it makes little sense to compare an individual task, but a chain of value delivery. Many times with mobbing, we end up with significantly less duplication of code, as someone in the group acts as the memory to tell that they are using something of that sort somewhere else.

Here's an anecdote I just today added to my collection: "QA person, where were you 9 hours ago when your knowledge would have saved us from all this work?". A team of programmers was mobbing, and wondering how to work on a particular technology. For everyone in the group, it seemed like there was some significant implementation work for somewhat of a scaffolding type of work, and the team set out to do that work. Later, another person became available to join the mob and with the knowledge available to them, eradicated all the work until that point, just having  the information available: an appropriate library for the scaffolding would already be available, and was used on the tests.

I've seen my own team talk around an implementation, starting with one strong idea, and ending up with the best of what the group had to offer. I've watched my team express surprise when days of work get eradicated with knowing the work has already been done elsewhere. I've watched them come to realization that whatever they would have implemented solo, would have been re-implemented to better match the ideas of architectural principles or the best use of common components.

I've also had chances of seeing a mob go through about ten solutions to a detailed technical problem just to find one with least tradeoffs between maintainability, performance and side-effect functionality.

A lot of times the best result - paying back in the long term - does not emerge ever from solo work. And that just makes the comparison of what did it take as effort to generate some value in mob vs. solo all the more difficult. It's not the task, it's not the delivery flow, but it's the delivery+maintenance flow that we need to be comparing.

Tuesday, June 6, 2017

Fill the Gap

About two weeks ago, business as usual, I installed a latest build to notice that clearly someone from some other team had worked on our user interface. Whatever we had done to make it nice enough had been replaced by problems I did not quite understand. Reporting the issue to offload, and focusing on other things of relevance. 

With communication through various steps on what was the status, we got the word that it would be fixed soon. Days passed, and soon wasn't soon enough. We finished another feature we needed to release, and a thing of temporary annoyance turned into release blocker. 

Friday afternoon, I decided to take a moment on the legwork to learn first that the developer making the changes left for a three weeks of vacation, and the second developer had very much partial knowledge on how the changes he would contribute made their way into the build. He also pointed out that he fixed "the issue" three hours ago and sent whatever he was doing over email to the one now on vacation. 

Asking around a little more, I learned that the thing was that was sent over email, and where it belonged - and that it was in place, yet problems still persisted. I learned to do the necessary tweaks there myself - all I needed was to know what to tweak. 

Monday started with fierce determination to get the problem over and done with. I sat down with the second developer to show him what I saw in the product, and he showed me what he saw in his component test environment. It because very obvious that the simulator he was running was not a match to the real end user environment with the problem. We narrowed down the problem into seven lines of CSS and eventually one line of CSS. 

The mystery started to unfold. The second developer would provide a piece of stylesheet that was correct. By the time it was in the product, it was incorrect. If it was as it was originally given, there would be no problem. 

Hunting down a bunch of Jenkins jobs in the pipeline, I learned the problem was on encoding a particular character that shouldn't get encoded. Speculating on the field that got encoded, we realized removing the encoding would have further effects. What came about was a funny one-hour experimenting with what could possibly work. The speculative solutions of hundreds of characters without a meaning and an argument about clear code vs. comments later, we found one that made sense and fixed it.

It all started with the idea of a bug that needed fixing. It continued to realizing that in a long chain of new and old pieces, ownership wouldn't be straightforward. And I did what we all do in our turn: identify a gap, fill the gap and collaborate on getting things forward. 

In addition to finding the gap, I sat next to people to get the gap filled. I don't need to be assigned responsible to be responsible. 

I could easily still be waiting but I'm not: I fixed the bug.