#CodeConfident: FizzBuzz

My previous challenges on my way of becoming code-confident felt too long. Granted, my Serenity Cucumber Practice (part 2, part 3) was my first challenge ever, and during Rest Practice I had a long period of travels. Still, right now I craved for a quick and simple challenge just to practice and learn just a bit more, not overdoing things. Last but not least, I wanted to go one level deeper regarding implementation and testing.

April 23

• decided to practice basic Java, TDD, and baby steps by doing http://codingdojo.org/kata/FizzBuzz/ on my own from scratch (did parts of it in mobs already quite some time ago)
• decided to install the latest stable Java version: https://jdk.java.net/
• create new Java project from scratch, see https://www.jetbrains.com/help/idea/creating-and-running-your-first-java-application.html --> learned new shortcut: Alt+Insert to generate new item
• set up the project as very simple starting point to go baby steps and practice TDD on my own
• added license, readme, gitignore files
• pushed to GitHub

April 24

• changed setup a bit to better suit the purpose
• wrote test for second case, then wrote code to make it pass
• agreed with myself that I will commit frequently, at least every time a new test is passing
• had to remember to run test first, see it fail, then implement, run the test again, see it pass
• baby steps and frequent commits (trying not to care about how elegant the solution is in the beginning as long as it's working) really helped get myself into a flow! Feeling I accomplish something and am on the right track
• first implementation fulfilling requirements was done very quickly
• personal observation: though doing quick commits (even when small) was at first still strange, it now felt a lot more natural to just create a repo and make several commits to it; was so scary in the beginning!!! A lot less already, can be proud :)
• TODO: decide on what else to do, like reduce to required tests
• TODO: finish challenge and seek the next one, this was meant to be a very small and short one

April 25

• removed superfluous tests; checked for code coverage; decided to keep two tests for the same branch, for cases 1 and 2 as the case for 1 is often handled in a special way
• figured that the original implementation also works for 0 and negative values which might be fine or not, not explicitly covered in requirements; would start a conversation about this
• decided to limit the implementation to the number range 1-100; any number out of range should return a related message
• discovered that one of my current coworkers commented on the kata! :D http://codingdojo.org/kata/FizzBuzz/
• I assumed I solved the problem in a very easy and not elegant way; looked for alternative solutions for the problem
• interesting JavaScript solutions: https://ditam.github.io/posts/fizzbuzz/ (oh my, I still have a long way to go understand even only half of them) & https://codeburst.io/javascript-breaking-down-the-shortest-possible-fizzbuzz-answer-94a0ad9d128a & https://www.codecademy.com/en/forum_questions/52ae8600631fe92cc000a168 
• Java solutions: https://codereview.stackexchange.com/questions/74443/fizzbuzz-problem-solution & https://javarevisited.blogspot.com/2015/04/fizzbuzz-solution-in-java-8.html (really liked the Java8 solution using Java 8 Optional, map and Stream map() function) & https://howtodoinjava.com/puzzles/fizzbuzz-solution-java/
• decided to not extend the challenge by extending or changing requirements (at least not on my own ;))
• I'm already eager to move on to the next small challenge!

#CodeConfident: Rest Practice

My second #CodeConfident challenge is finally done! It was all about RESTful services. Here's my coding journal, as raw as it is.

Finally decided on my second code challenge: this time I'm going to practice around the topic of RESTful services. Base project is there now, more to come. https://t.co/LB3fJG7dhY #CodeConfident

— Elisabeth Hocke (@lisihocke) 6. März 2019

March 3

• decided on second code challenge: go one level deeper from UI to API
• https://johnfergusonsmart.com/getting-started-with-rest-api-testing-with-serenity-and-cucumber/
• decided to not use the starter repo https://github.com/serenity-bdd/serenity-rest-starter but to start locally from my previous challenge and adapt it before committing to GitHub
• decided to use Restful Booker by Mark Winteringham as target site
• decided to not use REST Assured as standalone but in combination with SerenityBDD to get nice reporting https://mvnrepository.com/artifact/net.serenity-bdd/serenity-rest-assured/2.0.40
• https://www.blazemeter.com/blog/restful-api-testing-using-serenity-and-rest-assured-a-guide
• http://www.groupkt.com/post/5c85b92f/restful-webservice-to-get-and-search-states-and-territories-of-a-country.htm
• http://www.groupkt.com/post/f2129b88/free-restful-web-services-to-consume-and-test.htm
• TODO: check out starter project structure, connect to Restful Booker, decide on Cucumber or not or both (!), adapt license, adapt readme, decide on doing Postman collection and tests there as well, or maybe doing so in a separate repo
• implemented 2 JUnit tests for Restful Booker deployed on heroku, for test purposes; test data was changed during test which made one fail; still, it's a proof of concept I can build on; maybe choose a different target under test which is more stable
• wrote test for status code and body value in Postman, really easy when using available templates

March 4

