Sunday, November 3, 2019

On Having Become #CodeConfident

For 2019, I've once more made a pact with my learning partner Toyer Mamoojee. This year my personal challenge was to become code-confident. To learn about my hypothesis, the experiment I designed and who influenced me to embark on this journey, please read the origin story. Now that the challenge is officially over, it's time to look back and forth.

Why This Challenge

Why did I pick this challenge? This question followed me throughout the year. Here are the reasons I discovered on my journey.
  • Programming is a skill that many people benefit from; no matter their role. I think this is the case already now, and presumably even more in the future.
  • Many of my peers in the testing community program every day.
  • People say coding skills are essential for us testers. Even to stay "employable" and get new jobs. Whenever I heard this, I felt I don't belong and that soon enough everyone will see that, too. Even worse, many people consider you only technical when you're able to code. I absolutely don't share these viewpoints, but still felt the need to prove myself that I am not only able to read code but also write code myself. It was about time to conquer this fear of losing my face by showing how much I don't know yet and to see for myself how much I can increase my programming skills in a certain time frame.
  • I feel I „specialize in generalizing“ (as Patrick Prill likes to say) - so I wanted to upskill as a generalist. To strengthen my strength by adding coding to my toolbox.
  • I wanted to be able to help my testing better through automation and tool creation.
  • I wanted to understand our product architecture better, how things work together, where they tend to break, where the risks are.
  • My knowledge is quite broad yet scattered, and never really deep. I have lots of bits and pieces of knowledge and often try to puzzle them together to see the bigger picture. I wanted to see how far I can go with this when it comes to coding. The good thing: I realized I don‘t have to know everything to belong. The main key is to keep yourself aware of your contributions and the value-add you bring, and then to keep going and learning new things, adding to that toolbox you bring.

Continuous Practicing

In the beginning I found the very first steps to be the easiest and the hardest at the same time. If you want to know more, read about my first steps until picking my first coding challenge. As soon as I published my first ever GitHub commit, things started to roll.

As I started out on this coding journey, I soon felt the urge to blog about my experiences and lessons. At the same time I wanted to avoid spending too much effort on blogging and rather put it into practicing. I decided to experiment with a new lightweight blog post type in the form of a coding journal, documenting my raw notes while coding. My hope was was that these kind of posts 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 repositories and maybe provide feedback and support
  3. Potentially provide a source of learning and inspiration for anyone else following my journey
So I had finally started, I blogged about my journey - next thing to do was to call for collaborators, people to pair with me hands-on or provide feedback on my code. Once more I learned about the joy of doing things together when you put trust in each other. Compared to my Testing Tour last year, I did a lot on my own as well. However, I wouldn’t be where I am without my wonderful collaborators, so here’s a huge shout out to these great people!
Not mentioned above but never forgotten are my dear teammates supporting, encouraging and teaching me during work time. Thank you.

Besides those that paired with me, this wonderful community was a great factor and motivator on my journey by providing dearly needed encouragement! Like Angie Jones who recognized my growth in her technical workshops - which meant a lot to me! She even triggered me to submit to Test.bash();. Without her I wouldn’t have presented my lessons from this challenge at TestBash Manchster. Also, during the code-related workshops I attended this year I realized people thanked me for helping them - which made me realize I was indeed able to help them!

After getting started with my first challenge, I decided to go from more familiar topics to the least familiar ones for me. So I came up with the following plan.
  1. Start with automated testing through the UI (though these tests might actually be the most complex, starting with something familiar made perfect sense to me);
  2. Then go a level deeper to API testing;
  3. Then to unit testing;
  4. Now cross over to writing features myself, first implement a small backend feature;
  5. Then implement a small frontend feature.
I hoped afterwards I would already be ready to start my proof of concept project.

Last but not least: while working on my challenges, I had to keep an eye on my self-imposed constraints.
  • Pause criteria - play computer games at least once a week
  • No online courses or tutorials - at least not for the actual practice scope
  • Time - at some point I realized I had to speed up, especially for the TestBash Manchester talk
The great news is: I fulfilled the promise to myself to have at least five repositories of practice projects published on GitHub - even in five months!

Time to Tackle the End Game

As I had hoped, I was now ready to build an application myself. I pondered for a long time what I could do as my final proof of concept app. In the end I decided to create a learning journal. An app that would help me tackle my challenges, based on what I learned so far - and other people could use the same approach. A place to define a challenge, a hypothesis, the experiment. A place to track your progress, to evaluate your results.

So this it was! I created “Journey” - a learning journal application. I wanted to use a similar tech stack to what we have at work. In the end not as similar as I intended yet still really useful for practice.

