Me Teaching Testing (Brighton in October, wink wink)

For quite many years, I've had absolutely wonderful places to work in. I made an active choice of not being a consultant or contractor, and thus I've had the privilege to learn my craft (pretty good testing if I may say so) in context of product companies. Wonderful in the sense that they're flexible and let me train on the side of normal work as a tester / test manager.

Back in the days pre-dating context-driven testing, I founded my learning to Cem Kaner's Testing Computer Software. For a single career-defining moment, reading that book would be my top item. I learned there were companies that considered opportunity cost and optimised their testing to be smart. And that those companies typically in the first front were product companies.

Over the years, I've given numerous positive remarks about things that surprised me positively, changed business models with my feedback, contributed to many great features that work and logged my fair share of bug reports. The mindset I work from I would refer to as exploratory testing. It allows me to test appropriately and dig in deep when I need to, learn a layer by layer challenging my knowledge to find out things about the product I'm testing.

I've also been teaching quite a while. I started doing that in 2001. For quite a while, I taught courses on testing folklore. Things I'd experienced. Little exercises to wake you up to think. Tips and hints on how to navigate the testing corporate jungle. Over time, I became 'a testing dictionary' for the Finnish local community, someone you could ask pointers on just about anything in testing.

At some point having coached enough testers as part of my work, I realised the courses need to change. That I need to move from focus on folklore to focus on doing. My Exploratory Testing Work Course is the course package on the theme I've been delivering the most, and put most love and dedication on. And this course now sees the first public outside Finland delivery, with Ministry of Testing in Brighton Thursday Oct 22. Will I see you there?

I've built my course around the need to learn to self-manage the work we do while testing, to dig in deeper for more information. I've built my way of teaching how I think and keep myself on track, and  build on those ideas leading my students to test real software with me. Learning from me, but also learning from peers on the class. A safe place to try things out and to get feedback.

If you are like me, you would have already been to many other courses and you'd still learn a lot. If you haven't been as lucky on receiving training, this course could give you a framework to deepen your skills while testing in day-to-day work.

If Brighton is far away and the times just don't match with your other plans, I'm hoping to keep in touch otherwise. I always love a good, constructive discussion about the wonders of testing and developing software. If you feel like getting in touch, my email is in my twitter profile - for a reason.

Being a Driver in Strong-Style pairing

...this post continues where I left of with my previous post.

Driver: Things to Do

You are the intelligent input device. What is expected of you except for typing as you're told?

• Push back. Express that you need to modify the way the navigator is navigating you. You may want to change the box in which you work, make it bigger to give you more freedom or make it smaller to be clearer on what to do. You may realise you need to try something else, and express that in questions. Key is to be active even when driving. 
• Improvise. The navigator gives you a box within which you operate. You have choices on how you can do things. You choose what you believe to be nest for context at hand, and driver gives you more detail if she disagrees with your choices. Improvising is about adding your intelligence to the collaboration. 
• Switch level of abstraction. If you feel the abstraction level of navigating could be higher or lower, talk back to the navigator. If the navigator is using too low level, you can give them the higher level. "You can just tell me to run it", when navigator is telling you shortcut in keystrokes. If the navigator is using too high level, you can ask "Tell me what to type?" or "Where's that located?". Change the level of abstraction and enable a common experience of learning to work together better. 
• Ask questions. If you feel something isn't right, ask about it. You can simply go for "Are you sure?" to stop the navigator to think about what is going on. Keep your questions specific so that the answers can be short. You can try validating questions to clarify what is going on right now, "It seems we're using zip-add-object to regulate temperatures, is that correct?". You can check if the thing you did was correct against your understanding: "I thought the database only accepted one connection at a time. Why did we do two?". You can suggest where to go, without deciding for the navigator: "Shouldn't we do this first?". Avoid general why-questions and work to prevent long explanations.
• Initiate role switch on an idea. When you realise what should be done and think you could navigate this task better, initiate a role switch. You can switch roles on idea, without waiting for the timer. Or you could never use a timer and switch on tasks. 

