Entrepreneurship on the side

I had a fun conversation with Paul Merrill for his podcast Reflection as a Service. As we were closing the discussion in the post-recording part, something he said lead me to think about entrepreneurship and my take on it.

I've had my own company on the side of regular employment for over ten years. I have not considered myself an entrepreneur, because it has rarely been  my full time work.

I set a company up when I left a consultancy with the intent to become independent. I had been framed as a "senior test consultant" and back then I hated what my role had become. I would show up at various customers that were new to the consultancy, pretending I had time for them knowing that the reality was that on worst of my weeks, I had a different customer for each half a day. Wanting to be a great tester and make great impact in testing, that type of allocation did not feel like I could really do it. I was a mannequin and I quit to walk away from it.

Since I had been in contact with so many customers, I had nowhere to go. According to my competition clause, I couldn't work with any of those companies. They were listed in a separate contract, reminding me of where I can't work. One of the companies back then on the list of no-go was F-Secure, and the consulting I had done for F-Secure was a single Test Process Improvement assessment. F-Secure had a manager willing to fight for their right (my right) for employing me, and just stepping up to say that they vanished from my no-go list and I joined the company for 6-months that turned into three years.

As I was set out to leave in 6 months, we already set up a side work agreement. And in my three years with F-Secure, I started learning what power entrepreneurship on the side could have.

In the years to come, it allowed me a personal budget to do things the company wouldn't have budget for - including meetups and training that my employers weren't investing in for me. It allowed me to travel to #PayToSpeak conferences I could have never afforded without it. Training for money a day here and there were enough to give me the personal budget I was craving for.

I recently saw Michael Bolton tweet this:

Everyone is self-employed. Not everyone knows it. —source uncertain; Matisse Enzer? @JerryWeinberg?

— Michael Bolton (@michaelbolton) January 24, 2017

I've known I'm self-employed on the side, and it has increased my awareness that everyone really is self-employed. We just choose different frames for various motivations to do so. On the side is a safe way of exploring entrepreneurship.

What's worth repeating?

This is again a tale of two testers, approaching  the same problem with very different ways.

There's this "simple" feature, having more layers than first meets the eye. It's simple because it is conceptually simple. There's a piece of software in one end that writes stuff to a file that gets sent to the other end and shown on a user interface. Yet, it's complicated looking at it from just having spent a day on it.

• it is not obvious that the piece of software sending is the right version. And it wasn't due to an updating bug.  Insight: test for latest version being available
• it is not obvious that whatever needs to be written into the file gets written. Insight: test for all intended functionality being implemented
• it is not obvious that when writing to the file, it gets all the way to the other side. Insight: test for reasons to drop content
• it is not obvious that on the other side, the information is shown in the right place. Insight: test for mapping what is sent to where it is received and shown
• it is not obvious that what gets sent gets to the other side in the same format. Insight: test for conversions, e.g. character sets and number precision
• it is not obvious that if info is right on one case, it isn't hardcoded for that 1st case. Insight: test for values changing (or talk to the dev or read the code)

It took me a day to figure this out (and get the issues fixed) without me implementing any test automation. For automation, this would be a mix of local file verification (catching the file sent on a mock server because manually I can turn off network to keep my files, our automation needs the connection and thus a workaround), bunch of web APIs and a web GUI.


So I look at my list of insights and think: which of these would even be worth repeating? And which of these require the "system" for repeating them and which could just as well be cared for on "unit" perspective. Rather straighforward mapping architecture, yet many components in the scenario. Unlikely to change much but to be extended to some degree. What automation would be useful then if we did not get use of it as we were creating the feature in the first place? 

And again I think there is an overemphasis on system level test automation in the air. Many of these I would recognize from the code if they broke again. Pretty much all but the first. We test too much and review / discuss / collaborate too little.
 
Can I just say it: I wish we were mob programming.

Appreciating Special Programmers

I'm having this phase in my life where I feel like going to conferences to speak isn't really my thing. I don't think it is the infamous imposter syndrome, because there's plenty of stuff for me to share on. While I might have low self esteem in some areas of life, work isn't one of those areas.

So in this moment of crisis, I think of things that have changed for me. I realize one of the things that has changed a lot is how I identify. I remember tweeting with Adi Bolboaca about two years ago who I insist that testers would not be called developers and I can see the irony in now organizing European Testing Conference with Adi and not being able to recall why I would have ever wanted to insist on that, other than fear of losing appreciation for my special skills in testing.

So I keep thinking what (and who) changed my mind, and realizing it has been a group of individuals that never tried changing me.

