Making Internal Test Guild Meetings more engaging!?

Hi i’m currently a Training/Meeting Facilitator/organiser (yes bit of a mouthful lol) along side my Snr. Test role.

Past year or so I’ve been working with Test Lead at my firm trying different ways to make our bi-weekly and monthly internal test guild meetings more engaging, fun and insightful and place people can share their recent experiences, learning and having training sessions.

Currently split up into two chunks of specific domains at the company - with a wide range of testers who specify in mobile and web - automation and more on the functional side of testing.

I currently organise the training side of things, get some of the staff to share some presentations, workshops to upskill as every tester has something to bring to the table to share.

engagement can vary - sometimes sessions can be quite tech heavy in a certain area where another tester may not benefit in their current role as they are not using that specific tool on a regular basis etc.
Majority of our sessions are remote due to geological location.

What I want to ask, what cool and engaging test meetings do you have at your organisation? keen to try new things out :slight_smile:


Can I ask what the purpose /objective of the meetings is?

For example is it to actually share info, or build confidence in presenting, or explore new tools, and ideas etc (or maybe all of the above)


Are the guild meetings mandatory or voluntary? the “guild” I have is more of a Community of Practice, with the hook that it is voluntary - but those that show up are the right people and can set the agenda.

It seems that you do presentations, where the members take turns in presenting what they are working on. Perhaps you also have people sharing their learnings from external events (conferences, training, certifications).

A suggestion could be to repeat relevant 30 days of … exercises here in the club: Besides AI there is a range of topics: exploratory testing, … list here


So I have run similar meetings with varied success. You have to tailor to your audience quite a bit and so its useful to start with giving folks a heads up on expectations for the session and rotating the style to see what people are going to react to.

A few attempts I have success with were

  • Walking through a nasty / tricky bug. How it manifested, what tools we needed to reproduce it, what wrong paths did we take when figuring it out, etc. This usually get engagement because people will think of how they would have tested it or how different tools could have helped. It is also a more practical way of teaching this tool can be used like this and help you.

  • Tackling a common problem. Poll the participants on where they feel they spend the most time / effort for the least benefit, then pick one and have targeted meetings on how the tools / skills you have could help resolve it. While it almost always comes down to a variation of “Jira is painful, lets automate it”. Little gains coming out of the meetings will make people want to participate.

  • Testing demos for testing people. In most companies I have worked in testing demos are hard because you always are balancing how proud you are of finding bugs vs not wanting to insult a developer. Doing a more testing focused demo lets people show off a bit more freely.

  • Have folks swarm on a project. I have taken large or new projects and brought them to the quality guild and had them start picking it apart and kinda crowdsource a test plan or if it already exists have folks actually bang on it and share what they are seeing. It can be a mess but it does a good job of sharing alternative ways to approach the problems and can shed light on some expertise that you didn’t know about.

The best advice I can give you on getting engagement is out of the old showman’s playbook, use plants. It feels like cheating because it is but if you can get 1 or 2 people (preferably not your most senior folks) to engage that can lower the barrier of entry for other folks. Especially if they chime in with comments like “Didn’t Alice do something like that last year?” , “Does this mean we don’t have to use tool X anymore?” or “But that’s clearly impossible to automate!” which will get people to unmute and engage.


doing like @jesper suggests and calling it a “community of practice” will allow people to decide if they belong to the guild or not and how much they participate. I started one off where we work and we had one once a month initially. Over time that become fortnightly, and eventually turned into a bit of a stand-up which is more a cross-functional sharing of status than as a COP or guild anymore. We tend to have far fewer “show-and-tell” sessions though now. Because we are cross-team, attendance is not really mandatory.

It’s only about 11 testers but we sit across 5 teams, and we now meet twice a week. So when we give any updates we tend to also inform others in the organization of cross-team developments in flight. All of which helps for whenever there are integrations, but also whenever a team need a few extra bodies.

1 Like

All of the above-

We have a automation specific meeting, a work stream specific meeting (so more domain specific, then more of a global meeting where all testers in the company are invited, this isn’t just restricted to testers though, everyone interested in quality can join :slight_smile:


Yea I agree it is a pretty old school phrase, the meetings are not mandatory just voluntary in a sense, not everybody can make it due to other work commitments etc.

Yep we already have people occasionally share course exp and learning, we recently had a few of our testers share back learnings on a meetup/course they had attended that michael bolton had ran.

thanks I will take a look at that link


Thanks, the old showman playbook idea is great, it does tend to be the same speakers time and time again, allot of the quieter and new testers do occasionally be quiet, i try a more scrum master approach of allowing everyone to speak but i like this idea!


Hi @testymctestington,

Perhaps there’s an idea to be experimented with or adapted from this collection of Software Testing Challenges.

1 Like