Tuesday, February 27, 2018

European Testing Conference 2018 - Coming Home

Last week I had the honor to join European Testing Conference as a speaker. It was my first time attending this conference, but it made me feel like I'm coming home. Here's why.

Arriving at Amsterdam

My travels went smoothly, but got even smoother after I arrived at Amsterdam airport.
It was an awesome experience to get greeted this way by Llewellyn FalcoSimon SchrijverMaaret Pyhäjärvi and her sister. I instantly felt welcome.

After a short rest at the hotel I enjoyed the second highlight of the day: meeting my learning partner Toyer Mamoojee again in real life! Although we talk every two weeks, we had so many things to tell each other in person. And we also had a final task to do: a last rehearsal of the talk we were going to give the next day. Our chance to practice it for the first time face to face! Well, all our virtual sessions before paid out. Once again we learned how well we got to know each other since we first met at Agile Testing Days 2016.

Time for the speakers' dinner! I learned to love this part of being a speaker at a conference. The evening when we all meet each other before the conference starts is an awesome opportunity to get to know some old and new friendly faces, exchange experiences, and calm each other's nerves.

Conference Day 1: Telling Our Story on Stage

Although our talk was scheduled for the first conference morning, the first day started surprisingly calm. I slept well, nervousness regarding my upcoming talk was not kicking in already. When asking Toyer about it, he confirmed it was the same for him. This might be due to the fact that either of us had already gathered some speaking experience, or that we knew we will have the other one right beside us on stage; or maybe a combination of both. After arriving at the venue we made sure our room was prepared and our technical setup working. Now we were ready for the conference to start!

Franziska Sauerwein kicked it off. Being a developer herself, she made it clear that this is a conference about testing, explicitly inviting testers and developers side by side (as well as anyone else interested in testing). I'm really intrigued by this idea! Collaboration for the win. Another great point made: European Testing Conference was started to change the world of conferences, for attendees and for speakers; and that proved just about right.
After the opening, we all enjoyed Gojko Adzic's great keynote "Painless Visual Testing". An exciting story of an experiment that could have failed or succeeded - and turned out to become an even greater success than dreamed of. Make sure to check out his open sourced tool Appraise! Right after the opening keynote Toyer and I headed towards our room - it was about showtime for our talk "Finding a Learning Partner in the Testing Community". At first only a few people trickled in, but then more and more found their way to our room. Half of them were awesome people we already met and admired, and half of them awesome people we still would love to get to know. And what can I say? We finally shared our story how we found each other as learning partners - on stage! It was simply amazing. According to the feedback we received afterwards we managed to inspire a lot of people, just as we intended. In case you missed our talk but would like to learn more, here are our slides, here's our InfoQ Q&A about the talk, and if you happen to organize a conference yourself we offer to share our story again on stage! ;-) Finally, some impressions on our talk. Right after our talk we rushed to the next great session: a speed meet! As Llewellyn put it, getting 200 geeks to talk is an achievement in itself ;) This format is an awesome icebreaker and fit really well to Toyer's and my talk before. We all were asked to create a personal mind map with three branches: about our person, about our work, and about what happened last year. This was a great conversation starter for the limited time we had to get to know the other person in front of us. My personal highlight: This way I could finally speak to Gojko himself, who had joined our talk before so that we instantly had a great topic to talk about! He also loved the fact that I studied sinology, as "inspiration can be found anywhere". I absolutely agree. Afterwards: lunch break! Time to finally get to know João Proença better. He is part of the other pact group together with Christian Baumann and Sonja Nešić which emerged at Agile Testing Days 2017, inspired by Toyer's and my learning partnership. What a great new connection! Throughout the conference we had really interesting conversations and I learned we have a lot to learn from each other. In the afternoon I joined Amber Race's workshop "Exploring Your APIs with Postman". She did a great job at making people aware of what to look out for when testing APIs as well as in demonstrating Postman, a really valuable REST client with many useful features (if you now read about this tool for the first time, make sure to check it out). It seems many people really were not aware of how easily they could get started with testing APIs. Although I already knew a lot of what Amber shared, I still could note a few points to implement at work. The only sad thing for me was that the hands-on time during the workshop was very limited. I would have wished for more time actually practicing exploring an API within our group.