It's good to remember that you as the driver are helping the navigator to navigate. Sometimes navigators will try a general avoidance technique of declaring tasks mundane, and great driver will volunteer to be around even for that task. Sometimes you are just literally trying to go against the excuse. Sometimes the two of you just need to get through the bad stuff together to get to the fun stuff together, to build the long-term relationship. 

Underneath what we actually do as driver, there's a bunch of attitudes to consider:

• Trust your navigator. Stay in the moment. Be ready to work with partial knowledge. Your navigator is probably only one step ahead of you. 
• Just try it. You can always do it both ways and end up with a third that builds on top of both. Learn by doing. Learning while doing is just as important as getting the end result out of the process. 
• Constant self-reflection. Investigate what is going through you. Focus on learning. When following your navigator, you're reverse-engineering. Navigator keeps telling you stuff. You get a very thin, narrow view into the system. You can start putting things together a lot and this gives you a chance to reflect on what you're learning individually as driver with your pair. 
• Patience. Give the relationship time. It's good on  both sides, but it's extra useful on the driver side who works with incomplete knowledge. 

There's two main pitfalls to being a driver. 

• Thinking. You think within the box or change the box. Thinking too far as the driver takes the navigator's focus on bringing you back to the task at hand. 
• Silence. It's not an open box to do anything you think of. If you want to take the lead, switch roles, but try not to run your own way with the silence. 

The pairing experience: foundations

Back in the days when testing dojos were new, I tried some of them. We would pair up in front of a computer to test, rotate on clock so that everyone around the round table got their share of the computer.

I never particularly liked it. I found that people were really bad at explaining what they were doing and that is the key thing I'd want to learn from - ideas that drive them. The roles of driver and navigator split so that the driver tests and talks out loud, the navigator observes, makes notes and adds stuff felt it was not very engaging. Everyone in the room would have a different idea of what was going on at the computer, deciphering most information from actions as people tend to be bad at talking while testing without significant practice.

As I was teaching testing, I adopted free-form pairing into my courses. I'd have people work in pairs, without assigning them roles and see what comes out. Most often I saw one of the people in the pair be active and the other one trying to contribute something, often quietly watching unless there was a specific discussion on what to do.

Then I learned about strong-style pair programming. With strong-style pair programming, the core is that any ideas from one person's head must go through the other person's hands. It relies on the roles of driver and navigator, but changes what each of them is expected to do. Driver is the one who listens and types. Navigator is the one who tells what to do.

In classroom settings, particularly when working in mob (group) format, this style works wonders. You can place the navigator as far as possible from the driver at the keyboard, and everyone can hear what the driver hears. And it guides you to vocalise the core of what we're doing, leaving everyone same experience of navigation as the driver gets.

On way home from Agile 2015,  I collected our ideas about communication in a strong-style pair, in particular as a reaction to many of the issues we see in teaching settings. I've come to realize this isn't programming or testing specific, but it's more about how people work together.

The Story that Triggers This Post

In Agile 2015, I participated a session about unit testing and group learning. The session started with asking for volunteers to join a mob in front of the room, and I was the first to raise my hand as I had promised to model that women could join. Success, we had 50/50 split of genders.

The session was set up with strong-style pairing, with telling driver and navigator their roles. The lady driving first expressed happiness in her role of typist, "I can do that!" and navigator told her what to do word by word, and soon the test was passing. She had just written her first lines of code in her life. With that, the first driver became the second navigator and was soon explaining what the lines of code she was working on would do, just by reading what the English said.

I was third in the queue to become a driver. The third navigator had already been through this before, and he was a programmer, he had already been helping the earlier navigator while he was driving. And when he navigated me, he went to keystrokes telling me what to do. I would have been fine with higher level information, especially since this was not the first time I've seen these Koans.

When I then navigated, I was focused on what level to navigate on, to get the job ("fill in the blanks" as we were doing unit test koans) done fast, as I was feeling slightly annoyed with the idea that I was assumed to need the keystrokes when I was driving.

So the question kept puzzling me: is it better to start your navigation with low-level or high-level? You can say "create a class" or " write 'MyClass VariableName = new MyClass();'". You can say "Copy the text from the file" or go into details of explaining how that happens. And as a woman, I felt particularly sensitive for a level that would be too low. Expressing that idea, I learned I would have been equally uncomfortable with navigation that was too high-level, failing to do what was asked and at worst multiple times in search of the right level.

