I recently attended Swiss Testing Day, and it was a truly worthwhile experience.

It was a very well organized conference, with a great atmosphere, a strong sense of community, and lots of genuine enthusiasm for improving how we build and assure software. I really enjoyed listening to the various talks and perspectives on how we can advance testing as a discipline.

Unsurprisingly, AI was a big topic.

But while listening to the talks, I kept coming back to a thought:

A lot of the complexity we experience in testing would simply disappear if we invested much more effort upfront in business solution design.

By that I mean bringing the right stakeholders into one room — including business experts, QA, architects, engineers, and other key assurance stakeholders — and working together on an information-complete blueprint before implementation starts.

For me, that means using approaches like EventModeling and breaking the problem down into small, repeatable, business-aligned slices.

This is often misunderstood as waterfall.

It is not.

We do not need to model an entire enterprise platform upfront. We can take one business activity at a time, starting with the most important one, and build toward an MVP incrementally.

When this is done well, several things happen naturally:

• the actors are clear
• the flow of information is clear
• the business rules are clear
• the scenarios emerge directly from those business rules

And that is where not only testing, but a whole range of concerns, become much simpler.

Happy paths and relevant edge cases are no longer something we “discover” late. They are already visible in the design.

QA is not left reverse-engineering intent after implementation. QA can validate during the design session that the picture is complete and that the resulting test cases are clear from the identified scenarios.

But the same effect goes beyond QA.

When the design is clear and sliced properly, security, compliance, observability, and auditability also become far more straightforward.

Why?

Because spending the time upfront to understand actors, decisions, information flows, business events, and boundaries saves an enormous amount of headache later on.

It becomes easier to ask and answer the important questions early:

• Where do we need controls?
• Which rules must be enforced?
• What needs to be observable?
• Which events must be traceable?
• What do we need to prove for compliance or audit purposes?

Instead of bolting these concerns on afterwards, we can design with them in mind from the start.

Most delivery complexity is not caused by implementation alone. It is caused by unclear design discovered too late.

The result: testing becomes far more straightforward, coverage becomes aligned with real business relevance, security and compliance become easier to reason about, observability becomes more intentional, auditability becomes a natural byproduct of good design, and much of the traditional delivery pain fades away.

If our slices are truly autonomous and only loosely coupled through well-defined business events, then:

• regression testing becomes dramatically less important
• complex tests that drive the whole system through the UI can be kept to a minimum
• cross-cutting concerns become easier to handle systematically
• teams move faster with more confidence

In my view, the future of better testing is not primarily about adding more tools, more automation, or more AI on top of unclear systems.

It starts with better collaborative design.

Get the design right, and many downstream concerns — testing included — become simpler almost automatically.

Originally published on LinkedIn (2026-03-29): https://www.linkedin.com/pulse/better-testing-starts-design-gabriel-n-schenker-j9qme