However, there‘s a twist to it. I decided to kick-start the project so I wouldn’t have to deal with the whole setup. I chose a tool called Jhipster which allows you to generate apps from scratch. Great, right? Well, this approach had upsides and downsides to it. First and foremost: I felt guilty, like I cheated by doing this jump start; while being well aware that at work we also used code generators in the beginning of a project, like the Spring Initalizer or the generated snippets by Angular. It was great to already have a running base to work on; yet the project was bloated from the beginning, with features added that I did not need (like user management or auditing). When you start something from scratch, you know everything (or most of it); with this kick-start, I felt I immediately entered a legacy project, I had to learn how things work together. Yet after all it was still valuable for practice and learning! So I decided to move on with it.

Based on the generated code I then introduced my own entities, created views, modeled what I wanted it to do. What you can do with it is you can define your challenge, and you can create journal entries for your challenge, tracking your progress. Just that, serving as proof of concept. The project is absolutely not finished yet. There's so much more to do, and so much more there could be. It would be a great playground to practice all kinds of testing as well. Though my challenge is done, I can still continue work on it - which feels amazing!

Let's Evaluate

First of all: I could prove my hypothesis true. I did practice, I paired up, and in the end I did develop a small product.

Even more: My whole year was under the focus of coding. At conferences I chose courses, workshops, and talks according to my goal. I attended sessions about mutation testing, automation in testing, clean code practices, approval testing, Python for testers, Jest, and more.

The outcome was indeed actual confidence! End of August I finally realized how much I had worked on code at work over the last weeks. I found myself writing unit tests for our new frontend, to help my developers with our safety net here and to understand our product architecture better to see where it breaks. We were experimenting with mutation testing. I even did some refactoring myself! I finally realized it was the result of having become code-confident (past tense!). To illustrate that, for example I found myself having inner dialogs like the following:
"Okay, now I’m tackling the split of this dialog component into two. Or - nah, maybe someone else should do it, they could do it more efficiently. Or maybe we do it together! Pairing is great. Well, let's have a short look at it first. Oh, that looks like more than I thought it would... Well, whatever, let’s try anyways."
And I was able to do it! In addition, by doing so I understood our application a lot better. The thing is: I would have been capable of doing this before already - yet I didn’t dare to do so. I hesitated, found excuses.  Now I am not afraid anymore to try and to learn by doing. I know there’s a lot more to learn - and that’s fine!
All this made me think. I could stop now with confidence - yet what about if I dare even more? Step even more out of my comfort zone? When preparing my TestBash talk about this whole challenge, my original idea was to have no slides at all, just code, walking people through. Well - obviously I still had slides in the end, I did not dare go without them (yet!). Still I wanted to dare even more. So I decided to do some live coding on stage to show my confidence. I considered that this might go horribly wrong - yet at least I would have tried it. I thought, even if I failed I would have succeeded as I would have dared; and I would have learned what not to do in these situations. ;-) So I prepared for it. I chose my proof of concept project Journey as my target app. I chose a super small change to make it less scary, to not take too long, something that would still allow me to narrate what I am doing at the same time. Small steps, right? Also, I chose a frontend change so people could see the impact right away without me having to restart the app. So that's how I did it - and it worked out!

Plenty of Lessons Learned

There are a lot of lessons to take away from this journey. Let's start with the lessons learned when working with code.
  • Learn how to go in small steps. And then even smaller steps.
  • Googling is a real skill - if you know what to look for it will save you lots of time.
  • Read things carefully. Documentation, exceptions, what methods expect - don't skim over them but read them properly! Sometimes you really need to read everything to get the information you need.
  • Keep maintenance in mind. Would a method now take more than three parameters? Then it's time to refactor as it's getting too big to keep it in the head. One method, one purpose; keep it small. Shall we extract a method for a line that's used in two places? It might not be worth the effort, yet should be consistent. The most elegant solution might not be most readable one, find the middle way.
  • Test the tests. I encountered this classic several times: a test that's constantly green but not checking the right thing (or no thing at all). Sigh.
  • Learn IDE shortcuts by heart; especially for all features you constantly use.
When it comes to code review:
  • Get feedback early and incrementally.
  • Don’t take it personal.
  • Learn from it.
  • Thank people for their feedback.
  • Respond to each feedback.
  • Need to discuss? Then rather discuss in person.
  • Stay patient.
  • It’s scary but worth it!
And finally, I also learned a lot on the personal challenge itself.
  • Learning by exploring is really valuable (and very close to our everyday work). I have a hunch, thought, that it might be best combined with some more structured training.
  • In the end it’s all about practice, practice, practice. It's not about doing things perfect from the start, but about daring imperfection and getting feedback to improve.
  • Pair up for success. (Obviously.)
  • Follow your energies and don’t forget to take breaks. Tired days are not helping. For a private project you have the luxury of leaving a problem for a while and follow your energies instead to keep the momentum. After a while you can either come back to the problem or leave it there (if it’s just for practice); at work we often have to push through, yet defocusing can still help there as well.
