Tuesday, March 20, 2018

Bad Talk, Take Three: Sabina'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 Sabina Atic, written by herself, in her own words.
As a woman in highly man dominated IT job, I have had a lot of thoughts on how to achieve an including working culture where we have respect to each other and each other’s differences. In Sweden, the theory about equality is highly valued and in my senior working experience (+5-10 years), I had the luxury of not being directly addressed in an unappropriated way at my work. When I was younger, it happened a few times that both older men and women colleagues tried to “put me in place” in front of others, without any intervention from the public. Today I’m much more confident with both myself as a person and my professional knowledge. I also think that in most of the societies, the rib on how to talk and respond to young people and children is quite low. We somehow tend to forget that they also have equal feelings and that they are learning from us.
As for myself, as a woman not afraid to speak up and question talk I find disrespectful, it is quite easy when the talk is clear and direct. I can ask “how do you mean” or “could you please explain” or just explain how I perceived the message. I like using humor. I feel proud when I manage to use civil courage and I also am thankful to others doing so. But how do we handle subtle hints? Body language? Would I be able to understand that I hurt someone by using my ironic humor because irony has bypassed him/her? Is a man colleague/manager et al. even aware of being more critical to my suggestions and my knowledge compared to other men’s? Is he unwilling to listen to my questions and suggestions because he unconsciously thinks that I have less technical knowledge than my men colleagues and thereby is lacking trust? How do we communicate when our prejudices are constantly present, not just regarding men-woman relations but also relations between different cultures, races, gender identities, ages and so on? This is a quite complex and multidimensional topic and some people are more open and sensitive to both spoken and non-spoken vibes. Do we need to experience inequality to be able to perceive it? I think not. I think is a matter of taking the effort and time to evaluate own values and believes. To sometimes critically review societal structures, to understand and dare to trust that equality to others don’t mean inequality to me.
#metoo campaign is huge in Sweden and even reached government level. Hashtag technical failure points to the fact that harassment is present in our branch (https://www.thelocal.se/20171120/metoo-technical-failure-swedish-women-in-tech-say-sexist-culture-is-normalized-in-the-industry). If we want to live in a more tolerant and open world, we need to become a majority of men/women/other leading by example, questioning the structures and daring to speak out when encountering injustice.
—Sabina Atic
Thank you, Sabina, for sharing your thoughts with us.

Tuesday, March 13, 2018

Testing Tour Stop #3: Pair Debugging with Thiago

My testing tour continues! Today I had the pleasure to pair with Thiago Amanajás again. In our last session we worked on automating core scenarios of his team's product. In the meantime, Thiago implemented further cases but now had some tests failing. So we decided to first investigate and fix them.

Setting the Stage

The retrospectives of my previous two sessions showed that collaboration styles matter a lot. I resolved to clarify some things right in the beginning of the session. I asked Thiago if he would be up to do strong-style pairing, with one being the driver on the keyboard taking care of the implementation, and the other being the navigator leading the way to the solution. And he was! We decided to switch roles every four minutes. Furthermore, we agreed to try out a mob programming timer tool showing us directly on screen when it's time to take turns so that none of us would need to take care of stopping and restarting a timer while pairing.

Debugging automation. Exploring? Infrastructure issues!

As agreed, we started by having a look at the failing tests. After running the first failing scenario which repeated the same test for all available domains, we discovered that one of the test systems was not available and thus caused the test to fail. We asked a developer about it and found out that the system was up and running but not reachable from the office and that it was a known issue. Now that's interesting, we thought, how would they suppose to test this domain then? Later on we learned that the system was not accessible via wifi; using LAN connection it was.

