Good QA is often invisible to the end user. When it works well, people simply experience a reliable product, accurate information, and a workflow that behaves as expected. Behind that experience is a process of questioning assumptions, identifying hidden risks, and preventing small issues from becoming larger product problems.
On this World Tester Day, we asked our colleague Nihad Šahinpašić, QA Engineer at Galeyo, to share what good QA looks like in practice. Drawing on his experience with BIM and Revit, he discusses the problems hidden behind seemingly functional products, the importance of understanding real user behaviour and why testing should begin long before the final checkpoint.
Read his perspective on what good QA prevents before users ever notice it.
1. What does good QA prevent before users ever notice there was a risk?
For me, good QA is mainly about finding problems before they become visible to the end user. In BIM and Revit work, that can mean preventing broken or inconsistent standards, or a model that technically works but can create problems later in documentation or construction. Good QA should be able to give confidence that the product is reliable, not just that it opens and works.
2. Which problems are easiest to miss when a product appears to work correctly?
I think the easiest problems to miss are the ones that don’t immediately break anything. A model can open correctly and look fine but still contain incorrect parameters, incorrect names, duplicate elements or marks. These issues are often overlooked and create issues because they can remain unresolved until someone depends on that information.
3. What early warning signs tell you that a small issue could become a serious product problem?
I usually look for repetition and inconsistency. It can indicate a problem with the workflow, standard, family, template, or underlying logic. Another sign is when people start creating manual workarounds. If users have to repeatedly “fix” something themselves, that’s usually a sign that the product has flaws and issues that should be addressed earlier.
4. How do you test the assumptions behind a feature, not only whether the feature works?
I try to understand logic about what the feature is supposed to do and then test the situations following that assumption. I don’t only test the ideal workflow. For example, I would check what happens with different inputs, unusual but realistic user behaviour or when the feature is pushed to its maximum. From my BIM experience, this is important because something can work perfectly in one model and fail when the model becomes more complex.
5. Which user behaviours do developers and product teams most often underestimate?
Users rarely behave exactly as the designer expects. They usually try to skip steps, copy and use things in ways that weren’t intended or find workarounds. I think QA is important since he "understands" the way people actually use a product, not just the workflow described in the requirements.
6. When requirements are incomplete, how do you decide what needs to be questioned or tested first?
I start with the things that could have the biggest impact if our assumption is wrong. I try to identify dependencies - if one unclear decision affects many other parts of the product, I would clarify that first rather than spending time testing smaller details. I assume nothing and question everything that could have an impact on the final result.
7. What makes a bug important even when it affects only a small number of users?
The number of affected users isn’t the only measure of importance. I would also look at what those users are doing and what happens if the bug affects them. A problem affecting 1% of users can still be critical if those users are performing an important workflow or working on a high-value project. I think impact and risk are more important than simply counting users.
8. What is one QA practice that prevents more problems than most teams realize?
For me, it’s testing early and continuously rather than waiting until the end. Even a simple review of requirements, assumptions, and expected behaviour before development can prevent a lot of problems. In my BIM work, catching an issue early is much easier than discovering it after the same problem has been spreading across an entire project. QA shouldn’t only be the final checkpoint; it should be a core part of the process from the beginning.
Quality starts before testing ends
Good QA is not defined only by the bugs it finds. It is also reflected in the problems that never reach users, the rework that never becomes necessary, and the decisions teams can make with greater confidence.
As Nihad’s perspective shows, quality begins with asking the right questions early, understanding how people actually use a product and looking beyond whether something simply works.
That mindset becomes particularly important in environments such as BIM and Revit, where software behaviour, engineering knowledge, and reliable information are closely connected. A parameter that looks insignificant, or a workflow that requires one repeated workaround can eventually affect documentation, coordination, or a much larger project process.
The strongest impact of QA may remain unseen, but it is present in every reliable product, and every workflow person can trust.
Keep exploring
Quality becomes stronger when testing relates to product understanding, domain expertise, and well-designed processes.
Read How to introduce order where QA never existed for a closer look at documentation, shared expectations, and building QA into a team’s way of working.
For another perspective from our team, explore The journey from electrical design to QA engineering and how engineering knowledge can help testers understand the real workflows behind Revit products.
And if you work in architecture, engineering or construction, see Why accurate data matters for better decisions in AEC projects to explore the role reliable BIM information plays beyond the testing process.