Wednesday, January 31, 2018

Testing Tour Stop #2: Pair Automating with Thiago

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

Diving Into Automation

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

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

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

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

Either Learning or Contributing

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

Observations & Reflections

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

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

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

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

Friday, January 26, 2018

How to Respond to Bad Talk in a Good Way

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

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

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

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

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

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

Friday, January 19, 2018

A Triple Mob Achievement

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

#1 - Getting Invited to Mob Programming Conference 2018

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

#2 - Feedback from My Team

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

#3 - Mob Testing Workshop with My Community

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

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

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

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

Sunday, January 14, 2018

Testing Tour Stop #1: Pair Exploring with Maaret

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

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

The Session

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

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

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

What I Learned about Testing

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

What I Learned about Myself

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

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

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

What I Learned about Pairing

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

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

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

What I Learned about This Experiment

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

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

Where to Next?

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

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