Overall, I learned a lot! But I also struggled a lot. My biggest struggle increased my empathy for my developers. Not only the kind of work they do as problem solvers, or having your own work reviewed, but especially when it comes to testing.

When developing I caught myself just wanting to make things work and then move on. The sad truth is, I postponed errors. I sometimes did not test a change at all, neither using exploration nor automation. I just wanted to move to the next change and the next and the next… I really should know better and yet did not care! (Still can't believe this. Super embarrassing.) I really had to remind myself of switching between development and testing modes, or rather intertwine them. This is not easy and I will need to continue practicing. Now I know better how they feel and how difficult it can be to not jump to the next feature.

What else?

Besides this challenge: I‘m finally enjoying my hobby again! As I promised to myself, I played a computer game each week since 2018, December 16th. :D Yet honestly, I struggled to achieve even that. I did not play too much each week. The sad truth is, I dearly needed this personal limit to take better care of myself. So, I'm still working on finding a better balance. We should not put our personal lives behind our personal development.

Now that I survived puzzling bits and pieces of knowledge together to create something myself - I can go back to school! :-) I wanted to fill my theoretical knowledge gaps and get a deeper understanding of the languages, or at least revisit the basics. To begin with, I finally did a bunch of more courses offered by the Test Automation University. By doing so, I discovered that I knew a lot of these things already! This kind of confirmation is a really encouraging. Also, this made me revisit some important concepts that I had heard of already yet never really memorized. As a side effect, I know now that these courses are very worth recommending, they are well taught and provide a wealth of easily accessible, free knowledge. If you haven't done so already, check them out.

At work, I continued to contribute in new ways, using and practicing my coding skills a lot more. This feels so good! Especially as researching real problems open up so many opportunities to learn more.

Oh, and I'm sure there will be another personal challenge for 2020! :-) I'm already thinking about it. Yet no matter what I might choose, I already made a decision to continuously offer pairing sessions, on various topics. Over the last years this proved to be extremely beneficial to all parties. In case you're up for it, feel free to check my availability for the next period on Calendly and book a session with me.

In Summary

If you want to go on your own journey and tackle your own challenge, then break it down so it becomes testable and therefore achievable. Explore using the knowledge you already picked up on your way, and practice! Yet always remember: take care of yourself first.

Thursday, October 31, 2019

#CodeConfident: Journey - Part 4

My Journey application went through a couple of further changes. Here's my coding journal for them.