• tried to run Restful Booker locally so that maybe test data is not replaced all the time; but the Docker registry is not accessible and I didn't want to install MongoDB (editor's note: later I learned that Mongo was not required to run the app, so I could have used it as test target indeed)
• searched for other practice APIs, at best RESTful
• https://openclassrooms.com/en/courses/3432056-build-your-web-projects-with-rest-apis/3496011-identify-examples-of-rest-apis
• https://openweathermap.org/api
• https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/
• use GitHub API?
• https://jsonplaceholder.typicode.com/
• https://www.guru99.com/restful-web-services.html
• build own RESTful API and test it?
• https://medium.freecodecamp.org/build-restful-api-with-authentication-under-5-minutes-using-loopback-by-expressjs-no-programming-31231b8472ca
• https://hackernoon.com/restful-api-design-step-by-step-guide-2f2c9f9fcdbf
• https://spring.io/guides/gs/rest-service/
• https://leanpub.com/testrestapi
• https://github.com/TracksApp/tracks
• https://www.compendiumdev.co.uk/page.php?title=tools
• https://www.compendiumdev.co.uk/page.php?title=restmud

March 5

• decided to follow a tutorial to create own REST service, then test it with Rest Assured: https://spring.io/guides/tutorials/bookmarks/ This way I will not only learn how to use the library, but gain a deeper understanding how RESTful services are built
• also, it's only one step further into the learning zone, as the tech stack is still familiar
• set up base project using Spring Initializr; added Serenity and REST Assured dependencies; adapted license and readme files
• created new GitHub repo, cloned it, committed base project, configured repo

March 6

• did very first part of https://spring.io/guides/tutorials/bookmarks/
• installed Lombok plugin for IntelliJ
• (did not have much time to proceed)

March 9

