A peculiar relationship to typos

I was sitting in a meeting, looking at code. A summer interns last day at office. The code "works" but has not been tested by anyone other than him. The last I tried checking it out, I got no further than 1st page which was completely empty. Serendipitously I tried a use case where the two role requirement for the feature did not stand (not by accident though...)

As it was the last day, it is obvious to me that someone else will take over maintenance (fixing) of the feature. Then again, I have two more days at the office myself, so chances are no one will notice if it is broken.

We sit together and look at what he has done. He opens a page of code, in small font and before I can stop myself, I point out: "the method on line 1233 has typo". The feeling was peculiar. First of all, it made me realize how I see typos. It's almost as if they were in a different dimensional layer. They block my view of other things. Second, it takes me significant effort to not point them out and go past them. I can do that, but it drains me more than I feel it should.

These developers have had enough contact with me that they deal with this peculiarity quite wonderfully. Refactoring the name took seconds, and was repeated on a few other occasions over the thousands of lines we were eyeing.

It reminded me that I often find myself explaining to developers how people are different in how they deal with typos. Some people never seem to notice them. Some people (like myself) work hard to move past them or find approaches where they cause less of a hassle than if you would go through a Jira-ticket process to get them fixed.

We need to care for different needs. And it just so happens, groups identifying as testers seem to have a little more of people like me who use significant effort to move past typos.

Tester / Programmer happiness in specialization

Browsing through Twitter, I run into an interesting question:

Who has examples of a software development model where having separate developer & testing roles made people *happy?*

— Natalie Bennett (@bennett_nj) August 31, 2016

At first I thought, what *happy*means? That there's never any negative emotions? No frustration? But with a little pondering, I came to the conclusion that happy is just in relation to being happy without the separate roles.

I believe that in the last four years in particular, me and my programmers have had a decently happy co-existence with separate developer and testing roles.

When we need to dig in deep into the code and figure out adding a functionality or a fix, programmers know their way around (as in reminding themselves what was there, none remembers this stuff by heart). When we think we're clear on what we're building or what we've built, I dig in deep to see flaws and omissions.

Surely, I touch code. Surely, programmers test. But that is not what makes our roles separate. The separation comes from deep development of skills that sometimes appears like magic.

With the separate roles, some of the best experiences come from mob programming. Mentally connected and engaged, sharing a purpose without sharing the role. Paying attention to different details. And correcting things as they emerge without ego in play.

Not that there's much ego in play in everyday life too. I've been fortunate enough to work with programmers who get praised for good quality they deliver (with me) who remember things were different (without me). They invite my feedback. They test themselves yet miss connections.

Me and my programmers are not bored. We are not helpless and powerless. We're just as respected (and valued in financial terms) and supporting one another.

We work together well. I can't say that about all the groups I've worked with as tester.

My sources of unhappiness don't come out of the separate tester / developer roles. They come from either role having *unskilled* people who *refuse to learn*. With or without the role separation, these types of people need to first get out of the idea that bad work is acceptable day in and out.

Natalie asks in her tweet chain: "When the tester role works, what does that look like?"

It looks like mutual caring and respect, and drive for deep skills and improvement to create awesome products in collaboration.

How would I describe my new job?

Counting down to last week of my time at Granlund that I've wholeheartedly enjoyed, I'm starting to be dropping mentions on life after Granlund.

I have a new job. I've signed the contract. I've talked about the job but I have not done the job. Inspired by a tweet, I wanted to write down that I think it will be about.

My new job is with F-Secure. I'll work on the Corporate products, and in particular, the corporate security client product. I used to work for F-Secure 7 years ago, so I'm returning to a place I loved, that has changed just as much as I have changed while gone.

Last time I was there, I worked on the consumer client. Corporate is different. If there's one perception of how it is different that I have, it is one where the control over the environment isn't with the product company. Moving from a world where I could at will install new version for customers on a daily basis, this environment is bound to be more constrained.