September 26

  • received security vulnerability report from GitHub, upgraded generator-jhipster
    1 generator-jhipster vulnerability found in package.json 3 days ago
    Upgrade generator-jhipster to version 6.3.1 or later. For example:

    "dependencies": {
      "generator-jhipster": ">=6.3.1"
    "devDependencies": {
      "generator-jhipster": ">=6.3.1"
    Always verify the validity and compatibility of suggestions with your codebase.

    GHSA-mc84-xr9p-938r More information
    high severity
    Vulnerable versions: < 6.3.1
    Patched version: 6.3.1
    Generated code uses repository configuration that downloads over HTTP instead of HTTPS
    Gradle users were using the repositories in plain HTTP, and not HTTPS, so a man-in-the-middle attack was possible at build time.

    Maven users should at least upgrade to 6.3.0 while Gradle users should update to 6.3.1.
    If you are not able to upgrade make sure not to use a Maven repository via http in your build file.

    Replace all custom repository definitions in build.gradle or pom.xml with their https version.


                <url></url> // <-- must be httpS
    maven { url "" } // <-- must be httpS
    For more information
    If you have any questions or comments about this advisory:

    Open an issue in

October 13

  • activated issue tracking for my GitHub repo, added all open todos I am aware of
  • added the projects option, created a project and added open todos to it to provide a better overview and track progress
  • added as guideline how to contribute to the project
  • changed default sorting for journal entries and challenges

October 15

  • Github reported a security alert; upgraded swagger-ui
    1 swagger-ui vulnerability found in package.json 2 hours ago
    Upgrade swagger-ui to version 3.23.11 or later. For example:

    "dependencies": {
      "swagger-ui": ">=3.23.11"
    "devDependencies": {
      "swagger-ui": ">=3.23.11"
    Always verify the validity and compatibility of suggestions with your codebase.

    CVE-2019-17495 More information
    high severity
    Vulnerable versions: < 3.23.11
    Patched version: 3.23.11
    A Cascading Style Sheets (CSS) injection vulnerability in Swagger UI before 3.23.11 allows attackers to use the Relative Path Overwrite (RPO) technique to perform CSS-based input field value exfiltration, such as exfiltration of a CSRF token value. In other words, this product intentionally allows the embedding of untrusted JSON data from remote servers, but it was not previously known that <style>@import within the JSON data was a functional attack method.

October 27

  • pairing session with Michael Kutz
  • our goal was still to introduce Lombok to Journey; as preparation for our pairing session, I recreated the situation where we ended last time, using the @Data annotation from Lombok which caused the equalsVerifier test to fail
  • when debugging the failing test again, Michael noticed that Logback threw an exception:
    WARN in net.logstash.logback.appender.LogstashTcpSocketAppender[LOGSTASH] - Log destination localhost/ connection failed. Connection refused: connect
    This does not cause a problem for the test as we still have log output in the console, yet is something to investigate for later. Maybe deactivate the file appender in case of running tests.
  • we tracked down the difference between the previous "equals" implementation and the one Lombok provides: Lombok does not consider the need for the object instances to have the same id, in the implementation generated by JHipster, however, they need to have an id defined and that to be the same
  • this triggered thoughts that it might not be wise at all to use @Data annotation for entities; Michael remembered a discussion with a colleague and a related blog post and will investigate further --> here it is!
  • as side note: Michael shared that any additional dependency introduced for microservices is a risk in itself as dependencies result in frequent maintenance costs on updates
  • we researched whether we could use the @EqualsAndHashCode annotation configured to include or exclude certain fields
  • Michael questioned the design of the generated code of JHipster regarding entities that are also used as business objects; we have DTOs here as well, which can be considered as objects that construct a JSON object from the entity
  • in the end we decided not to risk using @Data as using Lombok here might lead to unwanted side effects like not persisting entities in the database or creating duplicate ones; these kind of problems tend to surface only much later and are hard to figure out; in the end it was good to have a test for it!
  • instead we decided to use the following specific annotations which still replace a lot of boilerplate code: @Getter, @Setter, @ToString
  • for equals and hashCode we kept the original implementation; equals here will only return true in case the instances have the same id persisted in the database
  • the hashCode implementation which sets it to the magic number of 31 is completely obscure to us; the hashCode is used e.g. in a HashSet to check if an object of this type is already present
  • before committing, we reviewed our change set
  • we discussed where to put the Lombok dependency in the Gradle file; the current list of dependencies is provided by JHipster, using a BOM = Bill of Materials; therefore no specific versions are provided for the dependencies, JHipster will take care of getting the latest versions they have available; this is similarly solved in SpringBoot; we decided to add our new dependency at the very end, considering we would find it again quicker and not miss it when skimming over the JHipster dependencies
  • we discussed our previous sample test for the toString method without and with Lombok; this was rather meant as test to showcase how Lombok works, and build trust in this library; as soon as we trust it, such a test is not useful anymore, so it's not meant to be maintained but rather to help our exploration, so we threw it away; the Lombok toString might be implemented differently now, yet this method in general is only meant to provide a human readable representation of the object, while hashCode is meant as interpretable for a machine
  • when committing, we discussed proper commit messages; Michael recommended the following post: He has trained himself to make use of these recommendations and learned their benefits; we used the same approach here:
    • a) write commit messages as short as possible --> write them in present tense (which is always shorter than past tense), and as imperatives for git
    • b) if you want to provide more information, add an empty line after this "subject" and then write your comments in the third line
    • c) don't write more than 50 characters for the subject or more than 72 characters per line for the rest of the commit message
    • d) start the subject with a capital letter
    • --> IntelliJ settings offer automatic warnings in case such patterns are ignored
  • it's great to reflect on commit messages together with a pair as this helps you become aware of potential ambiguous commits; if a pair cannot formulate a great commit message together, then it might be too big, too early or not ready yet at all; great heuristic!
  • trying to commit, we stumbled across different shortcut settings: per IDE, per operating system, overridden by another program, or using custom ones; for pairing it's great to know the default ones provided by an IDE as well as most people use them
  • Retrospective:
    • I learned a lot again, it's a pleasure to pair with Michael, he takes time and stays patient to explain things well
    • Michael shared it's fun to pair with me, and explaining helps him see where his gaps are, what are only his opinions or more common viewpoints
  • Our pairing session was over, and yet we continued talking for over an hour :) We ended up with a great conversation on the following topics and more:
    • how to structure big test suites, e.g. in teams aiming to cover nearly every bit of code with automated tests
    • what are integration tests, what are service tests, what should they call and what not
    • potential future blog posts, talks, video courses, books
    • Test Automation University
    • public viewing of talks and pairing sessions at work and their discussion afterwards to learn more
    • Agile Testing Days 2019 which starts in a week and where we will meet in person
    • a conference I wasn't aware of yet: SAEC Days
    • paired talks and their specifics; paired workshops and why we should always pair for them
    • exploratory testing and introducing it to developers; how close it is to security testing
    • coaching and career development
    • pairing in general: If Michael sees one person working alone and they are not deleting their emails, then he considers this as waste. They might not know what they do; they need to share their knowledge anyway with the team; if they don't share it's a knowledge silo; feedback like had regarding proper commit messages will be lost as it's mostly not provided at a later point in time; feedback should be timely and constructive anyway and this is a lot easier when pairing. With me, pairing is easy as learning is always my second goal, yet that's not the case with all people. Having people do things alone is always dangerous.
    • code confident: Michael would instantly have me pair in his team and people wouldn't know I'm not a developer. The only difference would be that coding is rather on my breadth than my depth when it comes to my t-shaped skills, which is not bad as pairing is always learning and broadening our skill set. The one most important skill in his opinion when it comes to pairing is curiosity and the thirst for knowledge and I bring that. :D
  • TODO: fix logging configuration for running tests
  • TODO: make use of Lombok in other classes