• followed rest of tutorial: https://spring.io/guides/tutorials/rest/
• implemented Spring HATEOAS examples (for more see https://github.com/spring-projects/spring-hateoas-examples)
• wrote first tests
• TODO: learn how to write better tests, add more

March 11

• simplified tests
• assertThat not needed, throws the same exceptions as without; REST Assured already handles it
• removed response, added and() for readability
• learned more in https://semaphoreci.com/community/tutorials/testing-rest-endpoints-using-rest-assured; e.g. that "internally, REST Assured uses Groovy and allows for Groovy expressions inside its API"
• added test setup class
• added smoke test before class, does not run any other tests in case it fails
• added test to delete employee, creating it before deletion to stay independent
• changed test formatting to become more readable, as in https://www.joecolantonio.com/rest-testing-with-java-part-two-getting-started-with-rest-assured/
• had "Invalid number of path parameters” exception; solution found in https://stackoverflow.com/questions/39917496/invalid-number-of-path-parameters-expected-0-was-3-error-while-passing-the-u --> after I used pathParam in another test I had to use it in the get first employee test, too
• TODO: find out how to do setup using Serenity Rest, implement further tests

March 12

• pairing session with Amitai Schleier
• we walked through the project, I explained my reasoning behind
• Amitai: the build step includes test, that comes unexpected
• found the included Gradle wrapper was not executable, marked it as such
• we had to add the Lombok annotation to the classpath; this came unexpected, did not already come with the repo or Gradle; we deferred identifying the root cause here; was a great reminder to run a project locally on a fresh computer from time to time to see what's missing
• Amitai: shared he would desire fast tests that can run without the app running, just triggered by a key stroke; however, this comes from the perspective of test driving an app, we're in a different context here
• we learned that the extract method was not instantly comprehensible, not clear what it's doing
• learned about fluent interfaces (see https://en.wikipedia.org/wiki/Fluent_interface); Amitai: they are nicely readable but might not be instantly comprehensible
• we both shared concerns like: do we really need to have multiple given/when/thens in a test when we only want to test one action? How to make sure the deletion test really deleted the record, e.g. by calling it again? How can we declare the base path in a nice way at one place?
• what to test for in which test? Amitai: in general he is thinking of what if this test fails, how hard do I have to think? When it goes red, how obvious is it what I have to do?
• Amitai: uses the following principle when it comes to tests: make it work, make it right, make it fast
• Amitai: using auto-format on save a lot; uses a plugin for Intellij: "Save Actions"
• we committed several changes together throughout the session :)
• we left TODOs in the code to make it obvious for any one else what's troubling and what is still worked on
• learned several IntelliJ shortcuts (for MacOS): that were new to me:
• cmd+9: toggle version control tool window; then cmd+D: on versioned file shows the diff
• option+cmd+K: commit (& push)
• option+P: push
• option+Up/Down: extend / shrink selection
• after test run, double-click on test lets us jump to the test
• retrospective:
• Amitai: already shared his feelings throughout; that was one key learning for him after all the coaching and pairing and mobbing: we don't have to wait to talk about it later, we can talk about it now
• we were feeling the same pain; how much do we have to say to set up a test; it's a screenful and shouldn't be --> could improve it a bit by reformatting and extracting the test data setup in a separate private helper method (did so); this matters as a test should be so simple that we don't need a test for it; it's supposed to serve us
• Amitai in general does like the given / when / then structure
• learned about "TDD as if you meant it" as subcategory; implement class inside test until you come across the first business object (see https://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/)
• we shared similar concerns, like what does the test actually do, test the test, add assertion that content was actually deleted, multiple given when then steps, test setup, etc.
• we didn't use a timer, pairing was fluent, frequently switched, quite natural; we both thought of addressing it but decided to give it a go and it worked well
• I really learned a lot, curious to see how different people tackle different problems, which issues do they see, how they debug and find solutions; e.g. Amitai explored using code and the tests, would have used Postman rather as last resort to find out the behavior
• love the hands-on approach, already improved things right now, have more pointers what to improve next
• TODO: think about formatter, start using the plugin
• TODO: build step includes test
• TODO: see TODOS in the code ;)

Had a great #CodeConfident session today, #pairing with @schmonz! We shared our pain points with my current challenge https://t.co/LB3fJG7dhY and brought it to the next level 🎉 Learned so much. And the best thing is: Amitai already scheduled a second session with me! 🙌

— Elisabeth Hocke (@lisihocke) 12. März 2019

March 12 (cont)

• realized when summarizing the results from the coding session that pushing from my laptop revealed my work email address; and this time we pushed 3 times, so I could not only amend the last commit like I did before (see https://www.git-tower.com/learn/git/faq/change-author-name-email)
• this time I had to rebase and edit the commits; above link showed how to do it:
  git rebase -i -p 4f72861fe2fbee02da716f3442cec263e762b4b6
  git commit --amend --author="lisihocke " --no-edit
  git rebase --continue
• problem: I pushed and merged, and new commits had been created, but the old ones were still there!
• rebased again and tried to drop these commits, but push did not do anything
• learned I need to drop them and then force push to replace the remote repo with my local one, this finally did the trick and the concerned commits are gone; feeling relieved!
  git push -f
• lesson learned, for the second time: be careful what you push..

March 18

• pairing session with Toyer Mamoojee
• walked him through the project, explained the reasoning behind, the targeted scope, steps taken so far, open questions
• we agreed to review what is there for our first session and later have the option to try a different test framework and/or do performance/load testing
• Toyer: first observation: usually we have test only one endpoint per file
• naming conventions for tests: have to agree with the team on that, yet should be consistent; Toyer: test name should include what you are testing for, "getEmployee" feels not enough, better "getEmployeeDetails"; also, there's a mixture right now with using "get" for reading or receiving information and "create" for posting
• Toyer: current test setup class might be sufficient for a practice project for now; would normally have the config in a separate file
• Toyer: the smoke test looks fine; what they usually do is to additionally include a test for the structure, data types, i.e. including contract testing here as well already
• Toyer: get first employee: are you sure this id exists? would extract it as constant; for test data setup they are using a separate database that can be queried, I could think about a catalog here; data should be built somewhere else to avoid duplication, in a different class generating the payload; building the payload might be more elegant as well, instead of adding properties I might create a map; creating it upfront to ensure independence makes sense; maybe can include randomizer here as well to detect more issues
• Toyer: getting information out of the response becomes impossible when you have asynchronous APIs that only return a 200, then you have to query another system
• Toyer: what else I could test for is that only 1 record is created instead of 2, checking the count of what comes back
• maybe I could also check if the generated id is not null
• Toyer: consider splitting tests based on risk; create itself might be crucial and working, only the details might be wrong
• TODO: revise project based on suggestions

Had another great #CodeConfident #pairing session on my practice project https://t.co/LB3fJG7dhY today, this time with my #LearningPartner @tottiLFC. Thank you Toyer for providing your thoughts and feedback - invaluable! We should so do that more often 😁

— Elisabeth Hocke (@lisihocke) 18. März 2019

March 27

• follow-up on last pairing session
• renamed test methods to be more expressive and clearly test methods
• extracted the building of the JSON object
• temporarily switched to org.json objects, switched back to Google's gson implementation again after reading more; the biggest downside for me were the exceptions thrown
• https://stackoverflow.com/questions/42641301/org-json-jsonobject-vs-gson-library-jsonobject
• https://www.baeldung.com/java-org-json
• http://www.doublecloud.org/2015/03/gson-vs-jackson-which-to-use-for-json-in-java/
• https://blog.overops.com/the-ultimate-json-library-json-simple-vs-gson-vs-jackson-vs-json/
• https://www.baeldung.com/jackson-vs-gson
• https://medium.com/@dannydamsky99/heres-why-you-probably-shouldn-t-be-using-the-gson-library-in-2018-4bed5698b78b
• http://tutorials.jenkov.com/java-json/index.html#jackson
• https://proliferay.com/create-json-by-jackson-api/
• introduced constants for existing and non-existing employees
• added check for non-existing employee; check for message fails as response is plain text
• started research how to have JSON response for exceptions instead of plain text
• TODO: resolve todos ;)

April 21

• took up challenge again after a longer period of travels and conferences
• removed superfluous semicolon (bothered me ever since I detected it and did not find the time to remove it earlier)
• thought about running the Spring app together with the tests so you don't have to start the app in advance for the tests, like it's done for Restful Booker Platform; decided that this is out of scope for this challenge, would be interesting for a real app though
• renamed request body to payload
• potential for future: REST Assured can convert back to Java objects, don't need JSON
• ran with coverage, however nothing found covered; learned I need to run the tests on the same JVM for it to work, see https://groups.google.com/forum/#!topic/rest-assured/pzBJQqtkvS0 and https://blog.jayway.com/2014/07/04/integration-testing-a-spring-boot-application/ also, need to run as JUnit not as Gradle task it seems
• doing so I got the error "Error running 'EmployeeTests': Command line is too long. Shorten command line for EmployeeTests or also for JUnit default configuration." --> this fixed it: https://devis.cool/quick-fix/quickfix-intellij-idea-command-line-is-too-long-shorten-command-line-for/
• still, no coverage found; assume I still need the same JVM; using the Serenity Runner cannot run in same JVM, also issues with SpringRunner
• interesting post: https://medium.com/@manu.me/bdd-simplified-with-springboot-b56ffdcadb2b
• did not work so far; also having bootRun as pre-step for test did not trigger tests; however: it's okay to not solve everything in this scope
• stopped, started Test Automation University course by Bas Dijkstra that I wanted to do for so long already: "Automating your API tests with REST Assured" --> filled several knowledge gaps I had and was not aware of - awesome course!!
• added checks for content type
• this way found out how to test for the response content of plain text responses
• observation: by distracting myself / getting my mind to focus on different but related things (the course) I could solve other issues I had before; was really worth it to "unstuck" myself
• added test for updating an employee record
• considering the challenge scope officially done; I'm up for the next challenge! :)

By the way...

First: I learned once again that others appreciate the idea of keeping coding journals as well for their own learning.

Awesome! I'm doing so for my #CodeConfident challenge and it helped so far. Curious what I'll say next year 😅

— Elisabeth Hocke (@lisihocke) 6. April 2019

Second: I did not have to pause my code-confident challenge yet! I've now indeed continued playing a non-casual computer game at least once a week, and it feels great. Definitely worth following my passion and carving out time for it!

Third: My feeling is I have to speed up. Only two challenges of five completed, let alone my final proof of concept app.

Last but not least: I've been pretty busy the last weeks. The good thing: although I could not work on my personal challenges, I still practiced! I've attended Automation in Testing, TestBash Brighton and Mob Programming Conference. A lot was hands-on learning which I really appreciate. Also, I can't but share one of my absolute highlights with you! Thank you Angie Jones for your encouragement, you're the best!

Can I take a moment to shout out @lisihocke?

She attended one of my workshops last year. This year she has set a personal mission to become #CodeConfident.

She's in my new workshop today and the growth is beyond impressive! pic.twitter.com/JIvRkhFKI3

— Angie Jones (@techgirl1908) 4. April 2019

Code-Confident at TestBash Manchester

Remember when I submitted to Test.bash(); in the last hour? Well, I did not exactly get accepted for this very technical format - yet they selected me for TestBash Manchester! Simply couldn't say no to that. So, I will have yet another challenge this year: craft a presentation out of my ongoing challenge. Already playing with some ideas in my head, curious how they will work out with an audience! :)

Yes! Congratulations @lisihocke for bringing your #CodeConfident tour awesomeness to #TestBash Manchester! https://t.co/cKHxCdvmEA

— João Proença (@jrosaproenca) 11. April 2019

Mob Programming Conference 2019 - A Comeback

Remember my joy last year when I got invited to the Mob Programming Conference 2018 as a moberator for the first time? Imagine my joy when Woody Zuill invited me back again for this year's conference! Truth be told, I wholeheartedly hoped for this opportunity and booked my flights for the preceding TestBash Brighton accordingly, allowing me to fly to Boston shortly afterwards.

So, here I was, back in Boston, seeing so many lovely people again, and getting to know many more. It was a wonderful experience. Here's a glimpse into what happened.

Arriving

When I learned that Lennart Fridén would be back on board, I was super happy. We met last year and had some great conversations together, already on the very first evening. This time we could continue, meeting for dinner on the evening for the conference. A wonderful way to get into conference spirit!

I got the best imaginable reception arriving yesterday for #MobProgramming2019. Stumbled into @WoodyZuill’s warm embrace in the hotel lobby and picked @lisihocke’s brilliant brain over dinner.

Lovely! ❤️

— Lennart Fridén (@DevLCSC) 11. April 2019

The Conference

The first day was kicked off by the amazing Linda Rising with her keynote "Experiments: the Good, the Bad, and the Beautiful". It's always a pleasure to listen to Linda's thoughtful and inspiring talks! She's a real master on stage, and a huge role model as well.

"Experiments: the Good, the Bad, and the Beautiful" by @RisingLinda #MobProgramming2019 pic.twitter.com/uwksG3gp7e

— Elisabeth Hocke (@lisihocke) 13. April 2019

Let's try new ways of working with small, simple, fast, and frugal experiments! Thanks to Linda Rising for kicking off the #MobProgramming2019 conference with an inspiring talk.

— Tobias Froehlich (@FroehlichTobias) 11. April 2019

Afterwards it was my time to facilitate a mob session. This year I chose the topic of "Mob Exploratory Testing", evolving a workshop I gave both for another company on my last year's Testing Tour, as well as my own company just recently as a cross-team, cross-role, cross-location mob. It went well and also triggered many new ideas how to improve my mob sessions further. Mission accomplished!

Just gave my "Mob Exploratory Testing" session at #MobProgramming2019 - people learned and practiced hands-on together, making their first steps into testing - it was great! 🎉 #MobProgramming #MobTesting pic.twitter.com/AYjlUEikF4

— Elisabeth Hocke (@lisihocke) 11. April 2019

After lunch it was time for a  lean coffee session. I found myself helping out as facilitator at a table full of co-workers. That really made me think how to encourage people better to spread out and learn from other people's experiences. I get why we prefer to stick together, and yet it feels like a missed opportunity at conferences. On the other hand: this experience proved again why a lean coffee session still makes total sense to have in your own company as well. People came from different teams and learned a lot about each other's challenges and solutions they had no idea about before.

For the afternoon I chose the mob session hold by Chris Lucian from Hunter Industries, where the "original" mob evolved. He introduced us to the "Mob Programming Roleplaying Game - A Powerful Learning Experience". It was developed by Willem Larsen and all material can be found on GitHub for people to give it a try themselves. What I really liked about it: the purpose is to show good behaviors in a mob and thus level up your mobbing skills.

The second day started with a great keynote by Karin Tenelius: "Learning from Self-Managing Organizations". What an impressive journey she is on for a long time now! Karin gathered lots of data why self-managing organizations area win-win for everyone. By the way: I loved the fact that both keynotes were given by strong, knowledgeable, inspiring women. True role models, again.

"Self-managing Organizations - Stories and Lessons Learned" by @ktenelius #MobProgramming2019 pic.twitter.com/YbJrr7unnl

— Elisabeth Hocke (@lisihocke) 13. April 2019

Next up I chose the mob session by Colin Snyder: "When The Mob Encounters 'The New'". He jumped in as replacement for Lisa Crispin and Stephen Vance who unfortunately could not make it to the conference and were dearly missed. I liked Colin's idea of learning something new together as I used this topic myself several times for mob sessions so far. Our little mob ended up in doing first steps in Pearl by doing a coding kata together. Paying nicely into my #CodeConfident challenge! ;-)

After lunch I was very tired, so I spontaneously decided to skip the open space and instead talk with Andrea Zuill and Lennart. What a wonderful, re-energizing and inspiring conversation! One thing that stuck with me after talking with Andrea, who is a children's book author and illustrator: Sometimes it takes a ton of sketches to get a character right. So draw many sketches quickly without trying to improve any of them; instead, instantly move to the next one. If sketches are too refined, they are not sketches anymore ;-) Wise advice and applicable to other areas of life as well.

The last session I chose was Scott Ford's "Mob Programming with Legacy Code". He used the Gilded Rose refactoring kata translated to many different languages by Emily Bache. A wonderful exercise I got first introduced to by Maaret Pyhäjärvi's awesome talk at Selenium Conf India 2018. Alternatively, check out her blog post "Exploring Gilded Rose".

#MobProgramming2019 I was able to attend a few sessions - I would have loved to go to every one of them!

Our Moberators minus one or two. pic.twitter.com/MDd66AGPZf

— Woody Zuill (@WoodyZuill) 11. April 2019

The Social Side of Conferences

I learn a lot from the content shared at conferences in talks and workshops. I learn even more when doing things hands-on together with other people. That's not everything, however. Often I take the most things away from the socializing opportunities offered by or evolving around conferences. Like the evening reception after the first day. Great conversations throughout the evening!

Some introverts like #mobprogramming more than #pairprogramming. Can take breaks when they need to recharge without disrupting the mob. #MobProgramming2019

— Jeremy Kriegel (@sonarc) 12. April 2019

After the conference ended, many of us joined for dinner and the evening was full of inspiring talks as well.

That not being all, the day after the conference, Lennart accompanied me on my sightseeing tour through Boston. Loved it! By the way, in case you'd like to see photos from my conference travels, I've just recently started my own Instagram account. It's private as of now, yet feel free to request access.

To 2020!

The 2019 edition of the Mob Programming Conference came to an end. Yet there are already plans for next year being made! And we know one thing already. We need more moberators, meaning people who facilitate mob sessions, so we could offer more smaller ones to make the conference even more focused on hands-on practicing and learning with each other. If you have mob experience and would be up for facilitating, feel free to reach out to Woody! Or alternatively, Lennart. Or me, as it seems. Time will tell ;-)

