Selenium on my mind

Selenium Webdriver has been the theme of my week - a theme that would appear to continue because I choose to continue. I’m struggling with my feelings about this, as I find working on the test automation the most boring part of my work I could volunteer on. But I volunteer to investigate deeper how I think while testing this way (working with tests as artifact focus) and how I think while testing the usual way (working with improvisation on the application with tests as performance). I have a working theory that I’m seeking evidence against: that I find more complicated yet relevant bugs when exploring without the form of artifacts keeping me on a leash. As a sort of corollary, I’m investigating a claim that I don’t enjoy test automation because I’m not fluent in it, through becoming more fluent before dumping the activity - unless I change my mind on what I want to spend my life on.

In the last week, I’ve done pretty much all-Selenium activities. Mobbing Selenium tests with my whole team. Pairing with a summer intern on creating more Selenium tests. Group/pair activities have been helpful as they both fulfill my need of being social at work, but also keep me honest and progressing on task that really isn’t one of my favorites.

I seem to find some of my motivation from playing with the dynamics. While last week we focused our efforts into automating scenarios for existing features that should be monitored, today we experimented with focusing on a completely new feature I’ve never tested manually before.

I was navigating (fixed pairing style since last session and was much happier with the work) and while I had many scenarios on my mind, I chose first one that I’d like to see included in the tests. It was almost the simplest one, but with a twist: a theory of error, a hunch I find so common on what would be likely wrong.

The feature was tiny. We have a dialog that lists packages, where we have previously hidden all packages considered “ready” for a particular user role. We now needed to extend it to show the ready packages. To test this, we need to play with two different user roles to create different states of the packages that then should or should not be visible.

My first hunch was that if something was wrong, one thing that would be wrong is that there’s two types of “ready” packages, ones that are made visible for the other role and others that are not. And that’s what I chose as our first scenario. We clicked through it manually to note that there’s a bug. We laughed at my ability to guess priorities and decided to try out something a developer from outside our organization once suggested me: reporting a bug with a failing test. The little framing difference created just enough variance for me to get out of my general Selenium boredom that I fight, and we were progressing very nicely on automating. There was all the usual obstacles we see with finding the right things to wait on so that the test would run reliably, but those felt more of a thing we just keep seeing on the route.

When the test was done and we run it, it passed. We were expecting a fail with the last thing we were checking. The bug was not visible, although both of us knew it was there. So we started looking into steps of our test where we reused existing pieces and isolating the exact conditions that would cause this bug. We learned that the bug would show only if there was exactly one user of the other role to handle the package, and extended our page elements and test data to include differences in the scenario.

Looking back, we used about 5 times the effort on isolating the bug and reporting it this way over the usual “Jira issues” way. But we did not do this to save time, but to try our how it would feel.

As we finished the test, the developer whose implementation we were testing walked by and got excited about the failing test. He suggested pairing to fix the problem. I was just leaving with other things scheduled, but our summer intern - my pair of the day, volunteered to pair on with the fix. He seemed really happy with getting to work on the application instead of just the tests. Sad that it had to happen for the first time on his last day at work.

Traditional pairing on adding some Selenium tests

Since my team isn't big on pairing, when I get them to pair, I tend to let things happen as they happen without insisting on mechanisms. Strong-style pairing does not happen naturally.

Today I paired with our summer intern, who's been spending some of his summer getting around our Selenium Webdriver -tests. Pairing meant joining him on his work of today with whatever I could bring into it. And the reason we paired is that I'm an expert in what features there are and how we might know if they work, and he was "out of scenarios to automate".

His computer, his tools and technology, and I was sitting by him fighting sleep. He was very helpful speaking about what he was doing, which is something I've learned not to take for granted. Even though I'm familiar enough with our structure, keeping myself up to date on where he clicked and where he ended up, reading the filenames from the tabs and interrupting him whenever things did not make sense was hard. I was continuously feeling it was too exhausting, that I was not learning as much as I'd like and that I was there just to remind of the scenario we were automating. This was very much traditional style pairing. I could review whatever he was doing. I could contribute and did. I fixed typos and corrected the test naming. I required concepts relevant to the test to be visible in the test and not hidden in the underlying structures to improve readability of the test. I observed the application to realize which wait from our utilities would be appropriate. And I was in control of the test scenario, what happens first and what verifications should be in place. I wasn't useless, but I wasn't as engaged as I tend to be when driving / navigating in the Strong-style.