October 27 (cont)

  • adapted implementation of entities and more to use Lombok as well
  • found some generated integration tests for the user management implementation were broke (already before using Lombok), presumably after one of the latest security fixes --> TODO

October 31

  • pairing with Simon Berner
  • he was also focusing on coding this year, so we had decided to start our session with sharing our experiences and lessons learned, before moving to a hands-on part on Journey
  • when it comes to personal learning challenges, we shared how tempting it is to do too much and loose focus; time is limited and you can only do so much
  • it helped Simon to focus on things he is passionate about, and that he also wants to present at conferences, like the workshop "Git like a Pro" he is soon giving at Let's Test Southafrica
  • he did a sneak peak into everything, learning new things and trying stuff out without any pressure involved
  • we shared our experiences regarding submitting papers at conferences for talks or workshops; we shared how awesome it is that people like Lisa Crispin helps new voices to increase their visibility by pairing up with them; it's hard to kick-start your journey into speaking and this kind of support, sponsorship and encouragement helps immensely
  • we had paired already last year on my Testing Tour, and Simon shared it was a great experience; scary at first to suddenly pair with a stranger, yet now I'm already no stranger anymore and it feels natural to pair; it really helps to share the same interests and work together
  • we talked about the things Simon tried out (check out Simon's GitHub account!); he focused on small examples, learning by doing without having to invest too much time into things; this freedom really helped him
  • sometimes we go to bed frustrated that things don't work as we wanted them to work, and then the next day we catch ourselves thinking: "wait a second..." and we know the solution; you can't force these things to happen, sometimes you need to defocus; despite us asking ourselves "all the others can do it... is it me??", we know that the job is 80% searching, exploring, experimenting, talking with people, and only a tiny part is actual coding
  • we talked about testing, our roles at our companies, how fascinating our job is and how many opportunities it offers; and how often we have to share this with people who are not aware of what this job is about
  • we talked about pairing and mobbing and getting people to give it a try; it's fascinating that with some people this kind of collaboration becomes very natural and you get into a super productive and effective flow; yet with some people you cannot; some people also strongly resist to give things a try, and you cannot force people into something
  • we decided it's time to start the hands-on part
  • I walked him through the Journey project, explaining what JHipster provided when generating the base project, and showed him the project board with the tasks I want to work on
  • Simon instantly went for the top item on the todo list: "journal entries should show the related challenge tag instead of id" I hesitated and warned him this one might be too big for our limited time, yet he said: "why not, let's try it!"
  • we explored the code for the journal entry edit dialog, trying to understand where the challenge ids are coming from and how the drop-down list is populated
  • Simon shared that he really values good documentation, especially in these kind of situations; here we don't have any and also the generated code itself is hard to understand and not self-explanatory
  • Simon shared that when exploring an unknown code base he often deletes things to see where they get used and if they are needed
  • we shared knowledge regarding Visual Studio Code features as it's a newer IDE to both of us; Simon really likes it to be lightweight and having a great ecosystem; he likes IntelliJ for their advanced features like search, yet it's rather the heavy lifter
  • we went slowly step by step, and discovered a method named "trackChallengeById" in the journal update component which returned the id of a challenge; we changed it to return its tag instead, yet this did not do the trick yet; we found the method to be used in the related template, where we also needed to change the call to tag - and it worked!!
  • Retrospective:
    • Lisi: Thank you so much! Especially for the courage of giving this task a try. Amazing. Just within 30 minutes we solved a challenge I spent already many hours on. This clearly shows the benefits of pairing!
    • Simon: This was great! Really happy we could solve it, even when exploring the code for the first time. Let's pair again! 
  • TODO: solve the task for the rest of the views as well :)

Besides that?

I've had the honor to present what I learned on my #CodeConfident challenge at TestBash Manchester - an amazing experience. During the conference's open space, we formed a mob and worked on a coding challenge together. Our goal was to experience this collaborative approach and practice our development skills hands-on together. We made progress but did not manage to finish the challenge in the limited time of the open space. The thing is: I couldn't let go working on the it myself! I did not take notes for this one, and yet I'm still trying to figure out how to upgrade MobTime to latest open Java and JavaFx versions in order to then change it's preset alarm tone (or offer more options). Unfortunately I couldn't get it to run (yet). Still, I learned a bunch on this challenge already - and it's yet another project I'd love to pair (or mob again) on! :)