This and two other posts are about what we learned about Driver-Navigator communication from that trigger.

Driver-Navigator Pairing in Strong-Style

For the pair to work well, both parties in the pair need to work well in their roles, and there's specific skills and techniques you can learn to work better from get-go with a new pair in either one of the roles. Techniques, however, are just ideas until you apply them in practice. Only through doing you can learn to pick up the small hints on what would be right thing to do, as you both are equally responsible for your mutual success.

We may think of the driver as an intelligent input device. Intelligence means that while the driver takes orders on what to do and where to go, the driver can also guide to get on the right abstraction level or improvise within the box the navigator gives her.

The navigator is responsible for mining the to-do list and passing the next things to do with instructions on the highest possible abstraction level.

This all builds on trust. The navigator may be just one step ahead of you, and thus unable to give you a clear overview of what you're about to do. The direction the navigator is going to is where the driver goes. When the driver has an idea, the roles can be switched keeping the basic rule in mind: for an idea to get on the computer, it must go through someone else's hands.

Next post up: Things to do as the Driver. 

Away from Fear: Kindness-driven dialogue-oriented testing community

I don't want to be afraid. And even more, I don't want people around me being afraid. Fear is all too common in the world of testing I live in. Fear of dismissal. Fear of bullying. Fear of being put to one's place. Fear of not being right with limited experiences.

I've stayed off some agile stages with the fear of being put to my place about my views on automation.  I've built specific styles of presenting experiences to feel safe with the context-driven testing thought leaders. But the fear goes outside stages. It's fed on social media.

Let me give you a specific example. Last week, I saw this tweet.

Take Your Career to New Heights with ISTQB Certification - http://t.co/Fk30a6lnCH

— SoftwareTestingClub (@testingclub) August 6, 2015

It's clearly an ad. Ad amongst all the other tool adds I have a tendency of dismissing. I dismissed this one too. Until a reply got into my tweet stream. I started looking at it more. I saw comments like "Hacked?" and "You must be kidding, right?". I continued looking into STC discussion forums and found more examples unkind approaches.

It's amazing how many people start a conversation with me as I identify as a context-driven tester by apologising that they have an ISTQB certificate because they have been trained to believe they don't "belong" if they admit to having it. Liking it is even worse. I too format my two ISTQB certificates as "I have them but find them useless". I would perhaps offer my views on its usefulness, but it hardly defines the person I'm talking with.

To feel you belong in context-driven testing community, there's more no-no's than ISTQB. There's test cases. There's vocabulary that calls automated tests checks. These are strong beliefs, that I too hold, but that I wouldn't want to get in the way of collaboration and communication.

Context-driven testing with its rules of what is appropriate is a cause of fear. I've started to observe this fear in myself. It manifests in me second-guessing things I said without a proper reference (everything could have a reference, there's hardly anything original in this world). It makes me overreact to facial expressions of certain experts during my talks when they are in the audience. I'm afraid, clearly.

I see the same fear in others as almost compulsive-obsessive mentioning of the key names like a mantra, so that their talks are really about other people and their own great messages get diluted.

Recently, I've heard the same fear cited as a reason for stopping great people from getting up on that stage in the first place. This one makes me particularly sad.

Kindness is the key

On a day I was particularly frustrated with agilists telling me that my tester job should not exist anymore, I posted my new guideline on twitter.

We don't have to agree. But we have to take the other as a person that deserves to be treated kindly, regardless of our differences of opinion. Telling me personally I should go away from software isn't kind. The discussion could be about unlabeling what I do and finding out if there's still value with a specific mix of things I contribute.

Dialogue culture

Context-driven testing builds on the notion of "debate" and scientific principles. Without kindness, debates turn into argument and not actual dialogue. Peter Senge in his book 5th Discipline distinguishes between dialogue and discussion. The first aims at mutual learning. The latter is about finding the best viewpoint in a group and enforcing that on all participants. Dialogue requires suspending own views in search of the truth, and listening deeply to each other.