And all of a sudden it was over.#MobProgramming2019 was, as always, a blast! I met new and old friends alike. So much warmth and generosity, so much willingness to share and care. A shining beacon in the dark. ❤️

Time to begin the preparations for #MobProgramming2020. Join us!

— Lennart Fridén (@DevLCSC) 13. April 2019

TestBash Brighton & Automation in Testing - A Full Week of Learning

About a week ago, I returned home from a full week of learning. I got selected to speak at Test Bash Brighton 2019, the mother of all TestBashes - feeling super honored! When I learned that Richard Bradshaw and Mark Winteringham offered their three day course "Automation in Testing" just before the conference, I decided to extend my stay by these days.

Automation In Testing

The first time I heard about this topic was by listening to Richard's talk back in 2015 at Agile Testing Days. I got intrigued, and joined Richard's and Mark's related tutorial day the year afterwards. I was super curious how their content evolved. And I did not regret it at all, to the contrary!

They gave the course for the tenth time and thus labeled it their version 1.0. Also, as we started on April 1, a nice little April's fools joke was included ;-)

Checking slides for this weeks #AutomationInTesting, forget that the one a few weeks ago at #TestBash fell on the 1st April, so this was our opening slide, and what we had planned for the next three days… pic.twitter.com/w0iq1ykuVi