Sunday, October 6, 2019

TestBash Manchester 2019 - About Learning, Daring and Enjoying

Looking back at the last week of TestBash Manchester 2019, I have to say this was an absolutely amazing week! Thoroughly enjoyed this experience. Brace yourself for quite a lengthy report. ;-)

Arriving in Great Company

Already when boarding my plane to Manchester there was the first nice surprise. Sven Schirmer was going to TestBash as well! The conferring part of conferences officially started for me then.

After arriving at the hotel, we joined the first meetup preceding the workshop days. I really enjoy meeting a few people already before the official program starts. This gets me into the mood and it's not as overwhelming as "meeting" everyone at once.

Together with Sven, Richard Bradshaw, Mark Winteringham, Maaike Brinkhof, Gรถran KeroRick Scott and several more we had a great dinner and lovely conversations. I felt emotionally prepared for the workshop day.

Learning: Workshop Day

I really enjoy workshops for learning, especially when they are hands-on and interactive. This time, I could finally catch a workshop I wanted to join for some time now: "Using Dependency Mapping To Enhance Testing Techniques" by Melissa Eadon. It was great! Exactly met my expectations. Mel emphasized how dependencies are a huge risk in modern development and how everything is about communication. In working groups, each of us drew a dependency map of their team, product or a problem they had. The rest asked questions for clarifications, trying to identify where the problems are and what could be done about them. As simple as it may sound, this visualization exercise was extremely powerful. It helped to get the thoughts and knowledge we have from our brains onto paper so we could discuss about it together. It triggered us to describe the situation while drawing, and the resulting questions caused interesting insights. For example, I realized what part of our product I had nearly forgotten to draw at all; and indeed, this is a part that's not well covered with testing. Another example: by casually answering a question I realized that I had neglected testing one of the most crucial parts of our application! The identified risk areas are a great input to focus further exploratory testing on. Besides that, this exercise would be very interesting to do with lots of people in my team and also across teams. Everyone has a different mental model and this makes it visible, therefore serving as discussion base. As a plus: it's also a relationship-building exercise!

In the afternoon I had the chance to see Emily Bache in action in her workshop "Getting High Coverage Regression Tests Quickly". She introduced us to the concept of approval testing and its characteristics. How you can still do test-driven development, how to handle test failures, how code coverage and mutation testing can guide us. This approach especially comes in handy when it comes to legacy code, yet is also convenient for new projects. The best part of the workshop: Emily provided us four practice projects to work on, in the language of our choosing. Trying out approval testing and covering existing code with tests. One of the persons at my table could not get their IDE setup to work for approval tests, so we decided to pair up. Even better: he was familiar with strong-style pairing and showed great communication skills, so it was a real pleasure to pair up and solve the challenges together. It's just a lot more fun this way! :)

For the evening, I had missed the opportunity to sign up for another meetup, hosted at the BBC. So I ended up with plan B (which should have been plan A in the first place): dinner with Sven, Maaike, Gรถran and Emily! I'm so much enjoying spending valuable time with my community peers.

After dinner, we decided to go for a drink to slowly end the day. And suddenly, to my huge surprise, Patrick Prill was standing in the room! He is the one I test all my talks with at a local meetup. Same about two weeks ago. Yet somehow I haven't asked him if he would also be at TestBash Manchester - I should have! This was an absolutely nice surprise. On the one hand because I really appreciate him as one of the kindest and most insightful human beings on earth. And on the other hand because of my talk. Granted, his presence also made me a tad more nervous, and yet I knew this would be the chance to learn whether I managed to improve my talk. What a nice surprise!

Daring: Conference Day

