Reliability Is Not a Coincidence. It Is the Result of How We Work.

In systems where documents represent obligations, decisions and compliance, an error is not just an inconvenience. It can mean missed deadlines, wrong decisions and loss of control over processes.

“Our main goal is to detect errors in time and to make sure that with every click, the user gets exactly what they expect,” explains Klavdija Blatnik, Head of the Software Quality Assurance Unit at Mikrocop.

Klavdija Blatnik, Head of the Software Quality Assurance Unit

The Final Checkpoint Before Production

The QA team is involved in every step of InDoc EDGE development, not only at the end.

“We are essentially the final checkpoint before something becomes part of everyday use,” Klavdija explains. “Of course, we cannot catch everything, but we can make sure that most critical errors never reach the users.”

Errors discovered in later stages, or only after a solution is already in use by a client, are more demanding and more expensive to fix. That is why the team thoroughly checks every new or changed functionality before it goes into production.The QA team is involved in every step of InDoc EDGE development, not only at the end.

Every Change Carries Risk, Even a Small One

InDoc EDGE is not a static system. With every upgrade, new functionality or integration, something changes. And every change, even a small one, can affect parts of the system that may not seem connected at first glance.

Small change, big impact

“One line of code can affect thousands of users or documents. Our job is to make sure that does not reach production.”

For example, after an upgrade, background processes may fail to start correctly. Without systematic testing, such an error is often discovered only by the user.

How Testing a New Functionality Works in Practice

When development completes a new functionality, the QA team takes over.

“We carefully read the requirement and need to understand what was done and how it could affect other parts of the system,” Klavdija explains.

Collaboration

This is followed by manual testing of all scenarios: positive, negative and edge cases. Test scenarios are prepared in advance where possible. Otherwise, they are written during testing and become part of all future testing for that version.

Where it makes sense, the team also prepares automated tests, which are triggered once a day, regardless of whether there has been a system change or not. “This means that potential errors are detected continuously, not only during the next upgrade,” Klavdija adds.

Key types of testing include:

Functional testing – checking whether individual functionalities work according to requirements.
Integration testing – checking whether connected modules work properly together.
System testing – checking how the application works as a whole in a real environment.
Regression testing – checking whether updates affect parts of the system that already work.
Load testing – checking how the system responds under higher load.
Security testing – checking access rights, authorizations and data protection.

Manual and Automated Testing: A Combination That Cannot Be Replaced

“Automation cannot replace the intuition you develop through experience: the feeling for where something might go wrong and why,” says Klavdija.

That is why the team always combines both approaches.

Manual testing brings an understanding of the user experience and helps identify edge cases. Automated testing ensures repeatability and continuous checking of system stability. One approach alone is not enough.

Collaboration That Reveals Real Scenarios

Even the best internal testing cannot simulate every real-life situation. Part of testing also takes place in cooperation with clients.

Clients test their processes, integrations and specific scenarios in demo environments. This often reveals dependencies on other systems, process-specific details and edge cases that could not have been predicted in advance.

This is not a failure of the process. It is the reality of complex systems.

That is why reliability is always the result of internal checks, real use and a fast response to any deviations that are discovered.

When a client reports an issue, it first goes through the support system, where it is determined whether it is an error, an improvement or a new requirement. QA becomes involved once the solution is ready and confirms whether the fix actually works.

When an Error Still Happens: Process, Not Panic

“It happens, and that is completely normal,” says Klavdija. “What matters is how quickly and effectively you respond.”

When an error is discovered, the team describes it precisely, reports it in the system and analyzes the cause together with development. Once the issue is fixed, it is tested again - not only the error itself, but also its possible impact on the system. If an error repeats, the test scenarios are adjusted.

Tested is not a coincidence

“When QA says ‘it has been tested’, it means that an entire team and a large number of checks stand behind that statement.”

The Goal Is Not Perfection, but Reliability and Responsiveness

“In a system as complex as InDoc EDGE, perfection simply does not exist,” Klavdija says directly. “But that does not mean we do not work toward it. Our goal is to reduce risks as much as possible and to respond quickly when an error appears.”

For an organization that processes thousands of documents every day, this means fewer interruptions, fewer unexpected situations and easier proof of compliance.

This is not only a better user experience. It is the difference between a system you can trust and a system where you simply hope that everything works.

Source: This blog was created based on a conversation with Klavdija Blatnik, Head of the Software Quality Assurance Unit at Mikrocop. Read the full interview on the dedicated Mikrocop website.