— Richard Bradshaw (@FriendlyTester) 14. April 2019

Now, I don't want to spoil the contents of the course. I'd rather heavily recommend that you take it.

What I really liked was that the following things were in focus:

• Testing and us as humans involved
• The multiple ways how automation can help your testing
• The manifold ways existing or self-built tools can help your testing
• How to educate people back home
• Many different hands-on exercises, learning and practicing together, in smaller and larger groups

The people-centered focus of the course was even greater as the participants were a wonderful group of kind people, eager to learn, open to collaborate. They made the course special!

Besides the actual content, I learned a lot about myself once more during the course. We had time to solve a problem on the second day. Our table's group worked very well together before, yet we stumbled in this challenge. Speaking for myself: I found myself pressured by the task at hand, especially by the limited time and the need to justify our decisions well at the end. I found myself not being able to make the jump from our great discussions on architecture and prioritization to actual implementation. I found myself a lot less confident in implementation than I would like to be. I found myself getting paralyzed by the fact that much of what we wanted to do existed already in the project, so what's the point of implementing it again. I found myself realizing the more stressed I am, the less I understand, also acoustically, the more solo I work, the less help I seek - the less I enjoy what I am doing. I found myself getting angry with myself. This was a real grounding experience. The good thing: The next day we found ourselves in different groups, getting a different problem to solve. And we thrived together! The whole table mobbed together, getting all tasks done by bringing all our knowledge, experience, observations and any other skill in. A wonderful experience! Now, all being said: if you have the chance, try it yourself.

