The UKSTAR conference is sadly over but what an experience it was. As well as attending some amazing talks, I also took the time to see all the exhibitors, meet and speak to so fellow attendees and visit the huddle area.

The huddle area included a ‘duck pond’ where anyone could enter a competition to win a UKSTAR water bottle (I managed to win one 😊), several board games, and opportunities to discuss a variety of testing topics. One particular event I took part in was the lean coffee session on the tuesday morning.

About 6 people were at the lean coffee event, apparently it is suggested that we have no more than 5 people but we seemed to be ok with the extra person. To start, we were given post-it notes and asked to write down a few topics and stick them on the white board. We then voted on which topics to talk about. Each discussion lasted about 5 minutes with the option to extend this if everyone else agreed that they’d like to continue the discussion. Typically, because of the small group, everyone was given a chance to say something about the topic.

In this post, I am attempting to give a summary of the discussion that took place rather than just present my own opinions.

Why do we attend conferences? How do we know if they are worth it?

The first topic chosen was “How do we know if teams arelearning from conferences?”, although this was merged with another suggestion “Whatconference do you plan to attend next?”.

Not everyone can communicate with confidence what they’ve learnt or what their experiences were when attending a conference. So how do managers and businesses know that the investment was worth it? Most mentioned that they were required to either write a report or do a presentation showing what they’ve learnt. I’ve never shied away from presenting my findings to a team – from either personal research, experiences at work, or attending events like conferences.

I suggested that attending a conference can add to a colleague’s personal development which can improve the way they work. Networking, discussions, and being outside their comfort zone can add to their confidence and communication skills. I’m sometimes worried that I’ll no gain anything from attending a conference, which would be disastrous for myself, the business and my colleagues who may wish to attend similar events in the future. Fortunately, this has never happened.

We all discussed reasons for attending a conference and how we managed to get support from our managers to attend a conference. I focused on specific talks and what I expected to gain from attending this talk. The reasons were mainly focused on learning and networking. Andrew Brown, one of the speakers at the conference, was one of those present and said that he can often only attend a conference if he is speaking. This highlights the issue where people often only have the opportunity to attend conferences if they work at a company willing to invest in its employees that way.

Andrew gave some brilliant advice during the discussion: “Never go to a conference session where you already know the answer”.

How can we find out how we learn?

This question was the basis for our second topic. It is definitely one that is hard to answer. It is something that a lot of people can take years to figure out.

It was mentioned how it can be difficult to engage with certain colleagues, especially when giving presentations. There is often that one person who struggles to understand, maybe because they are disinterested or don’t find presentations as the best learning tool.

Some prefer to read a book or article, some like to listen to podcasts or watch videos, some like to discuss. The preferred methods for learning can be very diverse.

Do Testers need to learn to code?

This was a topic which I suggested so was asked to open the discussion. I suggested 2 different avenues for discussion – Coding for test automation and coding for manual testing.

With test automation it can be easily argued that coding and programming skills are essential. However, with the existence of ‘code-less’* automation tools it may be easy to suggest that we don’t even need to know how to code for that anymore.

With manual testing, technically a tester does not need to know how to code to do manual testing. However, knowledge of the basic programming constructs, can make it easier for them to understand the changes being made to the application better and therefore improve their testing process.

A couple of people suggested that, even though it wasn’t essential for testers to know how to code, having that skill can be good for their career development. Times are changing, which means their job is also likely to change significantly. Knowing how to code can keep a testers options open and allow them to keep up with the times.

Someone made the distinction between reading code and writing code. It was suggested that there were huge benefits in including testers in code reviews. For this, the tester only needs to know how to read code.

It is a topic discussed often throughout the testing community, and one that can go in any direction.


This as the first lean coffee session I’d ever attended. Discussions are short and quick and, with no pre-planning, could go in any direction. With a group of attendees who have never met, there can be an interesting mix of diverse opinions. I will definitely be attending one again in the future if the opportunity arises.

This is the first of a series of blog posts that will cover my experiences at the UKSTAR conference. Feel free to comment with your own thoughts on some of the topics we discussed at the Lean Coffee session.

*I see the term code-less as a misnomer when it comes to test automation. The code may be invisible to the tester, but it still exists in the background. The code is generated automatically as the automated tests are developed.  

Main image from