Tuesday, April 24, 2018

DevExperience 2018 - A Whole New World

Not too long ago, I got invited to speak at DevExperience 2018. As the conference was scheduled quite soon after my return from Mob Programming Conference, I told them I could only speak if they would accept one of my existing talks. Time would just not have been sufficient to craft a new one. To my surprise, the answer was "We will go with the first talk, which by the way we knew and we already love :)" Awesome! Later I found out, that the conference invited most of the speakers and only few were selected from a call for papers. The conference offered five different tracks, and for each of them the track chair did their research whom to invite. In my case it seems he saw the mobile recording of my talk "'I am Groot - Learning Agile Testing" at Agile Testing Days 2017 and definitely wanted to bring it to their conference. The only thing the organizers asked me is to answer some interview questions for their blog to better advertise their conference. Well, sure! Want to learn more about me?

The next pleasant surprise for me was how easy the organizers made it for me as a speaker. They booked all my travel and accommodation, so neither did I have to spend my own money nor make sure to get it back. They organized a taxi to pick me up at the airport and also bring me back. They asked what I needed for my talk and made sure to provide it. They offered sightseeing tips. They even informed all speakers taking the same flight as I did so we could already start socializing at the airport!

Hanging Out on Saturday

My flight to Iași went via Vienna. There I had the pleasure to meet Bianca Buisman and Nicolas Frankel at the gate, having a nice conversation already. After taking our seats on the plane, Bianca and I were surprised we even had the seats behind each other, although we had selected them ourselves. And believe it or not, the next passenger taking his place next to Bianca suddenly asked us whether we were also going to DevExperience! It was Mark West, the fourth one to go to Iași with us! Had to be fate. Originally I had planned to sleep a bit during the flight as my day had started quite early, but our conversation turned out to be way too interesting to sleep.

Another benefit of arriving together on Saturday afternoon was that we could use the time to go sightseeing together. Mark and I explored the inner city area of Iași together and found some interesting places, enjoying the sunny and warm weather. And some ice cream!
In the evening, the conference organizers took all speakers who already arrived to a nice dinner location and afterwards to a very interesting place to get some tailor-made shots. The place had actually been a former tailor shop, but was transformed to a very small bar where you entered an unremarkable door, followed a narrow corridor, told the barkeeper which style you liked, got your shot, drank it, paid, and left again through the back exit. Brilliant. And tasty! Definitely an insider tip.

Enjoying Culture on Sunday

The next day I decided to sleep in and get some rest before the conference. In the afternoon, some of the speakers met again and went to the Palace of Culture together. We made it to three of the four museums inside - pretty interesting. And then: heading over to the ice cream shop! ;-)

In the evening we had the pleasure to meet most of the other speakers at the speakers dinner. Nice location, nice food, awesome conversations. Time to get to know even more wonderful people! Really enjoyed the evening.

Conference Day

The morning of the conference day, we got a lift from the hotel to the conference venue. Unfortunately we did not have much time before the conference started, so I did not find the time to talk to anyone or even have a short rest. I just grabbed a drink, found a seat and off it went.

The organizers welcomed us with a nice introductory video for the conference - interesting approach, it was well received. Afterwards we heard two keynotes in a row. And then it was time to split into the five different tracks. It was a pity that two tracks, the QA track being one of them, took place on another floor with 13 levels between us. It was already a challenge to find the elevators taking us there. I assume this was one of the reasons that the audience seemed to not mix up a lot between the tracks.

The first session of the QA track was hold by Viktor Slavchev, talking about the mindset of a modern tester. Great session! He started off by asking the audience who was a tester. Many hands were raised. He asked who was a developer. No hands were shown. He asked for any other roles, like coaches or managers, and still no one raised their hands. He, and I as well, were really surprised that we indeed had only testers in the room! It seems this new QA track did indeed attract the people. Still, it was a pity to not have a more diverse audience to spread our messages to.

After lunch, we heard Corina Pip sharing her tips how to properly wait when implementing automated tests with Selenium. Sound advice! I only knew her from Twitter, and it was a pleasure to meet her in real life for the first time.

