Published 14 May 2026

Testing smart, not hard - Quality assurance for lean teams

Get your product out there in stealth mode and test it before launching into mega marketing. In the early days of ionMy, the temptation was to shout from the rooftops. We’d won awards for our business plan, we had an idea we believed in, and we thought the world was ready. So, when the chance came up for a paid spot on Channel 9’s Your Business Success TV show, we jumped. There we were: a TV crew, a glamorous morning show, and our baby software being broadcast across the nation. It felt exciting, like we had arrived. The problem? We hadn’t. The software was still too green. Clients hadn’t yet shaped it with real-world use. The marketing splash cost a fortune and returned little in tangible results. Looking back, it was far too early for that kind of exposure.

I Stock 2204917953 Modified D2a032a9 2a41 479c 8729 582e8d24142c

Testing smart, not hard - Quality assurance for lean teams

Real testing means real users

The best testing environment isn’t a lab or a script, it’s your prospects/client’s environment. Watching a user fumble through a login, click the wrong button, or misinterpret a field tells you more than a thousand test cases.

Our most valuable QA didn’t come from in-house trials; it came from brave early adopters in childcare centres and schools who trusted us enough to try the software in their daily work.

Was it nerve wracking to know bugs might surface? Absolutely. But those early lessons were worth their weight in gold. Bugs can be fixed. Trust, once lost, is harder. That’s why we treated every test client as a partner, thanking them for feedback and moving quickly on fixes.

Lean, not lax

“Testing smart” doesn’t mean skimping. It means being strategic. As a small company, we couldn’t afford a 20 person QA department. What we could do was prioritise: focus on the features that mattered most, release them quickly, and gather feedback.

Our model became -

  1. Build lean
  2. Release to a few clients quietly (stealth mode)
  3. Learn fast from their experience
  4. Iterate

This wasn’t “fail fast” in the reckless sense (sideline comment: I dislike that saying), it was learn fast.

The server nightmare

Of course, no amount of smart testing can prevent every nightmare. I’ll never forget the day one of our hosting providers simply disappeared. Servers down, clients cut off. I was driving home after dropping my daughter to school when I took the call from our technical expert that there was a fatal error and we had no access to the hosted server.

A software founder’s worst fear!

But here’s where preparation pays off. Because we had insisted on cloud architecture and kept disciplined backups, we recovered within a day. Clients lost only a Friday of access. That experience, stressful as it was, proved the worth of planning for disaster not just testing features, but testing recovery.

The trap of perfection

One mistake I often see founders make is waiting until their software is “perfect” before releasing. Here’s the truth: it never will be. Technology moves too fast. Perfection is a moving target. Software is never finished, you can’t just develop it and that’s it.

It is a life long commitment.

Our early versions were basic, even clunky. But they were out there, in use, gathering real feedback. That’s how we grew.

If we’d waited for perfection, we’d still be waiting.

My advice

Testing smart is about balancing speed with responsibility. It’s about putting your product into the world, learning, and adapting. That’s how lean teams deliver quality without burning themselves out.

 

About the author Sonja Bernhardt OAM is a multi-award winning technologist, speaker, CEO of Thoughtware Australia, and author of "Girls Do IT Too!"