Well, it also had it's good sides. From the past conferences I've spoken at I learned that at the day that I have my talk, I will have a down phase where I will be unable to concentrate anymore and get distracted by the feedback on the talk coming in on Twitter. This time, this phase started in the workshop and unfortunately continued during Emily Bache's talk about "Testing Microservices". From what I saw and heard it was a great talk, and I would have loved to learn more about Emily's experience; but I just could not pay the attention it deserved.

Next up: lean coffee! I love this agenda-less format where participants can bring their own topics and challenges into the discussion. We speakers were asked to facilitate, and I happily focused on just that. After yet another break with snacks and great conversations (I love how this conference provides multiple opportunities for people to get to know each other and exchange experience!), it was time for the last keynote for the day. Lanette Creamer did a fabulous job, telling us how to "Test Like a Cat"; a very enlightening presentation with many invaluable reminders for us testers. Just afterwards I learned it was her very first keynote! She really should get invited by more conferences. Was that the end of conference day one? Not yet, as it ended by something I've never seen at a conference so far. And as I've seen it now, I wonder how any modern conference can do without. They scheduled a retrospective so that organizers can get instant feedback from everyone and see where they can immediately adapt. And they did solve what they could! Unbelievably awesome! After shortly returning to the hotel, many people still made it to the restaurant where everybody could follow-up on the day together, enjoy nice food and a free drink.

Conference Day 2: Too Good To Call It a Night

The second day started with yet another powerful keynote, this time by Zeger Van Hese: "The Power of Doubt - Becoming a Software Skeptic". I've enjoyed this talk already online, streamed by another conference, but it was just as good seeing it again. If you have the chance, check it out yourself!
After the keynote, it was workshop time again! This morning I decided to join Seb Rose and Gáspár Nagy on "Writing Better BDD Scenarios", as this is a topic I read a lot about but really lack practice. I was delighted that this workshop was really hands-on, triggering lots of discussions around how to best formulate scenarios to benefit from easily understandable documentation as well as maintainable automation.

After yet another lunch with plenty of healthy but really tasty food, I enjoyed one of my personal highlights of the conference: Alex Schladebeck with "Exploratory Testing in Action". And when Alex says in action, she means in action. She lived up to what she promised and tested live on stage, simultaneously talking about her own testing and then debriefing it together with the audience. For all live testing she only prepared the system under test and two charters, without practicing anything upfront. And she absolutely rocked it! Awesome concept, message, and delivery. I'm in awe of the courage she showed, demonstrating the whole room what testing is and how to talk about it while being authentic, highly entertaining, and knowledgeable. I guess the only thing to top this would be to have the audience select the system under test and charters live. Alex, in case you read this: challenge accepted? ;-) Next up I joined Mirjana Kolarov sharing her experiences about "Monitoring in Production". As my team is on our way improving our monitoring I could really relate to the talk and also gain some great tips. The rest of the afternoon was preserved for a longer open space. Participants brought forward lots of awesome topics, so it was hard to choose which ones to attend. I first joined an experience exchange on mind maps where I learned how other testers use them in many different ways to help testing. Afterwards I could contribute to the question on how to identify a good tester in an interview; a discussion which draw so much interest that it inofficially continued for yet another slot. Astronomer Pamela Gay got the honor of the closing keynote for the conference: "Testing v. Crowdsourced Data, or How I learned to stop worrying and Love the F-Bomb". What a wonderful, inspiring keynote about difficulties at a level that probably not many others are facing. You know, rocks are hard - literally and figuratively. Identifying craters on the moon so that spacecrafts could land safely is a very tricky problem for both computers and human professionals; but (lots of) humans prove to be good in solving it after all. You never heard of Pamela? Now you have, and you should remember her. Wanna help her map the moon? At the very end of the conference, you might have guessed it, there was yet another retrospective! This time using the input of the audience to craft a mind map to help planning for next year. One of the positive things people mentioned: Throughout the conference we enjoyed the notes of brilliant new sketchnote artist Marianne Duijst! Check out her collection of sketchnotes done by her and others during the conference, they are absolutely worth it. So, was the conference now really over? Officially yes, but inofficially it was still continuing! Many of us could not let go yet and rejoined at a nearby restaurant. And even after a great dinner we could not yet let it go and gathered in the hotel lobby for a few more drinks with absolutely awesome people. Although completely tired, having those invaluable deep conversations even after the conference officially ended, made me feel at home even more.