Then it was time for my talk "'I am Groot - Learning Agile Testing". I gave it several times already so I was not too nervous about it. The session got recorded, and I hope it went well enough that the video would be helpful for others, too. I'm also pretty curious about the attendee's feedback, especially as I didn't receive a lot of feedback in person yet. At least the one I got was positive. 
Seretta Gamba had the last talk slot of the day. She shared her lessons how to best ruin test automation in her experience - a really funny talk, conveying important messages! However, I could not follow her complete talk - as I already learned about myself, I'm loosing focus and energy right after my own slot.

The conference was closed not with a keynote, but with separate panel discussions with the speakers of each track. It was the first time to me to join such a panel, and it was an interesting experience! Sadly, most attendees had already left, but we still had a hard core audience interested in hearing more of our experience and asking several questions.
Now finally our job was done! As I didn't find the time to socialize with anyone else besides the speakers during the conference, I really hoped I could now finally meet some of the attendees at the following party. However, also here I only had one nice conversation and then couldn't find access to the others. Many people left soon. And I ended up with the speakers again. Well, they were awesome!

So, off we went again, going out for drinks and dinner and nice conversations. I had a great evening and would love to meet the people again.
A special shout-out goes to the following people who made the conference extra special for me. Even though this conference was a whole new world for me, conferences are always about the people.
  • Mark West for all our great conversations, the extended sightseeing tours, and the ice cream we had together! :D
  • Eva Lettner for sharing my wavelength, our wonderful talks, for joining my talk as developer and for your instant willingness to do a future talk together with me!
  • Enciu Stoica for selecting my talk in the first place and for his great job as a track chair and panel moderator!
  • Anastasiia Voitova for our great conversations after the conference - thanks for sharing your thoughts with me!
  • Andreea Ignat and all other conference organizers and volunteers for taking very good care of us speakers and making it a great experience for everyone!
While reflecting about this conference, I found myself thinking that I've just started on my speaker journey, and how much I learned already. How much I will still learn. It's indeed quite some effort, but it's definitely worth it!

Sunday, April 22, 2018

Testing Tour Stop #5: Pair Exploring with Lisa

Speaking of tours: last week at the Mob Programming Conference I talked to Lennart Fridén about his journeyman coding tour as a software crafter and his experience with these kind of tours. Just one day later, I had the chance to continue on my own testing tour. And by doing so, a personal dream came true! I pair tested with Lisa Crispin. As she and I both had been invited to the conference, we found ourselves once again located at the same place. What else would be better than making use of that and doing our pair testing session in person!

Sightseeing & Testing - A Perfect Day

The day after the conference, Lisa, Barney and I decided to go sightseeing. We explored Boston's Freedom Trail and had lots of fun together. We even tasted some delicious seafood at a wonderful Italian restaurant. Sounds like testing? Indeed, but the actual testing session only started when we were back at the hotel. Both Lisa and I were pretty tired, but as we were already looking forward to this session for so long we decided to start immediately on our return.

Settling down in one of our hotel rooms at a cozy kitchen counter, we decided to go for an application where Lisa was involved in. She knew it needed testing and that she could forward our results to the respective developers. Therefore it was training for us, but could have a real impact on improving the application as well.

For the following, imagine a web application where organizations can offer services for consumers. Four different roles were implemented.
  • Administrator, administering the system with full access
  • Service provider, offering a service
  • Consumer, consuming the service
  • An interested person, registering for news about the provided services
We decided to use Lisa's laptop, set the MobTime timer to four minutes to switch the driver / navigator roles, and set a mobile phone timer to 80min so we would have 10min left for a retrospective at the end of our session.

All set up, let's go!

