Saturday, September 15, 2018

TestBash Germany 2018 - My First Attempt In Sketchnoting

Why write down again what had already been written down by someone else? Therefore, here's the condensed form what the second edition of TestBash Germany was like. At least, what it was like for me. ;-)

This year I was not speaking but only attending the conference, so I had time to focus on having conversations with great people and enjoying the talks. Too easy? Well, that cries out for an experiment! Or two.

Experiment #1: Sketchnoting

Seeing all the masterpieces online, I also wanted to give sketchnoting a try. I mean, a real try - not giving up the first minutes into the talk when I saw my notes will never ever fit one page only. The evening before the event these thoughts kept buzzing in my head so my brain kept me awake until I finally resolved upon actually sketchnoting at TestBash Germany.

The following two persons inspired me heavily when it comes to sketchnoting: Marianne Duijst with her awesome collection of sketchnotes and constant encouragement to try it; and Ekaterina Budnikov who lately shared great advice how to get started. Now, I always did take notes on conferences before. I wrote everything down in great detail without thinking about it, and later on at home I transferred my messy scribbled notes into a readable and structured digital form. Doing so cost lots of time. As I'm now going to more than one conference per year I wanted to see whether I could reduce that time investment while still having proper notes for later reference.
The result: I really did it! It was quite exhausting, but I learned a bunch.
  • It was good that I brought some pens with me already: black, blue, green and red were the colors of my choice. I used a simple squared notebook.
  • I quickly noticed that the black pen was dry, so I had to switch to blue. At least this is only visible in my first sketchnote. The other colors stayed usable until the end.
  • The different colors were really helpful for additional structure elements, like marking section headers, as well as navigational elements, like linking different areas of the sketchnote. In the end, two colors were sufficient, blue and green.
  • I did not take notes on a separate sheet for adding them later to the sketchnote, but I did take photos of content-heavy slides so I could look up what I missed in case the speaker was faster than me.
  • Most of the time I focused on text, but over time I realized when there was time to add some small images as well. Doing so, I noticed which image vocabulary I already had learned for preparing workshop posters so I could quickly express ideas visually, and which images were not already accessible so I had to think about them, taking more time.
  • Some talks were way easier to sketchnote than others. Surprisingly, there was one talk without slides - but it was one of the easiest to sketchnote due to the storytelling.
  • In the end, I did manage to fit everything on one DIN A5 page for each talk. For some talks that was really, really hard. I did not yet bother how to fill the page's whitespace in a visually nice way when I did not take up all of it. Most times, I had the challenge what to leave out instead, as I tend to write down everything and therefore run out of space. Also, at times I lost some space I would have needed just because I started not on the very top of the page or had some useless gaps in between.
  • My hands got all blue from the main pen, and I happened to blurr some notes. Couldn't help it, so I kept going.
  • I'm so much in awe for those great sketchnoters out there who manage to extract the essence of what they hear in a split second and record it in a visual and informative way. At least, I would say I got better over the day, but judge for yourself.
Most sketchnoters make a photo right after the talk and instantly tweet it. I did not dare to do that, and also felt I lack the time. So I postponed this decision for after the conference, and then got inspired to just give it a try and shared them. The feedback I received was indeed heavily encouraging, I think there's going to be another round of sketchnotes coming! But next time I'll get me some proper pens. ;-)

Experiment #2: Tweeting Continuously

To follow the same theme of reducing my time investment after the conference, I wanted to go through the Twitter stream of the conference's hashtag continuously throughout the day in small pieces, to stay up to date. I decided to do this directly after each talk. I succeeded, however, also missed some great questions and answers by doing so. An accepted trade-off for this experiment. Also, I decided not to live tweet myself as I had tried that already at another conference and it would have clashed with the sketchnoting experiment, but merely retweet great live tweets of other attendees.

The result: Tweeting rather "just in time" was a quick and easy way for me to share content without having to do it in my free time. It was also nice to get instant feedback from those who could not attend the conference, they really appreciated to experience it from afar this way. However, this might only have been feasible because it had been a one track conference with only a few live tweeters, so the amount of tweets I went through after each talk were not too many. I can imagine this might not work out for conferences with multiple tracks and / or more live tweeters. Also, doing this right after each talk meant that I joined the breaks later than others and had less time for socializing in the real world. Another trade-off to consider.

This Was TestBash Germany 2018

Here's the list of talks, linking to the awesome live blog posts from Alex Schladebeck - I can only add my sketchnotes to that! Just like last year, TestBash Germany offered meetups the day before, as well as on the evening right after the conference day. Yet again I really enjoyed these additional opportunities to have great conversations with great people. Unfortunately, however, the open space tomorrow will take place without me this year. All in all, it was once again a great conference. Thanks to everybody!

Wednesday, September 12, 2018

SwanseaCon 2018 - Celebrating One Year of Public Speaking

It's this time of the year again, the SwanseaCon time. What can I say?
This conference is dear to my heart. I am most probably biased here, so I'd like to invite you to come and judge for yourself! I'm biased as this was the first conference that accepted me as speaker. Last year, on 26th September 2017 I gave my very first session on a conference stage. Coming back this year, again as a speaker, feels like closing a circle. Even though it's already more than a year of public speaking, and only nearly a full year of conference speaking, I consider my return to SwanseaCon as a personal anniversary. Biases aside, I overheard several others that they enjoyed the event just as much.

This year the conference took place on one day offering four tracks instead of two days with two tracks. Shorter with more options to chose from can be both better and worse, depending on your personal preferences.
The good thing of a one-day experience is that it's nice and condensed, and afterwards you can celebrate all the learning with all the great people. As a speaker it's nice to relax, too, you simply can't be scheduled for the next day! Still, more tracks mean more options and increased fear of missing out. It was indeed hard to chose the most favorite talk of this year's awesome SwanseaCon program. I love the fact that it was really diverse regarding content and speakers again, just like last year. The audience was quite diverse, too! A nice mixture of local and international community, of many different roles. Lots of women around as well. My personal impression, was a good one and I perceived the atmosphere as very friendly and open.