Saying Goodbye for 2018

The next day I finally and really had to return home. Tired, happy, full of inspiration, new friendships made, existing ones strengthened, keeping the conference spirit in my heart.

Last but not least I'd like to thank the wonderful organizing team Maaret Pyhäjärvi, Franziska SauerweinLlewellyn Falco, Peter, Alina IonescuJulia DuránSimon Schrijver, as well as all volunteers helping European Testing Conference. You indeed do change the world of conferences - for both speakers and attendees. Many thanks for all your support and service, inspection and adaption, and most of all for providing the opportunity for everyone at the conference to learn from each other, together, with joy. THANK YOU.

I've never attended this conference before, but yet it felt like coming home. It had a kind of magic. The schedule was well balanced, the content awesome, the mixture of session types perfect, the speakers well taken care of. The people were amazingly inspiring and given the chance to have deep conversations with each other. I learned that European Testing Conference is all about the people. And these people are home.

Thursday, February 15, 2018

About Conference Moberators and Beneficial Mobs

Only two more months to go until I'm going to be in Boston for the Mob Programming Conference 2018. It'll be my first one and I'm already looking forward to it as it's all about learning from each other.
I'm honored to host two mob sessions myself there: "Learning to Learn in a Mob" and "Mobservations: The Power of Observation in a Mob". What's especially awesome about this is that this makes me one of their so-called "moberators"!
But the very best thing about this conference opportunity are the people, the community behind. A few weeks ago, one of the other moberators, Ethan Strominger, reached out to me. He wanted to find out which impact mob programming has had on our team, as well as what I see as top three to ten benefits of mob programming. This got me thinking. Today I'd like to share my answer with you.

To give you some context, my current product team tried the mob approach last year in April for the first time. I blogged about it and also about our further experiences with mobbing. Ever since my team tried it for the first time, we started to mob quite frequently. The number of our sessions even increased over the last months. We don’t mob on everything, but on selected topics or spontaneously on demand, but mostly on real stories. Interestingly, my team was quite hesitant to give pair programming a try before we found the mob approach; and now we pair quite a lot as well. We also still work solo on things, but collaboration dynamics definitely changed. I also made some experiences with mobbing at meetups or conferences, or when facilitating it for our company’s testing community, but the biggest part of my experience is actually coming from my own product team.

Now here’s what I see as biggest benefits of mobbing. The list is most probably not complete, but represents what came to my mind.
  • We found mobbing is perfect for learning (for instance when integrating new technologies into our product) and spreading knowledge. Examples:
    • Our development team consists of full-stack developers and me as a tester. We once also had a DevOps specialist helping us solving all infrastructure-related topics. This was quite convenient, but it created a knowledge silo. As he was working for three teams he quickly turned out to be a bottleneck. Furthermore, in the end he left the company. We did not want to repeat this mistake, so we used the mob format to learn everything from scratch and instantly spread the knowledge in the team.
    • As I am the tester on the team, the mob is a perfect place to share testing knowledge with my developers. This is especially useful when I am not around, as the team takes over for me during those times. But they also support when I'm available, so testing is no bottleneck anymore.
    • The mob makes implicit knowledge obvious and triggers us to share it, thus often increasing everybody’s efficiency in everyday work. Could be as easy as learning about IDE shortcuts, how to increase cursor speed, or how to quickly create test data.
  • The mob helps to solve tricky problems as we have all brains focused on them. I absolutely agree with the statement that you don’t get the most out of everybody, but their best. It’s about quality. Also, a mob can trigger way more ideas how to solve a problem or how to most conveniently or cleanly implement a solution.
  • The mob provides a perfect environment for seniors to do what is in my opinion their biggest task: to increase the seniority of everyone else. The seniors learn how to express their thoughts and intention as easily comprehensibly as possible, and the more junior ones can practice hands-on how to do things, by actually doing them. Invaluable.
  • Everybody is instantly informed about everything. Decisions are made together in time; there’s no need for further feedback loops, follow-up tasks, asynchronous reviews, etc. Therefore it’s also a great format for any other activities. We already used it for writing a job offer, reviewing incoming applications, or designing a presentation for business.
  • Last but not least: My team grew a lot closer together due to mobbing. We learned how to communicate within the team better, to have synchronized coffee breaks together, in general get to know each other better. The trust level in the team was already high before, but it had heavily increased and we all know we have each other’s back.
