In a recent podcast episode of Software Engineering Tales, I sat down with Katka Pilátová, a senior software engineer in test with 10+ years of experience.
We discussed a topic that often sparks as much debate as it does passion in our industry: quality in software development.
Our conversation poked into what quality really means, the role of QA, and how a culture and mindset for quality can make or break a product.
Here’s a look back at some of the insights we explored I think are useful. The full episode is attached at the bottom of article.
Quality does not mean just bug finding.
Defining “quality“ should be one of the first tasks for QA.
When asked what makes high-quality software and what is the role of QA, Katka stressed that quality is more than just the absence of bugs. It’s about ensuring that every stakeholder is satisfied:
User Satisfaction: Software must meet user needs and keep them coming back.
Developer Wellbeing: Developers should not be overwhelmed by technical debt or poor processes.
Business Success: Bussiness is happy because it gets money
Katka summed it up perfectly: if users are happy, developers are engaged, and the business thrives, you’ve hit the quality sweet spot. And that will be subjective from product to product.
QA: More Than Just Testing
For many, QA is synonymous with testing, but Katka paints a broader picture. She described QA as a role that involves:
Cultural Transformation: Helping companies adopt a mindset of quality.
Process Architect: Establishing strategies around static analysis, coding standards, and even documentation - all that aimed towards quality and tailored to the product.
Collaboration: Working closely not only with developers, but also with UX designers, project managers, and other key teams to ensure that quality is built into every stage of the product lifecycle.
Rather than simply hunting for bugs, QA professionals act as coaches and advocates for sustainable, long-term software quality.
The Balance Between Manual and Automated Testing
A significant part of our discussion focused on the tools and techniques used. While automation plays a critical role - especially for regression testing - Katka reminded us that:
Exploratory Testing Remains Essential: Automation can only follow predefined scripts; it can’t catch the “weird edge cases” that human intuition often uncovers.
Investment Decisions Matter: Not every project needs a fully automated end-to-end testing suite. In many cases, especially early on or in rapidly evolving environments, manual testing remains valuable.
The key takeaway? Use automation for its strengths (consistency and speed) but don’t underestimate the value of human judgment. And don’t rush with investment you might not need yet
Collaboration: Communication is Key
One of the most actionable parts of our conversation centered on bridging the gap between development and QA teams. Katka advised:
Build Rapport Early: Don’t just limit interactions to formal meetings. Get to know colleagues across departments.
Engage in Thoughtful Code Reviews: Use reviews as opportunities for learning. Both in providing constructive feedback and in understanding the “why” behind design decisions. It is quite common that especially reviews for test code are underestimated.
Standardize Communication: Implement frameworks for code reviews that help depersonalize feedback and focus on the code itself.
When to Invest in Quality
Our discussion also touched on the practical side of quality: knowing when to invest in rigorous testing practices. Katka noted that even startups, which may initially prioritize speed over process, should:
Lay a Strong Foundation: Even a minimal set of coding standards and unit tests can prevent technical debt from spiraling out of control.
Scale Thoughtfully: As products grow and the stakes get higher, so too should the investment in robust quality processes. Before issues become too costly to fix.
The sooner you integrate quality into your development lifecycle, the more sustainable your product will be over time.
The Take-Home Message
If there’s one thing to remember from our conversation, it’s that quality is a mindset. It isn’t a one-size-fits-all checklist but a dynamic approach that must be adapted to each product, team, and business context.
Whether you’re a developer, QA professional, or business leader, getting into a quality-first mindset is the best long-term investment you can make in your software.
Full episode here (or listen wherever you usually find your podcasts - just search “Software Engineering Tales“)