The only downside of taking the course was that I missed the overlapping new conference TestBash Essentials. From what I heard from very experienced people, the talks were all super high quality and very welcome reminders of the basics we might have never got taught ourselves! Hope I can catch this new format next time.

The 3 day #AutomationInTesting course by @FriendlyTester & @2bittester was a blast! Valuable concepts to gain a deeper understanding of testing and how automation can help us. Lots of interactive discussions, hands-on exercises, real-life problem solving! Really recommended. #AiT

— Elisabeth Hocke (@lisihocke) 4. April 2019

TestBash Workshops

For the workshop day I chose two that I've wanted to attend for some time now. In Angie Jones' "Clean Coding Practices for Test Automation" workshop she guided us in refactoring a "smelly" automation project, sharing her wisdom of good practices and design patterns for automation throughout. It was great, well structured, easy to follow, giving time to practice and find the solution ourselves before discussing it. I really enjoyed it!

The workshop "Clean Coding Practices for Test Automation" by @techgirl1908 was really enlightening! It was fun to clean up smelly code step by step and discover new solutions and tools to help us. Learned a bunch! #TestBash

— Elisabeth Hocke (@lisihocke) 4. April 2019

In the afternoon I joined Mark Winteringham's workshop "Approval Testing: Superpower Your Automation Feedback". I've heard of the approval testing approach for quite some time now, yet never got my hands on it to give it a try myself. The workshop gave me exactly this opportunity, and I was positively surprised by how easy and fast it was to add valid tests. Even though you had to run them at least once to approve the first snapshot. The workshop was well instructed and easy to follow along.

In the workshop "Approval Testing" by @2bittester I finally could try that approach myself, hands-on. Had my first steps with #ApprovalTests and @Applitools and got to appreciate this approach! Great introduction, well taught. #TestBash

— Elisabeth Hocke (@lisihocke) 4. April 2019

During both workshops, I worked solo. Not my preferred way of working, yet paying well into my #CodeConfident challenge. A personal achievement during Mark's workshop was that I was able to do all exercises quickly and offer my help for others!

TestBash Conference Day