That said, I'm really looking forward to meeting Åsa, Ethan, all other moberators, as well as the conference attendees. I really want to learn about other people's experiences and discover what they see as biggest benefits of the mob approach.

Sunday, February 11, 2018

Bad Talk, Take Two: George's Story

As announced in my post about How to Respond to Bad Talk in a Good Way, I am honored to host the voices of some of those who joined our discussion back at Agile Testing Days 2017.

Today I'd like to share with you the thoughts and experiences of George Dinwiddie, written by himself, in his own words.
I often struggle with what to say when friends say things I now consider inappropriate, or at least inappropriate to the circumstances. Society has changed over time, and not everyone is socialized at the same rate into new understandings. Many things that were once considered normal things are now out of bounds by today’s standards. Or, at least, by some people’s standards today. It’s obvious that not everyone has the same standards.
When I was growing up, the rules I saw in use in the society around me were quite different from what I try to follow today. When I watch an old movie from the early 1960s, I often cringe at lines or situations that didn’t bother me then. Every now and then I catch myself in mid-joke, realizing that the punchline hinges on assumptions that I now find unacceptable, and awkwardly stop in embarrassment. These are not jokes I made up. They’re jokes that I heard as a child that lie dormant in my subconscious memory to pop out in surprise. If I still have remnants of these attitudes in me, how can I condemn someone for speaking them in my presence?
Yet I must say something. I must say something to remind myself of the changes I have chosen over the decades. I must say something to help my friend choose such changes too, or to help them notice a lapse in a choice they’ve made. And I want to do so in a gentle way, so as to remain friends and be most helpful. Surely over the long run I can have more influence on my friends than on my former friends.
And if I say something inappropriate, I would hope my friends would do the same for me. I suspect that, given the socialization I received as a child, I will never reach the level of behavior to which I aspire. I do, however, wish to continue to improve the best that I can.
—George Dinwiddie
Thank you, George, for sharing your thoughts with us.

Wednesday, January 31, 2018

Testing Tour Stop #2: Pair Automating with Thiago

My testing tour had started out this year by pair exploring with Maaret Pyhäjärvi. After taking time to reflect, I moved on to my next stop as a testing traveler. Today the tour led me to pair with my colleague Thiago Amanajás on test automation. I was really looking forward to this session, as I've planned to initiate cross-team pair testing within our company's testing community for quite some time now, but never found the right moment to get it started. My testing tour experiment felt like a perfect fit to make it finally happen!

Diving Into Automation

Thiago is currently working on an automation project to cover the most critical scenarios through the UI of his team's web application. We both agreed to pair on this topic as he wanted to get some feedback and input from a different perspective, and I wanted to improve my automation knowledge and skills.

We planned to have a session of 90 minutes, being collocated in the same small meeting room, having one laptop and one further screen in front of us. Thiago started out with an introduction to their product and the current status of the automation project. He showed and explain the tools used, problems encountered, scenarios covered so far. I used the time to ask questions and compare the situation with what I've experienced in my current product team to gain a better understanding of what there is to build on.

Having set the stage, we wanted to extend the project by another scenario. We chose a feature which was easy to understand but also introduced a new complexity: checking that the mobile website for Android displays a certain banner on the first visit, but not anymore for the next page visits due to a stored cookie. Using Selenium for browser automation, this meant we needed to introduce an Android driver.

Being highly focused on the task at hand, we noticed a bit too late that we already breached our timebox of 90 minutes. As we were eager to find a solution for the current problem we faced, we agreed to go for full 120 minutes, wrapping it up with a short retrospective.

Either Learning or Contributing