Then the time had come. The main conference started. Our compรจre: the great Leigh Rathbone! Once more I sketchnoted most of the talks - besides the one directly before mine. Such a pity, I would have loved to learn from Areti Panou's story! Yet I knew I wouldn't be able to focus. I did so many conference sessions already, and yet I can be certain I will be super nervous just before, and super distracted right after my own session (so I didn't catch the 99 second talks either). I learned not to beat myself up because of that anymore.
This time I went last - a great honor, yet my nerves were on edge and showing. Also, this time it was not only a talk for me - there was an even more daring part included as well. On the one hand I shared my lessons learned on my #CodeConfident journey, and on the other hand I proved my increased confidence live on stage with my very first live coding demo! Small and short, and yet really extending my comfort zone. The demo gods were kind to me and all went well, so next time I'm ready for more! For here, I'll let the tweets speak for themselves.
After the conference we all came together for a meetup at a nearby location. Great food, even more great conversations - yet it was extremely noisy and I felt drained. So, a shorter evening for once; the next day another conference day waited for me! Time to get some rest.

Enjoying: Test.bash();

The next day it was time for the second edition of Test.bash(); overall, and my first one. It can be considered a more technical and hands-on focused version of TestBash - and I really enjoyed it. Lots of great talks all over the place, lots of live demos, too. Hosted by the wonderfully energetic Gwen Diagram! I got out of the day with more knowledge and even feeling refreshed.
Right after a great conference day, we all continued with a meetup hosted directly at our venue, The Lowry. Not only that, it was indeed inside its gallery! I love art, so this was a special treat. I thoroughly enjoyed the opportunity to have both great conversations as well as some quiet contemplating time when looking at the great paintings and sketches by this artist from Manchester. Simply awesome. I loved this.

And once more: A great dinner with great friends. Elizabeth Zagroba, Joep Schuurkes, Patrick, Sven, and Geert van de Lisdonk. Thank you for a great time

Open Space

Only one more day to go before TestBash Manchester was finally over. I really looked forward to the open space day, hoping I still had enough energy. Lots of great topics made this easy, I learned a bunch.
  • "Testing without touching" by Joep Schuurkes and Elizabeth Zagroba. What a great session! Our group generated lots of great testing ideas and assumptions to verify, just by looking at the first page of an application. Great exercise, looking forward to taking this back with me to work.
  • "Threat Modelling" by Saskia Coplans & Jay Harris. Always awesome to learn from great security people. This time we threat modeled a service of our choosing to learn which requirements to fulfill to mitigate those threats.
  • "Motivation & Productivity" by Rick Scott. Great exchange about all things productivity hacks and self-motivation. It's not easy to get things done, and everyone is different so we need to learn what works for us.
  • "Accessibility Quiz" by Ady Stokes. This was super insightful! Ady handed out a page full of UI examples illustrating different types of accessibility issues. Great way to learn more how we can include all people and at the same time make the lives of everyone easier!
  • "Tester Growth" by Melissa Eadon. Mel asked all of us three questions: Where do you want to go? Where do you come from? How did you change? Great opportunity to reflect on our own situation as well as listen to the experiences and wishes of my peers.
  • "Practice Mob" session by me, additionally initiated by Joep Schuurkes and Elizabeth Zagroba (who mob with their testing community once a week). We wanted to work on something hands-on, practicing together - using the opportunity of having your peers in one place. Most people were simply interested to experience a mob for the first time, so we went for Joep's idea: let's extend MobTime, my (so far) favorite mob timer! Its drawback: an annoying alarm tone. On our endeavor to change it, we faced several setup issues as the project had not been maintained anymore for longer. Still, the session was great, we made progress, and most of all: so much knowledge was shared within just two hours of mobbing. Loved it!
How to end this evening best? Of course with a nice dinner and some goodbye drinks, with Mel, Joep, Elizabeth, Rick and Geert.

Now this leaves me only with one more thing to say: a huge THANK YOU to organizers and volunteers! You did an amazing job. This was my favorite TestBash so far, and I'll remember it dearly.

Sunday, September 22, 2019

#CodeConfident: Journey - Part 3

The preparations for my upcoming talks at TestBash Manchester and Agile Testing Days kept me pretty busy the last months. Despite them needing lots of attention, I made some further progress on my Journey application to be shared here as part of my coding journal.

September 1

  • compiled todo list for Journey as preparation for next weeks and next pairing session: what to do before my TestBash Manchester talk about my #CodeConfident challenge, and what I could do any time
  • I'm still considering using the GitHub project board feature to make ideas transparent and keep track of them in the future; for now I postponed the decision to a later point when I have more capacity for it again

September 2

  • pairing session with Michael Kutz
  • before we got started we had a great chat about exploratory testing, quality indicators, giving workshops, and the difficulties of switching between developer and tester mindsets :)
  • I explained the project background, what got generated by JHipster and what not, as well as the general purpose of the app and the open todos that I see as of now
  • Michael chose to help me use Lombok to get rid of some boilerplate code (we also use Lombok at work)
  • Michael explained that Lombok is executed before Java, Java ignores the annotations
  • first we checked that I had actually already installed the Lombok plugin for IntelliJ
  • we added Lombok dependencies to the gradle build script
  • added the Lombok @ToString annotation to the Challenge class and removed the related method; in the structure we could now see that the functionality still got generated as virtual method by Lombok
  • to see if things are working out we created a minimal test for this method; it's questionable whether to keep it or not - on the one hand we trust Lombok, on the other hand sometimes maybe not
  • learned a new shortcut to create a test: press Alt+Enter on the class name; for Java it's good practice to keep the test in the same package structure to have access to protected methods; using this shortcut the test will automatically be created in the same structure in the test package
  • JHipster generated the integration tests right next to unit tests; Michael normally keeps integration tests separate, as we also do at work
  • Michael saw that the generated unit tests had been created as public; he shared that this was needed for JUnit4 but is not anymore for JUnit5 so this access modifier can be removed to use default access within the same package instead
  • Michael instructed me when writing this simple test; we kept it really minimal having it only check if it contains a defined tag; if we would keep it we would implement all kinds of checks here
  • when running the test using the IDE we noticed that Lombok had not been recognized; we realized that we needed to activate annotation processing first for the project in IntelliJ
  • now @ToString was working!
  • we tried out the @Data annotation next which includes toString, equals, hashCode, getters and setters implementation
  • we removed the related methods and kept the builder methods that can come in handy when writing tests
  • to see if everything was still working we ran the related integration tests and saw that one test failed: equalsVerifier()
  • we checked this generated test and saw it was very generic
  • we debugged the test to see what happens; I learned that you can simply right-click on any previously executed test and directly re-run it from the offered context menu
  • we could not see yet why the test passed for the previously implemented equal method but not for the one generated by Lombok; and here we ran out of time
  • I learned that you can run gradle commands in a shortcut format, using only the initials of the command; e.g. instead of "gradlew integrationTest" just use "gradlew iT"
  • when trying this I learned that commands were not executable on Unix machines; Michael shared that you can run "gradle wrapper" to set the missing permissions; yet this failed, reporting an error in the gradle file! Another thing to look into
  • Reflection:
    • Michael: it felt like you were using IDEs for years already, you seemed quite code-confident already; you only waited for instructions when it came to writing the unit test, not sure what this was about; Lisi: I had a blackout in this moment, happens to me quite often especially when pairing, often have to look up syntax; Michael: especially as you shared you switch between different languages - I mostly stayed with one which then becomes second nature, routine
    • Michael: really likes pairing a lot; it's super important to read documentation together, to stay on the same page; was happy to navigate me through; Lisi: the session was super insightful and it was very pleasant to pair with you! I was happy to drive and have you navigate, especially with you sharing lots of knowledge, thoughts, your intention, shortcuts to increase efficiency and more.
  • TODO: check: when preparing for the session, it seemed that I messed up liquibase as the checksums did not match on first startup with a fresh database; yet later Michael said he could start the app without problems
  • TODO: when cleaning up, also separate integration tests from unit tests
  • TODO: make gradle scripts executable and commit, they are not running out of the box on a Unix machine
  • TODO: make unit tests private
  • TODO: investigate reported error in the gradle file
  • TODO: investigate failed test when using Lombok and fix, test if everything is still working, then switch to Lombok