Now what about the content? The sessions I've joined were very insightful, I learned from each of them.
  • It started with the opening keynote of Hadi Hariri: "Where's My Free Lunch?". He vividly made clear how people in today's society pay for free apps with their privacy and time, becoming more and more indifferent; just because it's so convenient. "Personalized experience" a.k.a. manipulation. It's also convenient to not contrast any presented "fact", validate it, and only then share it; we have our part in producing and spreading fake data. Hadi's conclusion: We're screwed. So what we can do? Raise awareness and think before we act.
  • Next up: Gem Hill with "Anxiety Under Test". Gem talked very openly about her mental health issues and how she learned to live with them. Companies like BBC discovered the benefits of mental health first aid programs, offering trained contact persons for people in need. There are many more places we can reach out to, Gem shared a list of resources in her slide notes. Key is to learn our individual signs of upcoming issues, and find out what helps us mitigate them. Self-care is essential in these cases. What a very hard topic to talk about - and so incredibly important.
  • An interactive workshop! That's a first-timer for SwanseaCon as far as I know, and it was great. Lisa Crispin and Kristine Corbus took us on an experiment of "Questioning requirements: improving quality for everyone". The small room was crammed with interested people! Time flew while all groups tried different approaches to come up with a first release plan for a new product, given only a few ambiguous requirements. It was great fun and we learned a lot!
  • After lunch, it was time for my own talk, "Cross-team pair testing: lessons of a testing traveler", sharing lessons learned on my testing tour.
    The goal of this talk is to inspire people to go on their own learning journeys by giving an example. An idea to take, adapt to their context and make it their own. And it worked, just like the last times I've given the talk. Right after the Agile Testing @Munich meetup Guna Petrova signed up for my tour. After CAST Alex de los Reyes scheduled a pair testing session with me, and now it was Gem Hill! Also, further people came and discussed how they could start their own experiment. This makes me unbelievably happy. Moments like these made my journey out of my comfort zone by public speaking and the testing tour so much worth it.
  • This time I was eager to give my best to not fall into my usual post-speaking state of total distraction and lack of focus but instead closely listen to Nick Tune's talk "Strategic Autonomous Design: Patterns and Heuristics". I knew Nick as great story teller, he could really engage and entertain me last year. Now, following the talk worked out well at first. But then: technical problems. The projector refused to show the slide deck. One slide was displayed, the next one not. They had to reactivate sharing, it worked for one slide, and so on. In the end they had to use another computer. Nick got constantly interrupted and it cost a lot of time overall so that he could not present the whole talk - what a pity.
  • Erkki Salminen and Mari Wuoti's talk "Culture for the win" was my last choice of the day. They shared how the culture at their company Gofore evolved. They values they have are used as guideline for everyone to decide to the best of their and the company's needs. The nearly 500 people only have one "middle manager" - a Slack bot! Culture is strategy for them, it's a lot about the mindset. Great example that you can indeed grow your own culture and related structures; maybe inspired by others but not copied and pasted into your context.
  • The closing keynote was given by Seb Rose: "Whatever your job title, you’re actually being paid to think!". Wonderful talk around his rant for the FFS Tech Conference, sharing why metaphors, acronyms, templates and models can be confusing, ambiguous and generally unhelpful - if you don't think. That's our job, we're creative thinking professionals! Seb asked everyone to not just belief him, but really think about it first and make up our own minds. Wonderful closing keynote that was fitting so well to the opening keynote.
There were several more talks I would have loved to see. The good thing: There was again a post-conference meetup hosted by Equal Experts - with great lightning talks!
A great conference ended with even more great and fun talks and long conversations with awesome people. Just perfect.

Tuesday, September 4, 2018

Testing Tour Stop #19: Session-Based Pair Testing with Guna

Guna Petrova had listened to my testing tour talk at a local meetup end of July. Right afterwards, on the same evening, she scheduled a pair testing session with me. What a wonderful feedback! We had a great time testing together.

When it came to selecting our topic, we had lots of ideas and areas we would like to dive into or improve our skills in. For our session we agreed to try an approach we've known for a long time but never actually tried out ourselves: session-based testing.

Prepare and Align

As neither of us was really familiar with session-based testing or session-based test management we had to first read about the approach. The following resources helped us prepare as well as guide us during the session.
We agreed to try this approach to support our exploration, so we needed a test target. We decided to go for the Hours time tracking web application. The domain is not unfamiliar, the product still unknown to us.

We also needed to decide where and how to take notes. As far as we could see, usually a simple text file is used which can easily be parsed for automatic reporting. For our session we did not care about the automation part, so we decided to have the sample session reports guide us, but not limit us. We wanted to create a mind map instead.

Taking the template and making it our own, in a visual way, was a great exercise in itself. We had to discuss and align which information to take over, where to put it and how to structure it in the beginning, knowing we will adapt it as needed during our session. We agreed to use child nodes along with notes on them to store more detailed information. Later during the testing session we also decided to use icons to mark issues so we could quickly get an overview on our findings.

While creating the mind map and aligning on everything, we agreed on our mission and our first charter to focus on.
  • Mission: Evaluate the web app whether it's suitable for a first time user
  • Charter: First interaction with the system, namely the
    • Web home page
    • Registration
    • App landing page & content
We noted down areas to test and session metrics. We planned to report issues and opportunities for future charters, as well as test data and tools used.

We agreed to time box our testing session to 45 minutes. We also wanted to pair the strong-style way, frequently switching the navigator and driver roles, having a mob timer support us. Finally, all agreements were made and we felt ready to start our session.

Time Flies

We started testing, tackling the very first contact point of most first time users of Hours: the web home page. If we would want to evaluate the product, this is where we would start to learn more about the application and create an account.