One of the principles I really like about mob programming, or any activity done in a mob, is that you should be either learning or contributing. If one of both is true, the mob is valuable. From my point of view, the same proves to be true for pairing. In this session, I learned some interesting things.
  • I finally saw testNG running in action and learned quite a bit about this testing framework in combination with Selenium.
  • The problems around test automation Thiago solved or still encounters were quite familiar, comparing them to those my product team faced when implementing automated checks through the UI. How to integrate them in a build pipeline or build a pipeline for them? How to structure the test runners and which parameters to let the user provide when running the tests manually? How to work around authentication via single sign-on? Which test data and database to use? How to collaborate on test automation together with the developers and raise testability issues? How to select web elements in case we don't have IDs available?
  • The Chrome extension Katalon Automation Recorder was completely new to me, but proved to be a really interesting tool to quickly discover how to select elements best. It's a bit like Selenium IDE for Chrome, but its best feature is that after recording you can export the result in e.g. Java and make use of the snippet without many adaptions!
  • Another plugin I did not know of yet and came in quite handy was the User-Agent Switcher for Chrome. It does not only allow you to switch between the predefined user agents, but also let's you define your custom ones to test against.
Furthermore, I was happy to not only learn but also contribute myself to the progress of the automation project, as well as share the one or other tip.
  • Speed up commenting of code blocks by using the related IDE shortcut instead of manually doing it (one of my favorite shortcuts!).
  • Googling is a skill we use every day. Improve your searches by not only getting better at finding good search terms, but also by getting aware of other search options. For example you can exclude certain terms (like "appium") by just adding a minus right before it ("-appium").
Just before the end of our session we both discovered Selendroid, a Selenium-based test automation framework for Android. I'm curious to learn more about it!

Observations & Reflections

What else did we learn? First of all, that the session was both fun and really valuable to both of us. We both appreciated the constant feedback from the other, keeping us on track what's still to do as well as giving guidance what to do next. Four eyes simply see more, and two brains trigger more ideas. At no point we had a problem where we could not agree where to go next, or even got stuck. There was always one of us who came up with the next step.

Having two persons sitting together in front of the problem also created the opportunity to discuss different approaches, find good names together, or think about how to best structure the project. We were glad to finally have someone to share our thoughts with and get them challenged! As Thiago said: "it made him think". I can't express it better.

Our collaboration went really smoothly, even though none of us addressed the topic of how to pair. Shall we have one of us stay at the keyboard? Or switch roles? And which approach would we use, traditional or strong-style pairing? When reflecting, we learned from each other that we both thought of the topic at the beginning of the session, but didn't address it with the intention of seeing where it would lead us. Thiago started out with the keyboard in front of him, and he even tried to move it towards me once, but I didn't realize his intention at all. Meanwhile I made up my mind and decided to try out that we both navigate but he stayed at the keyboard. And interestingly, it worked really well. Still, some experiments cannot be run twice with the same conditions, so I cannot tell how it would have been in case I would have either asked him upfront to pair strong-style, or requested the keyboard during the session. We both agreed that it would be interesting to see our dynamics in case I would get the keyboard, or if we even place two keyboards in front of us. In any case we would both love to do further pair testing sessions and experiment with different collaboration styles, while constantly improving the automation project and thus providing additional value to our company.

My thanks go to Thiago for becoming part of my testing tour, sharing his knowledge with me and the great collaboration. I'm already looking forward to our next sessions, curious what we might learn then!

Friday, January 26, 2018

How to Respond to Bad Talk in a Good Way

In 2016, Agile Testing Days hosted a "Women in Agile" event which had opened my quite naive eyes. It made me realize two things: first, that the women in tech problem is not yet solved; and second, how privileged I truly am.

As shared in my post about Agile Testing Days 2017, the conference offered a “Women and Allies Evening Gathering” this time. Following up on my experiences from the previous year I was eager to attend it; and didn't regret it. I took lots of food for thought home with me.

What I really liked about the 2017 event in general was the following.
  • The event’s title did not only invite women (which often feels kind of exclusive to me), but welcomed any allies at the same time.
  • Just before the gathering, we listened to the late night keynote by Ash Coleman and Keith Klain addressing the topic that “Culture Is More Than A Mindset”. It was perfect to get attuned to talk about gender, diversity and inclusion topics.
  • A huge group of diverse people joined the event and contributed, so we could hear many perspectives.
My highlight of the evening was a very personal group discussion of our challenges with great people in a safe environment. Unfortunately we could only tackle one topic due to lack of time, but this one turned out to be invaluable for me.

