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:
Just like the years before I enjoyed the Agile Testing Days a lot. A fun theme throughout many of the talks were… unicorns and I think Gojko Adzic started it. This affected my brain so much, I said ‘Look, a unicorn!’ to my dog, when I took him for a walk for the first time after I came back from the conference. Actually, the animal crossing our path was a squirrel.
Here’s a short summary of my favourite parts. In order to stay in sync. with the printed & online conference program I’ll start counting the conference days at 0.
Just as the full title “Software Testing Reloaded – So you wanna actually DO something? We’ve got just the workshop for you. Now with even less PowerPoint!” promised, there was only very little PowerPoint and a whole lot of testing & questioning.
I especially liked the way Pete & Matt presented the examples & exercises as well as the reasoning behind them.
There were a lot of games and actual testing. All was very hands on, well explained and debriefed at the end. To give just one example: We tested electronic dice, in order to give an estimation about how long testing would take and to come up with a recommendation whether these dice were ready to be used.
Questions like “Can we ship it now?”, “Is there a pattern/problem there?” and “What actually are the requirements?” were covered.
I also won a price, so my point of view might be biased. 😉
Get them in(volved) by Arie van Bennekum
I found it super interesting to listen to one of the creators of the Agile Manifesto, especially since he pointed out that many of the principles and values have been around before the manifesto was written.
Myths About Agile Testing, De-Bunked byJanet Gregory & Lisa Crispin
Lisa & Janet debunked myths as ‘Testing is dead’, ‘Testers must be able to code’ and ‘Agile = Faster’. Excellent story and fun presentation.
Consensus Talks – 7 10-minute-talks (including mine)
The format of 10-minute talks, all back-to-back and no break included was the one I missed in the previous Agile Testing Days. This way a whole lot of ground is covered in a short time and it’s a great opportunity to explore new techniques in presenting without doing too much harm and/or presenting on conferences for the first time.
Self Coaching by Lasse Koskela
Lasse explained how to coach yourself. After explaining how the human brain works he talked about how to step ‘out of the box’ (your personal point of view) in order to better understand what others actually say and to stay honest to yourself at the same time. Deep knowledge, very well explained indeed.
The MIATPP Award Night 2012 Lisa Crispin won the MIATPP Award. Congratulations!
Test Lab by James Lyndsay & Bart Knaack
This year I went to the “Test Lab” and tested a small LEGO Mindstorm robot, that could move around on a coloured sheet of paper and react, depending which colour its camera would detect. The task: Find out what the specification of the robot is and find defects in its implementation.
Very interesting: We had to come up with a hypothesis of how the robot was supposed to work as well as finding defects. I really enjoyed the way Bart & James gave feedback and asked the right questions.
“Reinventing software quality” – Gojko Adzic
Gojko made the point that in agile testing we might (still) not focus on the right thing: To build the right software. Instead we concentrate on finding bugs and building the software in the right way. He illustrated this with one of his books: He found a defect and then spent a while searching & listing more problems and ended up with a good number of them, definitely enough to make you worry about the quality of the book. However, the publisher explained that essentially all reviews were very positive! So: When people keep paying for your product or service, worrying about defects may not be that important.
“Fast Feedback Teams” – Ola Ellnestam
explained the importance and value of fast feedback. And he’s right: In many projects feedback could be gathered a lot earlier and be used to improve what features are built (as well as how they’re built). Other talks at least touched this topic as well. And while I wholeheartedly agree about this, I’m also a bit worried that we (as software creators) might forget about (or even ignore) slow changing aspects (for more about this see my previous post ‘Slow Feedback Cycles‘).
“Exceptions, Assumptions and Ambiguity: Finding the truth behind the Story” by David Evans
David explained how natural language is ambiguous, unclear and sometimes hard to understand. His examples included part of Jabberwocky (in several natural languages), music lyrics and last but not least programming. Also, I like his short introduction of the Cotswolds.
“It’s the Economy, Stupid! Learn the fundamentals about the one and only argument which will drag your management into agile practices” by Lucius Bobikiewicz
Lucius talked about economic reasons of letting teams focus on 1 (one!) project/product, as opposed to working on multiple projects/products at the same time. It didn’t surprise me much, that letting teams finish one thing and then progress with the next is economically favourable. But I was very surprised how much of a difference it made in the example he presented. These are the main advantages of the 1-project-only team Lucius presented:
The time between the 1st project start and the first paid project (usually at the end of the project) is much smaller, meaning that significantly less money is needed to fund the upfront costs.
Given the limited period of time in which a software can be sold, the product can likely be launched at the optimal time, whereas multi-product-teams may enter the market later and therefore always lag in selling.
Since the overhead of context switching is minimised, the team can work on more projects/products per time unit. This advantage depends on the amount of time needed per context switch and the time the projects take .
The economic point of view Lucius presented was a surprising and welcome detour form the other sessions which were much more focused about technology and/or ‘doing the right thing and doing it right’.
Every morning of the conference days 1-3 Lisa Crispin organised a Lean Coffee in one of the hotel bars. In small groups we discussed topics people were interested in. In order to cover some topics we limited the time for each topic to an initial 8 minutes and then added another 4 minutes depending on a quick vote. I find this is a very fun way to find and discuss topics. Thank you Lisa for organising them!
As a leaving thought: The chair persons were given (foldable) chairs as a present — ‘chairs for the chairs’. Super funny, if a tad bit unpractical to get home via train or airplane.
A big “Thank you!” to José, Uwe and Madelaine as well as the other organisers that made the Agile Testing Days such a great and enjoyable conference.