We found several issues already on this home page. We frowned upon lots of things we would not have expected. We also found praise! We took note of all these findings in the report section of our mind map. Besides that, we also stored details on what we tested in the notes section of our charter. I wondered whether I really would put down so many notes myself (I normally don't). The benefit I saw was that it would definitely help tell the testing story in the end when discussing findings. Guna added that this was also proof what we did, it felt safe to do it, especially in situations were you needed to show evidence of your testing.

Our mind map evolved quite naturally. We discussed and aligned ourselves. Suddenly we realized that not much time was left and we were still on the web home page, not even close to the other parts we wanted to look at. We decided to keep it with that, and still we went overtime. We tested for 55 minutes and therefore exceeded our time box by 10 minutes.

Debrief!

In session-based testing the session is debriefed right afterwards. We agreed to not use questions of the offered debrief checklist, but try the PROOF approach of Jon Bach.
  • Past. What happened during the session?
  • Results. What was achieved during the session?
  • Obstacles. What got in the way of good testing?
  • Outlook. What still needs to be done?
  • Feelings. How does the tester feel about all this?
This felt pretty fast and easy, straightforward, and indeed helpful. Mental note to myself: Do debriefs more often for your own testing; you might learn a thing or two.

Looking Back

In retrospect, both Guna and I liked our session. It was great to try something - together. It's way easier this way. As Guna put it: She wouldn't do session-based testing alone. Cassandra did it alone and struggled. But together it provided value. It's not a bad format.

What I liked about our approach was that we took the format and template, tried to understand the essence and then transferred it to a visual mind map, thus making it our own and adapting it to a setting which might be useful in our everyday life. Guna said documenting testing and findings like this seemed to be a neutral way to not force your own style on the other person. It felt great for multiple people working on the same stuff and it was a good reminder that there's more to consider for testing sessions.

Regarding our strong-style pairing, Guna offered interesting thoughts on it as well. We had to communicate and align ourselves. Whenever we felt we were not aligned, we explained why we would want to do this or that. We had to hold back sometimes, especially when we wanted to bring up something but it wasn't our time yet. These cases were the only time she noticed the pairing part. Besides that we were still having a natural conversation and flow. Her conclusion: we should do more pairing. I agree!

Monday, September 3, 2018

Testing Tour Stop #18: Mob Exploring with Amitai and codecentric

This stop on my testing tour was really special. Why?
  1. I saw Amitai Schleier again! We had read each other's tweets since longer and first met in real life at the Mob Programming Conference 2018.
  2. Amitai went on a coding tour this summer, joining several companies for one week each to learn together (find more about it on his blog). Most of the tour happened to be in Germany, and the last two days in Munich at codecentric. He knew about my testing tour and imagined us to have a common stop in my home town.
  3. We mobbed. My original hypothesis for my tour was about either pairing or mobbing, however, I only had the chance to pair before.
  4. The people on the mob identified as developers and had no experience with exploratory testing. My tour was about learning from testers, still, this promised to be interesting. I did not join the mob myself but stayed the facilitator. Though my tour was about hands-on testing, with me included, I learned a lot about teaching testing.
  5. My previous stop with Simon Berner was about pairing and mobbing itself. Only a few days later I could put our exchange into practice!
At first I saw this session as guest visit on Amitai's coding tour. Amitai, however, wished for counting it as stop on my testing tour as well. Even though I was not on the mob myself, this indeed felt like a bonus stop on my tour. So be it! :)

Setting the Stage

Amitai and Thorsten Brunzendorf already welcomed me at the entry. We had a nice chat, set up the room intended for our mob and waited for interested people from codecentric to join our session. They came, and even brought a test target we could use where they would value feedback on. Great, I really like to have our sessions to not only have the training effect but also have real-life impact.

After Amitai and I introducing ourselves and sharing some words on our tours, the session started. I decided to have a short introduction round in the mob as well, asking them for their name and core expertise. I knew everybody was identifying as developers, however, it was still very interesting to hear the different backgrounds, interests and specialties. Some people were into DevOps, some preferred backend development, or even tended towards security testing. I was pleasantly surprised to hear most of the group already had mob experience, only two persons didn't. After giving them a short heads-up, I went over to introducing testing, and especially exploratory testing. I presented my preferred definition by Elisabeth Hendrickson, as well as her charter template that I find useful especially for people new to exploration.
"Simultaneously designing and executing tests to learn about the system, using your insights from the last experiment to inform the next."
"Explore (target)
With (resources)
to discover (information)"
(Elisabeth Hendrickson, Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing)
I wanted to keep the basic theory short and have people learn by hands-on testing as soon as possible. I asked the ones who provided the test target to shortly introduce it and afterwards asked the mob to write their charter. They, however, were really unsure what they wanted to focus on as they felt they didn't know the product well enough yet. So I decided to have them do a recon session for the first rotations in the mob, mapping out the system. I also recommended to already jot down notes together as a mob, for example in a mind map. And off they went!

Let the Mob Explore

It was really interesting to observe this mob explore a product most of them saw for the first time. They were unsure about their procedure, trying to align themselves as a group. They jumped all over the place, already finding great issues; not taking notes of them. They started a list of assumptions and wishes they had for the product. And they shared lots of implicit knowledge with each other, just as I have witnessed it in so many mobs before.

After nearly one full round of rotations, I had them stop. I shared some of my observations and provided recommendations. I also asked them whether they now felt ready to write a charter so we could do more focused exploration, using a simple Roman vote for quick decision making: thumbsup - I feel we're ready, thumbsdown - we need more information, thumbs sideways - not sure which way to go. Half of the group voted up, half sideways. I could have used the mostly positive result to have them write a charter now, but decided to have them finish a full round of rotations before asking again. Now all thumbs went up! Chartering didn't come easy to them. I helped them through, trying to not enforce my own suggestions or opinion. They managed to come up with a first charter to start with, providing them the needed focus. Interestingly, they decided to explore user experience with the help of the source code! That promised to be interesting, and it was indeed.
  • They used the code as oracle - great.
  • They looked for existing unit tests - nice.
  • One person shared: "I still don't understand the test, can you shortly walk me through?" - liked that.
  • They fed different values to unit tests, in an attempt to use it for exploration - awesome! Unfortunately, they did not follow up on it, or left a remark for future sessions.
  • They said they should also test the feature from user perspective - exactly! It might be the code they saw was actually never executed, right?
Towards the end of our mob session they started a discussion of whether a certain feature was useful at all. They brainstormed ideas how a different solution might be way more valuable to the user in the end. They questioned the context the product might be used in. Many great points were made.

Retro? Debrief, Discussion, Feedback

On my testing tour sessions, I normally do a short retrospective in the end so we can learn how to improve (I learned their value on my very first stop with Maaret). This time, I did a debrief of the testing session with the mob instead, to have them reflect on certain aspects. It proofed really valuable to get them thinking about what they did. Mental note to myself: I should do that more often for my own testing as well.
  1. What was our mission?
  2. What did we test and what not?
  3. What did we learn?
  4. What feedback can we provide about the product, can we quickly derive it from our notes?
  5. What to focus on as next highest priority with the knowledge we have now? 
The response on the last question was my personal favorite. They wanted to talk with the product owner as next step to see if they were going in the right direction or whether other areas might be more risky.

After a short closing, the mob session was officially over. Still, the group stayed and started an informal discussion. One of the persons who proposed the test target now shared that he didn't want to spoil the session, but the tested product version was outdated already and they had indeed agreed to remove the challenged feature - so the mob's feeling was indeed correct here!

It was great to hear people's experience with testing, mobbing and knowledge sharing. I really enjoyed the conversation to conclude a great session. Afterwards, Amitai shared personal feedback with me. He said he could clearly see I did these sessions very often already. This feedback took me by surprise. I had facilitated several mob sessions since beginning of the year: three in my company, one at a meetup, and three at conferences. So this session had been my eighth only. Amitai shared it was received as really professional and it was exactly what he was hoping for. This showed me I had learned a lot and it also triggered me to reflect. The session had indeed felt good. Maybe because I taught developers new to exploratory testing? Would it have been the same in case they would have been other testers? Still to be answered. This I know for sure: I had shared a lot about testing and testers during the session while people were doing hands-on testing. The mob approach is just an awesome way not only to learn but also to teach testing.
Bonus: Amitai also shared what he learned on his blog as well as recorded a conversation with codecentric sharing their highlights from this stop; including my exploratory testing session! :D

Sunday, August 26, 2018

Testing Tour Stop #17: Pair Evolving a Mind Map about Pairing and Mobbing with Simon

On my latest stop on my testing tour I had the pleasure of pairing up with Simon Berner on the topic of pairing and mobbing.
We only had contact via Twitter before. It's always a great experience to put a real face to this sort of virtual connection and have a meaningful conversation with them.

Going on a Meta Level

Simon put a lot of thought into our session already in advance and proposed our topic as follows.
Hi Lisi
There are so many great things out there that I would like to discuss and explore with you, but so little time. I have something specific in mind where I know little about yet: to Mob. As you seem to have quite some experience around this topic, I would love to pair up with you on the topic of “to Mob” and elaborate a bit on it, if you are up for it. What are our experiences with MobTesting and MobProgramming in general? What are its benefits? When can it be applied best, when not? Are there different forms of it? Can a whole Sprint-Iteration completely be developed in a Mob? How can you introduce “to Mob” to a team who knows nothing about it? How do we learn best from its outcomes? … and many more interesting questions to discuss.
My intention in this session with you is, to create a MindMap where we both can share ideas/experiences and grow up on it (maybe me a bit more than you as you seem to be already a pro on it)
I’ll create a MindMap in advance with some of my ideas around the topic, so that we can get started on them.
Hope that sounds interesting to you
Cheers
Simon
If that sounds interesting to me? Indeed it does a lot! Our session could only last that long, but I'd love to continue the conversations around it.

Now, originally my goal for the testing tour was to practice testing hands-on. I read and talked a lot, but felt I didn't practice or try out new approaches and tools enough. In this sense, this pairing session was a bit different, as we had a paired conversation around a certain topic. Still I was eager to give it a try, betting there's much to learn out of it as well.

Evolving a Pairing and Mobbing Mind Map

As promised, Simon already prepared a mind map. And it was huge! It contained most of the things already, so it was great to get our discussion started, elaborate on certain points and develop it further. As words cannot express what mind maps can, let's start at the end and show you our end result. I decided not to edit it after we stopped, so this is exactly as we left it. The original file which allows to follow the links can be found here: TestingTour_2018#17_Pairing&Mobbing.xmind.
I really enjoyed that Simon thought of including an "introduction" node for us to get going. After all, we didn't know each other and this made it easier to start and learn one or two interesting bits about each other. This way, I got to know that he just started in a new team with huge potential where he's the only one to drive things forward regarding testing and collaboration. Simon already pairs with his teammates and now got intrigued to try the mob approach as well.

We talked a lot about styles of pairing and what comes with them. We both enjoy and prefer strong-style pairing the most. When it comes to explaining this form, I normally shared this blog post by Llewellyn FalcoLlewellyn’s strong-style pairing. Great to see Simon had it already in his mind map. And he also had the following post by Maaret Pyhäjärvi right next to it: Being a navigator in Strong-style Pairing. I really enjoyed reading it afterwards, as well as her previous posts in this mini-series The pairing experience: foundations and Being a Driver in Strong-Style pairing. (Update: Maaret just compile an article from her notes on strong-style pairing: The Driver-Navigator in Strong-Style Pairing; my new favorite post to share.)

Simon shared that when it comes to understanding the roles of driver and navigator in strong-style pairing, the metaphor of the rally driver and navigator was enlightening to him. When driving a rally, the driver has no time to read the map or think about what else to consider, they are fully occupied with getting them there. It's up to the navigator to take care of directions and instructions and thinking ahead. This metaphor was flipping the switch for him.

Another interesting point Simon made was that "listening is an art". I so much agree! Especially when he shared his observation when meeting people. He's interested in people and the one asking questions about the others. People have a tendency, however, to tell you about their lives and then not ask in return to learn who you are. I made this observation myself so many times as well. However, I also fell into the trap of the other side so many times already, being guilty of not asking back myself. Best example was when I was speaking at a conference and someone approached me asking questions, I was really happy I could talk about things I love for once and not only listen to others, so that I often forgot to ask back. Another factor here is that exhaustion makes it worse as Simon added. When I'm tired, I fall back into my worse habits and less social behavior.

Another interesting discussion point was what to do when you see that people are falling back into a traditional style of pairing, having the navigator take over control of the keyboard again. We both experienced these kind of situations already which can be tricky to solve. I realized that I personally grew with experience, so when I am the driver, I won't allow my navigator to take over. It's really hard for me, however, to be on a mob and watch the driver freely handing over full control to the navigator. I normally intervene, referring to the learning aspect for both. Sometimes this is helping people find back on track, sometimes my voice is not heard. Now, the worst thing is if I'm myself the navigator (maybe also tired) and have to actively stop myself and refrain from taking over. At least it's fully in my hands to stop it then.

When focusing on mobbing, we quickly came to the question how to introduce it to a team and tackle the likely question regarding productivity. I referred to a great keynote by Woody Zuill at the Mob Programming Conference 2018: "Mob Programming and the Power of Flow". Unfortunately this talk cannot be found online, however you can find my notes about it in my blog post about the conference, and Woody's webinar Enhancing Team Effectiveness with Mob Programming seems to be sharing about the same content.

In a mob, it's important how we treat each other. Kindness, consideration and respect are the often-shared ground rules for a mob. Simon and I felt "kindness" is kind of straightforward, and "respect" understandable as well; "consideration", however, is not as easily graspable. I admitted I had to look this one up the most often before explaining it to a new mob. I explained it with being aware of the others and their context and considering that everyone's doing everything to the best of their knowledge. And instantly admitted I would love to look it up again right then to see if that's correct. Now that I have written this down in this blog post, I really went back to the Mob Programming Guidebook and looked it up. And found that once again I indeed mixed "consideration" up with "respect"!
"Consideration is really about listening. [...] The place it is going to show up the most is at the driver seat. Often the driver will start by not listening to the navigator. [...] Another way that this will manifest itself is that good ideas will be spoken by members of the mob and will be totally ignored. [...] As a facilitator, it is your job to call attention to those ideas and make sure that everyone gets heard. Over time the mob will learn the habits of listening to everyone and people will find their spots to contribute. [...] Another aspect of consideration is to remember to allow other people to shine. [...]
[Respect:] We always assume that the person who wrote the code before us did the best they could with the knowledge and circumstances they were in at the time they wrote it. [...] We want to create a space that is safe."
(Maaret Pyhäjärvi & Llewellyn Falco: "Mob Programming Guidebook" version 2018-03-24, chapter "Working in You First Mob", section "The Rules for Working with Each Other")
The next interesting topic was the size a mob should have and when it stops working due to the number of people involved. I learned that three persons already form a mob, however, if one leaves the mob for a break you are back in a pair. Therefore, a minimal size of four people is working out really nicely. When it comes to the maximal size, the general idea that I picked up was that the size of a mob is still right when everyone's either learning or contributing. If you have a normal-sized agile team it's perfect. I heard from two team mobs temporarily joining forces in a bigger mob, or from people trying a mob with a full meetup group. So far I still made good experience with a mob of ten people myself.

We were running out of time and still had many more topics on the mind map. So I asked Simon what would be the last most valuable topic he'd love to have input on before trying to mob with his team himself. Simon wanted to learn about the "don'ts" in a mob. Two points came to my mind instantly.
  1. Don't force anyone into the mob. If they are not willing to give it a real try, leave them out and only do it with the people who want to. Make it fun so they might want to join in next time, as I learned from Maaret. In my team's case, the two most skeptical persons who did not want to be on our mob either changed team or the company soon after, so I cannot tell from experience how it might have evolved with them. Still, we cannot force people, only convince them.
  2. Don't force anyone to stay in the mob. Besides from the very first mob sessions, we made very good experience with allowing people to take any break they need and temporarily retreat from the mob. These can be as simple as toilet breaks or getting some water, with them being back on the mob very quickly. These can be meetings that just happen to take place at the same time, like a one to one with our manager or an interview. These also can be times people need to fall back to solo working mode and tackle other tasks they have. With this rule we made it easy for everyone to opt in and out, and the result was we were even longer together in the mob. Just the freedom was needed. And the coffee breaks? Since then we nearly always do them together, staying synchronized, and having that extra bit of socializing that helps so much when working together.

Retrospective Time

Simon shared it was a wonderful experience for him, joining me on my testing tour. He was nervous in the beginning as we didn't know each other (just like me always!), but it turned out to be a cool session. He also got a lot of information and value out of the session, which I loved to hear. He didn't think we should have improved anything in our session, as a lot depends on the energy flowing between two persons and ours was great.

I really enjoyed our discussion and the additional food for thought when it comes to pairing and mobbing. The preparation work Simon had put in already in advance was simply awesome! So much more to dive deeper into, lots of resources new to me. It was really interesting to try strong-style pairing on such a meta level topic, evolving the mind map with our results together. Because this is what we did! We used a timer and switched roles, however, for this kind of a topic it was quite hard to do and we often lost discipline. Still, both of us could contribute and learn. Simon made a good point here: it's the natural flow that matters, we don't have to force people into a box. It was as if we would have done it before.

All in all, it was once again a pleasure to pair up with great people of our wonderful community. There's so much to learn from them, to give back, and to discover new insights together.

Monday, August 20, 2018

CAST 2018 - A Community Adventure

Two weeks ago, I had the great opportunity to be part of CAST 2018, taking place in Cocoa Beach, Florida. I had heard great things about last years' events, and indeed, it turned out to be yet another wonderful conference!

The theme was "Bridging Between Communities", a theme I really loved. It is great to exchange experience with other testers working in a similar context. It is also great to share knowledge with testers working in different ones. And it is great to learn from people who do not identify as tester as well! Maria Kedemo was program chair and created a wonderful offer. It was really hard to pick a session and I would have loved to go to each and every one of them. Thanks a lot for the diversity provided.

Organizers in general were great and really supportive. Together with their volunteers they did a great job! I felt very welcome, communication was easy, and facilitation and support during the conference was awesome. Especially as a speaker this part is nowadays really important for me. Though we had some short-term changes in the schedule or regarding rooms, everything went smooth and without major problems.

Getting to a conference as speaker is a great thing for me in any case. It's not only that I get the chance to share my experience and give back to the community from which I received so much myself, or that I receive the opportunity to level up my presentation and training skills, but also that I learn so much from these conferences myself. I learn as an attendee, I can reach out to fellow speakers way more easily, and I get approached myself by other participants myself. As I identify as introvert at heart, this helps me so much to connect with people and learn from them. Thank you for making it so much easier for me.

At CAST 2018, there were so many wonderful people with whom I enjoyed many insightful conversations.
  • Lisa Crispin. I consider myself really lucky that we had so many opportunities over the last year to meet and exchange thoughts. I enjoy all our conversations and am already really happy that we are going to meet again at three more conferences within the next half year!
  • Marianne Duijst. Thank you for listening, for providing constructive feedback, for facilitating the questions for my talk, for your most wonderful sketch notes, and last but not least for spending a full day with me after the conference doing awesome touristic stuff! I am so glad I got to know you.
  • Ashley Hunsberger. It was such a great coincidence that we had a first call just a few weeks before CAST! It was even more lovely meeting you in real life, and just picking up things from where we left them. Thanks for the evening spent talking about anything and everything.
  • Lena WibergTomas Rosenqvist. It was fabulous to meet you in person, and that even already on the plane to Orlando. Thank you for sharing your experience. You gave me so much food for thought!
  • Angie Jones. Finally I had the opportunity to join one of your tutorials! It was great. Even better was the opportunity to talk with you. Thanks for making it easy, as well as for your feedback! :-)
  • Amit Wertheimer. It was great meeting you again, I really enjoyed our deep conversations on so many topics! Already looking forward to the next chance.
  • Jan Eumann. There are still not too many people who already experienced mob programming, mob testing, or mob anything. I really enjoy sharing thoughts with those who did! Even greater considering the fact that we now submitted a proposal for a mob session at another conference together.
