A column on a team board that holds work currently being tested, making testing activity visible alongside the rest of the workflow. An ever-growing in test column is a signal that testing has become a bottleneck, which is part of why teams encourage others beyond the tester to pick up testing work. Used well, the column can also show whether a diverse range of people are contributing to testing rather than it sitting with one person.For example: spotting that items are piling up in test and redistributing the work; seeing several different names attached to items being tested; or using the column to make a hidden testing backlog visible to the whole team.

A simple, repeatable cycle that structures an exploratory testing session so that people without a testing background can follow it. A common shape is: generate initial test ideas within a short time limit, take a first look at the change, refine the test ideas based on what was seen, then go deeper, repeating as needed. Keeping the loop simple at first lowers the barrier for developers and others to take part, with extra concerns such as testability added only once the basic rhythm is comfortable.For example: spending ten minutes on test ideas before opening the feature; doing a quick reconnaissance pass and then refining charters; or adding a side list of testability problems once the team is used to the core loop.

A short session held before work on a story or ticket begins, where the team discusses what is being built, clarifies acceptance criteria, and surfaces questions or assumptions. A kickoff that leaves questions unanswered or feels vague is itself a signal, often marking a change as worth deeper exploratory testing later. Treating the kickoff as a quality activity, rather than a formality, helps catch ambiguity while it is still cheap to resolve.For example: agreeing extra acceptance criteria before any code is written; noting outstanding questions that nobody could answer in the room; or flagging a story as one to test more thoroughly because the kickoff felt unsatisfying.

A fixed, agreed limit of time set aside for an activity, after which the person stops and reflects regardless of whether the work feels finished. In exploratory testing, a timebox keeps a session focused and reduces the fear that testing will expand without end, since the tester stays in control of how long the work takes.It also turns the outcome into useful information: if little progress is made within the box, that itself signals something about the change being tested.For example: giving yourself one hour to explore a feature and debriefing at the end; spending ten minutes generating test ideas before looking at the product; or running a thirty minute session and then deciding whether to go again.

A task that draws heavily on a person's experience, judgement, and skill to produce outsized impact, as distinct from routine work that almost anyone could pick up. For a quality engineer, identifying which activities are genuinely high value (and reserving their attention for those) is itself a skill, since the same person could spend time on low-impact checks instead. The judgement is contextual: a task that is high value on one team or for one change may be low value on another. For example: applying deep exploratory testing to a complex, risky change rather than to a minor copy tweak; leading a story kickoff where requirements are still unclear; or reviewing an architecture for risk before code is written.

A while back Ash Winter wrote about looks good to me culture (LGTM) and the feel good vibes stuck. In some senses, it perhaps shouldn't have appealed so much to me, especially as it can be looked a...

Are we ready? How quality coaches and engineers can use patience to support their teams.

How does a team’s stage of development influence the style of quality engineering it needs to thrive?