At first we decided to explore a feature where Lisa knew that it had been added recently: automatic cancellation of invoices for services that had not taken place. However, already the very first steps left us wondering how the whole invoicing is supposed to work. We figured we might have to set up our test data first. So we started creating new accounts for the service provider and the consumer. By doing so, we stumbled across so many issues! Here are some examples.
  • For offering a specific service, the provider could define a start date and an end date. When we clicked on the same dates in the date picker again, the date value was removed and the field was evaluated as required. Really unexpected!
  • When we defined a start date and then changed it, we got an alert that you cannot save without assigned consumers of the service. In our point of view the form should not save at all before we confirm our entries, and it also should allow us to save without consumers we would not even know yet.
  • When we clicked on the date picker icons, nothing happened; we had to click inside the fields to get the calendar displayed. However, from many similar date pickers of other applications we were used to being able to access the date picker when clicking on the icon.
  • When we had the keyboard focus on the field before the date pickers, then added dates using the mouse, then pressed Tab to jump to the next field, the focus was on the first date picker field instead of the first field after the date pickers as we would have expected.
  • We noticed the form instantly evaluated fields while we were still typing and entering values in the field. The form did not wait until the field lost focus, which we found a really strange behavior. It made me think (or rather cry out) "But I am still typing!". This kind of fast validation was way too fast for my liking and annoyed me a lot.
  • We also raised several questions, like: "It seems you can only cancel a service which is scheduled further in the future, is this behaving as expected?", or "There is a view called 'Approvals pending' without content, but what should it show? Have scheduled services first be approved by anybody? Is this feature used at all?"
In the end we found that we could not even test the new feature. Invoices got not sent out automatically as they should, so we could not test their automatic cancellation either. We decided to switch our focus to security testing instead. And, oh my: what we found was both satisfying and terrifying. Again some examples.
  • We decided to test for access permissions. A consumer must not see any information besides their own profile. We tried if they could access invoices? No, cool. Hm, what about other views we saw when being logged in with other roles? And suddenly we found a treasure trove. A consumer could actually access lots of pages with sensitive confidential data like names, emails, addresses, payments, global settings, and so on. Some pages were indeed forbidden, but many were still accessible.
  • As a consumer, we could successfully create ourselves a discount and then use it. Even a discount of 100%. How convenient, and how bad.
  • Fortunately we did not find a way how a consumer could create their own new admin account.
  • We checked the pages that seemed secure; the actual HTTP request returned a 302 (Found). We would have expected a 403 (Forbidden). A question to ask!
  • When we opened an existing URL where we were lacking permissions, we got a related error message. However, for a non-existing address we got a 404 (Not Found). Here we reached the limit of our knowledge: is the information which pages exist and which not the sort of information hackers could make use of?
  • We found that auto-incrementing IDs had been used for building the URLs. We both knew that this is an anti-pattern as it makes information easily discoverable for hackers. If there is consumer number 21 we know that there had been 20 of them before. We can try and find how many exist. We can track growth over time. Rather use undiscoverable, unordered IDs like UUIDs instead.
While testing, we also came across things like the following.
  • When registering as interested person you needed to provide your country. The country field was grayed out, as if inactive - but it was still editable. Mixed messages here.
  • When loading the consumer homepage, a payment related JavaScript file was loaded; but why? It should not be needed at this point in time.
  • We came across several typos. This way we could also see that sometimes two different translations were used for the same label (like in view and edit modes).
  • We found inconsistent, mismatched namings for web service endpoints and pages, like "/versions" for pending approvals.
  • We saw that the copyright year was still 2017 instead of 2018.
  • The version number of the application was displayed strangely: of "" the two last digits were displayed lower than the rest. Also, the mouse pointer changed to a hand when hovering over the version number as if it was a link, but nothing happened when clicking on it.

In Retrospect

In the beginning, both of us were super tired. But as soon as we started testing together, the time flew by, we got into a flow state and all tiredness was forgotten. Before we knew it the phone alert went off, reminding us that our timebox was over and the retrospective was due.
All in all the session was really fruitful - and super fun! We both learned new test ideas, tricks, insights, and even provided actual value with our results. Meanwhile Lisa also informed me that the forwarded issues had already been fixed - awesome!

From what we saw, we made some assumptions about the application development. Our biggest assumption was that the involved developers worked solo on the application, not sharing much among themselves. What made us think that? We saw inconsistent styles throughout, like differently colored save and cancel buttons, different labels, features only implemented in some views but not in all, etc. We also saw features we did not understand and did not fit the bigger picture; why would they be offered at all?

