Taking My New Job By The Balls, Part 1

In April 2014 I accepted an offer and in June I left the company I’d been with for the past 6.5 years (4 years as tester/team lead), and started my new job as a senior testing specialist at another company. These notes/remarks/observations in the upcoming series of blog posts are based on my first 2.5 weeks on the new job. Orderly notes and thoughts are not guaranteed. Also, a lot of the things here may seem very obvious to you (they already start looking very obvious to myself as well…) but that’s OK. I mostly want to share my journey and I want to have at least semi-digested notes for my future self because I have come to appreciate the value of introspection more and more, and the valuable learning I get out of it. And… I’m also seeking the comments and remarks of other testers who recognize the questions I’m trying to answer and the problems I’m trying to tackle.

Some background

Since I’ll be writing a few blog posts about the balls of my new job, I expect most of the details of context and background to emerge from several posts instead of one lengthy intro. However, for the sake of a little clarity, here are some notable details:

  • then: used to test a product 30+ years on the market, 2000+ customers; now: beginning stages of a software project for a single customer
  • then: built a team of testers, 2 of them coached and trained by me as newbies; now: 2 testers plus me on the project team, both have previous experience but have been “lone testers” on projects up until now
  • then: no specs, no business analysts, various people partially filling that role (including testers); now: business analysts and specs and all that jazz
  • then: different in-house teams of programmers specialized in a domain; now: testers, programmers, BAs on one team focusing on the same thing together
  • then: cowboy development; now: planned and organized sprints
  • then: geographically distributed teams across 3 continents; now: everybody’s in the same country but there a few different companies developing parts of the software for the customer

I think this could give some idea about the change I was about to undergo… Add to it the fact that now I’ll be testing a web app which I’ve never done before and you’ll get the picture.

Getting into the zone

So… I step into the office on my first day not sure what is going to happen next. Oh, was I nervous… What really happened was that I got to learn a lot of new stuff. And this. Is. Awesome. I did know something about the project context from the time I was first approached by the company. However, a couple of months had passed, so I figured I wasn’t up-to-date anymore. Well, that hunch got confirmed on the first day.

I had been preparing myself mentally for the context where I was going to do a lot of learning. I’m not very sure how to describe it… I kept having internal monologues about focusing on learning, jumping right in and tackling whatever got thrown at me. I was recycling the learning and thoughts from Rikard Edgren’s tutorial on Test Strategy that I attended at Nordic Testing Days. Somehow it made me feel like I had solid ground under my feet.

I also had quite a few internal conversations/introspections about what I had learned at my previous job, the mistakes I’d made and how I thought about them; what kind of things I’d learned and why I’d learned them (I don’t think all potential lessons stick… or that I’d notice every lesson I could learn); what were my personal goals on the new job; what were the things I’d wanted to try but couldn’t at my old job. I went over the reasons I’d accepted the offer: to learn new things, to push myself out of the comfort zone once again, challenge myself. There were moments were some part of me was thinking “oh shit… how am I going to do this… will I fail?…” but that’s when I told myself this: “Helena, remember what happened the last time you plunged in head first into the unknown 4 years ago? You had no fucking clue what you were going to do but remember the trust you had in your ability to figure things out. If it’s the potential discomfort that makes you edgy, then just lean into it as you have done before. Push through the discomfort as you’ve done before: you know well enough that discomfort is exactly what will make you think of a solution. After all, nothing changes if you’re comfortable. And didn’t you want to purposefully make yourself uncomfortable so that you’d learn new things?”. Or something like this…

Maybe I’m slightly crazy for preparing mentally like this. Maybe. For me it seemed necessary to get really focused, keep my head straight, and “sharpen” my mental state. In hindsight I believe it paid off (and surprised some of my new colleagues :)).

I used to play volleyball as competitive sport back in the day. What I was doing back then before a game and what I was doing recently felt quite similar. You collect your thoughts. You try to identify and tune out the noise (or silence certain damning internal monologues). You try to will your feet move quickly. You observe how the other team warms up, start figuring out strategies… You get ready to do your best!

When I started as tester/team lead 4 years ago, I did no such thing. But then I really had no idea of what was in store for me. Now I had an inkling and I used that as an heuristic to do something differently this time.

The Vast Opportunities for Learning. Great! But…

I believe I’ve been able to establish that I was going to do a lot of learning of different kinds (technical, managerial), on different levels (personal, project-related, professional…). During the first couple of days I observed a few key questions/issues surface. Or rather, these questions had a floodlight pointed at them for me…

Firstly, how to best deal with information in general? How to deal with the information I was given on a daily basis (meetings, discussions, briefs, documents, specs…) or that just landed on my plate? Getting hosed down with a lot of different things from different sources  – how not to lose my head?

Secondly and more specifically, what to learn now and what to learn later? E.g. what kind of information to actively seek myself, what to delegate, what to disregard.