The big day came, and I had the honor to open the conference! In my talk "Cross-team Pair Testing: Lessons of a Testing Traveler" I shared the lessons learned on my Testing Tour. I was overwhelmed by all the positive feedback I received afterwards, both in person and on Twitter! This really added to my confidence. As this if often dearly needed, I established a habit over the last conferences. To make my own achievements visible, I started to list all the feedback I received for myself. Whenever I am having a bad day, that's something to look back into. It really helps me to acknowledge that I indeed could provide value to these people. I am also always creating a Twitter moment and add all tweets to it. I normally don't share these, yet feel free to check it out my TestBash Brighton Twitter moment to see for yourself.

My #Sketchnotes from @lisihocke 's talk at #testbash pic.twitter.com/Sy5scanM0D

— Swanny (Leila) (@swanny) 6. April 2019

#Sketchnote of ⁦@lisihocke⁩’s testing tour at #TestBash - learnt so much, such a great talk ❤️ pic.twitter.com/onlLfL1Nhp

— Marissa 🤖🧚🏻‍♀️ (@MarissaTestsIt) 5. April 2019

“Set out on this journey, join others and please share your travel reports with us.” – @lisihocke #testbash #TestingTour

— Simon Tomes (@simon_tomes) 5. April 2019

Check out @lisihocke testing tour blog https://t.co/OlwaBSpViJ Awesome talk. Thank you #testbash pic.twitter.com/Z3F77XX6yV

— Dan Billing (@TheTestDoctor) 5. April 2019

Seriously inspiring talk by @lisihocke about pair testing beyond your own company. "Co-location is not a requirement but an excuse". Also "If you learn 1 thing from it you are better than you were yesterday" Great stuff! #TestBash

— Ammar Hassan (@ammar_uk) 5. April 2019

The greatest thing: With my talk I could inspire many other people to go on a testing tour themselves, or start pair testing with other testers at their company. The best feedback ever!

Who is going to attempt to do a testing tour next, inspired by @lisihocke talk? I’m up for it if you want to chat. #testbash

— Kim Knup (@Punkmik) 5. April 2019

Yup! After @lisihocke 's @testbash talk, #swannyontour is a thing!

— Swanny (Leila) (@swanny) 6. April 2019

@lisihocke you completely rocked the stage!! Thank you for your talk, you have gotten our wheels moving on testing tours. #testbash

— Emma Keaveny (@EmJayKay80) 5. April 2019

The rest of the day, I created sketchnotes of the talks again - I found I really enjoy this style of note taking during talks. I remember a lot more from the talks, and the community really welcomes me sharing them - so thank you Marianne Duijst once more for your huge inspiration!

• "United by Security: The Test that Divides Us" by Claire Reckless and Jay Harris.

  "United by Security: The Test that Divides Us" by @clairereckless & @JayHarris_Sec #TestBash pic.twitter.com/Dd1Fhu2hSp

  — Elisabeth Hocke (@lisihocke) 6. April 2019

• "Changing Testing Culture in a Ginormous Company" by Jim Holmes.

  "Changing Testing Culture in a Ginormous Company" by @aJimHolmes #TestBash pic.twitter.com/pXgLd5uTJ2

  — Elisabeth Hocke (@lisihocke) 6. April 2019

• "Owning Your Craft" by Mike Smith. This was the only talk I unfortunately could not sketchnote. I always experience a huge down after I have spoken myself, and this was the time I helplessly got distracted. Yet what I heard this was a great talk!
• "Practicalities of Building Communities at Scale" by Lindsay Strydom and Gareth Waterhouse.

  "Practicalities of Building Communities at Scale" by @strydom_lindsay & @gwaterhouse85 #TestBash pic.twitter.com/6ylI3Eg2Qv

  — Elisabeth Hocke (@lisihocke) 6. April 2019

• "Continuous Performance Testing" by Eric Proegler.

  "Continuous Performance Testing" by @ericproegler #TestBash pic.twitter.com/59QSkDYEsl

  — Elisabeth Hocke (@lisihocke) 6. April 2019

• "Testing Biscuits: Benefits of Exploring Other Disciplines and Industries" by Conor Fitzgerald.

  "Testing Biscuits: Benefits of Exploring Other Disciplines and Industries" by @conorfi #TestBash pic.twitter.com/vqO1yIty32

  — Elisabeth Hocke (@lisihocke) 6. April 2019

• "Rise of the Guardians - Testing Machine Learning Algorithms 101" by Patrick Prill. I loved the fact that I could finally listen to a talk of Patrick myself! He is the one who heard the raw versions of my talks and leveled up each and every one of them. I owe him! And I loved his way of breaking down a complex topic in a comprehensible and even entertaining manner.

  "Rise of the Guardians: Testing Machine Learning Algorithms 101" by @TestPappy #TestBash pic.twitter.com/mnIcmByV03

  — Elisabeth Hocke (@lisihocke) 6. April 2019

• "Combating Bias with Heuristics of Diversity" by Ash Coleman.

  "Combating Bias with Heuristics of Diversity" by @AshColeman30 #TestBash pic.twitter.com/zgvGXlHUfS

  — Elisabeth Hocke (@lisihocke) 6. April 2019