When we were asked to pitch the topics we wanted to talk about in front of the whole group, I decided to take a leap and share one of my huge and very personal challenges:
"How can I grow into a person that acts when they notice a behavior that is not cool, and also has the courage to do so. I often don't have the courage right now, but I don't want to be this person anymore in the future."
Two other women wanted to discuss a very similar problem: Jose Tegelaar and Kristīne Corbus. Kristīne had proposed two topics. As she saw the bad behavior topic taking care of, she chose to host the other one; so it was up to Jose and me to facilitate the group discussion.

Well now, how to respond to bad talk in a good way? The following people joined our discussion and shared their experiences. Thank you all for a lively discussion, sound advice, great ideas, and especially for making it very safe for everyone to talk openly!
We shared personal experiences and stories of when we had recognized bad situations in the past. What we tried, what seemed to have worked and what not. Together we brainstormed potentially good ways how to respond when we overhear bad talk or identify inappropriate behavior.
  • Ask why? --> ask for responsibility
  • How to not make this passive aggressive: replace "why?" with "what?"
  • Get out of the situation and talk about it later
  • How to deal with the risk of getting negative feedback
  • Tell them your experience
  • How to walk the line in your responsibility
  • Ask: Would you like to rephrase that in a more neutral / nicer way?
  • Directly refer to common sense
  • Make a request: Please don't refer to our colleague in that way - it bothers me
  • How to take action without "hurting" the subject
  • Keep to your experience: "This bothers me…"
  • Do rude people need a rude response sometimes?
  • "We don't do that here"
  • "It was just a joke"
  • Don't laugh --> let your face speak
  • Say "That was not a good joke." (in a dry tone)
  • Recognize that different people get socialized in different ways, they are not bad people
  • Leave a path to retreat
  • If it bothers you for too long and you don't know what to do, maybe ask the "trusted person" in your company
  • Bring up the topic in another situation by stating your opinion
  • "Let us discuss our working agreement." --> with the group, i.e. during retrospective
At the end, everyone agreed that our next step has to be the following: to talk. To do something. To step up. As simple as that! Well, maybe simple but definitely not easy for everyone. However, we made it a bit easier for us as we now have lots of ideas what to try at hand. And even better: we now have a list of fellow people to exchange our experience and lessons learned with!
Speaking of our group: what do they think about this whole topic? What are their experiences and stories? I’m honored to have their voices featured on my blog in future posts; look out for them to learn more from different perspectives! This topic is not done yet.
On our way back home from Agile Testing Days, I had another conversation with Diane about this topic which made me realize a very important point. Although I often feel like a coward nowadays when it comes to difficult situations, I had been acting way more courageously about two years ago. Our conversation suddenly made me remember a repressed incident with my team back then. I had just recently joined the company but still found the courage to speak up. However, doing so was badly received by another colleague. By triggering me to question my own behavior again, I realized that after this incident, I had become way more cautious again. However, I cannot use this as an excuse not to step up anymore. I must not let myself do so.

It’s time again to speak up in case of bad talk. At least now I know that I am not alone.

Friday, January 19, 2018

A Triple Mob Achievement

If you've followed my blog so far, you know that I'm an ever-growing fan of the mob approach. Today I have three achievements to share, all related to mobbing.

#1 - Getting Invited to Mob Programming Conference 2018

Yes, exactly! Two days before New Year's Eve, Llewellyn Falco contacted me and asked me whether I would be interested and available to be a "moberator" at the Mob Programming Conference in April 12/13 in Boston. This opportunity absolutely intrigued me! Not only that I'm really convinced of this whole-team approach, this was also the first time someone invited me to a conference as a person, without even discussing potential sessions beforehand. I was (and still am) really feeling honored to get considered. So I checked the conference page and saw that the selected guest mentors were really experienced in facilitating mob sessions. In my case, however, it would be my first time doing so outside my company. This made me uncertain whether I would qualify; however, I told Llewellyn I'd love to learn by doing. And what did he do? He instantly referred me to the other organizers Nancy Van Schooenderwoert and Woody Zuill, who officially invited me. After having a first call with them, discussing potential sessions, I finally believed that this was really happening so I made it public myself.
I'm so looking forward to this event and would love to see you there as well!

#2 - Feedback from My Team

