Lean Coffee is an example of fortitude and determination. It takes a special kind of person to be willing to be at a meeting at 7:00 a.m. to talk about testing before a full day of talking about testing, but that’s what these folks are here for.

 

Color photo of several participants sitting around a table at Lean Coffee

Early morning conversations at Lean Coffee

For those wondering what Lean Coffee is, it’s a lightly structured meeting where a group gets together, presents a series of topics by writing ideas down on sticky notes, and then the group votes on the topics that most interest them.

Color photo of sticky notes arranged in order for setting Lean Coffee agenda.

Lining up sticky notes and getting ready to vote.

Once we have a list of topics, we vote on the topic that most interest us and then place the topics in order of the votes each topic received. Five minutes gets put on the clock and each topic gets discussed until the time runs out. At that point, the group votes to see if there’s more energy in the topic, or if there’s more interest to keep discussing it. If there’s energy to keep covering the topic, three minutes gets added to the clock and we keep talking until that time is up. We vote again and if there is still energy to keep going, we add another three minutes. IF the topic has been thoroughly covered, then the group may vote to move to the next topic.

Our first topic was asking about how to apply Exploratory Testing in their day to day testing. When a manual tester is looking to include Exploratory Testing into their arsenal, there’s a series of possible heuristics or options that they can apply, but first, consider what they want to do and how they do it. Don’t get too caught up in the idea of having to explain how much time or energy is required to perform the needed testing. Too often, we try to take on too much at the start, and we look at the application as a large monolith that we need to explore. That’s like trying to map a continent standing in one place. That sounds ludicrous, but it’s how we try to approach testing a large application by trying to tackle everything at once. Start small, make small charters, and map a given area within a small section first. Expand as you learn and understand what you are covering. Also, a critical aspect of Exploratory Testing is that you will not be able to test everything, even if you wanted to. Time constraints will likely limit that, so think about the area that is most important or where you believe there is the greatest risk.

Next topic was “Is GUI Automation a waste of time or just over-hyped?” Part of the challenge that GUI automation has to deal with is that tests can often be brittle, or that there is a limited value to a full push of covering GUI automation. Also, while we can test if values entered can be used, or that elements are on the screen, it doesn’t necessarily tell you the user experience or give you an idea as to how those tests will work. It also makes the assumption that GUI Automation is that you are automating all of your interactions via the GUI. It’s also becoming more common to have tests done in different ways, such as interacting with an API or using other tools to check for flow and interaction, such as cURL.

Just two topics today, but it was a good series of discussions. Looking forward to tomorrows conversations.