When it comes to Marianne, who normally creates wonderful sketchnotes herself: this time she did the amazing endeavor of live blogging the talks. Check them out to get a lot more in-depth impressions of the talks!

That is 6631 words & wrap! Mission #LiveBlogging the #TestBash is completed! See https://t.co/q2ZXGLNcNj for all the liveblogs & add your own notes, thoughts & start the discussion!

— Marianne Duijst (@marianneduijst) 5. April 2019

TestBash Open Space

Saturday came, and it was the sixth day of learning in a row. I had to admit to myself that my brain did not work well anymore. So I've spent most of the open space sessions in the hallway, in conversations with other people. That re-energized again!

The one session that stood out for me personally was the last one where I joined Jay Harris being asked all things hacking and penetration testing. Absolutely informative, learning a bunch!

Relaxing and Looking Forward

The conference was over, and there were few people left. One of them was Melissa Eaden, and we chose to go sightseeing together. We had a lovely time! If you get the chance to, speak with Mel. She is simply amazing. Extremely knowledgeable, inspiring, and simply fun to be around with.

@lisihocke It was a lovely time! Thank you for hanging out with me and exploring Brighton! pic.twitter.com/Dswtt4RrzK

— MelTheTester (@melthetester) 10. April 2019

This conference was made by the community, the people. I loved the reunion with many wonderful beings, such as João Proença, Patrick Prill, Gil Zilberfeld, Gem Hill, Claire Reckless. It was great to meet people for the first time in real life, like Parveen Khan. And it's always great to meet many new people as well, many of them on their first testing conference like Marissa or Georgia Bloyce!

At the Cricketers @melthetester @g33klady @lisihocke @jrosaproenca #TestBash #FirstDay pic.twitter.com/LdQ7xFBvoS

— Gil Zilberfeld (@gil_zilberfeld) 3. April 2019

I had a very great time, and am already looking forward to returning to the UK for my next TestBash - as I got selected to speak at TestBash Manchester as well! For this I will share my journey and lessons learned from my challenge of becoming #CodeConfident. This will be a brand-new presentation - so Patrick, I need you and looking forward to receiving your wonderful feedback! :-)

Calling for Diversity - Tickets for the German Testing Day

The German Testing Day 2019 will take place on June 7th in Frankfurt am Main, preceded by a pre-conference event with workshops the day before. Check out the awesome complete conference program or the one filtered for English talks.

This year I have the honor of giving the opening keynote, and by doing so I have the following conference tickets to give away:

• two tickets including travel assistance, and
• one ticket without travel assistance.

These tickets are intended to increase the diversity of the German Testing Day and to enable people to attend the event who would not be able to come without support. Following Cassandra H. Leung’s great example, here’s how it goes.

How to Apply

Simply let us know why you’d like to attend the German Testing Day this year but cannot come on your own. Maybe you are just starting your career in software testing. Maybe you don’t receive financial support from your employer. Whatever it is, tell us your story!

Please send an email to info[at]germantestingday.info with the subject “GTD 2019 DIVERSITY”.

We are accepting applications from today, Friday, April 12th, until 15:00 CEST on Sunday, May 5th - so go for it and send it in now!

The lucky ones will be contacted shortly after the submission deadline. We’re looking forward to reading your stories. Good luck!

Interested in the finer details? Continue to read.

Who Are We

“We” are Thomas Rinke and Lisi Hocke in particular, responsible for the selection process, and the German Testing Day organizer group in general.

What Is Included and What Not

Tickets with travel assistance. These tickets will provide entry to both the pre-conference sessions and the conference day. Furthermore you will receive up to two hotel nights in one of the conference hotels (which will be booked by the organizers). Travel costs will be reimbursed up to a maximum of 250,- Euro after providing receipts.

Ticket(s) without travel assistance. Theses tickets will provide entry to both the pre-conference sessions and the conference day. Travel and accommodation is not provided, reimbursed or covered in any way.

The tickets are not redeemable for a monetary value.

Requirements for Your Application

To apply, you must be able to attend both the pre-conference event on June 6th, 2019 and the conference day on June 7th, 2019. Besides that, all you need is an interest in testing and quality and your story why we should pick you.

In order to allow us to make the best selection, please also tell us your honest thoughts on how much you depend on the travel assistance.

If you win, you must also provide us with a means of privately sharing information on how to claim the free ticket. An email address is ideal for this.

What Happens if You Win

If you win, you will be provided with instructions how to register for the German Testing Day 2019 free of charge. You will need to provide us with some means of privately sending you this information, preferably an email address. This will only be used for the purpose of contacting you regarding the GTD diversity tickets.

Terms and Conditions & Data Privacy

If you get selected, you will be provided with instructions to register the German Testing Day 2019 free of charge. In order to complete the registration, you will have to agree to SIGS Datacom terms and conditions and data privacy statement. If you decide not to agree, or find that you are not able to attend for any reason, please let us and SIGS Datacom know as soon as possible, so another lucky person can be selected.