It all starts with Vladimir Tarasow, who invited me to speak in Latvia for an Exploratory Testing Training and then the Wildcard conference. Wildcard was one of the first mixed role conferences I've been to and Vladimir and his colleagues were first developers I met that cared (enough to act on it) on the community of testers and testing.

Since I was at Wildcard, I participated on sessions. And one of the sessions was full Saturday long Code Retreat, facilitated by Adi Bolboaca.

I loved Code Retreat and could recognize my team would love it too, so Adi came and taught a wonderful day for my two teams programmers. And unlike in the conference where I sat through the day, here I stepped down for feeling insufficient.

These people together with my programmers at work started a learning path in which I appreciated code quality in relation to end user quality in our efforts, and started looking more deeply into ways those two are intertwined.

Adding into the picture was being encouraged to re-learn to program through Mob Programming and Strong-Style Pair Programming, I can't even pinpoint who, when and where changed my mind. I can just recognize it did and find it fascinating.

I think the keys to this change have been:

• No one tried to "change" me but just allowed safe experiences and discussions where we could agree to disagree, and we did
• I had free capacity for learning widely over previous choice of deeply into exploratory testing, as every day brings more capacity if you just stick around long enough
• Other things I wanted (closer human connection at work, not sub optimizing testing but optimizing the product development) required me to do things I wouldn't have otherwise volunteered to do
• I connected with great people on my way, that I can only properly appreciate in hindsight

So Vladimir, I owe you a beer. Clearly. Thank you. I never realized how many aspects of our paths crossing had a meaning to me. 

Frustrations on system test automation efforts

