This episode of Ministry of Testing’s This Week in Quality began with Simon unexpectedly absent. Rosie Sherry opened with “404 not found” and stepped in as host. Gary Hawkes, Eamon Droko, and Judy Mosley joined her to share post-MoTaCon updates and talk about AI-assisted development, quality orchestration, career changes, community participation, fun in testing, and using AI to learn a new product.

This was not a session built around a formal agenda. The guests shared personal experiences and, at times, ideas they were still working through. Together, their stories point to a practical thread: quality work depends on engineering judgment, honest communication, community support, and trust between people.

This article draws on the Ministry of Testing episode page, published on 16 October 2026, and the accompanying transcript. Guest experiences remain personal accounts. Sections marked Engineering extension are recommendations from this article, not formal frameworks or universal claims made by the speakers.

Vibe coding: quick to build, costly to fix

Rosie called herself the week’s “chief vibe coder” and described her recent experience with AI-assisted development: creating an initial prototype took relatively few credits, while fixing problems and investigating issues took three or four times as many. That ratio is personal experience, not an industry statistic. Still, it is a useful reminder: generation speed is not delivery speed. A feature that runs may still violate requirements, mishandle edge cases, or create maintenance work.

She also described turning a set of Risk Lab risk lists into short posts. Her hope was that people could use them to inform everyday quality and testing work, including using AI to think through risks. The material initially felt overwhelming; reviewing and organizing it made it easier to use.

Engineering extension: Evaluate AI-assisted development across the whole delivery path: generation, comprehension, verification, repair, and maintenance. Time to first output alone can exaggerate the benefit. Teams can also establish stable identifiers for requirements, tests, defects, and builds, then let AI help retrieve and summarize them—with sources people can check.

From test management to quality orchestration

Rosie recalled a TestRail masterclass and wondered whether “test management” might be better understood as “quality management,” or even “quality orchestration.” The episode did not define a formal model or claim that the industry had adopted a new term. Rosie’s reflection was that work keeps changing, and the language around quality will evolve with it. The discussion was about scope: test cases and execution results are only part of quality information. Requirements, code changes, deployments, environments, defects, risks, and release decisions need to connect as well.

Quality orchestration does not have to start with a new platform. Linking important records so a team can trace which checks a change affected, or which build a failure came from, is a more practical first step.

From quality roles to engineering management: Gary’s story

Gary said that in roughly twenty years of work, he had rarely seen someone with a quality background move into a Head of Engineering role. At MoTaCon, he met several people who had done so, which challenged his assumptions about career paths.

He had moved into management and back to an individual-contributor role several times. Each attempt helped him understand what mattered to him and gave him clearer criteria for evaluating teams and companies. One reason he later moved into engineering management was quality itself: his QA team had already worked hard to simplify processes and improve efficiency, yet delivery bottlenecks remained elsewhere in engineering. Improving overall quality meant influencing more of engineering—not asking QA to move faster on its own.

Rosie also discussed how the community could make room for that kind of career change. The group had been trying to bring in engineering managers and developers, including through engineering-management discussions and invitations for developers and engineering managers to attend MoTaCon as someone’s guest. People who move beyond testing roles can still find a place in the community, share what they have learned, and make those career paths more visible.

This does not mean every QA professional should become a manager. Gary’s experience shows that people can influence quality from different roles. The right path depends on the problems they want to solve and the principles they care about. He encouraged people to get clear on those principles and use them when choosing a team or company; if the fit is persistently wrong, it may not be the right place to stay.

Eamon’s story: build a reputation by showing up

Eamon talked about co-facilitating a testing workshop with Lisa Crispin at MoTaCon. Before that, he had taken part in community discussions, given short talks, and helped organize a local chapter. A discussion he contributed to the previous year about staff-level QA roles was later cited in the book Staff Level Testing Roles. As he put it, “you don’t get cited unless you show up.” At the time of the episode, he had just started a new Senior QA Engineer role, alongside two other senior QAs. The team had ideas to work through, and building the QA practice and deciding what to prioritize were among the challenges ahead. He expected to keep asking the community for advice.

That participation had also helped during his job search. Eamon said he talked about his community work in interviews; during his first week, a company leader mentioned his podcast appearances and conference talks. Rosie saw public participation as a way to create opportunities for recognition, collaboration, and learning. Eamon encouraged people to start small: even one observation or question is enough to “just jump on stage” and share. Showing up gives people a chance to see your work. He framed the professional reputation built through community as a personal brand that can outlast any one employer.

Lisa’s approach to collaboration is worth noting, too. Rosie said Lisa often paired with less-experienced people to give them opportunities to facilitate or present. Eamon described how Lisa checked in during preparation and reassured him when he worried he was not contributing enough. Good collaboration is not just dividing up tasks; it also leaves room for a partner to learn and contribute.