Although Lisa and I never tested together before, our collaboration was super easy. Also, the mob timer supported us again really well. It gently reminded us to change roles without disturbing. We sometimes caught ourselves to mix up our navigator / driver roles, but we both instantly noticed it ourselves and corrected it immediately. We found sometimes it's hard to resist and that we need further practice, but that the roles are really valuable and our few mistakes did not disturb the session at all. Our assumption regarding our smooth collaboration: pair presenting helps pair testing. And probably also the other way around! Although we didn't test together before, we already had worked together when preparing our workshop for Agile Testing Days 2017. We talked a lot before, we knew each other pretty well, trust had already been established. This definitely helped a lot.

An observation: We did not take common notes of our session. Instead, Lisa made notes for herself to forward to the developers, I made notes specifically needed for this blog post. This only worked out as we waited for each other to finish taking notes before we continued testing. Still, we could have simply taken notes together, without any waiting time. (I should have learned that already from my exploration session with Maaret.)

Equipment is really important when pairing or mobbing. We only had the one laptop with the English keyboard and a small Enter key (which caused me to stumble frequently). We also only had the one laptop screen. If you come into each other's space, it can quickly get uncomfortable. Lisa shared that at her current company Pivotal they try to remove any barriers that could keep people from pairing. They get the keyboard and mouse they want and can carry them around. They also have two big screens to pair, one for the task and one for the video call when remote pairing. People have great noise-cancelling headsets. Everything's made easy for collaboration.

Lisa and I found we complemented each other. We built upon each other's ideas and never got stuck. When doing this alone we would have wasted way more time thinking what we could do next. Furthermore, we kept each other on track and in scope (like Maaret and I did as well in our session). We called it out when one of us wanted to divert from our focus, making clear that this was not important right now. At the same time, we also went deeper ("Let's try one more!") when one of us would not have gone there and found many issues by doing so. We felt that pairing provided more freedom and less anxiousness what to try next. We were way faster like this. Also, structure was really important, especially having the retrospective at the end.

Getting Inspired?

All in all, our session was super fun - thank you Lisa! Now I got already excited about the next stops on my testing tour. It seems some people read Lisa's advertisement (thank you!) as I received further session requests. For example, Jean Ann Harrison already announced her interest about a mob testing session with Lisa and me. That would be awesome! Also, Alex Schladebeck and Cassandra H. Leung scheduled a session - really looking forward to those! In any case, I hope even more people will get inspired and schedule a pair testing session with me.

Tuesday, April 17, 2018

Mob Programming Conference 2018 - All About the People

These days I'm feeling energized. Energized from the manifold conversations with so many wonderful people I had in the last days. I came for the Mob Programming Conference and found a whole bunch of awesome people. We could strengthen old connections and form new ones. And we learned with each other as well as from each other all the way. Just like a conference should be! Many thanks to the wonderful organizers Woody ZuillNancy Van SchooenderwoertLlewellyn Falco and whoever I might miss for inviting me as "moberator". You, the volunteers, the other speakers and the people attending made the conference a full success.

Heading to Boston

A few days before the conference, I was already excited to go to Boston early to attend the third day of the Agile Games Conference which took place the days before. Well, seems I cheered too soon: my flight got canceled due to ongoing strikes. The lucky part was that I had planned to fly early. My booking got changed to the next day and I could still arrive in time for the Mob Programming Conference.
Nancy and Woody were so kind to pick me up from the arrival station and give me a lift to the hotel. As a few other speakers had arrived around the same time, we all headed out to a nearby restaurant together. I love these opportunities to get to know a few people in a small setting before the conference starts! Having some already familiar faces around makes me feel less insecure. This time, I had the pleasure to meet the following most awesome people: Jessica KerrLennart Fridén, and Amitai Schleier. Wonderful.

Conference Day 1

The day started with a short walk over to the venue where a nice breakfast waited. A great chance to have some first conversations. I love to meet people I only know from Twitter finally in real life! Makes such a difference.

