What to Consider Before Engaging On Test Automation for Training or Consulting

On Test Automation is the training and consulting practice of Bas Dijkstra, a test automation specialist based in Amersfoort, the Netherlands, with 20 years of experience in software testing and test automation. Before engaging, a team should be clear about the problem it wants solved, confirm that the format (training, consulting, or mentoring) fits how the team actually works, and expect the engagement to be built around the team's own context rather than a generic curriculum. The site positions the work around one outcome: getting more valuable feedback from test automation, faster.

Start with the problem, not the service

The site's central claim is that valuable feedback from test automation requires more than picking the right tools and writing more tests. It calls for a deliberate approach to what is tested, how it is tested, and how the resulting feedback informs decisions. That framing is a useful diagnostic before you make contact.

Ask internally:

• What feedback is missing or too slow today? For example, are regressions found late, or are test results too noisy to act on?
• Is the bottleneck technical or methodological? A flaky suite and an unclear test strategy call for different kinds of help.
• Who needs to change? If only one engineer attends training while the rest of the team keeps its habits, the effect will be limited.

A team that cannot yet name its pain point is likely to get less from a consulting engagement than one that arrives with a concrete, current problem.

Match the format to your situation

The site describes three ways of working: hands-on training, consulting, and mentoring. They serve different needs.

The stated focus across all three is practical, lasting results, with work done on real problems in the team's own context. If your goal is a one-off audit with no follow-through, that emphasis on capability-building may be more than you need. If your goal is to stop depending on outside help, it fits.

Check the experience level against your challenge

The site cites 20 years in software testing and test automation and says Bas has helped teams and organisations worldwide improve testing practices, solve technical challenges, and get more value from automated tests. It also mentions work on test automation strategy, improving existing test suites, and exploring new approaches.

Use this as a filter: if your problem is a large-scale organisational transformation with heavy procurement and change-management components, confirm during the initial conversation that the scope matches. The published material describes hands-on training, consulting, and mentoring rather than broad programme management.

Look at public activity as a signal

The site lists upcoming appearances, which give you a low-commitment way to gauge the practitioner's current focus and communication style:

• October 20–22, 2026 — keynote (title to be announced), English, at CypressConf (online)
• March 4–5, 2027 — keynote and workshop (topics to be announced), English, at Taqelah Testing Conference, Singapore

There is also a weekly newsletter, plus LinkedIn, GitHub, and an RSS feed for the blog. Reading a few posts or subscribing before you reach out helps you judge whether the approach resonates with your team.

Contact first, decide second

The site's call to action is a direct conversation ("Let's talk"), with a contact page and an invitation to get in touch. No pricing, packaging, or booking process is published, so treat cost, availability, and scope as things to establish in that first exchange.

Come prepared with:

1. A one-paragraph description of your current test automation setup and its main weakness.
2. The outcome you want in three to six months, stated in terms of feedback speed or quality.
3. Who would take part and how much time they can commit.
4. Whether you are buying skills, advice, or ongoing guidance.

Ask in return how an engagement typically starts, what the team is expected to contribute, and how progress would be judged. The site's own standard — more valuable feedback, faster — is a reasonable yardstick to hold the conversation to.

When this is probably not the right fit

• You want a tool recommendation and nothing else; the stated approach treats tool choice as secondary to what and how you test.
• Your team cannot free up people to work on real problems during the engagement, since that hands-on element is central to the offering.
• You need a fixed public price list before any conversation; none is published, so the initial contact is the place to raise budget.

If none of these apply and you can articulate a concrete testing problem, the next step is straightforward: describe it through the contact page and see whether the proposed format matches how your team works.