And there were so many more lovely people! Maria KedemoLouise PeroldAnne-Marie CharrettJenny Bramble. Richard Bradshaw. Alex de los Reyes. Bailey Hanna. Many more great persons with whom I loved exchanging knowledge during tutorial, workshops, talks, lunch, or a bus ride.
If you came that far in my post you might think this conference was all about people. Well, I think conferences are indeed about the people, just like software development is. Still, those people also shared great content. I learned a bunch again and took several ideas with me back to work. Here are my highlights of each conference day I attended.
  • Tutorial day. The tutorial "Advanced Automation for Agile: UI, Web Services, and BDD" by Angie Jones. She taught everyone how to create a well designed automation framework, shared her experience, demoed what she told, and made sure everyone shared the same page. At times I perceived the pace as slow, yet "slow allows for thoughtful thinking" to quote Maaret Pyhäjärvi. It felt good to learn that I know more than I thought I would. That I could easily follow and still had time to help others, and was able to do so.
  • Conference day 1. This day is tricky, as I had two favorite sessions. The workshop "An Exploration of Observing - Creating system awareness in our quest for quality" by Louise Perold was great to practice our observations skills hands-on and especially debrief what happened and what we perceived. And the talk "Risk Based Testing: Communicating Why You Can't Test EVERYTHING" by Jenny Bramble was so entertaining that I even forgot that I was next! It also made obvious how important communication, talking about risk to guide our testing, and team morale really is.
  • Conference day 2. Finally I could hear Marianne Duijst's talk "Wearing Hermione’s Hat: Narratology for Testers". Learned a lot about biases, perspectives, trust when it comes to information, as well as enabling others. It was simply awesome. If you get a chance to hear it, take it. It should have been a keynote for everybody to hear.