Afterwards, the conference program started with Woody giving his opening keynote "Mob Programming and the Power of Flow". Finally I could experience Woody in action! Here are my biggest takeaways of this great keynote.
  • Woody always got the question: "How can we be productive with 5 people at 1 computer?"
    • Woody's first answer: "I don't know. Does that matter?"
    • His second answer: it's not about productivity, it's about effectiveness.
      • Efficiency = doing things right => busywork
      • Productivity = output/input => wrong things
      • Effectiveness = doing right things => right things
    • So the question should be rather: "How can we be effective if we separate the people who should be working together?"
  • Question Queue Time = The amount of time we must wait to get an answer to a question that is blocking us
  • Flow plus flow plus flow
    • We enable individual flow by giving each person the safety and space to think in their own way
    • We enable team flow by working well together
    • We enable lean flow by eliminating queues
After the keynote I joined Lennart's mob session "M.E.L.T. (Mob Exploration & Learning with TIS-100)". It was all about learning together, just like the session I was going to host in the afternoon. So I was really curious how he tackled the topic, and also eager to learn myself. To keep it short: it was a blast! Lennart was (and is) such a great observer, helping us to discover what we learned and what we could improve. Really well done. If you have the chance to attend one of his sessions, do it - it was full of learning and fun, highly recommended! The best thing was that the application he used is an actual game available on Steam. Having such a game really leveled the playing field as you most probably would not have any expert in the group. I already told Lennart I might steal this brilliant idea to introduce people to mob programming! After lunch I had the opportunity to host one of the lean coffee tables. We had a wonderful group, bringing up many topics and having great conversations. And then the time had come for the first of my two mob sessions to facilitate: "Learning to Learn in a Mob". It was a blast! Many thanks to all the wonderful participants making this learning experiment a full success! The first day ended with a reception at a nearby restaurant. And it ended as it started: having wonderful conversations with inspiring people!

Conference Day 2

Yet another great conference day was about to start! It was kicked off by Jessica Kerr with her keynote about "Shared Mental Models". She triggered lots of thoughts and in the end even provided a new title for us! Here are my key takeaways, but you should really watch the to be published recording to get the full message. (Edit: Or read her wonderful blog post about it!)
  • Great teams make great people; not the other way around!
  • We all learned a new word, "symmathesy", and it really fits to what we are doing when mob programming.
    • Sym = together, mathesi = learning; symmathesy = a learning system made from learning parts
    • Or, as Nora Bateson who coined the term writes: "Learning together in context, at all scales", "mutual learning in living systems".
    • Software is the most malleable material we ever had for engineering.
    • The code learns, too, because we change it. All code and things are also part of my team => sociotechnical symmathesy.
  • In order to change the system I have to have a model of it.
  • Downhill invention vs. uphill analysis:
    • Downhill invention: it's easier to do something from scratch.
    • Uphill analysis: it's not easy to analyse existing products or frameworks.
    • You don't know what someone else doesn't know.
    • If you invent something new you have the mental model, you are going downhill. The others trying to use it are going uphill and can't keep up. You can change it faster than they learn the model! Would that mean that you are a 10x developer? In that case only YOU look good.
  • The team-side of productivity is generativity = the difference between the team's outcomes with me vs. without me.
    • We should evaluate teammates by generativity.
    • Obliquity: to become great, put the team first.
    • It's easy to be super productive & negatively generative.
    • "I don't believe in 10x developers, but I do believe in 10x teams."
    • Great developers aren't born. They aren't trained. Great developers are symmathesized.
  • Software is not a craft, it's also not an art, it's the next thing after art.
    • Serious software development is the practice of symmathesy.
    • We can impact so many people, our software changes the world and moves it forward.
    • This makes Jessica a symmathecist, in the medium of software.
    • But it's not only her, it needs a team; everyone who moves an idea forward is part of the idea.
Mindblown. I even changed my Twitter bio after hearing that keynote!

Next up: Lisa Crispin teaching us "Visual Thinking Strategy for Skills that Help you Mob". Visual Thinking Strategy is "a research-based technique that improves creative thinking skills through a facilitated discussion of artworks." It "Helps us practice skills such as observing, brainstorming, reasoning with evidence, critical thinking, storytelling, empathy" and let's us "Back up observations with evidence, build comfort with ambiguity & the unfamiliar" (for more detail see Lisa's slides). Wonderful approach, and fun! I already plan to facilitate a session at my company.