My role is one of a Lead Quality Engineer. I have no idea what it really means or if people have expectations on it. For me it means I go to be a hands-on tester, who is senior enough to do test leadership through focusing on empirical evidence. I will never be "just a tester", but I will never be "just a manager" either. I'm both. And I will be a programmer whenever I feel like it, even if that identity still gets under-shadowed by others I hold more dear to me.

There's a few things I look forward in particular:

• Solving the continuous feedback puzzle for the corporate side
• Pair-testing with a dedicated automation specialist
• Figuring out team work when there's an invisible wall of technology selection (C++ / Python) 
• Untangling interrelations through empirical focus in cross-team larger organization setting
• Delivering the first version on a seemingly unrealistic schedule by focusing on small incremental pieces of value - do less, smarter
• Working with other testers who want to be awesome (this was what I loved about F-Secure 7 years ago - co-creating innovations on how we work) 
• Organizing bunch of local meetups with a company that has great location and openness to invite others to learn with us
• Having conference (keynote) speaking as part of my work instead of my hobby on the side

I can't wait to start on these. Sad to go, and excited to start on something new. 

Visual Talk Feedback

Last spring, a Finnish colleague was preparing for his short presentation at an international conference. I've had a long-going habit of practicing my talks with the local community, and he decided to do the same. He invited a group together to hear him deliver the talk.

It was an interesting talk, and yet we had a lot to say on the details of it. Before we got to share what was on our mind, one of the people in audience suggested a small individual exercise. We jotted down the main points of the story line chronologically on a whiteboard together. Then each of us took a moment to think how engaged we felt at different points of the presentation. Finally, we all took turns on drawing our feeling timeline on the whiteboard.

What surprised us all in the visualization was how differently we saw what the engaging key takeaway moments were for us. A diverse group appreciated different points!

Knowing the overall frame of some of us liking almost all parts of the presentation provided a great frame for talking around the improvement details each of us had. It also generated improvement ideas that were not available without the image we could refer to.

Today, I was listening to a talk in a coaching session over Skype. I was jotting down the story line and thinking how I could visualize the same thing online. Next time, I'll get Paper on iPad out early on and share that with who ever I'm mentoring. It will provide us an anchor to see how the talk improves. And it gives a mechanism of inviting your other practice audiences to engage in giving feedback.

It was just a typo

As a tester, I'm a big believer in fixing UI string typos as I see them. You know, just going into the code, and spending a little time fixing the problem instead of spending the same (or more) on reporting it. These are just typos. These are changes that I find easy to understand. And yet, I test after I make those changes.

In the last week, I was testing a cleanup routine. Over the years, our product database has piled up quite a lot of cruft, not the least for an earlier (imperfect) implementation that created duplicate rows for everything that was touched in a common user flow. I asked the developer who created the cleanup routine on what it was about and his advice on testing it, to learn that it was "straightforward" and that he had spent time on testing it.

As we run the cleanup routine on the full data, it became obvious that "testing it" was not what I would mean by testing it. The cleanup for a copy of production data took 6 hours - something that no one could estimate before the run started. Meanwhile, the database shouldn't be touched or things will get messy.

So we talked about how we cannot update the production like we do for test environments - hoping none will touch it. We need to actually turn things off and show a message for the poor users.

The six hours and 1/3 of database size vanishing hints to me that this is straightforward because our data is far from straightforward. With very first tests, I discovered that there was data lost that shouldn't be, resulting in what we would refer to as a severe problem of the product's main feature of reports not working at all. To find the problem, all I needed to do is to try out the features that rely on the data, starting from most important: this one.

Fast-forward a few days there's a fix for the problem. And the developer tells me it was just a typo. Somewhere in the queries with IDs, one of the groupings was missing a prefix. We talk on the importance of testing and I share what I will do next, to learn he had not thought of it. I joke to tell him that at least he did not tell me it was just a 10 minute fix after using significant amount of my time on making him even aware that a fix is needed.