Well, and I also had two sessions myself. I gave my brand-new talk "Cross-team Pair Testing: Lessons of a Testing Traveler" for the first time at a conference, speaking about my testing tour. Although my timing was not working out well enough, it seems people did not notice and still felt it to be consistent. After the talk, there was a facilitated discussion which I really feared in the beginning - but it went well and people asked many great questions so we could dive a bit deeper on the topic. And the best thing: Alex de los Reyes came up to me after my talk and told me that he really related to it, shared my fears and wanted to pair with other testers for some time himself already. Now my talk was finally the trigger for him to actually do so! Amit Wertheimer instantly joined in, and both agreed to have a pair testing session. How awesome is that?! It seems more people came out of my talk inspired. That was my goal and I am really happy about this kind of feedback. What more could one want?
In addition to my talk, I gave my workshop "Mobservations - The Power of Observation in a Mob". I had less time to prepare myself for it as expected as schedule slots were swapped, so I felt less energized and the session less organized as it could have been. Still it went out okay, people got value out of it, and I also received constructive feedback how to improve it further. As Louise Perold shared with me, workshops are never perfect, they can always be improved. And they depend also on the people you have and your skills to adapt to them and the context.
In conclusion, the people were great. The conference was great. And then also the social activities around were great! For example, the sponsors enabled most of the people to visit Kennedy Space Center where we all had dinner together. What a location for that!
As a bonus: there were two rocket launches around the conference dates - who can say they offer that?!
Last but not least: I have the most awesome team ever.