After lunch we had an open space. I used this opportunity to join the Coding Dojo hosted by Woody to learn how he facilitates those sessions hands-on. Interesting experience! Last but not least, my second mob session was coming up: "Mobservations: The Power of Observation in a Mob". Fully focusing on observation skills! This one was more tricky to facilitate than my last session. My room had been changed to one that was not perfect for mobbing, and it was also big enough that I could not only work with the mob alone but also had an audience. A first timer! As if this wasn't enough, the organizers had been informed on short notice that we had to leave the building earlier that expected, so I also had less time for the session than expected and had to leave out a whole part. Considering the circumstances it went quite well, but I would have loved to know what would have happened given the same circumstances as my previous learning mob session.
Conference over? Yes, but not the socializing! Several people joined for a delicious dinner at a nearby restaurant. And there's always this persistent core group going for a drink or two afterwards. I love it when people cannot yet let go of an awesome conference experience!

Finally: Sightseeing!

What's a better conclusion to a conference than going sightseeing together with the people? It was awesome to spend the weekend with several others who had planned some additional days in Boston just like me. Many thanks to Lisa, Barney, Marcus, Nancy, Woody, and Dawna for the awesome time together!

Monday, April 9, 2018

Testing Tour Stop #4: Pair Setting Up Automation with Dianë

Back on the road again! This time, my testing tour made something become reality what I was thinking about for two years already. You read correctly, I said two years. Two years ago my colleague Dianë Xhymshiti joined my company. Although we're working on two different product teams, both teams are literally sitting in the same office since two years. And we never paired before.

In the beginning I was too afraid to pair myself. I wasn't ready to fail safely. Now that the last year taught me so much that I decided to go on this testing tour, this was the perfect opportunity for me to finally make it happen. And I'm really glad about it! Here's what I learned pairing with Dianë.

The Idea

When first agreeing to pair, we considered to practice exploratory testing together, on any application. When making things concrete, however, we found that Dianë currently has a task on her list which she hardly finds time for but which would make her tester life easier. So we decided to give it a shot and pair on setting up automation through the UI for one of her team's applications. In addition, Dianë wanted to learn more about Cucumber, and I wanted to finally try out the Screenplay Pattern I learned about at last year's Agile Testing Days.

We both researched a bit about our topic before and started the session by sharing our ideas. I came from the perspective of what we are using in my product team which is SerenityBDD together with Cucumber. The latest version does support and even favor the Screenplay Pattern. However, we have quite an old version in place as well as a lot of legacy and anti-patterns in the code from our initial learning phase. I was eager to learn more about the newest version as input for completely revising our tests. Dianë's team instead is using Protractor for another application, and she thought about trying it out in combination with Cucumber and the Screenplay Pattern for this new use case. As our target system under test was Dianë's, we decided to go for her approach, follow a tutorial she found to get started and then continue from there. We also agreed on the following.
  • We used Dianë's laptop as it shows an English keyboard layout which is easier to use than my German one.
  • We connected an external screen and used the laptop screen as additional one.
  • We paired strong-style, switching navigator and driver roles every four minutes.
  • We tried out MobTime, a mob timer application I haven't used so far, running on my laptop standing at the side.

Achievements, Challenges and Other Lessons

When following the tutorial steps on how to setup Protractor in IntelliJ, we were delighted how smoothly and quickly it went. It only took us a few minutes to have a first example test running. We only stumbled once when IntelliJ complained about our spec file. Seems we missed to copy over the closing brackets from the tutorial example; easily fixed. Speaking of the tutorial itself and other resources we came across during our session, several issues quickly caught our eyes, like having step 9 before step 8, or checking for the "4rd" element. Documentation can be buggy, too, it also needs to be tested. Besides such more obvious things like ordering or grammar, it might not fulfill the need of the one who's reading it. If that's the case, sometimes you need to switch to another resource.

