简体中文
EnglishWhat Approach to Test Automation Does On Test Automation Advocate?
Updated
On Test Automation advocates treating test automation as a feedback system, not a tooling exercise. The site's stated position is that teams test to learn the state of their product and to surface problems users might hit, and that automation exists to deliver that feedback fast and with value. The approach therefore puts emphasis on deciding what to test, how to test it, and how the resulting feedback informs decisions — rather than on picking tools or writing more tests. It is aimed at engineering teams and organisations that want practical, lasting improvement in their own context, delivered through hands-on training, consulting and mentoring.
The core argument
The site frames the purpose of testing in feedback terms: "We test because we want to be informed about the state of the product we're working on, and about any potential problems that might occur when people use our product." Automation is the means to get that information quickly.
From that premise, the site draws a direct conclusion about what does not produce good automation:
- Choosing the right tools is necessary but not sufficient.
- Writing more tests is not the goal in itself.
- What matters is a thoughtful approach to what is tested, how it is tested, and how the feedback is used to make better decisions.
This is a quality-of-feedback position rather than a coverage-count position. Two teams can run the same number of tests and get very different value, depending on whether those tests answer questions the team actually needs answered.
What this looks like in practice
The site describes the work as hands-on and context-specific: tackling real problems in the team's own environment and building skills that persist after the engagement ends. The stated focus areas are:
| Area | What the approach implies |
|---|---|
| Test automation strategy | Decide what feedback the team needs and how automation will supply it |
| Improving an existing test suite | Raise the value of feedback from tests already in place |
| Exploring new approaches | Try different methods while keeping the focus on practical results |
A useful way to picture the difference: a team that adds a hundred UI tests because coverage looks thin is following a tool-and-volume approach. A team that first asks "which product risks do we most need early warning on, and what is the cheapest reliable way to get that signal?" is following the feedback-first approach the site describes — and may end up writing fewer tests that are more trusted and acted upon.
Who it is for, and the conditions for fit
The approach is presented for engineering teams and organisations, delivered through training, consulting and mentoring. It suits teams that:
- already have automation but suspect it is not producing decisions they trust;
- want to improve an existing suite rather than start from a tool comparison;
- can commit to working on their own real problems during the engagement, since the stated model is hands-on rather than lecture-only.
It is a poorer fit if what you want is a tool recommendation or a ready-made framework to install — the site explicitly positions tools as secondary to the thinking around them.
Background and ways to engage
The practitioner behind the site, Bas Dijkstra, states 20 years of experience in software testing and test automation, working with teams and organisations worldwide, based in Amersfoort, the Netherlands. Contact and ongoing material are offered through a contact form, a weekly newsletter, LinkedIn, GitHub and a blog RSS feed. Public appearances listed on the site include a keynote at CypressConf (online, October 20–22, 2026) and a keynote plus workshop at Taqelah Testing Conference (Singapore, March 4–5, 2027), both in English.
To judge fit, the most direct step is to read the blog and newsletter for the reasoning style, then use the contact channel to describe your team's current feedback problem — the site's own framing suggests that conversation starts with what you need to learn about your product, not with which tool you use.