Saturday, July 21, 2018

Testing Tour Stop #16: Pair Exploring an API with Thomas

Yet another stop on my testing tour? Yet another stop on my testing tour! Yesterday I learned together with Thomas Rinke. We shortly met each other at Agile Testing Days 2017 where we had a great conversation over lunch. Like many of the other people I paired with, Thomas is really engaged in the community as well, something I really appreciate. He is on the conference board for the German Testing Day, and also actively helping his colleagues grow. He already did what I wanted to do with my own company's testing community for a long time: watching great conference talks and discussing them together. Still on my "to try" list!


The Preparation Phase

About a week before our session, we started brainstorming and aligning ourselves on our topic. Thomas was up for exploration as well as automation. I proposed to go for an exploratory testing session, pairing the strong-style way. Thomas shared he never experienced it himself but was intrigued to give it a try. He had come across Alan Richardson announcing Thingifier, his new demo app for API testing. Awesome! I wanted to have a look at that myself already, so we chose it as our system under test. We directly went for version 1.1, however, as the previous one did not start up successfully on our computers.

In case you haven't explored an API yet, I recommend Maaret's fantastic article Exploratory Testing an API. For our session we agreed to use Postman as our tool of choice and to run the app on my computer, sharing screen control. Have I mentioned already how much I love Zoom for not only offering great video quality and recording functionality, but also free control sharing that's easy to use and actually works?

