Rethinking the Quality Mindset
By Yuney S. Chonlee ·
Learning when and why to test
Before working in SaaS, I worked in product development at Fisher & Paykel Healthcare (FPH), where testing was part of an engineer's responsibilities.
Verification and validation (V&V) were formal stages of the development process. An engineer would write a test protocol based on acceptance criteria derived from the product requirements. Once reviewed and approved, another engineer would execute the tests and document the results.
And testing could take a long time.
Even with accelerated environmental conditioning, some tests required weeks to complete. A full verification programme could take months.
But nobody really talked about "shifting left". Quality was already everyone's concern and responsibility. We tested our work during development, while formal verification followed a more structured process.
We were developing medical devices, after all. Failures could have serious consequences for patient safety.
Despite the effort involved, one thing was relatively straightforward: knowing what we needed to test.
Requirements were clearly defined. We knew what the product should and shouldn't do, and the verification process was designed to establish whether those requirements had been met.
Then I moved into startup SaaS, and it was as if my world turned upside down.
Instead of lengthy verification cycles, features could be implemented, tested and deployed within days. A Sev-1 bug discovered in the morning needs a hotfix that afternoon.
Requirements changed frequently. Sometimes decisions were made in conversations rather than documented specifications.
I found myself constantly catching up on context, worrying about what I didn't know and agonising over how much testing was enough.
But there was another important difference.
We weren't releasing an entirely new product every few years. We were making smaller, more incremental and more frequent changes to an existing system.
I couldn't hold up a PR just because I hadn't performed 10 different types of testing. The velocity of delivery in SaaS was an important factor that I wasn't concerned about previously.
Quality engineering isn't about applying the most rigorous process to everything. It's about knowing where that rigour matters.
I had to rethink my approach. But there was another hurdle beyond changing my own mindset...
"Someone forgot to write up this ticket."
Except nobody necessarily forgot. Sometimes that really was all the information available.
A ticket lands in "Ready for Testing". I open it.
A one-line description. Maybe some acceptance criteria, maybe not.
Now I have questions.
What are we trying to achieve? What's the expected behaviour? What could go wrong?
Then come the practical questions. Do I have the right test data? Can I reproduce the necessary states? How will I verify what's happening behind the scenes?
So I go back to the developer, gather context and work out a testing approach.
And if I discover that something isn't easily testable, we might need additional setup or implementation changes before meaningful testing can even begin.
That's a lot of work happening after the feature is supposedly ready for testing.
So, is it really ready to test? Not quite. We're readying to get this ticket in a testable state so it's ready for testing.
It would be unfair and impractical to expect every ticket in a startup to be document controlled like a formal test protocol. That would defeat the point of moving quickly.
Then what are some approaches we can take as a team without slowing down development and delivery? How can we align better without adding more processes and still adopt a quality mindset so that testing doesn't become the bottleneck or a gated phase?
To the Left like Beyoncé
A few practices have helped me approach this differently.
Three Amigos. Bringing product, development and QA together to discuss upcoming work gives us a chance to understand the requirements, priorities and risks before implementation. It also helps us plan for testing rather than treating it as an afterthought. I often like to have more than just three amigos, too. Sometimes that means bringing in a DevOps engineer or UX designer when needed.
Early test discussions. When a developer picks up a ticket, we'll sometimes have a quick chat about the testing approach. What might be tricky? What data will we need? Is there anything we should consider before writing the code? We don't need a complete test plan, just enough shared understanding to get started.
Desk checks and pairing. Sometimes it's easier to sit together and walk through a feature. The developer explains the implementation, I explore it from a testing perspective, and we investigate unexpected behaviour together. Small issues can often be addressed on the spot rather than going through another round of hand-offs.
None of these requires QA to attend every meeting or approve every decision.
And I don't think we need another formal process for every ticket.
It's simply about having the right conversations while there's still time to do something useful with the answers.
So, what is a quality mindset?
Looking back, the biggest difference between my two experiences wasn't really how much testing we did.
It was how I needed to approach it.
At FPH, I learnt the value of deliberate, repeatable and mature testing processes as well as thorough failure modes and hazard analysis.
In SaaS, I've learnt to work with changing requirements, assess risks more selectively and seek out context before starting to test.
To me, a quality mindset means asking the questions that help us make better decisions.
What are we trying to achieve? What assumptions are we making? What could go wrong? And how will we know if it works?
Those questions don't belong exclusively to QA engineers, and they don't need to wait until a ticket reaches "Ready for Testing".
Perhaps that's what I've come to appreciate most.
Testing might be a phase in our workflow, but thinking about quality shouldn't be.