This however left me thinking: if a non-coder pairs up with a developer, it's easy to imagine they might at first prefer this style. Even if they are asleep most of the time on the details, they are not challenged to actually get into the code. If they drive in strong-style, they will learn to code little by little. The work proceeds slower, as there's more learning going on. If they navigate in strong-style, there's a bit of a confusion on what part is navigating on an abstract level and what part is sharing the navigation with the driver.

So there might be a balancing thing here: how much time are you willing to invest in knowledge transfer in the pairing? Strong-style transfers more knowledge. Traditional style allows two experts of very different fields co-exists and collaborate.

I had enough time to let my mind wonder: for a test that I do manually in 20 seconds, we spent 1,5 hours building the test. And most of the stuff we used was pre-implemented. A big chunk went into finding out what to wait on to avoid Sleeps. I wonder if I will ever see this work worthy of my time within my interests. It bears little to no resemblance to what I know as testing.

Added: 
Hmm, the smell in traditional pairing might be: "I did not have to put in much of my effort and this was not a good use of my time".  

Illustration of traditional vs. strong-style pairing

I'm reading a sample chapter of the book "Pair Programming Illuminated" by Laurie Williams and Robert R. Kessler and on the first example of the sample chapter 13, I pause as I want to share something. Here's the first example from the chapter.

This is an example of Expert-Average pairing. The Expert is the navigator, getting very anxious about the Average guy pondering what to do when driving and speaking out loud. 

This is an example of traditional style pairing. It's described as "One partner, the driver, controls the pencil, mouse, or keyboard and writes the code. The other partner continuously and actively observes the driver's work, watching for defects, thinking of alternatives, looking up resources, and considering strategic implications". 

In this case, the navigator actively observing was also collecting quite a bit of frustration. The given consideration is for the Expert to drive and the Average to learn to ask questions to learn from the Expert. 

This whole scenario would look very different in strong-style pairing in which "from an idea to go from your head into the computer it must go through someone else's hands." The driver is the one reviewing while writing. The navigator is the one setting the direction. 

In strong-style, the above scenario could go like this, if the Expert had the answer all along. 

Donna (an expert, navigating): sum input1 and add it to the average of input1 and divide the average by two. 

Skip (an average programmer, driving): Great, what next? 

If the Expert is in the process of coming up with the answer while the work is going on, the discussion in Strong-style could go like this: 

Donna (an expert, navigating): ...Then we need to do the munge. Input1.munge().

Skip (an average programmer, driving): How do I do that?

Donna (navigating): result = input1.sum() + input1.munge()/2; 

Skip (driving): That seems like it's the general average? 

Donna (navigating): Oh yeah, that's a better name for it. 

The whole discussion above in traditional pairing shows a frustration growing between the pair. The whole dynamics in Strong-style pairing makes the frustration different. You might still be frustrated about not having the answers. You might be frustrated not knowing where your navigator will be taking you. But you are not frustrated looking at the less experienced one dabble for a direction that is right now available in your head. 

I find it fascinating that even the basic practices like pair programming still have fine-tuning to do to make them more effective. And that the fine-tuning isn't at all that obvious.  

Imagine replacing "average programmer" with "brilliant tester who does not code so much". That relationship without strong-style pairing is all about frustration. 

Encouraging for observations in training sessions

Among my many identities, I'm a speaker and an organizer. Being an organizer gives me chances of watching a wide variety of other speakers in action, and has proved to be invaluable source of ideas of things I want to improve on myself. As an organizer, I'm also often invited into the dialogue of what I thought of the session, further deepening my understanding of what and why goes on when someone speaks.

Yesterday I organized two sessions and co-presented one of them. The sessions were ones in the series of many similar ones, but every delivery is unique in some way. For me, yesterday's sessions were special as to noticing that over repetition, I've learned to really appreciate the way Llewellyn Falco primes his audience for observations - to share what you learn, both ideas in your head and things you think you're seeing. And because some of you may not have had a chance to experience and observe that, I decided to share it in writing.

What the audience is observing could be anything where something is going on. Collecting everyone's input seems to be particularly good for sessions where some are active volunteers in mob doing something while others watch. But it's equally valuable to get the voices and ideas heard in a team that just all collaborated focusing on getting something done and would benefit from sharing things around the doing.

