Rosie Sherry
Rosie Sherry
CEO & Founder of the MoTaverse
She/Her
I've been working in the software testing and quality engineering space since the year 2000 whilst also combining it with my love for education and community. It turns out quality, community and education go nicely hand in hand.
I'm here for community as a service and building the best possible tech community out there.
🎓 MoT-STEC qualified
🎂 MoTaBirthday | November 23, 2014
Open To
Teach
Speak
Mentor
Podcasting
Write
CV Reviews
Meet at MoTaCon 2027
Wherever you find yourself copying and pasting, ask whether AI can do it for you. Start small. Learn. Iterate.
In my last How I use AI post, I wrote about replacing spreadsheets with vibe-coded in...
4 Nov
The great thing about humanity is that we love to talk.The terrible thing about humanity is that we love to talk.Yes, I say that in jest, but we must apply our critical thinking skills to industry ...
30 Oct
Spreadsheets are great, until they are not. With spreadsheets scattered everywhere, they are where data goes to die.More recently I've been raising a 'red flag' mote to myself whenever I see a spre...
26 Oct
On my wish list, for quite a while, has been to get better at going to other meetup type events, and conferences too, to be honest. I feel like I have the headspace to do so now.Last week Simon Tom...
26 Oct
Explore AI product risks in part 7 of the AI Risk List from the MoTaverse, focusing on system safety, failures and limitations.
27 Oct
Explore the sixth part of the AI Risk List from Ministry of Testing, focusing on socioeconomic and environmental impacts.
22 Oct
Explore how AI makes community work more human, the case for building data over features, and how bad bots and data centres complicate the picture.
4 Nov
Louise Woodhams, automation and test lead at ZapMap, on finding small joys in testing while burnout, AI pressure and job worries mount.
4 Nov
Kubernetes (K8s)
Kubernetes, often shortened to K8s, is an open source platform for running and managing containerised applications across a group of machines called a cluster. Teams use it to deploy, scale and isolate software, and testers increasingly meet it when their applications, or their automated tests, run inside a Kubernetes cluster.
Why it matters: When the product under test runs on Kubernetes, the environment itself becomes a source of bugs. Resource limits, networking rules and the way containers share memory can all behave differently from a laptop or a local Docker setup. Tests that pass locally can fail in the cluster for reasons unrelated to the code under test.
In practice: Applications are packaged as container images and deployed into pods, the smallest units Kubernetes runs. Related resources are grouped into namespaces, often one per customer or environment. Test code can be packaged the same way and run as a Kubernetes job, a short-lived task that starts, runs the suite, reports results and is then discarded. Debugging usually means getting inside the pod, reading logs and copying files such as screenshots back to a local machine.Examples:
Running a UI test suite as a Kubernetes job in a customer's namespace just before and just after a major version upgrade.
Keeping a debugging pod alive with a sleep command so a tester can run tests by hand and inspect what happens.
Finding that headless Chrome fails to load iframes in a pod because of limited shared memory, then fixing it with a browser flag.
Common pitfalls:
Assuming a test that works in Docker Desktop will behave the same way once deployed to the cluster.
Treating cluster failures as flaky tests instead of investigating resource, network or configuration differences.
Do testers need to learn Kubernetes? Not in depth, but knowing how pods, namespaces and jobs work makes it far easier to run tests in the real environment and to tell product bugs from environment problems.
What does K8s stand for? K8s is a shorthand for Kubernetes, with the 8 standing for the eight letters between the K and the s.
Knowledge Silo
A knowledge silo, sometimes called an information silo, is a situation where important information is held by one person or a small group and is not easily available to others who need it. In software teams it often shows up as a single go-to person for a system, tool or process.
Why it matters: When knowledge sits with one person, everyone else has to wait for them, and work stalls when they are busy, on leave or leave the company. Testers feel this sharply, because testing depends on understanding how systems, data and business rules really work. Silos also limit creativity, since fewer people can build on what is known.
In practice: One simple habit that breaks down silos is asking and answering questions in public spaces, such as a team channel, rather than in private messages. Once a question and its answer are visible, anyone can find them later, add to them or correct them. Teams also reduce silos through pairing, rotating responsibilities, recording decisions and keeping shared documentation current. Leaders help by making it feel safe to ask "obvious" questions in the open.Examples:
An engineering manager who asks people to repost private questions in the team channel so everyone sees the answer.
A tester who is the only person able to run the payments test environment, so releases wait whenever they are away.
A team that pairs a new starter with the person who knows the legacy reporting service, so knowledge spreads.
Common pitfalls:
Answering the same private questions again and again instead of moving the conversation to a shared space.
Writing documentation once and never updating it, which creates a new silo of out-of-date information.
How do you break down a knowledge silo? Make questions and answers public by default, pair people on work that only one person understands, and rotate tasks so more than one person can do them.
Is a knowledge silo the same as a low bus factor? They are closely linked. A low bus factor measures the risk, while a knowledge silo describes the situation that creates it.
Knowledge Map
A knowledge map is a visual or written overview of what a person knows, what they are learning and where their gaps are, used to plan what to learn next. It can be a mind map, a canvas, a graph or a simple list.
Why it matters: Testers face a constant stream of new tools, frameworks and AI products, and trying to learn all of them leads to scattered effort and burnout. A knowledge map gives a clear picture of current skills against what work, the market or a promotion needs. That makes it easier to choose a few priorities and say no to the rest for now.
In practice: A tester reflects on their skills and builds or updates their knowledge map every three to six months. They note topics they are strong in, topics they need for their role, and areas of interest. Gaps then become learning goals for a month or a quarter, broken into small tasks such as reading one chapter or watching one lesson.Examples:
A mind map with branches for automation, APIs, AI tools and domain knowledge, each marked as confident, learning or not started.
A simple list comparing the skills in a company's promotion criteria with the skills a tester already has.
An AI-generated diagram of how concepts in a topic relate, compared against the learner's own notes to spot what is missing.
Common pitfalls:
Building the map once and never revisiting it, so it stops reflecting what the tester actually knows or needs.
Filling the map only with what work or the market demands and ignoring personal interests, which raises the risk of burnout.
How often should I update a knowledge map? Every three to six months suits most people. That is long enough to see progress and short enough to keep it current.
Is a knowledge map the same as a learning plan? No. A knowledge map shows where you are and where the gaps lie. A learning plan sets out the goals, tasks and timings for closing some of those gaps.
Knowledge Management
Knowledge management is the practice of capturing, organising and sharing what a team knows so that it can be found and used when someone needs it. In software teams this covers documentation, wikis, test artefacts, chat threads and meeting transcripts, and increasingly how AI tools can surface answers from all of them on demand.
Why it matters: Few people read every page of documentation or listen to every piece of advice. When knowledge is well managed, a tester can pull up the right product decision, past bug or known risk in moments instead of rediscovering it the hard way. Old conversations and recordings can become a source of early warnings about quality problems.
In practice: Teams start by exploring the knowledge they already hold, such as chat history, product plans, test plans and transcripts. They look for what is missing or slow to find, then agree a consistent structure for how information is written and stored. Small habits help, such as linking to related material and using clear keywords so things are easier to search later. AI assistants connected to these sources can then answer questions directly.Examples:
Connecting a team wiki to an AI assistant so a tester can ask how a feature is meant to behave instead of searching dozens of pages.
Searching meeting transcripts for phrases such as "I'm worried" or "that's strange" to find risks raised and never followed up.
Agreeing a set of shared quality prompts that help the team start test planning from existing knowledge.
Common pitfalls:
Expecting AI to produce useful answers from scattered, inconsistent information, when it needs a solid foundation of well structured knowledge.
Trying to design a perfect system up front instead of improving the process in small steps.
Why does knowledge management matter for testers? Testers rely on context about how a product should work and where it has failed before. Good knowledge management puts that context within reach, which leads to better questions and better tests.
Key Performance Indicator (KPI)
A key performance indicator (KPI) is a measurable value a team or organisation tracks to judge progress towards an important goal. In software and quality engineering, KPIs might cover things like escaped defects, lead time, test pipeline stability or customer-reported issues.
Why it matters: Well-chosen KPIs help teams see where they are improving and where they are not, and give leaders evidence for decisions. Poorly chosen ones do harm: when metrics are imposed from above, the people doing the work rarely buy into them or feel accountable for them, and the numbers end up ignored or gamed. The phrase "if you can't measure it, you can't manage it" is often quoted to justify KPIs, though the original idea was closer to the opposite.
In practice: KPIs work best when they are built with the team rather than for it. Leaders can ask the team what successes were missed, what failures could have been avoided and where they want to improve, then agree a small set of measures that reflect those answers. The team reviews the KPIs on a regular basis, adding, changing or dropping them so they stay relevant.Examples:
A team that agrees to track production incidents caused by changes after noticing too many weekend call-outs.
Engineers choosing to measure flaky test reruns because pipeline delays were their biggest frustration.
A set of managers' metrics nicknamed after the person who wrote them, a sign the team never adopted them.
Common pitfalls:
Creating KPIs in a managers-only meeting and presenting them to engineers as finished, so nobody feels ownership.
Setting KPIs once and never reviewing them, so they keep measuring problems the team has already solved.
What is the difference between a KPI and a metric? Any measurement is a metric. A KPI is a metric the team has chosen because it tracks progress towards a goal they care about.
What are good KPIs for a testing team? That depends on the team's goals, which is why the team should help choose them. Common starting points include escaped defects, time to detect issues and pipeline reliability.
Comments
(316)
New Chapter at work
Bug congrats!
Do you practice CUWI (Community Unscripted With Intention)?
It's coming full circle!
TWiQ and TWiC is community unscripted, ftw.
Also, we're in the process of organising a MoT Brighton social, no agenda, just good people and conversation.
Empathy, care and joy in building
I most definitely approve of this type of AI modfication of images, very nice :)
I was in the Pacific Northwest Software Quality Conference 2026 in Portland to present Lynqa
Great to hear.
I'm curious how you've experienced people reacting to a third way of testing, of course it's inevitable, or at least it seems. In the past, the mental mode of thinking about it was either manual or automation. Now it's manual, automation or agentic.
I guess, I'm wondering if it's too much to ask teams to manage all modes, or how can we simplify our approach or thinking around this. It's certainly interesting (and also overwhelming) to think and plan for.
The 99 second talk I didn't get to do at MoTaCon
Love to see this happening.
Next year we will ensure we don't run out of time! :|