Be yourself in a diverse, welcoming community

Authenticity came up as its own theme. One guest said they had always shown up as themselves, without lying or asking AI to write their posts, and felt that people appreciated that. The conversation also described the community as diverse and welcoming, where people with different backgrounds can participate without pretending to be someone else. That is one person’s experience, not a rule that everyone must post often or speak at conferences.

Bring the fun into testing: from Mob Testing to Testing Party

Eamon and Lisa turned a large mob-testing session into a Testing Party: people wore party hats, shared sweets, and tested together in a relaxed atmosphere. Participants captured observations on sticky notes; near the end, several groups spontaneously gathered for photos. Eamon felt the energy showed that the workshop had created an enjoyable experience as well as getting people to test.

The conversation also touched on the shift from Mob Testing to Ensemble Testing and then to Testing Party. The name changes the picture people have of the activity and can make it feel more welcoming, but changing the label alone will not create good collaboration. The activity still needs a real, bounded subject for people in different roles to explore together.

Engineering extension: Start with a low-risk feature. Spend five minutes explaining the user goal, constraints, and scope, then let small groups rotate who operates the product and who records questions or counterexamples. Participants in the actual workshop had about fifteen minutes to work together; a team could set aside fifteen to twenty minutes for exploration, then sort findings into reproduced defects, open questions, and improvement ideas, with an owner for each follow-up. These timings and steps are suggestions here, not a verbatim reconstruction of the workshop agenda.

For organizations with many rules, the guests suggested starting with small touches—party hats, sweets, or a playful surprise—and adding fun gradually, without making a big announcement about it. Sometimes, the more you explain up front, the more reasons people find to object. The conversation also included “ask for forgiveness, not permission,” but that should not be read as advice to hide risks or bypass security, compliance, privacy, budget, or staffing controls. A safer approach is to run small experiments within existing authority, retain required approvals, and use what the team learns to build support. Gary also noted that even when a problem is serious, teams can look for a more engaging way to address it; making work enjoyable does not mean avoiding the hard parts.

Challenge your first interpretation: Judy’s story

Judy had recently earned a Senior QA title and joined a calmer team, where she was adjusting to a different working pace. She noticed that a relaxed environment did not stop self-doubt from coloring how she interpreted people’s words. She shared two examples of how quickly an assumption can form.

A colleague suggested making a Jira ticket focused enough to be actionable. Judy initially took this as criticism of her ticket-writing. At their next meeting, she asked directly. The colleague explained that her tickets were detailed; the point was simply that a clearly scoped issue is easier to pick up.

Later, she noticed that she was not receiving testing tickets and worried that the team thought she was too slow. She and her manager checked the Jira assignment automation and found that her name was missing from the rule.

In both cases, what Judy observed, what she initially inferred, and what she eventually confirmed were different. The same discipline applies to testing: an error log is not a root cause, a failed test is not automatically a product defect, and a missing automation event does not prove that someone deliberately ignored a teammate. Asking a precise question is often more useful than sitting with an unverified explanation.

Use AI as a learning companion

Judy used an AI Companion connected to all of the team’s documentation and the issue-tracking system to learn a new product. She found that a broad question such as “What does this mean?” was rarely enough. Answers became more useful when she named the application area, page, field, and exact text she was looking at.

She also asked the AI Companion who belonged to the QA team. It listed three core members but left her out. Judy realized the internal information needed updating. The example shows how quickly AI can retrieve existing knowledge—and how it can expose gaps in that knowledge. Its answer is not the final authority on the organization.

A more specific question might be:

I’m testing the refund details page in the order-management module. The Settlement status field currently shows Pending. Based on accessible product documentation, explain what the field means, its possible states, and the conditions that move it between states. Cite the documents you used; if you cannot find support, say so explicitly.

This is an example created for this article, not a page discussed in the episode. Judy also took AI-generated answers back to colleagues for confirmation. That helped her avoid repeatedly interrupting people without turning learning into an isolated activity.

Engineering extension: Provide the application area, page, field, current value, version, and the question you need answered. Ask for traceable sources and an explicit statement when evidence is missing. Confirm critical business rules with people who know the domain. Clearer links between documents and systems make retrieval easier, but a citation still needs to be checked against the claim.

This connects back to quality orchestration. AI-ready quality depends not only on individual requirements, tests, or defects, but also on the context and relationships between them. Maintaining those links takes ongoing effort. AI can help retrieve and organize information, but it cannot turn a broken relationship into trustworthy evidence.

The episode did not offer a quality process for every team to copy. The guests’ experiences point to choices we make at work: take part in the community and build a reputation that can travel with you; leave room for fun in testing; ask before assuming; and give AI useful context, check its evidence, and confirm important details with people who understand the work.

References

ACP (Agent Client Protocol)Active MemoryAgent AuthorizationAgent CardAgent Evals
Share