The three messages to encourage observation

Llewellyn uses three points to encourage observation.

1. On obvious things, half of us miss the obvious. 
2. We see and hear things that are not there.
3. We need everyone's perspective to build a fuller picture.

Each of the points comes with a video and an explanation. Watch the video and read then the commentary.


The first video is about inattentional blindness. Llewellyn let's the audience watch the video with the sounds, stopping the video just before the number of passes is show to check with how many passes people saw (just asking the number) and who saw the animal. With this video, he deliver the point:

Many things happen during the session we observe, and none of them is as obvious as the gorilla on the video. And yet, half of people miss even that. 

 He encourages everyone to share what they observed. Anything. It could be something the session leads you to think about, something internal. It could be about anything going on in the session. Every observation is valuable.

The second video Llewellyn starts off at about 30 seconds into it.  He lets people get into the faa/baa difference with the video to then deliver his point.

Some of the things you experienced might be things others did not experience as they were not there for others. Your observations are uniquely colored by your experiences.

 You see things that weren't there for others, unless you share them with others.

The third video is about forced perspective and how easily people can be fooled. Again Llewellyn delivers a point:

One person has forced perspective, but as a group, our different perspectives draw a fuller picture that is more realistic.

My thoughts on this

For some reason, I was comparing my observations on the audience reactions yesterday. The audiences would appear to respond better when primed with the encouragement, and the videos leave people on a good mood.

In work settings, showing the videos once might make a good impact, but practice improves things more. Feedback regularly teaches us to observe what we're doing.

I find these little tricks people do absolutely fascinating. Every speaker needs to find their own voice and style, but I wanted to share this as one example of a great style to break the ice. With post-it notes from everyone, it's at least a great cultural fit for Finland.

Pains of learning mob programming

Treat one another with kindness, consideration and respect takes a bit of practice. Or better expressed, practicing it makes me exhausted.

Me and my team did our first session of Mob Programming today without an external facilitator. With troublesome teams, a facilitator is great to have. But this time we were amongst ourselves.  Trying to figure out what goes on in something you haven't done before code-wise and helping the process, it's kind of a handful. Especially when not everyone agrees on the idea of mob programming in the first place, even for training purposes. 

Why are we trying Mob Programming?

Let's take a step back. Some people in my team of 9 developers and me really have strong dislikes for group work. When I first suggested pairing/mobbing, that was treated as the biggest insult one could imagine with a particularly genderised attack on me. When I later brought in someone to refactor with us in a mob, I was told that group work is a waste of time but after the experience, occasional pairing (if not with me) could be an option. When I asked my team to mob so that I could fulfil my social needs of happiness at work and learn stuff, others agreed to give in a little but one keeps disliking anything that is "intended to destroy the introverts and bring in these stupid collaboration ideas".

I've been looking at how we do, and we're not very good. We can release to production daily, but only because the throughput times are ridiculously long and we throttle what goes through depending on the skills of an individual developer. Individual differences of quality from a developer are significant. And quality is not just "bugs" I see. It's also code that others want to touch. 

Courses and training haven't really helped. People fall asleep on courses. You need to learn at job. You need to get better every day. So I work very hard to help people find time to learn, mechanisms to learn. Every day is an opportunity to be just a little better. That's how I test. That's how I want to help developers turn ideas into code. 

We need to learn from each other. So pairing and mobbing are the things to do. We’ve identified several team challenges we feel this will help us with.

• Asking for help
  We often get stuck in development and ask Google, where we should ask one another.  As an end result, we have more cleanup work later. We could avoid cleanup by having more brains on the work. 
• Reuse and rework
  We could learn to use our technical assets (reuse existing code) in addition to working actively against adding technical debt. We have technical assets we don't use, but recreate as information of what there is isn't shared. 
• Continuous learningWe could learn from one another and have the learning show up right away in what we’re delivering. In particular, we could even out our individual skill differences in technical excellence we’ve already been working on. No course teaches how to work with our code and application specifically, we need to share examples by doing things together.
• Teamwork
  We could get away from feeling alone and isolated. There’s very few other practical ways than pairing or mobbing to expose the practical level knowledge from developer to developer. It’s in the doing we learn.
• Focus
  We could be more focused on an item we’re delivering, making the throughput times shorter without having to consider merge conflicts or additional work in splitting up into something manageable for several people. We could reduce procrastination and waiting, making think time explicit instead of hiding it into tasks. We still control our own use of time, just as always.
