Thursday, February 21, 2019

European Testing Conference 2019 - Designed for Us

Last year I got selected to speak at European Testing Conference together with my learning partner, Toyer Mamoojee. It was such an inspiring experience that I knew I had to come again in 2019. And yet again it was amazing!
For this edition I was joining the conference as participant - nothing to do for me than learning together with great people of many different roles and perspectives, all interested in testing. After speaking at many conferences this was a really relaxed experience that I really enjoyed for a change.
Here are the sessions I attended, including my sketchnotes.
As always, I tried to get the most out of the event, not only attending all session slots (I felt I also had the energy to do so), but also making good use of the breaks to talk with people old and new, and of course using the time after the official program was over. After experiencing a lot of conferences during the last few years (a lot more than I ever imagined, thanks to my speaking challenge of 2017), I learned that the unofficial socializing part of a conference is usually the most valuable time spent. Attending sessions is great and a good learning experience, and yet exchanging knowledge and new things learned with my peers is unbeatable.

The great thing about European Testing Conference is that they design the conference so that plenty of these kind of informal learning opportunities and networking chances are available, the space for that is created by intention. You only have to seize the moment! To get further impressions about this very special atmosphere, check out the following links.
One conference was over, and the next one started! I felt really honored and lucky to get the opportunity to attend #ET19 just the day after European Testing Conference. This was my very first peer conference, and also one about a topic very dear to my heart: exploratory testing. For now, I can only say so much: it was great, and it was a lot to take in! I still have to process everything. In the meantime, check out Marianne Duijst's awesome #ET19 sketchnotes.
Last but not least, here are some of my favorite #ETCmoments of 2019! I'm already looking forward to the 2020 edition of European Testing Conference!

Thursday, February 7, 2019

#CodeConfident: Serenity Cucumber Practice

As announced, I plan to publish my coding journal for each GitHub repository I create within my #CodeConfident challenge. I've just finished the scope of my first challenge, so here are my related notes; as raw as they are, in chronological order. My hope is that they will serve three goals.
  1. Act as learning journal for myself, making my learning journey visible helping me acknowledge what I achieved
  2. Provide context for anyone who would like to check out my repository and maybe provide feedback and support
  3. Potentially provide a source of learning and inspiration for anyone else following my journey
Here's my journal for my first GitHub repository serenity-cucumber-practice. Want to provide feedback on it or pair up with me on further challenges? I hereby call for collaboration!