Throughout the last months, my team had and still has frequent mobbing sessions. We currently work on a huge topic where this approach is invaluable for us. We have to make sure that everybody is aware of everything and shares the knowledge to avoid bottlenecks in the future. Last week my team had a retrospective. We were talking about things we want to do better in the new year and also brought up the desire to further improve our mobbing sessions. In the course of presenting ideas what we can try, the following discussion came up. I was so happy about the reaction of my developer colleagues that I had to share this with one of my Slack teams, the Women in Testing group, where we have a special #brag_and_appreciate channel to practice bragging in a positive way and to celebrate each other's achievements.
Furthermore, my teammates stated that mobbing might be expensive, but for learning it's the best way they've seen. I cannot agree more.

#3 - Mob Testing Workshop with My Community

Maaret Pyhäjärvi gave a wonderful mob testing tutorial at last year's Agile Testing Days. It really inspired me to try this with my company's testing community as well, in a shortened form focusing on exploratory testing only. Yesterday I finally had the chance to introduce our testers to the mobbing approach.
It was a lot of fun to facilitate this session and I learned a lot again. We had a tester joining from remote, and another one who had to skip the middle part of the workshop, only being able to attend the beginning and the end. Still, we managed to integrate both well without causing too much disruption.

Before yesterday, we testers already worked together on several topics, like recruiting, building a career path, hosting meetups, and so on. But this workshop was the very first time that our testers actually tested an application together. This made it really obvious how different our ways of approaching a task are. As an example, after getting past the initial practice round, we had to spend quite some time to find an intermediate working agreement just on how to document our findings.

You can imagine that I was all the more happy to receive the following feedback from some of the testers attending the workshop.
I'm absolutely looking forward to our next testing sessions together! We can learn so much from each other this way and help each other grow. And last but not least, whenever we face real-life testing challenges concerning our products, we now have a great approach at hand to get the best out of everyone.

If you'd like to learn more about how mobbing can benefit your testing efforts, make sure to check out Maaret's recently published Mob Testing: An Introduction & Experience Report.

Sunday, January 14, 2018

Testing Tour Stop #1: Pair Exploring with Maaret

My testing tour has officially started! Wonder what's a testing tour? Then head over to my post about my personal development challenge for this year first.

For the first stop on my tour I consider myself really lucky and honored that Maaret Pyhäjärvi agreed to pair test with me. I admire her work in the community and was glad to meet her personally at last year's Agile Testing Days, where I could see her testing and critical thinking, coaching and feedback skills in action; to name only a few. With every day of our session coming closer, I grew more nervous about it; even though rationally I knew that this was an awesome opportunity to learn even more from her, and that I have nothing to lose. In hindsight, our session was absolutely worth it as I indeed learned a lot in a short period of time.


The Session

We both wanted to dive deeper on exploratory testing and practice our skills. Maaret proposed to tackle the Freemind version for Mac; according to her it's "buggy as hell and therefore really rewarding for newbies". This makes it a great system under test when teaching about testing (idea noted ;). To reduce the scope of our session we focused on the find & replace feature of the application.

As soon as we started testing, we discovered so many different issues together, it was really hard to keep track. All in all we felt the user experience was really poor and the features rather glued on top of each other without having a consistent vision in mind. We came to that result really fast together; and our findings proved it when we went further. Overall, having two testers explore a feature together produced great results in a short amount of time and thus proved really efficient.

The identified issues were spread all of the place. Some questions we asked ourselves several times:
  • What does this mean? What does this message try to tell us?
  • Why does this feature behave in a completely different way than similar features in comparable applications?
  • Why are things so inconsistent? Why do labels or icons imply different functionality than they actually offer? How come even a simple form shows different spacing between input fields, just a few pixels below each other?
  • Why is this data displayed in this location? It does not have anything to do with the feature. Why not put it in a different place where it might actually provide value?
  • Why would we need this data or feature in the first place?
  • Where is the functionality I am looking for? Why is it so hard to find things and learn this tool?
The funniest issue we found was that we could copy nodes of an older mindmap to a new file and the creation timestamp would not get updated for those nodes, thus showing a timestamp way before the birth of the current mindmap. This made me feel not only as testing traveler but also as time traveler! :D

What I Learned about Testing