• Skills outside the "developer" boxWhen working with requirements, we still often take what was asked and deliver that without questioning it enough. User interfaces in particular can be very dodgy. Exploratory testing that actually find bugs happens only when I do it or I sit quietly next to a developer testing and pretending I'm a totem or a mascot holding space for testing thoughts to happen. There's a lot of siloing to tear down on what a developer can / should do. 

Mob Programming to train use of Selenium Webdriver

I believe very strongly that mob programming would be a constructive way to tackle some of our team challenges. So I've been on the lookout for chances to try it out. Being where we are now just isn't good enough, because we have potential to so much more. If nothing else, less time at office doing the same work much faster. 

Last week our summer intern needed something to do, and the developers came up with having him work on adding some Selenium Webdriver tests. I was aware we had one developer who had been adding them and being kind of keen on using them to drive his development, but the skills and habits related to doing tests were isolated to him. The summer intern changed the power dynamic and I went to read through what we had now.

I learned we had 3284 lines of code in the Selenium test project. I reminded myself that we started working on this stuff with me creating opportunities to try it out and create things already two years ago. And whatever was created, had emerged in the last six months. The one developer who had taken the given chance to focus on learning to do stuff with Selenium had used what was given and created quite a nice page-object - utils - tests structure. It was time to get that to the rest of the team. So we agreed to mob with two learning goals.

1. Everyone would learn to run tests / subset of tests / analyse the results when tests fail to make them a team asset
2. Everyone would learn to create new tests

I find it hard to see that any other mechanism would have lead to the point where we were 2 hours 15 minutes later, where every one of us had not only seen how to write a test, but also written (stumbling  on their way but improving every round of rotation) a part of the scenario we were testing. And we had added test for a relevant scenario that will now run every night. A test I will not focus on while exploring, since I know it exists without deciphering, backtracking and monitoring what is going on with checkins. 

The experience was good but also painful. We were really bad at sticking to the roles of Strong-Style pairing. And every time we dropped the roles, the next one up as the driver did not know quite where we were, as you just cannot keep up with reading code while someone silently writes it. One of us was continuously pointing out that this was a waste of seven people's time, while everyone else felt they were learning a lot, in a hands-on way. 

During the session we got from one capable navigator in Selenium to three people navigating quite happily. We decided to work on navigation skills sharing next time, and have a designated navigator so that everyone will take turns in trying that out too. And we decided to do a better job in creating a common understanding of the scenario we're automating - this time I knew the test and that there would be problems on  the way, but the problems took everyone else by surprise. A Jira-ticket of a problem is nothing compared to experiencing the problem yourself. 

I was really proud of pointing out how nicely our summer intern had reviewed code while working in the mob, fixing things we would have seen when running the test - which was slower feedback that a smart person pointing things out. 

But I was also exhausted on the continuous negativity towards trying out something new. I got to hear that "I'm not paid to do this, this socialising is too much work" and "You just want us to play and not do real work, all this stuff is like being in kindergarten" and "I could just be a manager and sit around not doing anything, just suggest these idiotic things that waste time". I was keeping myself as calm as I can, working to dismiss the stuff, trying to believe that more of this will change the dynamics in the team.

I noticed three things I can put my finger on that we caught in the team within the session:

• Keyboard shortcuts. People learned to use the IDE a lot faster over just short practice. It's just more efficient telling people shortcuts and then telling on a higher level with things happening faster when you don't search around with mouse. And surprising shortcuts were missing from people who do this stuff daily. 
• Resharper. We've had it for ages. And many in the team did not use it. Renaming manually to three places becames visible and something we can help with changing when it is visible. And it's error prone. 
• Consume-first programming. It was interesting to notice that only some were comfortable with the idea of faking what you wanted to code to have in the test, before implementing it. Most people were first navigating with the idea that you build each piece and put them together in the end. Example was very powerful in that, and I was particularly pleased on how smoothly it came in developer collaboration.

I try to focus on the positive. Others will want to mob again in two weeks on sharing knowledge of TypeScript, and then week later, more on Selenium as the team is back in full composition. 

I show very uncharacteristic patience in changing the team. A little every day. And we'll get there, eventually. 

Being a navigator in Strong-style Pairing

...this post continues where I left off with describing the Driver role in Strong-style pairing.