Let me give you an example of what makes our debates discussions and arguments. People I respect come out of those discussions with a message that they "don't belong to the context-driven community", and are blocked from participating in discussion forums identified as context-driven. There's an impression that people recite in conferences that context-driven testing is an elitist circle that controls opinions of it's members and is quick to kick you out, should you disagree. The context-driven school has become a label of bad behaviour some of us need to avoid.

I've been reading a book 'Argument Culture' by Deborah Tannen. The key takeaway for me from it is that I do not want to be in war against the people who have opposing views. I want to have a constructive dialogue. We can agree to disagree, and still treat one another with kindness. We should encourage people having differences of opinion, instead of telling which opinions are not good enough. Argument has an implied meaning of one being right and the other being wrong, and only a mild undercurrent of changing one's mind if the opponent comes up with good enough arguments.

People shouldn't have to keep their experiences to themselves for the fear of having a disagreement. We should be kinder in our disagreements and treat people with respect.

I'm still a context-driven tester. I look at the practicalities of where I am, and adopt my testing to it. Saying ISTQB has been good in some contexts I've been in does not make me any less of context-driven. I've chosen that label, it has not been assigned to me. So, the CDT leaders cannot take it away from me. Right now I'm thinking that label has more bad than good, but I will let that thought build up some more before deciding on taking action.

I belong to the kindness-driven dialogue-oriented testing community. If that is different from context-driven, let it be.

It's not a women's shirt if you just call it women's

Up until a year ago, I would not have written this post. I had been to dozens of conferences handing out t-shirts, and used them as cleaning rags or passed them on to my friends and family. I thought I did not care for t-shirts.

Then I lost weight. And I started to like my body. And I started to like t-shirts that look good on my body. Started to realise that there were t-shirts that would have looked good on my body also without the weight loss. There's such a thing as women's model.

Because I care, I made a new friend through twitter, who cares too. And a few more who are like me before, taking the shirts home to clean up the house with them.

Men's shirt in my bag=bad way to start a conference. Had to tweet it. Must be fixed next year. #agile2015 #agile2016 pic.twitter.com/5uV91EyoZK

— April K. Mills (@engineforchange) August 3, 2015

April was unlucky to arrive just before the conference started, so she got a men's shirt. The word was there were women's shirts, they were just out. But really, there weren't.

I met April over lunch and we compared my "women's" and her "men's" shirt. Can you spot the difference?

There's three distinctive differences.
1. The size is a little smaller
2. The sleeve cut is a bit different
3. The label in the neckline says which one it is

But really, the women's shirt isn't women's. It's branded as women's, but it's not fitted for the female body. There is a difference. Look at this example for an Agile open space conference that gets it.

If you think the branding makes it a women's shirt, you could consider going back to your feelings after watching the fun scene of Joe from Friends with his new bag.

YouTube is great for other purposes too. Like finding out how to tune your t-shirt with just scissors available to be a feminine one. There's a lot of different styles, but I settled for the one that fixed the main problem: female shirts are fitted, not straight around the waist. Cut out the pieces from sides, conveniently modeling on another conference t-shirt from someone who gets it.

Agile 2015 conference was kind enough to give two women's by label shirts, so I cut the other one to become the string to put my craftwork back together. And here's a picture of me with the finished shirt.

It lived just one use, as I was not careful with my scissors, cutting too close to seams. So if sponsors in the back would have hoped for visibility, my solution was a short-lived one. Giving me a female fitted shirt would have worked. I hope it will next year. In agile, a year for iteration is a long time, so crafting is a great option of shortening the cycle. Conferences should stop wasting the $5 on shirts without creating value, and give women cool agile conference shirts we can wear. 

Power and Delusion of Stories

Thinking back to Agile Coach Camp USA and things I picked up there, there is a story that stuck with me. I want to share that with you, and discuss a bit about ethical questions I keep pondering with.

Mob Programming is a Game 7-year old wants to play

In a session about Mob Programming, Woody Zuill and Aaron Griffith from the original Hunter Mob, were sharing a story about a 7-year old girl. In one of the conferences or training sessions about two years ago, Aaron's daughter was around. As for mobbing in general with the inclusive principle, the girl was invited to join. She refused.

As the mob programming started on a doing a kata, the girl watched the adults programming. And after a few rounds of rotation, she voiced out that she would after all want to join.

