The Plain Testing Glossary

I've onboarded a lot of junior testers and the same thing happens every time — they nod along to words like flaky, smoke, contract test and staging, and they mean something slightly different at every company. I was writing the same explanations in chat repeatedly, so I started collecting them in a document, and eventually put it on the web so I could send a link. It's grown to about ninety entries over four years, added whenever I explain something twice.

The problem is that testing vocabulary is inconsistent across the industry and most reference material is either a certification syllabus written in formal language nobody speaks, or a blog post with a strong opinion. Each entry here gives the plain meaning, notes where teams disagree about it, and says what it looks like in practice. It's for people in their first year or two of testing, and for developers who work with testers and are quietly unsure what half the words mean. I'm careful to mark the entries where I'm giving my opinion rather than a settled definition.

It's mine — every entry written by me, plus the site itself, which is deliberately plain. I built it in Astro so it's just markdown files I can add to from my phone. I also did the search, which is the only real feature and took an evening. I've accepted about fifteen corrections and three new entries from readers, and I've turned down a few that were really product pitches. I maintain it, which mostly means revisiting entries where my own view has changed.

I decided each entry has to name where teams disagree, rather than pretending there's one right answer. That's the whole reason a glossary is needed — the disagreement is the confusing part, and hiding it makes the reference worse than useless. I also decided against comments, a forum or any community feature, because moderating a place where people argue about definitions is a job and I have one. It's a static site with no analytics and no tracking; I have no idea how many people read it and I've found that restful.

The hardest thing has been my own bias. I've worked in regulated industries for most of my career and my instinct about what's normal is shaped by that — my first version of the entry on test evidence read as though everyone has an auditor, which is nonsense for most teams. A reader wrote to tell me so, fairly bluntly, and I rewrote about a dozen entries afterwards to separate what's generally true from what's true where I've worked. I now try to flag it explicitly when an entry is coming from a regulated context.

It gets linked in onboarding documents at two companies I know of, which I found out by accident when a stranger mentioned it in a conference hallway. Four of the juniors I've mentored have contributed entries. It saves me a genuine amount of repetition — I now send a link instead of writing the same paragraph, which is the entire return on it. It's about ninety entries and will never be comprehensive, and I've stopped feeling bad about that.

Four juniors I've mentored wrote entries, and theirs are better than mine at the thing that matters most — they still remember being confused, and I don't. One reader I've never met sent the correction about my regulated-industry bias and has since reviewed about a dozen rewrites for me by email. A former colleague who works in developer relations told me to cut the entries where I was really just arguing with a vendor, and she was right about all four of them.