A step back: who should drive and who should navigate? 

You have a pair of people. You are different people, with different ideas and experiences. The two of you are stronger together because you build on each other, and also because each of you have unique qualities. Sometimes the qualities are more of a foundational or long-lasting kind, like experience that does not build up over night or transfer in a few days of pairing. Sometimes the qualities are more of temporary, like one having a rough day just today. 

One of you will take the role of the Driver - the intelligent input device. One of you will be the Navigator, working out the direction you're about to head to together. Which of the two of you should be which?

The first rule on being the navigator would be that whoever has the idea to get on the computer, should navigate. Remember: for an idea to get on the computer, it must go through someone else's hands in Strong-style pairing. This brings quickly the idea that perhaps the more experienced one should navigate. At least first. At least until it's time to switch. You learn very different things in being a driver and being a navigator. 

The dynamic of newcomer and a seasoned professional is interesting. Having the newcomer just drive is already a relevant service for the navigator, freeing you from typing to think on a bit higher level. The information for the newcomer sticks in a completely different way from doing it, hands on the keyboard, than watching what someone else is doing. 

Here's a story that stuck with me about powers of pairing with newcomers from Agile 2015. Someone was teaching his daughter to code by having her pair with him with one rule: ask "is there a test for that?". The daughter would sit and ask that every now and then would ask the question at the right time. Looking at what's going on, information catches on and the questions expand. This style is more of the traditional pairing. Having the newcomer type for you gives a whole other level of learning in strong-style pairing. 

Whoever had the idea of what to do will navigate. When I started pairing on exploratory testing with a developer, I was the Navigator. When I started pairing on unit tests with a developer, I was the Driver. Over time with both tasks, I will take both roles. And I will grow towards navigating so that the first idea that I have that I could navigate us through, I volunteer to do. 

There's three trigger options on change of roles:

• On time: you can just change roles on a regular interval. Start with shorter times and grow the time as you grow to work as a pair.
• On task: you can change roles when some task is completed. Like a typical ping-pong style pairing, you change so that one creates a unit test and other implements, and both get to do both types of tasks. 
• On idea: you just change when the driver feels there's a direction he'd like to navigate to. It's like saying "hey, I have an idea, you take the keyboard now".

Regardless of the role you're in, the pair of you should remember to take breaks. Pairing can be very intensive work and outside getting the work done in a pair, you're also responsible for building forward your pairing experience. And that usually works best by inviting for feedback, like taking a small walk around and retrospecting your most recent pairing experience together. 

Navigator: Things to Do

As navigator, you are in responsible for caring for your driver. If the driver is the intelligent input device, for her to operate properly, you need to care for the conditions of work. Being the navigator, you need to pay attention to your driver, to constantly know where she is going. And you need to enable her to go as fast as possible.

As a navigator, you have three main tasks you're paying attention to:

• Feed driver the next thing to do. You're creating the driver the box she works in on as high abstraction level as your driver can handle. We'll talk about abstraction level a little more later. 
• Mine the to-do-list. Create an idea on where to go next. You might be just one step ahead, but being that one step ahead is important. Where to go to get your thing done? 
• Observe your driver. See where she is and where she is going, and correct if the direction does not match what you had in mind. Pay attention on how she is doing, and help her whenever she needs it. 

Three main tasks might sound simple, but there's a bundle of advice to do them slightly better. 

Programming style matters

The style of programming matters. Pair programming would seem to work a lot more fluently if the programming style is consume-first. With this the idea is that you start with an end result at first and then one by one build the things you wish you had in order to have the end result. Consume-first enables the navigator to go immediately, coming up with things to do while figuring things out herself. And the end result and it's division keep a visible checklist of what there is to do to get to the end result. 

Some navigators prefer to work with bottom-up programming style. They build the image of the end result in their head, and feed the smallest possible pieces to the driver, one at a time. In this style, the navigator has a lot more of the information about what we're trying to achieve, leaving the driver to interpret more of why the navigator is having her do things. 

The third style is hardest, when there's no ability to work in small pieces. If the navigator has to figure out the whole thing before feeding driver work, most of the time the driver is paused or participating in design discussions over taking the implementation forward. As a navigator, you're supposed to care for your driver, not just having her type for you. Keeping driver waiting while navigator figures things out by herself isn't exactly the optimal way of caring. Working with partial information is essential.