She aced it, without any programming experience. She was navigating in her turn, following the "rules of the game" she had picked up watching, being very oriented to the TDD-process where you draw on board to describe intent, write the English as comments and then turn that to code.

She thought this all was a fun game she wanted to join as soon as she saw that.

I picture would be more powerful than words, and I was shown one from a mobile phone. The little girl amongst all the adult men, looking comfortable was moving to an extent that I will share this story on to illustrate why I've grown so fond of mob programming. I asked for the picture to share it with you.

* facts to check: was she 7? Or is my memory failing me on the story :)

On Ethics of Making Up Stories that Are Memorable

I feel quite confident saying the story of the little girl is true. I heard it from people I respect, and from more than one person. One of those people was the girl's father. And there was a picture. Stories are powerful, they appeal to emotions and make the message more memorable.

I remember a particular story from EuroSTAR over a decade ago. The story back then was by James Whittaker. That story was not backed up by evidence. And I did not question the reality of that story until recently.

In a conference this spring, I listened to a great presentation that shared stories. Memorable stories that were well told. As we were discussing the stories in afterparty, I was telling the stories on. And the presenter pointed out that the stories were not real to the facts. The message of the story was true and real experience. But the events themselves were exaggerated to portray the main character of the story in more positive light to create empathy. And that while some of the things had happened, they had happened in a completely different context and were just all put together in the context of this story.

I realised then that this is how some of our software industry folklore is born. People tell stories that are made up and catchy, and they live on. All of this is fine, if we know this is how the game goes. I did not know. I thought the rule is that when you get up on a conference stage and tell a story about a personal experience, that story should be your perspective of the truth. Not a creation of imagination to illustrate your point.

There's a story I've told many times to illustrate the point of exploratory testing.
A few years back, my sister went to driving school to get her drivers licence, at an adult age. She wasn't really paying attention in theory lessons as it seemed irrelevant. When the time of her first driving lesson came, the teacher went through all the individual pieces of how to operate the car in a parking lot. To her surprise, after a moment of looking into that at the parking lot, the teacher told my sister to drive out of the lot, amongst traffic.
She came home, in panic and excitement. She just drove amongst traffic! But she needed help from our brother so that he would show her around the individual pieces and remind her which one was clutch. She could remember only two things from the lesson: the traffic experience and that the teacher was kind of hot.
In Finland, when you get your driver's licence, it's considered permission to practice amongst traffic. The new driver will still have just the individual tricks in her sleeve, and things like change of gear and turning the wheel at the same time are impossible. But as you practice, the individual things become second nature, and you don't even realise what you did to operate the car on a scenic route and can focus on experiencing the world around you or within your head.
Exploratory testing is the same. You can and need to learn the individual controls. But there's so many layers to learn, that after 20 years of testing, I'm still an enthusiastic student becoming better at operation and observation.  New people can't handle all the layers at first. But every day at work is a learning experience that makes us better. Fluency grows over time.

So not hot, unattractive. I got my facts wrong. Should I not have told that story because it was untrue in a fact? It's more powerful with the positive memory of the teacher than with the negative. I felt like I wanted to apologise everyone I've mislead and I'm puzzled on how I will tell this story tomorrow with my talk on Agile 2015.

To me, learning that stories are fake was a big deal. I no longer trust people on stage, I do more fact checking. I'm more careful telling on stories and more focused on what their potentially made up stories trigger in my own experiences and memories.

I can't help but wonder: was I really the only one this naive? Do we go to tech conference to learn things that will stick with us and change us to help us react to things for future, or to learn about authentic past?

On being and becoming a speaker at conferences

People and conversations drive the themes I think about, and this weekend people at Agile Coach Camp USA drove my thoughts to being and becoming a speaker at conferences.

This is my year of international conferences, and during this year a goal that I've working towards has become clear to me: I want to do what it takes to deliver keynotes at relevant international testing conferences. So I'm always on a bit of a lookout for ideas and tips on that process.

For the track of keynoting, I learned one relevant piece of information. I talked to a lady who is also doing her first keynotes this year. We talked and saw similarity in where we are: I too do a few keynotes, but there's higher-status conferences to work towards to still. She gave me a datapoint on something I suspected based on earlier discussions: to  become a keynote, you need to put yourself out there. Volunteer, make yourself available, help the organisers know you. Don't just wait for them to find you.