September 8

September 15

  • GitHub reported a security vulnerability, asking to upgrade generator-jhipster to version 6.3.0 or later. The details stated it's of critical severity:
Vulnerable versions: < 6.3.0
Patched version: 6.3.0
Account takeover and privilege escalation is possible in applications generated by generator-jhipster before 6.3.0. This is due to a vulnerability in the generated java classes: CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) 
Generated applications must be manually patched, following instructions in the release notes:"
  • upgraded version and adapted the RandomUtil class as suggested
  • ran all tests
  • found that e2e tests tried to run with outdated chromedriver for Chrome 74 instead of 76
  • yet upgrading the related npm package still used the old one
  • could run e2e tests using protractor directly instead:
    npm install -g protractor
    webdriver-manager update
    webdriver-manager start
    protractor src\test\javascript\protractor.conf.js
  • found that three e2e tests now failed after some recent changes where I forgot to run them before; one was asserting for text that I changed, updated this one; two are failing due to changed pagination - need to think of a better solution here for assertions, need to revise these generated tests anyway
  • TODO: refine e2e test assertions for creating & deleting journal entries without depending on pagination configuration
  • TODO: find out how to run e2e tests with latest Chromedriver

September 18

  • reconsidered the open pull request from Toyer Mamoojee to remove Chai as superfluous additional framework
  • the suggested changes did not work out of the box, but threw the following errors: ReferenceError: expect is not defined and WebDriverError: element click intercepted
  • googling did not result into a quick solution
  • decided to keep the tests as they for now and pair on them later on as they need general re-work anyway
  • commented on the PR accordingly and close it for now

Two Exciting Talks Coming Up

TestBash Manchester is getting closer and with it my talk about my #CodeConfident challenge. I had two test runs already, one with members of my power learning group and one at a local meetup. The resulting feedback was invaluable to improve the talk further before going on the conference stage. A special shout-out to Toyer Mamoojee, Joรฃo Proenรงa, Viktorija Manevska, Simon Berner and Patrick Prill! Thank you all so much. The talk is already a lot better because of you.

About a month later, it will be time to enter another keynote stage. I'm feeling especially honored by this fact because of two points. First, it's the keynote stage of Agile Testing Days - the very first conference I've ever attended back in 2015. Second, I will go on this stage together with Toyer, sharing our personal journey as learning partners. If you wonder how it came to that, check out my latest guest post "What a Journey! From Conference Participant to Keynote Speaker" on the Agile Testing Days blog!