Skip to content
English
All posts

Building Quality Through Responsibility

Klavdija

Interview with Klavdija, Head of QA at Mikrocop 

In a world where organizations process thousands of documents every day, errors are measured not only in lost minutes. They can lead to missed deadlines, incorrect decisions, or even a loss of trust.

That is why, when developing InDoc EDGE, there is no room for randomness – but we also avoid the illusion of perfection. Every upgrade, feature, and line of code undergoes careful verification to detect potential issues as early as possible.

This work is carried out by the Quality Assurance (QA) team, whose attention to detail and sense of responsibility help ensure that problems are identified and resolved before they affect users.

 

Klavdija, QA teams often work behind the scenes. How would you describe their role in the InDoc EDGE platform?

 

That is true – our work is not always visible, but without it, InDoc EDGE would not be what it is today.

Our main goal is to detect issues early and ensure that whenever a user performs an action, the system behaves exactly as expected.

Errors that appear later in the process – or even worse, when users encounter them – are much more difficult and expensive to fix. That is why every new feature or change goes through thorough testing before it reaches users. This helps ensure that updates are stable and that users can continue their work without interruption.

In a way, we are the final checkpoint before something becomes part of everyday use.

Of course, it is impossible to cover absolutely everything, but we can ensure that the most critical issues never reach users. In this way, we reduce risks, prevent disruptions, and maintain the reliability that users expect from a business-critical platform.

So the goal is not perfection, but reliability?

Exactly. In a complex system like InDoc EDGE, perfection simply does not exist. But that does not mean we ignore quality. Our goal is to reduce risks as much as possible and to respond quickly when an issue appears.

It is important that we have a good understanding of the system and all related processes. This allows us to identify potential impacts and manage them effectively.

Every fix or upgrade is also an opportunity to improve something.

How does your work look in practice when a new feature is developed?

When development finishes a new feature, the QA team takes over. We first review the requirements carefully and make sure we understand what has been implemented and how it might affect other parts of the system.

Then we perform manual testing, checking different scenarios – positive, negative, and various edge cases.

If possible, test scenarios are prepared in advance. Otherwise, they are created during testing and then reused for future testing cycles.

We use several testing tools. If a feature is suitable for automation, we also create automated tests that run once a day.

This means we always test on two levels: with human insight and with technology that verifies technical details.

The combination of both provides the highest level of reliability. Manual testing helps us understand the user experience, while automated testing ensures repeatability and continuous verification of system stability.

“Every change carries a certain level of risk. A single line of code can affect thousands of users or documents. Our job is to make sure that such issues never reach production.”

A professional testing approach: different types of testing

Because InDoc EDGE is a complex system, we use several types of tests:

  • Integration testing confirms that connected modules interact correctly.

  • System testing evaluates how the application behaves as a whole in a realistic environment.

  • Regression testing ensures that new updates do not break existing functionality.

  • Load testing checks how the system performs under higher usage.

  • Security testing verifies access rights, authorizations, and data protection.


What happens if something still slips through?

That can happen and it is completely normal in complex systems. The important thing is how quickly and effectively you respond.

When an issue is discovered, we document it carefully, register it in the system, and analyze it together with the development team. After the issue is fixed, we perform another round of testing to verify that the change works correctly and does not affect other functionalities.

If the same type of issue appears again, we update our test scenarios so it can be detected earlier in the future.

“Perfection does not exist in systems of this scale, but what matters is that we detect issues and resolve them as quickly as possible.”

How long does testing usually take?

It depends on the scope of the change. Smaller tests can often be completed within a day, while larger and more complex changes may take several days.

It is difficult to estimate the exact time in advance, because sometimes new issues are discovered during testing that require additional investigation and coordination with development. 

That is why you need to be flexible and ready for a constantly evolving environment.

How important is communication between QA and development?

Extremely important. Collaboration between QA and development is essential. We are in constant contact with developers and often collaborate during the planning phase of new features.

We exchange ideas, clarify questions, and resolve uncertainties together. It is important to speak openly when something is unclear and not leave things to chance.

In the end, everyone works toward the same goal: delivering a stable and reliable product to users.

Sodelovanje

How do you collaborate with other teams and customers?

We collaborate with other teams as needed, most often with product managers, support teams, and business solution specialists.

Customer feedback is also very important. Customers are often involved during testing in demo environments, where they test their integrations and customizations. This sometimes reveals specific scenarios we cannot always predict internally because we do not have insight into external systems.

When a customer reports an issue, it first goes through the support system (PIS), where it is classified as a bug, an improvement request, or a new requirement.

These situations are very valuable because they show how InDoc EDGE behaves in real-world environments, not just in controlled testing environments.

QA becomes involved again once a fix is prepared, verifying that the solution works correctly.

What are the biggest improvements you have introduced in the QA process in recent years?

We have automated many parts of testing and defined testing phases more clearly. Today, we have systems where some tests run automatically whenever code changes are made, allowing us to continuously monitor system stability.

However, the human factor remains essential.

Automation cannot replace the intuition that comes with experience – the ability to sense where something might break and why.

That is why we always combine both: technology and experienced people.

Now, from another angle - working in the QA team. Who thrives the most in a QA team?

People who think analytically and appreciate structure. People who are curious about why something works – or why it does not. People who are detail-oriented, curious, and enjoy investigating problems. Continuous learning is also essential.

What knowledge and skills are important for working in QA?

You do not necessarily need a programming degree, but you do need logical thinking, persistence, and attention to detail.  Knowledge of SQL, programming or scripting languages, and understanding how systems work in the background can be very helpful.

At the same time, it is equally important to think from the user’s perspective. People who enjoy solving puzzles and do not give up until they find the root cause tend to do well in QA.

The job of a tester is not to "click buttons" - it is to explore, think and anticipate what could go wrong  and how things could be improved. 

Above all, a willingness to keep learning is essential. In QA, you never stop learning, because systems, products, and technologies constantly evolve.

How do you onboard new team members?

If someone joins without previous experience, it usually takes about six months to learn the basics and about a year to become fully independent.

New team members start by learning testing fundamentals and understanding the system’s logic. Under mentorship, they gradually take on more complex tasks.

We have a structured mentoring program, learning materials, test scenarios, and internal Wiki documentation. Mentorship is not just a formality – it is real support. We focus on teaching the logic behind testing, not just procedures.

What advice would you give to someone who wants to work in QA?

Be patient, curious, and analytical You should be interested in understanding why something works – and why it does not.

Even without a strong technical background, you can learn quickly if you have the right mindset.

In QA, we are not looking for perfection. We are looking for reliability, precision, and the desire to understand systems.

What motivates you most about this work?

The best feeling is when our work prevents a problem before it happens. When we improve something, when the system runs more smoothly, or when users do not even notice that anything has changed – that is when you know you did something right.

“The work is dynamic and very diverse. Every new version brings something different, and that is what keeps me motivated.”

What would you highlight as the greatest value of your team?

Reliability and collaboration. Everyone in the team understands that their work directly affects the product.

When QA confirms that something has been thoroughly tested, it means that an entire team and many verification steps stand behind that decision.

We do not promise perfection. But we do provide responsibility, responsiveness, and the level of trust the system needs so users can continue their work with confidence.