The Session Introduction

We started out setting everything up and getting any open questions out of the way. Interestingly, Thomas shared with me that he was nervous and excited, thinking "well, what could go wrong, it's going to be great". Especially testing with "strangers" was something extraordinary, and we didn't know each other so well yet. The thing was: I was nervous, too. I always am for my pair testing sessions. Fear is even one of my reasons that I started the whole testing tour. Doing this is still scary for me. However, I already see that it is continuously getting better over time. "If it's scary, do it more often" really applies for me here.

Thomas also shared he prepared for the session upfront. For example, he read Llewellyn Falco's blog post about strong-style pairing and listened to Woody Zuill's podcast episode about mob programming on Agile Uprising. Both really recommended!

I learned Thomas was running Windows as operating system, so I advised him to rather not use shortcuts as they are mapped differently on macOS and this doesn't work easily when sharing control, as I had learned in my session with Pranav. Due to the preparation done beforehand, everything could be quickly clarified so we could activate the mob timer and start testing together.

The Testing Part

Thingifier is described as a "hard coded model of a small TODO application". Our first goal was to get an overview of the capabilities of the application and understand its model. We started out using the given documentation and sent first requests to see how the application worked and behaved. Interestingly, later on I saw that the app's release note for version 1.1 said "When the app is running, visit http://localhost:4567/documentation in a browser to see the docs." This was in contradiction to the actual documentation that could be found directly on "http://localhost:4567/".

Thomas started out as navigator, but when it came to him to take over keyboard control as driver, we found that Postman and Zoom screen control sharing did not work well together. He could do right-click actions with his mouse, but not left-click. We discovered that it worked in Chrome, however, and when going back to Postman it now worked here as well. Would be an interesting topic to explore itself!

When getting to know Thingifier's Rest API, we came across the following findings and starting points for conversations.
  • The documentation spoke of todos and tasks. On first scanning over the documentation, it looked like these terms had been used for the same thing, so it seemed like an inconsistency. However, on second read it became clear that you had standalone todos on the one hand, and projects that have todos as so called "tasks" assigned on the other. Nonetheless, this naming differentiation caused us to stumble. Later I found that when using a category guid as resource instead of a todo guid, it's successfully accepted as task, but then calling the task collection returned a 400 (Bad Request).
  • When adding a task to a project, the request returned a 201 (Created). Repeating the same request did not add the task a second time which was good, but the request still returned 201 (Created). We considered that not critical but also not completely clean, we would have rather expected a message that the relation already existed.
  • We stumbled a bit regarding the naming of resources. For collections the singular form was used (e.g. "/todo"), for sub-collections of an element the plural form (e.g. "/todo/:guid/categories"). We wondered whether there was a related naming convention for Rest APIs. Intuitively we would have used the plural form for all kind of collections, as the request was returning an array of all items. For example "/todo" returned an array of "todos", so we would rather have named it "/todos". Further research showed that it indeed seems to be best practice to use the plural form for collections.
  • For testing purposes we would have loved to see existing relations in the request responses, e.g. when querying a project to see its assigned tasks and categories.
  • Creating a todo created it with a random guid, and it was marked as not completed by default; just as expected.
  • When checking all given relationships between entities, we found them to be inconsistent. Categories and todos were implemented in both directions, so you could see all todos of a category as well as all categories of a todo. However, for example, you could see all projects of a category, but not all categories of a project.
  • We had already tried three of the four offered relationships, and thought everything seemed okay. To complete our understanding we tried the fourth as well - and it failed. "/todo/:guid/categories" resulted in a 400 (Bad Request). Fun fact number one: It's so often the last thing we try that unveils an issue. Fun fact number two: I could not reproduce this issue anymore when writing this blog post; it seems we missed something here.
  • When querying a collection, we would have liked to directly see in the response how many elements were returned, at least to help testing.
  • When requesting a resource that did not exist, we received an error message as expected. Its wording was quite technical but expressive.
  • We deleted all todo items and then queried for the collection of all todos. The request returned only an empty response without value ( i.e. {} ). We would have preferred to receive an empty array of the queried entity instead to keep the response expressive (i.e. {"todos": []} ).
