Ash Winter
Ash Winter
Staff Quality Engineer
He/Him
An experienced, community focused tester. Loves training, mentoring and helping teams with testability. Co-organiser: Leeds Testing Atelier, co-author: Team Guide to Software Testability.
🎂 MoTaBirthday | December 10, 2015
Continuing with an experiment. Let's look at the talk and workshop descriptions of MoTaCon 2026 and share my thoughts and reflections before the talk/workshop has happened. And then, hopefully, sh...
13 Aug
Leeds, UK. 23/04/2024. Part of the joy of attending a Leeds Testing Atelier is getting to design posters for the talks. I had a lot of fun creating this one. Kudos to Ash Winter, Gwen Dia...
5 Aug
On the 15th of January 2026 myself and Ujjwal Kumar Singh joined a call and pressed record. We were curious to see what would happen. A few weeks later I’d done the same with Neil Taylor and Clare ...
6 Jul
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...
20 Apr
There's a skill in spotting which of your activities are genuinely high value
22 Jun
Are we ready? How quality coaches and engineers can use patience to support their teams.
16 Apr
Join Simon Tomes and his team of global correspondents in this engaging episode of The Testing Planet
26 Apr
In Test Column
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.
Exploratory Testing Loop
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.
Story Kickoff
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.
Timebox
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.
High Value Activity
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.
Comments
(6)
Throw back Wednesday! Giz us job goat
Diana's goat is the real GOAT. We will struggle to top that.
Throwback Wednesday: Behold! The golden circle of testing!
Ha ha! Bryan's talks are a bit like a journey into Mordor, plenty of mortal peril. :)
Seriously though, I like his style, owns the empowered tester with strong opinions on quality vibe. Bryan goes way beyond being an information provider...
Call for Insights turns 45
I love this format, a deep exploration of a topic is most welcome, helps me get my thoughts out/in order.
So much value stored in everyones contributions, long may it continue.
My integration testing tools / frameworks of choice
This can vary a bit depending on technology under test but...
* Component testing - restAssured with JUnit as a runner with TestContainers for mocking.
* Contract testing - Pact is used widely, not sure what PactFlow is though (its the enterprise platform built on top of pact)
* External integration test (with an interface) - Postman or Bruno for exploratory testing, not necessarily at one particular level though.
* External integration test (code) - restAssured again, with a JUnit runner
To grow your influence, you might have to drop 'quality' from your title
At an old job, I asked that everyone from all roles became Quality Engineers when the idea was floated to change the testers job titles. Developers, Ops, Analysts etc were not keen.
The word quality in a job title has serious credibility problems and places too much expectation on the Quality Engineer to change the world. For some reason, we are still relying on someone to embody quality...
Learner completed your lesson
5.2.0 of MoT Software Quality Engineering Certificate
Community Star
1 day ago
Influence, from the other side of the table
What I learned about influence by becoming a stakeholder
Online Event
3 days ago
Learner completed your lesson
1.4.0 of A tester’s role in continuous quality
Community Star
10 days ago
