I’m looking to schedule a bi-weekly meeting of our team’s QAs and QEs to discuss current projects, upcoming projects, do demos of automation, showcase new technology or testing tools or processes, challenges or bottlenecks, areas for improvement , tips / tricks / hacks / wish-somebody-had-told-me’s, etc. Q: What other things are you all discussing in your QA team meetings?
7 Likes
During several years and 6 workplaces, I had one that had these meetings.
They were done for about 4 months (once every 2-3 weeks)
- it was more like a status report to the manager
- the manager was updating the testers with the latest news.
3 Likes
Thanks for having responded, @ipstefan. But, this meeting will be for QA-only, no managers or other team members. It will be a safe place for us to discuss anything QA-related (to the benefit of the whole team). Q: Why did these meetings only last for four months for you? I’m curious…
2 Likes
Hi @yelbmik1
Sounds like you have a great approach and plan for the meetings already.
That is exactly what we discuss in our guild meetings (weekly), but is only a team of 4.
Admittedly, we do get off on a tangent discussing ‘gripes and grumbles’ which I advise to take to retro!
But yeah, an update on automation solutions, any new way of working, how to, training needs, and general ‘State of play’ is our approach.
We are a remote team, so it is also a sort of “welfare check”, and much-needed opportunity to have input.
6 Likes
The structure and focus of QA team meetings can vary significantly depending on several factors within the company. It’s important to consider whether QAs are integrated into feature teams or operate as a separate testing unit. The distinction between manual and automation QA roles and the company’s size and team composition also play a crucial role.
Some potential activities for these meetings:
- Business Knowledge Sharing: Ensuring everyone is aligned with the business aspects and objectives.
- Production Incident Reviews: Discuss recent incidents, their impact, and action points to prevent future occurrences.
- Case Studies from Testing: Sharing interesting or unusual cases encountered during testing, which can provide valuable insights.
- Tool and Technique Workshops: Knowledge-sharing sessions about new tools and investigative techniques.
- Expert-Led Workshops: Learning from experienced colleagues through in-depth workshops.
- Pair Programming Sessions: Collaborative coding or testing sessions to tackle complex problems.
- Hackathons: Organizing internal events to innovate and solve challenges creatively.
However, there are challenges to consider:
- Preparation Time: These activities require significant preparation to be effective.
- Cultural Adaptation: Fostering a culture of constant learning and improvement takes time and effort.
- Engagement and Utility: The meetings should be more than formal sync-ups; they need to be engaging and genuinely useful. This might mean holding them less frequently, such as once a month, with additional sessions as needed based on demand.
But the main goal is to ensure these meetings are not just a routine catch-up but a tool for continuous learning, sharing, and improvement. Communication is the key
6 Likes
Thanks for this feedback, @clittlefair! I endorse the discussion of “gripes and grumbles” at the team retro for the benefit of all to hear and respond to. And, CHEERS TO you all’s sanity check! These are so much needed – especially these days.
1 Like
Thank you, and I appreciate this detailed reply, @shamrai! I agree that our meeting won’t be as effective unless those attending also see the value in doing so, and committ to contributing toward this end.
Our first meeting is next week, and I hope to ensure that it’s a psychologically safe place for each of us to share, learn and grow.
2 Likes
Twice a week, 15 minutes, 7 attendees. Cross-functional team, so no sprint or backlog. Round robin:
- Everyone gets to announce what feature releases their dev team is working on, and discuss their latest automated testing blocker/pain.
- What security tool or check “someone” needs to do still.
- Why is nobody even reading the failed test log from team X (usually not my team or responsibility)? How come the test reports still hard to read? Oh yeah, nobody wants to fix them.
- Why is test environment “X” still blocked?
- When is our next Major-Release Retro?
Other topics do come up, but these are the most common.
Every few months we have a big retro or a big backlog-combing and that often takes well over an hour, some bigger work pieces gets prioritised and maybe one of them gets dune, until the next big meeting. It is hard work, but if people focus on blocked tasks only then the meeting does work a lot better.
People are so good at giving status updates that mean/convey absolutely nothing. I have been listening to a project manager who has managed every 2 weeks to give a status update and never ever once ask for help or even mention more than one project name if at all. He has done this for a whole year, next week will be his last status update, no loss.
5 Likes
One small remark I forgot to mention. Just set the goal of the meeting, because every meeting has its costs. And when you compare the cost of meeting with the result, you should be sure the value it brings covers the expenses
5 Likes
Unfortunately in my experience these devolve into another stand-up unless there is a leader taking charge of establishing the environment and agenda. That sounds a bit heavy-handed; but it doesnt have to be. Its going to be awkward and a little uncomfortable at first because no one wants to volunteer or risk a nice big flare up of “imposter syndrome”
So, my advice is to:
take the lead. bring in topics to discuss. topics that promote discussion. look for opportunities to “raise up” some of the quieter voices
volunteer people and get them to feel good about it. i.e. “Thats an interesting idea! I would love to hear more about it. Could you expand on it in the next meetup?” I had a mentor/manager who would take just about any suggestion “I think we should…” or “You should…” and accept it as an item “Thank you for doing that! It will be awesome to hear about the result you find at the next meetup!” But always in a friendly way and always with a lot of interest and praise so that the volunteer felt rewarded by doing it.
Like changing any process it takes repetition and effort until it gains its own head of steam.
One of these kinds of meetups is where I learned of Cypress and ended up evaluating it as a framework for my team
6 Likes
We don’t have an office, so we all work from home and several of the team have never met each other. We have a weekly call for 2 to 3 hours that starts with personal banter so we get to know each other (a double edged sword if ever there was one!) and feel more of a team. That’s one of the big things you lose when working from home.
Then we each talk for a minute or two about what we did work-wise in the last week. We typically all work on different projects, so no one would know what anyone else was doing if we didn’t do this.
Finally, we talk about anything interesting we have found regarding testing tools, test techniques, weird code and bugs we have encountered, new or obscure HTML elements and CSS properties etc… Interpretation of WCAG accessibility guidelines and other standards is always a big topic because they are mostly written so badly.
Creating a searchable repository
We record that last section of the call and manually index it so we have a searchable database of every discussion. That’s time consuming, so we have just started to use Zoom’s AI Companion feature to generate a summary instead. It’s surprisingly good, although it can make bad mistakes and often attributes comments to the wrong person. However, we can live with that as long as it contains all the relevant keywords we may want to search for in order to find videos containing those topics.
We’ve been doing this for about 3 years and we rarely cancel a weekly call - I regard them as mandatory because they are so important. And we’ve never run out of topics to discuss.
6 Likes
That long? Ive often found that meetings that are greater than an hour tend to be ineffective as people’s concentration drifts after that. How do you keep the focus for that length of time?
I’m not talking about collaborative sessions, to be clear. Problem solving sessions over screen share (paired programming/rubber ducking, war room for a production issue, helping unblock someone via shared session) can go a lot longer because there is a focused goal.
3 Likes
It might have something to do with us all being more than 40 years old, but we don’t have any problem focusing for 2 or 3 hours. Another factor is that we keep it interesting - almost everything is new to everyone. And the meeting organiser constantly asks people for their views, so no one can just sit back and tune out.
On the topic of keeping focus, I worked 80 to 100 hours a week for nearly 40 years without any difficulty. Each week would include two 20-hour sessions or one 30-hour one, and loss of concentration was never a problem. There’s something wrong with you or your job if you can’t concentrate for more than an hour.
6 Likes
This is an extremely ableist response and one that I personally feel attacked by, I am sure others will too. My attention span varies hugely to switching off almost immediately to being able to hyperfocus for hours non-stop. Funnily, I tend to switch off quickly in meetings. There is nothing wrong with me.
I’m not here to educate people on neurodiversity, but it’s a thing and as a result the world has been designed to be disabling in so many ways. It’s every manager’s responsibility to learn and understand how people function in different ways.
Even outside of neurodiversity, there are so many reasons why people can’t be expected to commit crazy long hours or work in ways that simply doesn’t work for them. It’s not just about disability, it’s also about the state of their personal lives. Humans are a diverse bunch of people.
14 Likes
Thank you for sharing this insightful and powerful reply, Rosie.
2 Likes
… this is not something I’d brag about… there is being committed to your work, then there is just plain being a mug. I sincerely hope you work for yourself by this statement.
Concentration loss was NEVER a problem? Never ever? Never had a personal crisis with yourself, your family or friends that might have distracted you? Never a health problem, never a money or work problem? In 40 years?
You are blessed sir. I suggest you buy a lottery ticket tonight.
What a kind, thoughtful and supportive statement - you must be fantastic to work with in a team - I imagine standups are a laugh a minute with you 
4 Likes
That’s a shockingly arrogant take. Working 80 to 100 hours a week isn’t a badge of honor, it’s more likely a red flag about needing help. Maybe try a little empathy?
@rosie You’re not alone. This kind of alpha geek behavior is unfortunately all too common in our industry–no matter how skilled someone is or thinks they are, it’s no excuse for looking down on everyone else.
5 Likes
I have to ask: were you being paid for 80 to 100 hours a week? Because if you were a salaried worker with a standard 40 hour workweek, you were effectively being paid less than half your official pay because you were putting in more than twice as much work as you should have been.
On the other claw, if you were being paid on an hourly basis, you should have been getting insane amounts of overtime because the standard of a 40 hour work week has been around for rather more than 40 years.
You might be a truly magnificent being who can sustain that kind of work without burning out or succumbing to death by overwork, but most of us aren’t that awesome. For most people involved in knowledge-based work, there’s an upper limit in the order of 10 hours per day after which the amount of time they spend fixing mistakes wipes out any gains they make from the extra work - and that number decreases the longer they’re working the longer days (as a side note, just as companies were stunned by how much safer and more productive their employees were when they dropped to a 40 hour standard work week, there’s a rapidly growing body of research suggesting that dropping to four 8 hour days for the same pay either improves profitability or makes no difference to the bottom line).
I hope you don’t think you’re being jumped on here: tech folks tend to start neurodivergent and end up further off the norm than that (technology and creative arts tend to be where those who aren’t “normal” cluster) and you probably weren’t as tactful as you could have been.
Personally, I can’t stay focused for a 2 to 3 hour meeting and I am older than 40. If said meeting is structured into multiple smaller submeetings I might be okay, depending on the topic. I can stay focused for more than an hour if I’m doing something that absorbs my entire mind - and maybe I’ve just been unlucky, but I’ve never encountered a meeting that can do that.
In any case, I personally believe that if any employer expects or requires more than twice the normal work week as a matter of routine, that employer is doing something wrong. If they’ve convinced their employees that maintaining such a pace is a good thing, then they’re exploiting their employees.
6 Likes
these are mainly retrospective sessions, we discuss challenges we’ve faced the past 2 weeks and share learnings, discuss interesting bugs and defects identified in the pervious 2 weeks, we have a “bug of the sprint” nomination where we identify the most severe bug. we then discuss our focus areas for the next two weeks. 
4 Likes
Devolving into just another stand-up is the reason we only meet twice a week.
I actually initiated our QA stand-up as a fortnightly, I think there is an old MOT thread about that someplace. My reasoning was that I wanted to slowly build a cross-team discipline and not let it become yet another stand-up. Also we had very little in common in QA because we worked on completely different stacks. But because the value delivery in the stacks is vertical while the teams are horizontal, having someone who is “T” shaped was going to help everyone win. I think testers need to remember, that we are “T” shaped people.
I really like this concept. I was thinking about it this morning over coffee. One thing testers do not do enough of is regale each other with stories of how we caught bugs as a way to share lived experience. Stories that make it clear that “test-automation” is no the thing that catches bugs, it points to them! Humans catch bugs, and we need to make that catching process much more social.
3 Likes