The phrase it was just a typo is interesting. We're an industry that has blown up space rockets for just a typo. We have lost significant amounts of money for various organizations for just a typo. Just a typo might be one of the most common sources of severe problems.

For any developers out there - I love the moment when you learn that it's not about the extent of the fix but extent of the problem the lack of fix causes. I respect the fact that there's fixes that are hard and complex. Just a typo is a way of expressing this isn't one of those. 

Just read the check-in!

Today was one of the days when something again emerged. At first, there was a hunch of a sort order messing bug and all of a sudden there was a fix for it.

The fix came with very little explanation. So my tester detective hunch drove me to the routines that I do. I went to see the check-in from the version control and routinely opened up the three changed files without any intention of actually reading them.

The first thing I realized is that the files that were changing had names that matched my idea of what I would be thinking of testing. It's been more often that I care to remember that this was not the case.

The first nagging feeling came from realizing there were three files. A small fix and three files changing. So I looked at the diffs to see that the changes were more extensive than the "I fixed a bug" gave warrant for.

I walked up to the developer and asked about the changes "So you needed to rewrite the sorting?" to learn that it was long due.

With a little routine investigative work, I had two things I wouldn't have otherwise:

1. An actual content discussion with the developer who thought that the change he was making was obvious
2. A wider set of testing ideas I would spend time on to understand if the re-newly implemented feature would serve us as well as the bad old one had. 

There's so much more to having access to your version control as a tester than reviewing code or checking in your code/changes. Looking at check-ins improves communications and keeps absent-minded developers honest. 

Circular discussion pattern with ApprovalTests

At Agile 2016 Monday evening, some people from the Testing track got together for a dinner. Discussions lead to ApprovalTests with Llewellyn Falco, and an hour later people were starting to get a grasp of what it is. Even though I Golden Master could be quite a common concept.

Just few weeks earlier, I was showing ApprovalTests to a local friend and he felt very confused with the whole concept.

Confusion happens a lot. For me it was helpful to understand, over longer period of time that:

• The "right" level of comparison could be Asserts (hand-crafted checks) vs. Approvals (pushing results to file & recognizing / reviewing for correctness before approving as checks). 
• You can make a golden master of just about anything you can represent in a file, not just text. 
• The custom asserts are packaged clean-up extensions for types of objects that make verifying that type of object even more straightforward. 

Last week, I watched my European Testing Conference co-organizers Aki Salmi and Llewellyn Falco work on the conference website. There was contents I wanted to add that the platform did not support without a significant restructuring effort. The site is nothing fancy, just Jekyll + markup files built into HTML. It has just a few pages.

As they paired, the first thing they added was ApprovalTests for the current pages to keep them under control while restructuring. For the upcoming couple of hours, I just listened in to them stumbling on various types of unexpected problems that the tests caught, and moving fast to fix things and adjust whatever they were changing. I felt I was listening to the magic of "proper unit tests" that I so rarely get to see as part of my work.

Aki tweeted after the session: 

The more I have chance to work with @LlewellynFalco, the more I fell in love with ApprovalTests - this makes refactoring so fast and easy.

— Aki Salmi (@rinkkasatiainen) August 17, 2016

If you go see the tweet I quoted, an exemplary confusion happens as a result of it.

1. Someone states ApprovalTests are somehow special / good idea.
2. Someone else asks why they are different from normal tests
3. An example is given of how they are different
4. The example is dismissed as something you wouldn't want to test anyway

I don't mean to pick on the person in this particular discussion, as what he says is something that happens again and again. It seems that it takes time for the conceptual differences of ApprovalTests in unit testing to sink in to see the potential.

I look at these discussions more on the positives of what happens to the programming work when these are around, and I see it again and again. In hands of Llewellyn Falco and anyone who pairs with him, ApprovalTests are magical. Finding a way of expressing that magic is a wonderful puzzle that often directs my thinking around testing ApprovalTests.