2020 was the first year, I facilitated a LeanCoffee. Thank you Janet Gregory & Lisa Crispin for inviting me to help! Since this was an online-only conference, we used a web application and Janet selected LeanCoffeeTable. I found it easy enough to use. I particularly like the ability that all participants can enter actions and learnings during the topic discussions as well as generate a PDF to summarise the meeting. I found this a very pleasant experience.
Here are some of the ideas and insights, I kept:
No Testing Column I’ve learned that some teams entirely remove the testing column(s) from their boards. Obviously, this simplifies the board. But more importantly, it also seems to help teams integrate testing tighter with the overall development. This in turn supports teams working as one entity, and not as a number of people who happen to work on the same story.
After all those years: So many topics about testing Even after years, in some cases decades in testing, there are still areas that one can learn about, drive into and possibly thrive in. The next point is one that surprised me a bit.
Automated accessibility testing At least some parts of accessibility (commonly abbreviated a11y) testing can be automated. More on that later.
Productive ensemble testing Test in an ensemble testing (formerly known as ‘mob testing’, similar to mob programming) can be productive even with people that haven’t worked together. This was mentioned by a Lean Coffee participant who joined a group of people (with whom they never worked with before) for a testing session. To their surprise people worked together quite well.
The Last Talk On Software Testing
I had the great pleasure to moderate Rahul Verma’s talk ‘The Last Talk on SoftwareTesting’, where he explained were he thinks the business of tasting (no typo!) went wrong. Entertaining, hilarious and light hearted. And thankfully not actually the last talk on software testing at all. Here’s a very nice summary by Ekaterina Budnikov:
I was really surprised how far automated testing of accessibility is possible – and how easy it is to get started! In addition to that, I found it interesting that automated a11y (the common abbreviation for accessibility) tests can and should be divided into unit and integration tests.
An important learning: The tests that check contrasts (e.g. of text and background) are integration tests: Most often colours are set site using CSS, so not every article, product description etc. needs to be checked individually. Also the computation of how good (or bad) the contrast is, seems to be more time consuming than I thought it is.
For a first step to get some idea of accessibility of a page in Chrome: Using “CMD-OPTION-I” (on a Mac) or “View ➙ Developer ➙ Developer Tools” (via the menu) open the developer tools. Then go to the ‘Lighthouse’ tab & click generate report.
Moderating a New Voices Track
I also really enjoyed moderating Chris Baumann‘s talk ‘Extreme learning situations as testers’. The talk & topic were so good, some of the attendees stayed in the Jitsi room to discuss the topic for the whole next time slot! The following tweets cover some of the ideas & insights Christian shared with us:
I wrote “Fast Feedback Using Ruby” using LeanPub. The original version was published back in 2015. Since I’m updating it to cover the most recent (at the time of this writing) Ruby2.7 and RubyGem versions. I figured, it’s a good idea to leave a trace of my workflow and setup. 🙂
My workflow look like this:
Edit Text (or image) file
Save file to local disk
Commit to local Git repository
Push to GitHub
Generate preview PDF on LeanPub using a (post push) web hook
Have Leanpub automatically push files to Dropbox
Have Dropbox synchronise PDF file to local folder
Restart at 1
Whenever I push changes to GitHub, a new preview of the book is generated and sent to my computer. This means I get frequent and fast feedback about how the newly written text looks.
This nicely fits my working preferences and it also matches the topic of this particular book.
I recently started using Tomcat for a project I’m working on. Since I work on a Mac and am using Homebrew anyway, the installation was as easy:
brew install tomcat
The location of the installed files is /usr/local/Cellar/tomcat on a Mac, BTW. Now, occasionally and out of habit, I run this:
brew update && brew upgrade && brew cleanup
I prefer (usually) small issues with small version jumps to upgrading rarely with bigger version changes (and issues). Also cleaning up seems a good idea, not only on the working desk or kitchen sink.
This time, though, the upgrade removed the previously installed version of Tomcat — including stuff that I had put into a sub folder of the location given above. Not only was the Tomcat installation upgraded, but everything I’ve put in there was gone. 😳
Lesson No. 1: Maybe I shouldn’t have put the stuff there in the first place. Lesson No. 2: Learn how to pin a version of installed software, when using Homebrew.
It’s easy. Use, for example
brew pin tomcat
to, well, pin the tomcat version. To find out later, when you want to upgrade a piece of software and wonder why it does not happen, use
brew list --pinned
to find out, what software is pinned. Last but not least, a package can be unpinned using:
This year at the Agile Testing Days, I attended Samantha Laing and Karen Greaves 1/2-day workshop “The Collaborative Team”. It turned out that there was just one other participant in this tutorial, so actually it was much more like a private coaching session. A big thank you for offering the session anyway and making this possible.
The information and exercises were all about building and keeping trust in the team. I found it very interesting that, in order to increase the trust level, it is also important to know what the team can (and can not) influence.
Knowing this, makes it easier for teams to cope with undesirable situations. For example one of my recent teams was moved out of the building where most other teams are located, to a place some minutes walking down the road. For me, it was much easier to understand and accept this, after we learned about the reasons management gave us. — I still didn’t actually like the situation, but at least it was clear why this decision had been made.
This is a theme we touched in the tutorial time and time again: Talking and listening to each other helps immensely.
Another important takeaway for me were the exercises about the power of questions. The ability and patience to listen to people until they have spoken is so important. I have been given solutions (or suggestions for immediate steps) so often, when instead it would have been important to first understand the problem in more detail, rather than providing the tips that came to mind first. — I admit that I have done this, too.
With the experience from this workshop and the material we were given, I feel much better prepared to help teams improve, not limited to software testing but also in the topics we covered in this coaching session.
I liked the half-day format of the session a lot for two main reasons. First of all, this coaching session with two coaches and two attendees was very intensive and a little bit exhausting (but in a good way). Second of all, I had a free afternoon that I was able to spend in the beautiful city of Potsdam. 🙂
Thank you very much Karen & Sam and of course co-attendee Elena! If you have the chance to get this kind of session at a conference (or elsewhere), I can only and full-heartedly recommend it.
My ‘Day 1’ of this conference ended with a delicious speakers dinner in a very festive atmosphere.