Thirdly, what kind of action to take now and what to postpone?

While untangling the questions from each other and clarifying my thinking, I had these brief deja vu moments. These came about in the form of “oh, this line of thoughts sounds familiar” and “I think I’ve read about/discussed this several times but that’s just been theory so far”. Funnily enough, even though I’ve never been on such a project before and I’ve never had hands on initiating a whole new software project, I almost felt as if I had. There were thoughts and ideas gushing out from the back of my head about how to start tackling these questions. I know I was applying heuristics that I’d “accumulated” over the past years but this library needs to get more organized. To be honest, it was more like a flurry of ideas… which is exactly why I’m now putting myself through the paces and going through the exercise of identifying and thinking about the heuristics I already used during the first days to do the things I did.

The questions I highlighted have formed the trinity I’ve kept revisiting and that I will look at more closely in the following blog posts.

Some Notes from Copenhagen Context 2014

Copenhagen Context is a new conference held in… Copenhagen, obviously. The focus was on longer keynote-style talks, so the whole conference was comprised of 5 talks. However, some of them introduced practical exercises as well. I’d go so far as to say that such talks align with the spirit of the context-driven community, i.e. ideas you introduced should be applied in practice.

Overall, I think there was a good balance between philosophical, inspirational and practical talks covering different aspects of context-driven testing. I left feeling content and equipped with useful material. Thanks to Morten Hougaard (and Anette) who put such a great program together!

Michael Bolton took his time to get to the whisky part. I almost got thirsty. He talked about the principles of context-driven school and his preferred order. I agree with putting the third one (people, working together, are the most important part of any project’s context) to the first place because it goes well with my own observations.

He also talked about the paradox of CDT: instead of being context-driven we sometimes have to be context-driving as we need to change the context to persuade someone that there is no one true way. That’s when you’re not context-driven.

Though, when I think about it an tie it with my experience, I end up with something like “the context can drive me to become a driver, that is due to something in the context I decide it has to be changed”…

Carsten Feilberg encouraged us to use child labor for testing remember how we used to be natural explorers as children, and how heuristics help us comes up with test ideas. It was useful to be reminded to go meta yourself and recognize the heuristics you actually use. I guess that if I tried, I’d initially come up with fairly context-specific heuristics but I’d like to try and generalize them. Although I think there’s a fairly good chance I’ll just re-discover what others have put out there. It would be a good awareness exercise anyway.

Carsten didn’t really trust a room full of testers with his remote-controlled helicopter (the remote was out of our reach but we could gently touch the helicopter at least). But it was fun to think about test ideas for it. Funnily enough, my first couple of ideas were pretty much a perfect match to the mission of Carsten’s test session of the helicopter: finding out the range of the remote control and if the radio signal could get obstructed by objects, and if the helicopter could get lost (apparently, my hunch was right and Carsten did find a bug with that :)).

I missed out on Louise Perold‘s beer testing session at Let’s Test last year but I was in luck this time in Copenhagen. Many interesting conversations were sparked and cool ideas introduced as people were thinking of testing a bottle of beer. I really think it is an elegant example to use beer as the product to test because it’s versatile, informal, and pretty much everyone can relate to it in some way.

I really liked the idea of “talking to the function in your own words”. I tend to forget the power of paraphrasing from time to time but it is really powerful for clarifying my own thinking as well as detecting fuzziness in other people’s thoughts.

I’m going to work through the slides and the ideas again but there’s a lot of stuff I want to share with my team.

Huib Schoots‘ talk was about what he believes are the key ingredients of becoming a great GREAT tester: passion, learning, and courage. He emphasized practicing testing and asking feedback for learning purposes. Since Huib challenged the room of testers on knowing the test techniques they use (or rather… the number of them), it made me think of what are the criteria for professionalism in context-driven community. I asked him on Twitter, so now I’m looking for that blog post 🙂 Though I’m thinking now that “heuristics for recognizing professionalism” is a better way of putting it (inspired by “Context-Driven (presentation) heuristics“).

Finally, Henrik Emilsson encouraged us to put names and faces next to stakeholder roles, think of them as people (and the feelings we have towards them), and THEN think of how to communicate the test strategy to that person. The session included to practical exercises which I liked (they focused on writing) but I shall try this out on my own. I gave it my best but I felt I was getting tired already.

One of the most valuable thoughts for me from Henrik’s talk was related to having invested or detached stakeholders. I’m wondering if great test strategy communication could be way to gently “re-attach” stakeholders to projects. And I can see how this goes well with systems thinking when solving problems… So yes, a lot of good stuff to think about for me as I’ve been trying to improve my communication of test results over the past 6 months (still have to blog about it…).

And then I met my testing friends from Twitter and had a great time at a pub solving a testing challenge. There was other stuff but… what happens in Copenhagen, stays in Copenhagen 🙂

See you there next year?