Most of the points that I picked up today are about working up your way to the speakers track. I wanted to share a few points on that which really resonated with me.

So, you want to be a speaker. What should you do?

Do local talks and get a video of what you do
Practice speaking. Best practice for speaking is speaking. Deliver the same talk. Deliver different talks. Invite feedback from your smaller audiences to help  you grow. When you're ready for bigger arenas, make sure to get a video of your signature talk - the best of what you are and do. The big conferences look for great speakers with great stories, but they cannot know you. You need to show who you are in addition to writing a great abstract.

Do lightning talks. 
Agile 2015 (and Agile Testing Days 2015) takes submissions for lightning talks, but there's often room for emergent talks. Just go talk to the track chair and see if you could squeeze in your five minutes. Share something you are excited about and listen to the feedback. Build from there.

Prepare to be rejected
When you suggest your talk, there will be rejections. Your relevant title does not guarantee a speaking spot in the big competed conferences. Nor does a good solid proposal. Sometimes what you had is just not right for that time. But if you submit to many places, there's a variety of needs.

Find a unique angle to present on
Conferences often get a bunch of talk suggestion on the most popular topics. For you to stand out in the crowd, choose something that is relevant but not the clearest mainstream. Work with your niche. What makes you unique to learn from? Do a few different suggestions if you are comfortable with very different topics. My advise as conference organiser and regular reviewer is though to submit at most three and to make sure the three are not the same message in different packages. That just lowers the odds of being selected.

Write a blog and let smaller conferences find you
Keep yourself visible by blogging, and write about stuff you are passionate about. Some people had experiences on being invited to talk on user groups and conferences based on interesting stuff they were sharing in their blogs.

Get help in reviewing your abstracts
Ask your friends to read your abstract and tell you what your message is. Improve so that they get the right message. Iterate to a next friend.
Also, find one of the services that help you find a mentor for getting your abstract in shape. If you are new to speaking and in the area of testing, go for Speak Easy. The mentors there are free and brilliant. And I am one of them.

When accepted, ask why
On your track of becoming a regular speaker, you will get accepted. When that happens, contact the organisers and ask why. That is a powerful way of learning for future. The answers on acceptance are more direct and honest than ones on rejections.

The three stages of being a speaker

Speaking has been my route to learn so much. I still feel that while I teach and share, I do all of this to learn, to find my community and peers. My inspiration and power to deliver great results at work is in my peers - people with interests similar enough to engage in interesting conversations that energise me.

The advise above is particularly good is you are new to speaking for the audiences you are targeting. I find that there are (at least) three stages on the speaker track.

Stage 1: Being a speaker
You've tried it. You've deliver talk. You are a speaker. Your audience may vary. Your audience may be limited. But you are doing it.

I feel I stayed in this stage for years. I delivered my first public talk in local conference in 2001. Since then, I've delivered probably about a hundred talks (or more). I talked in conferences in Finland, and in companies around Finland. My first international conference was 2005, EuroSTAR. First ever I submitted to, and first ever I got accepted for. So my personal experience is not to prepare for rejections. I've had only a few rejections, mostly because I have not submitted. I've waited to be invited.

Stage 2: Being a speaker growing your influence
You deliver talks and enough people know you so that you get accepted more easily. You do track talks mostly. Deliver consistently. Your have found the audiences that know you just enough to prefer you.

I feel this is the stage I'm in now. I submitted more talks in the last year than I have done in my previous career. And I got accepted to all but one I submitted to, EuroSTAR 2014. For most conferences I submitted to, I would give two-three options, knowing that there's usually perspectives to complement the program to a balanced whole.

Stage 3: Being a default speaker
You are the person often invited. So often you get to look at your calendar and say you cannot be there since someone else booked you first. You're one of the names that come up when thinking of keynotes.

This is where I want to be. But I'm not in a rush. I thoroughly enjoy speaking and meeting people through speaking. To get here, I feel I should write a book. So, better get to writing the book in process: a paired book on pair programming. I'll practice with that.