The abstraction level dilemma

As the navigator feeding the driver the next thing to do, finding the right abstraction level to communicate with her is relevant, even key to making progress. For driver to go forward, you need to find the right level on which to talk. If you are using an abstraction level too high, you will see puzzled expressions and nothing happening at the keyboard. If you are using an abstraction level too low, you're not harnessing the powers of your driver by keeping her on too short a leash.

I was particularly puzzled with the idea of using highest abstraction level possible, until I realised finding the level is really a listening and observation exercise. If you give instructions and following them is hard, you're probably working on a too high abstraction level. Drilling down can be instant, just be more specific. If you're not noticing the need to change level, you're perhaps risking an experience of failing with tasks that lowers motivation in pairing, so it's good to keep your eyes and ears open. If you start from a very low abstraction level, the driver can always correct you by telling you the level she is comfortable with. But if she has not yet learned how to, she might get a feeling of being talked down. And I found I am particularly sensitive to that, being the only woman and paying attention to being treated differently.

Mining the to-do-list

There needs to be an idea of where we're heading. But the road ahead might be only clear for the next few steps, instead of all the way. An important thing for a driver is keeping track of the work ahead. There's three main things to consider on this:

• Timing: Find the right time to use an item on the list. What should be done first, what would make a coherent shared story in your pairing. What choices would enable you as the navigator to care for your driver in the best possible way? 
• Backlog: what is there on the list of things to do? Your backlog is best if it can somehow be part of the code and become a shared view - with consume-first style. But you can also make notes by scribbling on a piece of paper of a whiteboard. Whatever you need to keep track of things. Notes are disposable, code (including test code) is what remains when you're done. 
• Prioritisation: Deciding what comes next and in what order to do things. It's not just about the right time in long term, but the right thing right now. And it keeps changing as you learn. 

Express a in-a-nutshell idea of what you're doing

As a navigator in strong-style, you are not supposed to have to justify all your chosen actions to your driver. Sometimes the driver has little clue on where you're about to be heading, and a great practice in these cases seems to have been to invite temporary trust saying you'd like to just go to this direction for like 10 minutes, and if she is still unsure about doing this, you can change then. The argument of what is right thing to do takes easily more time than that. And nothing stops the pair of you implementing both of your ideas and then deciding that a third, completely different option is what you should go for. With programming in particular, there's a lot of uncertainty that unfolds only through implementation and experimentation.

If you need to express what you're doing, you should learn to express that in a very concise format. Instead of all the rationale, pick only the part of the message that is absolutely relevant to care for your driver.

Immediate feedback

When you navigate, keep an eye on your driver. Double-check with questions what the driver does. And if the driver does something you consider a problem, help her correct it right away. Feedback belongs with the action the feedback relates to.

Recognizing time to switch

Either one in the pair can suggest a switch of roles. But as a navigator, you are usually in a controlling position, so your position gives you a bit of extra responsibility to pay attention to when the driver would have ideas that she should navigate on. You want, in the long term, to build a pair where both can contribute. Switching pairs gives a chance to try out the other role, and only practice helps you get better.

Step back and think about what you're doing

Sometimes you may feel you get bogged down into the details of implementation, and you might want to take a step back and think if you are spending your efforts in the right area. You may not notice without intentional step back to look at the bigger picture, because you're going fast with support of your pair (and usually a nice bunch of unit tests too).

Retrospectives

Looking at your collaboration and how the two of you feel about it on regular intervals is also necessary. Not just looking at what you implemented and stepping back on that, but talking about what you learned and what you like and dislike about your collaboration, in a constructive tone.

Ending this with a word of warning

I've started to really enjoy looking into the dynamics of this style of pairing. But there's a story I learned, that I also find very specific to this style.

Two programmers were pairing in strong-style and had the time of their life. There was a lot of talk, as all ideas must go verbally for two people to share. Sometimes the discussions were very enthusiastic and to an outsider they might have appeared even heated.

While the pair was enjoying, the environment that did not recognise the different pairing style was betting on which one of the two in the pair would quit first.

Don't care just for your pair, care also for your environment. Verbalising your thoughts makes them available for more people than just the two of you. Take it as an opportunity to build relationships outside your immediate pair. 

Where do Testers Go With Agile