January 13

  • start from Serenity Cucumber starter project (
  • set up remote Chrome running Docker  
  • install TigerVNC for Windows 
  • revise scenario 
  • adapt step definitions -> still successful (gradlew clean test aggregate) 
  • create first page object and try to open it -> not compiling, packages to import "don't exist": "error: package net.serenitybdd.core.pages does not exist" 
  • TODO: fix issue

January 14

  • followed instructions to have page objects in main>java, which resulted in lots of fruitless searching why I got a "error: package does not exist" and the class and import could not be added to the classpath by IntelliJ; tried lots of things until realizing the resolved dependencies are shown in External Libraries for each module in the packages sidebar (always checked in the projects view); move of page object to another place solved the issue
  • "error: package net.serenitybdd.core.pages does not exist"  -> realized it has to be in test as only there dependencies are resolved by gradle build  
  • Selenium Grid setup in Docker is working as usual  
  • TODO: Clean up and do first minimal commit

January 15

January 17

  • generated SSH key and added it (all of -> worked like a charm, IntelliJ saves passphrase
  • discovered -> could delete old branch via UI
  • first version of add item to cart scenario
  • cleaned up a bit
  • revising package structure: learned I need to put everything into one custom package, otherwise test runner fails
  • TODO: improve first scenario, then implement second

January 20

January 24

January 26

January 29

January 30

  • cleaned up branch
  • split different test version into methods to keep code for feedback and be able to switch between them easier
  • none of them is working, need feedback
  • TODO: implement 2 other scenarios on master to finish scope and ask for feedback

February 5

February 6

  • several potential scenarios to try
  • tried to go for categories; stumbled across finding a good selector for menu element, was not interactable
  • switched to extend the search feature by further scenarios; added view product page
  • tried to add view product preview and again element was not interactable; found I was using the mobile site not the website for locating it!
  • learned how to use actions to mouse over the element then the next element is interactable
  • learned how to switch to an iframe (
  • merged latest master into branch
  • TODO: write blog post with learnings, ask for feedback

Calling for Feedback

That's it so far, good enough for now! Your feedback is appreciated.

Thursday, January 24, 2019

#CodeConfident: Getting Started with My Challenge

As soon as I made my challenge for 2019 to become code-confident public, I started thinking about how to tackle it. Drawing on the lessons of my past challenges, I created a Trello board to brainstorm and make things visible. From that starting point until my very first GitHub commit it took me quite some time. On the one hand I was facing other challenges at the same time and I still cannot fully focus on coding yet. On the other hand I honestly did not know how to get from a few familiar first steps to starting for real; and yet things evolved and finally all pieces fell into place.

Kicking Things Off

At work, we started out some months ago revising our legacy test automation through the UI in an incremental way. As it's work related and confidential I can only share generic lessons. Nonetheless, the frequent pair programming sessions are continuously increasing my confidence already, plus I get the feedback I desire to improve.

Still, kicking off my public learning journey was not that easy for me. Starting from my Trello board I added several lists. I brainstormed potential challenges I could tackle, courses and other resources to learn or get inspired from, people that might provide feedback or potential pairing partners, practice sites and last but not least my next todos.
As Calendly turned out to be massively useful when it comes to inviting people to pair up with me, I added a new event there. I read a bit more about licenses and how to properly use them when starting on GitHub. And I read really inspiring posts!

Then there was nothing left than the scariest task so far: decide on the first small challenge and start. I got stuck on that one for a while. Originally, I planned to finish another challenge I have and only afterwards start my coding challenge. However, this way I would have abandoned my challenge for several months which did not leave me with a good feeling. So I decided to mix things and follow my energies when it comes to deciding what to work on right now.

When really considering actual challenges to start with, I realized how comfortable and convenient it would be to just follow the guidance of a course instead of having to make decisions on my own and deliberately wander into the dark. At the same time I already presumed I would learn more by exploring.

Then I realized that defining a fixed scope and setting concrete goals for myself when to stop one coding challenge and move on to the next one was crucial for me to get started at all. My whole challenge is not about perfecting things or choosing exactly the best approach, the goal is practicing and this way eventually becoming more confident when coding.

And finally: If I would start with something I was more familiar with it would be less scary. I mean it would be scary enough to put something out there publicly, right?

This finally freed me up! I picked my first challenge. I made my first commit on my very first public GitHub repository. I nearly did not dare to celebrate it - and then still did it anyway the next day. Didn't regret it so far.
I haven't made much progress on my first coding challenge so far yet, and still I received lots of really encouraging feedback. Thank you everyone who supports me here! It means a lot to me.
Something came to my mind while setting everything up. Many people recommend to spend your time and energy and focus on working on your strengths, not on reducing your weaknesses. I feel more and more that my strength is being a generalist who can fill the gaps. Considering that, I'm indeed working on strengthening my strength right now. Even more important: I'm feeling good about it.

Coding Journal

When designing my challenge, I deliberately limited myself by defining pause and exit criteria for it. Therefore, I wanted to keep track of them early on. As they were depending on calendar weeks, I came up with just creating a new Google calendar and adding a new entry every time I managed to keep going with my challenge by granting myself free time to play a non-casual computer game. As I used Google calendars a lot already, this was a fast, easy and convenient way for me to get the quick visual overview I needed for monitoring.

After doing so, I realized I could also keep track of when I am actually working on things and document what I learned today, what were the next steps to go, and so on. So I added these to the same calendar as well. Yet again, doing one thing triggered another idea.

One of my goals was to spend less time writing lengthy blog posts. They were really valuable for me last year, this year, however, I wanted to use more time to work on hands-on challenges instead. Still, I'd like to preserve my lessons learned for my future self. My first reason why I blog is for my own learning, and only the second one is sharing my learning journey with the rest of the world in case someone cares. So I decided to try out a lightweight approach this time: For each GitHub repository I create, I plan to blog about what I learned on my way as sort of coding journal. Just the raw notes as they are, in chronological order. They might not be easy to follow for readers this way and yet will depict my learning journey as it went.

Only recently I came across a great blog post by Amy Williams about why you should keep a code diary and it clearly reflects my intention here. Give it a read and see for yourself.

Keeping Going

I'd like to spend a bit more time and go a few more steps on my own, then I'll call for collaboration and invite for feedback and hands-on pairing. Also, I hope to be able to focus more on my coding challenge from March on as other things will have been clarified until then. Well, that's at least my hope; I never know what might wait around the corner that will make me adjust my plan.

In conclusion, the challenge is clear. I can only grow more confident by practicing more. The good thing: I have the capacity to practice during my free time and the opportunity to practice at work as well. I consider myself lucky and I'm eager to make good use of it.