We came across two question marks right in the beginning.
  1. How to name the kind of tests we intended? They got sold to the team as "acceptance tests". The team also had another set of "end-to-end" tests defined already (by the way, I love Katrina Clokie's post about the different meanings of end-to-end). Dianë and I were both not quite convinced regarding this kind of naming. We were feeling confused about the many different terms many different teams use to refer to the same or often different kind of things. To not get stuck, we decided to go with the communicated name of "acceptance tests" for now and postpone the final decision.
  2. How to add the new dependencies to the existing project? The tutorial let us install everything for our local environment. But what about running the tests in our build pipeline on the server? Even though we frequently discussed automation setups and testing requirements with our developers, we normally only built upon what's already there and rarely set up things from scratch. We decided to postpone clarification of this part as well for now. Still, I could share what I learned from my developers, like the handy shortcut of copying over the needed Gradle dependency statement from the Maven Repository, for example for Selenium
After successfully having our first dummy example test running, we wanted to adapt it to be a real example for the actual system under test. Once again we noticed how often IDs are missing on elements to have them easily located; it seems people have to make an extra effort to consider testability when developing web pages. Well, we used this circumstance to refresh our locator knowledge and how to validate selectors using the Chrome DevTools.

All in all, the first steps were pretty straight forward; and then we stumbled heavily. We "just" wanted to verify that the expected page had been loaded. So we located an element and wanted to see if it's present. But no such methods were offered on the element! We checked the already existing Protractor tests in the other project and found that the expected methods were indeed offered on elements. What did we miss when setting up our automation basis then? The whole rest of our session we tried to find out where the mistake in our thinking was, trying out different things and searching for answers online. We generated further ideas what to try but could not find the solution yet. However, due to our Google research, I learned about how others search for answers. Dianë for her part suggested to search for a video and then quickly scanned through it to see if the content was helpful. I never realized before that YouTube offered shortcuts for that!
  • L: jump 10 seconds forward
  • K: pause/play video
  • J: jump 10 seconds backwards

In Retrospect

First of all, collaboration was nice and easy. Only very few times we ignored the timer and continued with our previous roles of driver/navigator. Rarely we mixed up the roles, like having the navigator type keys or the driver deciding what to do. All in all, everything went smoothly. Well, we know each other for two years already, so trust, communication or general understanding was not an issue at all.

Working on a foreign computer and setup is still hard. Even though I did it now several times due to frequent mob and pairing session, my finger muscle memory still wanted to go for a German keyboard layout and my eyes had to scan the English keyboard for the needed characters. On the level of "Where was the semicolon again?" I always need a short period of actively having my brain switch to the other keyboard layout. Same with picking up different scrolling directions. However, during this session the two screens confused me several times. We had them standing one behind each other instead of side by side, which triggered a severe "on which side of the screen can I move my mouse to the other one" kind of problem.

The mob timer program we used this time was surprisingly great. After the disappointment of last time, I didn't expect the next application I tried to work so well, but it did. It was yet another recommendation taken out of Maaret Pyhäjärvi's and Llewellyn Falco's awesome "Mob Programming Guidebook". I hesitated to try this one as I favored web applications and this one needs to be installed on the computer. But the setup is very easy, the UI simple and clear, when the timer runs it's only displayed really small on the bottom of the screen so it's not disturbing, and as soon as the timer is up it pops up to the foreground. This application had us to confirm starting the next round just like the last one did, but this time I did not feel annoyed by it, rather supported by the tool. Next time I would love to give MobTime another try, but running on the laptop we actually work on.

We started out very fast and straight-forward towards our goal, and then got sidetracked and confused in trying to find out what we were missing. Unfortunately this did not bring us closer to our original goal of trying Protractor with Cucumber and the Screenplay pattern. We couldn't even touch those topics. The session was still valuable for both of us and we had to create a basis anyway; but we definitely lost our focus. In hindsight, I think we should have shared our initial preparation for the session instead of doing it on our own. A different kind of start might have helped us to get farther towards our end goal. Another option would have been to begin our session with googling for the main intention we had. When I did so while writing this blog post, I came across a really promising framework which seems to fulfill all the initial intentions. Serenity/JS seems to combine everything we wanted to try: Protractor, SerenityBDD, Cucumber, the Screenplay Pattern. I also quickly found tutorials and getting started projects. Would love to try that next time! Really happy that Dianë and I already agreed to have another pairing session.

How to Become Part of My Testing Tour

The answer is pretty simple: just schedule a pairing session with me using Calendly! If the offered times really don't suit you, or in case you have any further questions upfront, feel free to send me a direct message on Twitter. Looking forward to pairing with you!

Thursday, March 29, 2018

Get up and share! A Shout-out to the Community

The last 2.5 years have been awesome. The past 1.5 years crazy. And the last 0.5 year overwhelmingly phenomenal.

Today I saw a tweet of Agile Testing Days that my newbie talk last year made it to the top ten talks; and it absolutely made my day.
Shortly after, I decided to send another tweet.
And as I saw the manifold positive reaction of the community around me, my day became even better. I'm so thankful to be part of it! This made me think: How did I get there? Here's the only answer I have, and I'll leave it rough and raw this time.

The Time Before

As my first job as a tester came to an end in 2011, I discovered Twitter and the testing community there. It made me start following them on Twitter.
Then cautiously shared some bits and pieces.
Got heavily encouraged by Lisa Crispin who suddenly followed me back!
Quite some time passed, but then I saw so many tweets about Agile Testing Days 2014. And I knew I had to go there!

2.5 Years Ago

So I did attend Agile Testing Days, in 2015.
And finally met Lisa in person! She encouraged me to speak at conferences myself. What, me? Nah...
End of the same year I changed jobs. After a period of projects, I finally returned to product development.
I encountered a really safe environment. Got valued and appreciated as a tester.
I grew. I tried things. I experimented, together with my team. I got lots of support. Strong leaders encouraging me. Trusting in me!

1.5 Years Ago

Back to Agile Testing Days in 2016. (I will always return to this conference; I'm biased as it was my first, but I love it.) It was massively inspiring.
And the best: I met Toyer! Accepted his deal to return next year as speakers. We became learning partners, and really took on this challenge!
I finally started to blog (by stopping overthinking it).
Started to tweet even more.
Started to finally overcome my fears and attended meetups. (First time in my life!)
Submitted to conferences; Agile Testing Days as well. (Of course.)
Got invited by Lisa to do a workshop with her!! Too good to be true.
And then also got selected to give a talk! For other conferences as well. Never expected that.
Now I had to do this. So I prepared and practiced a lot.
And got up on stage. Speaking! For the first time.
This way, got to know even more people in the community; especially the many other speakers. What a wealth of wonderful minds to learn from!
Time to celebrate.

The Past 0.5 Year

I'm absolutely stunned about the reaction of people around me. All this going out of my comfort zone and sharing increased my visibility in the community A LOT.
I even got invited to conferences! Never would have imagined that.
So tempting now to continue and submit further papers. (So I did).
Got selected to talk at further conferences this year as well!
This gained me the opportunity to attend even more conferences this year. I will meet again the awesome people I already know. I will meet even more people, gain more supporters, get more feedback, grow more.
I just love this community.


All this came not by its own. I consider myself really lucky: I have so many supporters around me who help me fly, and it's getting easier every day! I don't do anything differently than I have done before; besides one thing: I started to share. Publicly. And yes, I invested a lot of effort in that to make it happen. And also, I still have so many things to learn! Every day I learn how many more, and how many awesome people are already out there! I'm not the best tester, I'm not the most knowledgeable person when it comes to tools, communication, or anything; and I definitely haven't got all the answers. What the past 2.5 years taught me is that I don't have to be all that. You don't have to be. All I have is the experience I have. As simple as that. Plus: I now share it for those who decide to listen.

It took me quite some time to realize that throughout the past years, I already had made more and more small steps out of my comfort zone, learning on my way in my own pace. Starting sharing got me the visibility that accelerated my learning a lot. I can only recommend to get up, go out there into the learning zone, and share. Discover that awesome community yourself that made my day.

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 :-)