For a tester who would rather spend her time not automating (just because there's so much more!), I spend a lot of time thinking about test automation. So let's be clear: people who choose not to spend their days in the details of the code might still have relevant understanding on how the details of the code would become better. And in the domain of testing, I'm a domain expert, I can tell the scopes in which assumptions can be tested in to a level I would almost believe them.

Back in my earlier days, I was really frustrated with companies turning great testers into bad test automation developers (that happens, a lot!) and these days, I'm really frustrated with companies turning great testers away and rather hiring test automation developers. Closing one's eyes on what is the multitude of feedback that you might want while developing makes automation easier - yet just not quite the testing one may be imagining. One thing has changed from my earlier days: I no longer think of bad test automation developers as the end of those people, as long as they start treating themselves like programmers and growing in that field. It's more of a career change, benefiting from the old domain knowledge. I still might question, based on my samples, the goodness of domain knowledge of testing on many of the people I've seen make that transition. Becoming a really good exploratory tester is a long road, and often people make the switches rather sooner than later.

Recently, I've been frustrated with test automation specialists with a testing background, who automate in the system / user perspective and refuse to consider that while this is a relevant viewpoint, a less brittle one might involve addressing things in a smaller, more technology-oriented perspective. That unit tests are actually full-fledged tests as an option to keep track of things that should work. That it is ok to test a connected system with a fake connection. And that it just doesn't need to be, when automation is on the plate, a simulation of what a real user would do. Granularity - knowing just what broke is more relevant.

I believe we run our test automation because things change, and as a long-time tester, I care deeply what changed. I recognize the changes that my lovely developers do, and I have brilliant ways of being alerted both by them with a lot of beautiful contextualized discussions but also just seeing from tools what they committed. I read commit comments, I read names of changed files and their locations, and I read code. I recognize changes coming in to our environment from 3rd party components we are in control of and I recognize changes into the environments that we can't really control in any way.

And while our system test automation works against all sources of changes, I prefer to think my lovely developers over my users with the test automation giving feedback. The feedback should be, for the developers, timely and individualized to the change they just introduced. A lot of times I see system test automation where any manual tester does the timely and individualized better than the system created for this purpose.

Things fail for a reason. Build your tests granular to isolate those reasons. 

Testing in the iterative and incremental world

I've run my fair share of sessions where we test together something. My favorite test targets recently have been DarkFunction Editor (making 2D sprite animations), Freemind (mindmapping) and ApprovalTests (golden master test library) but there's a thing that is common to all these three. When I introduce them to my groups for testing, they're static. They don't change while we test. They are not early versions with the first of user stories implemented, to grow much later. They are final releases (until next one comes along).

In projects that I work with, I test a lot of things that are not yet the final releases. And it's almost like a different ballgame to find the right time to give feedback on things. In my experiences, early testing has been crucial for allowing for time to understand what we're building to guide that also from a testing perspective. As we learn in layers, the testers too need time to peel a layer at a time to be deep by time of final rounds. But it has also been crucial to fix issues before they become widely spread assumptions that can't be questioned without the whole brick structure falling down on us.

Some years ago, a session I was running was playing with this dynamic. I gave a group of testers the scope of product backlog (stories) for 1st increment and asked them to plan their test ideas. Usually very little came out. I gave then the 2nd increment with very similar results. Then I fast-forwarded 10 sprints to a close to ready game, and I got a long list of things to consider. The point of the session was to show that thinking in the ready state is easier, but having done that, you can categorize then your ideas to figure out how early you could run tests on some of these.

I think it is time for me to experiment with three different new sessions. 

1. Incremental test planning/design - bring back and improved version of something I have not paid attention to for years. 
2. Incremental exploratory testing - figure out a way of running a course where the test target is not static but grows incrementally
3. Test idea creativity - while executing and generating ideas now come for me intertwined (curse of knowledge), looking around me I realize that the creativity part of it could use more focus. 

The first is easy, so I'll just schedule a trial run for my local community. The two others take a bit more processing, and for #3 I think I might know just the perfect place for it - a developer conference. 

Re-testing without the tester

Some days we find these gems we, the testers, like to call bugs. Amongst all kinds of information, bugs are often things we treasure in particular. And we treasure them by making sure they get properly communicated, their priority understood and when they're particularly valuable, reacted on with a fix.

We're often taught how the bug reports we write are our fingerprints and how they set our reputation. And that when something relevant was found and fixed, the relevant thing is worth testing again when a fix is available to see that the problem actually has gone away.

We call this testing again, the precisely same thing as we reported the bug on, re-testing. And it's one of the first things we usually teach to new people that there is a difference in re-testing (precise steps) and regression testing (risk around the change made).

Today I got to hear something I recognize having said or felt many times. A mention of frustration: "they marked the bug closed as tested, and it turns out they only checked that a big visible error message had vanished, but not the actual functionality".

This was of course made even more relevant with external stakeholders coming back with the feedback that something had indeed been missed.

What surprised me though was the quickness of my reaction to mention that it was not *just the tester* who had failed to retest the fix. It was also the programmer who did the fix, who had completely closed their eyes on the actual success of whatever change they did. And to me, that is just something I want to see different.

It reminded me on how much effort I've put on teaching my close developers that I will let fixes pass into production without testing them - unless they specifically ask me to help because they are concerned of the side effects or don't have access to the right configuration that I would have.

Re-testing needs to happen, but re-testing by a tester is one of these relics I'd rather see more careful consideration when it is done. 

Two people who get me to do stuff

Sometimes, I feel like I'm a master of procrastination. For some types of tasks (usually ones requiring me to do something small by myself that has little dependency or relevance to other people) just seem much bigger than they realistically should. I wanted to make note of two people I respect and look up to for making me do things I don't seem to get done.

'I'll just sit here until it's done'

There's a team next door here, that works on the same system but we could easily organize our work so that we don't share that much. I had decided however I wanted to try out running their test automation, maybe even extending that when things I want to test benefit from what they've built. And I got the usual mention: there's instructions, just three steps. So I went and followed the instructions, only to be there in (typically) unlucky day when they had changed everything except their instructions while upgrading their test runner.

So a day later, I hear they've improved the instructions and we're back to just three steps. As I work on something else, I don't really find the energy to go back and see how things are. I gave it change, it did not work out, not like I really need it anyway. So my favorite colleague from that team comes into my team room, with his laptop and sits on the corner of my desk saying: 'Try it. I'll just sit here until it's done'. And I try it, and five minutes later we have delightful discussions on my feedback on making sense of this as someone new.

Thinking back to this, I realize this is a tool he uses all the time. Actively deciding something needs to be done and committing his time to insert positive pressure by just being there. Setting an expectation, and making himself available.

'Let's pair'

Another person takes it further. They volunteers to pair and actively schedules their time to get more out of the shared work. Sometimes their 'Let's pair' attitude feels like pushy, but the results tend to be great. It takes time to get used to the idea that someone is there with you on you doing something you know you sort of could do by yourself.

As one of the organizers for European Testing Conference, they have paired with every one of us. The pairing has both supported timely doing of things, but also created contents we wouldn't create without pairing. On the other hand, it also created schism when the style of pairing was a bad fit.

There was a task that I needed to do, and I was trying to find time in my busy schedules to do it. With him proclaiming 'Let's pair on it', it got done. And while I was sure I had the best skills for the task, I was again reminded on the power of another person on identifying things I could be missing.

From Envy to Stretching

I find it extremely hard and energy consuming to force myself on people who are not actively and clearly inviting my participation. So I envy people who, with a positive attitude just go and do it, like these two people. Recognizing the envy gives me a personal stretch goal. Try it, do more of it, find your own style.

It's not about doing what they do, but knowing if doing what they do would help you in situations you experience.