Well, for now we excluded the concerned domain so we could see if something else was going on here. And by doing so, we found a logic error in the automation code. Great! Fixed it, ran the test again, and - yet another failure, a different domain was complaining now. Okay, let's see. The code compared a given URL with the found URL and stated that they differ. Interesting. We dived deeper and saw that many elements were identified using complicated xpath locators. Hm, according to my experience they are not only hard to read, but also tend to change when implementation changes, and overall are not known to be the fastest. So I asked why not using IDs? And found that the application code did nearly not offer any IDs. Testability could really be improved here! For now, we introduced IDs where we could and returned to our failing test.

We improved the log output to see the actual difference in URLs, ran the test again, and - it failed. We checked and realized that also this domain was not accessible! But wait, we didn't see the log output we added. So we decided to run the test again. It failed again. But not where we expected it to fail! It failed for a domain which just had worked some minutes ago. What was going on here? Our just improved logging of URLs now showed us a really unexpected redirection. We checked the site and found it was marked as insecure due to an invalid certificate. Strange, it didn't happen before! We looked at the dates and found that serendipity helped us uncover an issue. When we started the test, the certificate was still valid, and just when the test came to that domain, the certificate turned invalid as we hit the exact timestamp like the bull's eye!

This made us check the certificates of other domains as well. And we found lots of interesting inconsistencies. Domains running on a certificate for a different domain. A domain with a soon to expire certificate. A domain with a certificate only valid for five days! Here we struggled with the localization of Chrome. We used the Portuguese (Brazil) version of the browser and the certification details date labels said "Inválido Antes de" (invalid before this date), and "Inválido Após" (invalid after that date). This didn't feel intuitive for us. Why stating when it's invalid instead of when it's valid? So we checked the German version and saw that the first label was translated differently to "certificate is valid from this date on". Interesting how different localization approaches can help or impede our understanding.

In the end, we summarized our findings. After clarifying some issues with his team, Thiago resolved to follow up on three things.
  1. Upgrade the infrastructure platform to handle more than ten certificates for the test domains and thus avoid the observed issues
  2. Allow the test systems for the concerned domains be accessible via internal wifi
  3. Create ID attributes for the frontend elements to increase testability

How was it this time?

At the end of our 90 min timebox we did again a short retrospective. We both liked the strong-style pairing a lot, also with the frequent rotation. We had the feeling we shared and learned more this way, especially when compared to our last session.

What really annoyed us, however, was the mob timer we chose to try. The setup was easy and the popup indicating the rotation was gentle and not disturbing; however, we had to restart the timer for each and every rotation again. We changed roles pretty smoothly from the beginning, just grabbing the keyboard and continuing quite naturally as soon as the popup was displayed and the bell ringed. Therefore, having to actively go to the timer to confirm the next round was quite distracting. We would have loved the timer to notify us but just continue counting down the clock so we could stay focused on the task at hand. For my next session I'll definitely look for another timer with that feature.

All in all, we deviated from our path quite a bit, as it's so often the case when you started testing something and that something behaved in a completely different way than you would have expected. So it needed debugging. And then you stumbled across the next issue. And the next. You really wondered why this would behave like this, or show those values. Ending up at a completely different place than intended, but having identified essential problems that need to be taken care of. Exactly what we did, all the while having lots of fun together! It was awesome.

This session showed me again how broad knowledge can be invaluable for a tester, just as really specific core expertise. Being "all over the place" enables you to combine the tools you came across and the skills you learned. Like writing automation to increase your regression safety net. Like using automation to explore strange system behaviors. Like applying infrastructure knowledge to identify the real issues. We cannot know it all, but every single additional piece of knowledge helps us with testing.

Want to join me on my testing tour?

After experiencing some issues when scheduling my next sessions with lots of messages back and forth, I decided to give Calendly a try as I heard a lot of good things about it. The free account offers one event type and lets you integrate the tool with one calendar like Google or Office 365 to show your availability, as well as define additional rules for scheduling. Really important for our international community: It also solves the time zone confusions, as everyone sees the times in their local time.

So in case you like the idea of hands-on practicing testing together and learning from each other, please don't hesitate and schedule a pairing session with me! Looking forward to it :-)

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.