After we had gotten more familiar with the application, we decided that it was time to go deeper on a certain part of the API. We agreed to have a more detailed look at creating todos as we perceived it as core part while still being small and graspable.
  • Sending a request with an empty body returned a 400 (Bad Request), as expected.
  • When providing the framing brackets {} as body we received the error message that the field "title" was mandatory.
  • When providing a body with the title field set to an empty string, we received the error message that the title must not be empty. Providing a blank resulted in the same message.
  • Providing a dot (.) as title worked, just as the Polish special character ł. Previously I learned those additional Polish characters are not included in the basic Latin character set so they can can cause problems e.g. when storing values in a database.
  • Providing a double quote (") returned a MalformedJsonException. We tried to escape the character, using a backslash (\), but it returned "Expected ',' instead of '"'". We wondered how to escape a character in a REST API request body but left that for future investigation.
  • We provided a quite long title of more than 256 characters. The request returned a 201 (Created) as expected. However, when then querying for all todos, the request only returned "Expected ',' instead of '"'". We found that this was not related to the long value provided, but due to our previous tries to escape characters. We indeed had to restart the app to reset the given test data.
  • We switched to the guid field. We found that if the guid is explicitly specified on todo creation, the given one is taken. In case the guid already existed, the todo is not created again but the existing todo is updated. We discovered that there seemed to be no validation regarding the length of the guid. Later I found you could even provide an empty string as guid which made it impossible to request the specific todo.
  • According to documentation, both POST and PUT methods were offered. However, their purpose felt mixed up. Both should create todos in case they did not exist yet, and both should update an already existing todo. However, I found that my gut feeling is mixed up here as well, as I thought in terms of HTTP, however REST only demands a uniform interface.

The Retrospective

As for all test sessions, we left some time for a short retrospective at the end to reflect how it went and what could be improved. Thomas started with sharing his thoughts, and by doing so provided wonderful feedback! Here's what I understood.
  • It was a lot of fun and overall a great thing.
  • He had seen on Twitter that I invited basically the whole world to pair test with me and thought that was a really cool thing. He told himself he could not lose anything there and wanted to join in.
  • The communication beforehand was great. He really liked that I reached out in time upfront, about one week before our session. That we clarified the technical setup, aligned on the topic to pair on, agreed on the style of pairing. That both of us could contribute when choosing our topic and how we wanted to collaborate.
  • He learned something during the session which was great. He had the feeling that it was also worth it for me, not that I thought "oh no, Postman, exploring an API, how boring".
  • He found that I was open, friendly, and welcoming. He really liked that I was looking forward to our session myself.
  • The session offered lots of first-timers for him. It was his first time of using Postman, first time of having a REST API, first time of trying the strong style way of pairing, first time exploring an API. He considered these quite a lot of firsts and therefore felt triggered to prepare for the session which he thought was good. He felt a certain sense of commitment and bindingness to do so. He wanted to explore an API for so long already, and our session triggered him to really do it now.
  • Thomas said the execution of the session and our alignment were good as well. Strong-style pairing was really great, too, he had a good feeling about it. He shared that he felt the trust given and had trust in me himself. He referred to Llewellyn's blog post which emphasized the importance of trust as well.
  • What was not completely perfect from his point of view was that we worked on different operating systems. Thomas felt he was slowed down as he always had to use the GUI for operations like copy and paste. This was not optimal as he felt that I was so much faster when I was driving. He said that the upfront warning about the mismatched shortcuts was great, and in the end this was okay for him, but he still felt I was always faster.
  • Thomas valued the results of our session. We found some behavior working as expected, some surprising things, and some classics.
First of all I had to thank him for his great, structured, constructive feedback. It is so helpful to receive detailed feedback also on the positive things, showing which things are going in the right direction besides those that could be improved. Really appreciated!

Besides that I shared that for me nothing is too basic to pair on. I learned that I always learn something, especially with different partners who bring different perspectives. Sometimes it's great to see a different approach, but sometimes it's also great to see when we share approaches or think in similar directions. I started out on my testing tour because I did not know where I stood regarding my own testing skills and knowledge, if what I was doing made sense at all.

We both shared the approach to first start with the base frame and then dive into the details. As Thomas added, there's also the other approach of going fully destructive at once. However, he normally likes to see the happy path first, how the application was intended to behave. He made better experience to first provide feedback around that to developers instead of instantly coming up with rare strange cases causing the implementation to fail.

The whole communication with Thomas upfront and throughout the session was so easy, I really enjoyed it. Furthermore, I really appreciated that Thomas created a safe environment for both of us from the very start of our session. He shared right at the beginning that he was nervous and excited, which made it really safe for me to share my thoughts and feelings with him and put everything on the table. Neither of us had a problem to call something out during the session, as this trust had been established beforehand already. 

Thomas shared that he loves to experiment and try new things in order to see which of them work. He also wanted to give mob testing a try, especially after having experienced strong-style pair testing now. With the strong-style approach you don't have any chance to lose focus, it's simply awesome to have two people or even the whole team fully concentrating on the task at hand.

The Inspiration

In the very end, Thomas gave me some feedback on my whole tour and what I am doing. He said it's a real inspiration for him to also get out of his comfort zone. For example he had recently decided to invest the time to join the Tuesday Night Testing and really valued the event, having great conversations and experience exchange. Honestly, this is so great to hear as it's exactly what I am trying to do: show people how to safely get our of their comfort zones and how valuable this can be for their personal development as well as for the rest of us learning from them.
Thomas also presented the example of Kim Knup, who just decided to tackle Alan Richardson's note taking experiment and made this decision a public commitment. This created the same sort of bindingness. Thomas shared he really wanted to use some of his time focusing on learning. We both encountered people who do not take any time to learn, not even half an hour. Many seem not to belief they are entitled to use their time for learning, "away from their tasks", a few might also not want to grow (which is a pity). Thomas said that sometimes we should do the things that we think are great fun, and sometimes we should do things that are on the edge of our area of responsibility. I so much agree.

I am already looking forward to meeting Thomas in real life again at the next Agile Testing Days end of this year. We are both going to join the Web Application Security tutorial by Dan Billing. Also, Thomas plans to join Toyer's and my workshop of Finding a Learning Partner in the Testing Community and hopes to find an accountability partner for himself there! So awesome. I really hope he will, alongside many more.