Last week at Agile 2015, I participate in a Stalwarts session with Elisabeth Hendrickson. Stalwarts is a fishbowl discussion, and one of the topics was to talk a bit about the visions of where current testers go with agile, in particular in the context of how things are set up at Pivotal Cloud Foundry.

Elisabeth described the ratios at Pivotal being 3 explorers amongst 150 developers. But in the session she did not address what she talked about after, that a lot of the traditional testers have actually found their niche in being great product owners prepping up the stories for the teams to develop, and there's quite a number of people in those roles.

Throughout the session, I was sketching a little picture to think about where do testers go with agile. Here's how I see it.

Some of us that have been testers before agile and in atypical agile teams (not quite there yet on e.g. teaming up and collaborating, but already releasing much more often that ever before) don't program. What we don't do today isn't saying we can't start doing it tomorrow, if that is the route we find interest in. It looks like we might have four directions, and none of them is called "tester" in this picture.

Some of us go away
Let's start with the hard part. Some of us will no longer be working with software. This portion is more about attitudes and wants, and inability to find the right ecological box to fit in. People ending up here might be people pushing for traditional manual scripted test cases - commodity testing. While building up e.g. automation and developer attitudes in agile-aspiring teams, there might be an appearance of need for a lot of this, but as the team learns and reflects, this is the work that I'm hoping that will go away. If this is the only thing you deliver, you will end up finding other line of work. Perhaps in support. Perhaps elsewhere in organisations. Or a different line of work that does not require you to think for yourself as much as creating software in any roles around it does.

Many of us will become programmers
I believe many of us will become programmers. Some of us are that already in addition to testing.

If we're new to testing, the risk is with focusing the attention. I believe it takes years and years to learn to be good at testing. It takes just as long to learn to be good at programming. And while there's some shared microskills, the two skillsets have a very different focus on what to learn and how to think about the system we're building.

If we've been around a while and are keen on shaping up our skills on the programming side, the door is wide open. We may be senior testers, but we start of as junior programmers. When might first focus only on using programming as a tool to automate things in the testing domain, becoming software development engineers in test. And eventually I believe that those choosing this track will not stop growing but should actively build on their skills to become full-blown developers, handling both the domain of test but also domain of the application. There's so much power in not splitting the work as soon as our skills allow for that. Test automation is coding. Get good at it. But why stop there?

I believe this is a majority route. This is the safe route. But only if you intend to become good. You do not need to be great today, but every day you learn through reflection on individual and team levels. A piece at a time. But only if you find this interesting and motivating. There's no reason you shouldn't, the great programmers excel in testing and expressing their intent, and transforming that to code and it's a fun thing to do. Especially when you add the pair / mob programming aspects where you're never alone with your attempts to learn more.

Becoming a programmer does not mean testing skill isn't relevant. It is. But it means learning to see testing problems as insights you can harness for automation as much as possible.

Few of us will become explorers
The world of deep exploratory testing is needed, but it's a specialty skill helping others in these types of tasks instead of doing it for them. It's more of a deep skill with idea of continuous work to transfer it.

Explorers will also learn to automate. First they perhaps learn to automate with a developer, pairing up. But for working closely with technical teams, a level of technical understanding will be required. It might manifest as writing particular kinds of scripts to support exploration, or being able to come up with ideas of that others can pick up and run with - with you.

There won't be as many explorers as there are traditional testers.

Many of us will become product owners
There's a lot of skills a traditional tester may have built that will be invaluable in the role of a product owner. With splitting responsibilities scrum-like, a team will need someone available for them full time, so there would be one of these for a team of two pizza boxes.

The testers who will not code or work with technical details are more likely to end up as product owners. Product owners prep the user stories, work out how the product is supposed to be with the technical team and customer representatives. Many testers who build ideas about products will excel in this role.

Product owners don't only define, but they heavily participate in learning through use. Product owners are business-oriented explorers.

My tester identity, where's that?

Personally I don't feel very excited with the idea of not identifying as a tester anymore. I'm still working on how I would feel about the idea of being a programmer. Tester identity for me means that I'm fast at learning new products and features, putting different abstraction layers of information together to see what works and what doesn't. It also means I can find other people with similar interests.

It just might be that to network, I would no longer seek testers, but people enthusiastic about testing. Whatever changes will take time. And probably I too will end up being one of the frogs who with slow change don't actually even notice which new skills I've been picking up and which old ones I've been deepening to help my teams do a better job.