Reflecting together on our testing session, we addressed several important topics. Here are my lessons learned about testing.
  • Where's our box? Who says what's in scope and what not? In this session we defined our box fluently on our way, calling each other out in case we started to divert from it. This was totally fine for us, but in the end we would have loved to have an overall picture of our box to see what we intentionally left out and postponed for further sessions.
  • You discover there are too many combinations requiring a lot of time effort? Check if you can automate your test data setup. We didn't go this way in this session, but this was one of the things we could do in a future one.
  • Whatever you document - always chose a notation that lets you quickly identify how many issues, questions, follow-up charters there are and what your feeling about the level of quality is.
  • During the session we talked a lot about different aspects of exploratory testing - without even mentioning the approach itself. Observation as a skill, heuristics, and more. It's quite easy to start with exploring, but it's always experience that brings you further.
  • Last but not least: testing and finding bugs is fun! I really love hands-on testing and close collaboration with people to get the best out of us.

What I Learned about Myself

No matter how I talk about things, I probably will be caught doing things differently than I said. Certain situations might trigger habits I am not aware of. Having someone else observing things was so helpful to point that out.

In this session this fact became obvious when it came to note taking. In the beginning of the session I told Maaret I'm just shortly noting down what we learn. To do so, I had a physical notebook right beside me and scribbled down on it as we proceeded. When reflecting on our session, Maaret asked me whether I had used a certain notation to quickly get a summary from my testing notes. I had not. Which stunned me. When I do testing solo, I always use a digital form for my notes, be it a comment on a ticket, a mind map, or anything; but always including a certain notation to quickly let me know how many issues I found, which questions are still open, what other things I postponed for further sessions, what should be automated, and so on. But this time I totally diverted from it.

So Maaret asked me why I had chosen a physical notebook in the first place this time? The best answer coming to my mind was that maybe I fell into a habit. As I only use a physical notebook in meetings, be them at the same location or online. Like in interview calls. Did I fell into a habit because of the situation I was in? Why did I divert from my normal testing behavior? After reflecting a bit further, my intentions were the following:
  • I told Maaret I was taking notes as I wanted to let her know what I'm currently doing as we couldn't see each other (we turned off video to improve call quality).
  • I wanted to roughly keep track of what we were doing to help our testing.
  • I wanted to have notes of our session to make it easier for me to blog about it later on; as this was part of my experiment.
Maaret pointed out how hard it was for her to not be able to see my notes, or see me changing my focus away from the application in order to take them. She tried to be mindful and not rush ahead and put me under pressure, but it was not an easy thing to do.

What I Learned about Pairing

My most important lesson here was: Be mindful! And keep the focus of both synchronized. The note taking example made that obvious. We could have just taken notes together, in the same moment, seeing the same screen, agreeing on the notes to take and the notation to chose - and everything would have been easy for both of us. The same would apply to draw models, or our box of what's in scope.

Also, we didn't really talk about how to do pairing. We both assumed we would do strong-style pairing, with one being the navigator and one the driver on the keyboard. We both share this knowledge and are used to this approach (probably Maaret more than me, but I made great experience with this style over the past year). However, in future sessions with other testers I have to set the stage first so we have a shared understanding how to pair.

This session was quite interesting with regards to pairing dynamics as the remote access tool to allow switching roles did not work. So we had to stick with our roles for the whole session, with me being the navigator and Maaret the driver, sharing her screen. It would really be interesting to observe our pairing dynamics further when we are able to switch roles, or with her being the only navigator.

What I Learned about This Experiment

It's absolutely worth it. My gut feeling is that I am on the right track here and it will actually help me become a better tester. In any case I'll be wiser than before; or let's say, more experienced.

There are also some things I have to improve. First of all, I have to prepare better for the next sessions. This first time I could rely on Maaret, as she chose the system under test and thought about how to collaborate during the session. Next time I should drive the technical setup myself, especially for the next online session. I really have to get a proper remote access tool allowing us to switch roles. To let the other person chose the topic to pair on, however, turned out to be a good thing; this way serendipity might be on my side and teach me more. I would dive into areas, applications, approaches I might not have chosen myself.

Where to Next?

Maaret gave me great food for thought. And not only that, she agreed to further pair testing sessions with me; a great chance to improve things and learn more from each other!


My next testing tour stops are still to be scheduled, but a few testers from inside and outside my company already agreed to pair with me. I am looking forward to each and every session with them. I'm really curious what I will learn next.