"You have to distinguish between what is a bug and what is just misuse," says an IT tester in an interview about non-standard scenarios and bugs."

What do people around you think you do?

Well, since I was already doing this job during the COVID period — and I spent a few months living with my parents then — they had the chance to see it firsthand. And most people’s reactions can be summed up like this: “So basically, you’re doing the same thing you did as a kid when you played on the computer, right?” Meaning — I just click and watch what happens.

But of course, that’s a very simplified view. I have a technical background, so my close ones might somewhat understand what it’s about. When I say I’m a tester, people often imagine that I just click more than others. And maybe that’s partly true — but it’s not just about clicking.

I think people often don’t realize the scope and complexity of this work. For example, before I became a tester — when I was just a user — I also used to think: “How could they have missed this bug?” But once I got to the other side, I understood that there are thousands of combinations to test. It’s simply impossible to cover everything. You can’t test an application 100%. Everyone thinks their bug is the most important one and should have been caught — but the reality is, it’s just not possible. And that’s probably the biggest misconception.

So what does it look like in practice? When do you enter the development process?

When a developer finishes their work, they hand it over to me — marking a specific functionality in the system, app, or solution as “ready for review”, meaning ready for testing. But it’s important to note that this doesn’t mean it’s deployed to the client yet. In our process, we have several environments — development, integration, and finally production. Testing takes place primarily in the development environment and only in the integration environment in exceptional cases.

For example, when a new feature is being developed, I don’t get involved right away. I step in only once the functionality is complete. It’s pointless to test half-finished solutions because other parts might still affect the ones already built. So once something is finalized, I get notified that it’s ready, it’s deployed to the test environment, and that’s when I start testing.

What does testing look like in detail?

First, I review what has been changed or added. I have a prepared test scenario — a precise set of steps that simulate the situation. If the bug behaves as previously described and is fixed, I can mark it as resolved. If not, I return it to the developer and include an exact description of the issue.

In such a case, I create an issue in JIRA, which is the tool we use to track the entire development cycle. In the issue, I include the bug title, a detailed description, the version in which it occurred, the environment, screenshots, and — most importantly — the exact steps to reproduce the bug. The developer needs to know how I got there, because they must be able to verify it on their side.

For example: log in, click on the document, do this — something breaks there. It has to be precise.

So you create this kind of “protocol” for every bug?

Yes. And the protocol isn’t just text — it has to be technically clear. It includes images, versioning, and exact conditions. For example, it can happen that the developer can’t reproduce the bug — then we investigate whether it’s an issue specific to a browser or a device. Maybe I tested it in Chrome, but they used Firefox, and the bug only occurs there. Or it might appear only on iPhone, or only on Android with a specific version.

Once, we even had a reported bug that turned out to be caused by the user having the DuckDuckGo browser. So testing every possible combination of hardware, software, and environments is simply impossible. That’s why we always focus on what’s relevant to the target market — for example, the browsers and devices the end users actually use.

So your test scenario — is that some kind of standardized document?

Yes, we have predefined test scenarios. Some were written by me, others by my colleagues. Ideally, these scenarios should be properly documented and shared among all testers, especially when there’s a larger team. Some scenarios are also used for automated tests — those are stored in special collections and include descriptions of what they do and what the expected results are.

And what happens if you find, say, thirty bugs?

Each one gets entered into JIRA as a separate issue. Every single one has to be described and documented, and then the developer reviews them. Once they’re fixed, the developer deploys an updated version, and I go through all the scenarios again. If everything is resolved, I mark the issues as closed and we can move forward.

And this repeats with every version?

Exactly. With every new version. For example, we have version 1.0 — developers fix the bugs, and I test again. If issues still exist, the cycle repeats.

Is there such a thing as a “bug-free version”?

Theoretically, yes. But in practice — no. Every application has bugs. The key question is which ones are still acceptable. For example, a bug that appears only when using Firefox on an iPad — that’s such a rare case that it’s treated as low priority. Of course, there are categories of bugs. We have “blocker” — meaning we can’t continue, such as when the server doesn’t work. Then there are “critical” bugs — issues in core functionality. After that come “major”, “minor”, and finally “trivial” — like a low-resolution logo or a slightly misaligned element on a nonstandard device. Those are mostly cosmetic.

How much actually needs to be tested? Is that even quantifiable?

It’s very hard to measure, but I often say testing takes at least half of the total development time. It’s not something you can just do “on the side.” If something takes a week to develop, it usually needs at least as much time for testing. And the more complex the application, the more combinations there are — and the more time it takes.

For example, language versions are a whole separate chapter. If you have an app running in English, Polish, Hungarian, Czech, and Slovak, you have to go through every version manually. Even if you don’t speak the language, you check whether any text is missing, whether line breaks are off, or whether characters from another language appear. We once had a case where the Hungarian version displayed a message in Ukrainian. Things like that just happen.

Testing, in my opinion, is still underestimated in terms of how much time and effort it actually requires. And I’m talking even about manual testing — where you have to go through everything by hand: input combinations, various devices, and different real-life situations.

And what about the cases that can’t be tested automatically? Do you do everything manually?

For a long time we worked purely manually, but now we’re transitioning to cover at least part of the scenarios with automation. Together with the developers we have a shared goal: to create automated tests that run every day. At the same time, I’m creating new, shorter manual scenarios that can be completed in a day or two. The point isn’t to test everything at once, but to be able to quickly verify the critical parts.

And once you’ve gone through all the scenarios, what then? Does the project end for you at that point?

It depends on the project. Sometimes that’s where my involvement ends; other times I continue even after go-live — providing support and consultations with the customer. It really depends on how the project is set up.

So in your work you have to think like a user?

I try to put myself in the user’s shoes — and it’s not always easy. Every user has different habits and uses the system in a different way. Some people click illogically or chaotically, or do something completely differently than you’d expect. And they’re often the ones who uncover bugs that regular testing won’t reveal. That’s why it happens that a client reports a bug and we’re left shaking our heads: “But we tested this — everything was fine!”

And what do you do then?

I start verifying, trying, simulating… and I don’t always manage to reproduce it. There are situations where I can’t repeat the bug — and that’s the worst, when you don’t know exactly what the person did. You find out they went down a very non-standard path that a typical user would never try. Then you have to evaluate: is this a bug that could recur, or is it so unique that it’s not worth fixing?

For example, with large systems like document portals with tens of thousands of users, it can happen that someone can’t complete registration. For us, that’s a signal: OK, we need to look into the logs and find out why it happened. Maybe it’s just a technical exception. Or maybe the person tried at the moment their internet dropped. In those cases we often open the developer console, watch what response came back from the server, and see what happened. If I can simulate it, I can confirm and address the bug. If not, I have to keep digging.

What are the most bizarre scenarios?

A classic one is when a user clicks the same button three times in a row. But not out of frustration because something isn’t loading — I mean those cases where a button appears for just a second, and the user somehow manages to press it three times in quick succession, completely breaking the process.

Or when we test situations with slow internet. I have to deliberately slow down my browser, set delays — because that simulates the real environment of users in areas with poor connectivity. People behave differently, have different devices, different conditions. Someone clicks something, then goes to cook dinner, comes back two hours later, and expects to continue as if nothing happened. But in the meantime, the app session expired, logged them out, or the link timed out. And they wonder, “Why isn’t it working?”

Do you also encounter cases where a client reports a bug, but it’s not actually a bug?

That’s a common scenario. For example, something in the documentation describes how the system is supposed to work — but the user does it completely differently from what’s expected, and something breaks. Then they report a “bug,” but in reality, they just bypassed the designed process. And we have to evaluate: is this a real error, or just incorrect usage? Sometimes it is a production bug that needs immediate fixing. Other times, the user simply did something the system technically allowed — but wasn’t meant to — and that caused the issue. A tester must be able to identify that boundary.

So you have to understand the system both inside and out.

Absolutely. For example, I still don’t know exactly how online banking looks in practice at a bank I don’t personally use — but I understand the processes, how they work, and how they integrate with other modules. It took us months to fully grasp all the interconnections. For our application to function, it has to integrate with more than ten other systems from different vendors. Each handles something different, yet everything has to work seamlessly together. And on top of that, the whole thing has to pass security audits, approvals, and compliance checks.

You mentioned working with analysts and developers. Who are the people you communicate with daily?

Primarily developers and analysts. With analysts, I discuss the logic of the system and functional requirements; with developers, how things were implemented and what technical limitations there were. Sometimes a project manager or consultant joins in, and occasionally even the client directly. And sometimes, when a bug falls outside my testing scope, I step into a consultant’s role — investigating what exactly happened, why it couldn’t be reproduced, and who might have the answer.

How did you actually get into IT?

It basically started as a game. We had a computer at home — with some of those early games my parents forbade me from playing because they were “too violent,” like Duke Nukem. But I was fascinated. I tried to get around the bans — copying games, installing them secretly, hiding the installs in hidden folders...

Gradually, I got into it more, taught myself things, experimented. And that curiosity helps me immensely even today. Many people say, “I work with computers every day.” But if you’ve spent ten years in a bank only opening Excel and Word, it doesn’t mean you understand how computers work. You ask them, “Do you know what Windows + E does?” and they say, “No idea.” But if you’re the kind of person who likes to dig into the system, experiment, explore — then you have a huge advantage. You can look at problems differently.

So would you say a tester should be a bit of a “self-starter”?

A tester on our team shouldn’t be someone who waits to get an exact assignment and then just follows it step by step. Sure, sometimes it works that way — but often it doesn’t. We sometimes get documentation that’s eighty pages long, full of descriptions of how everything should work. But even then, a lot of things can’t be fully simulated. In a banking environment, for instance, there are so many specifics that it’s almost impossible to cover them all in tests. If you expect someone to draw everything for you and tell you exactly, “Do this,” you’ll struggle. That’s why it’s important for a tester to think independently, fill in missing information, and be able to judge what else needs to be checked and what’s already beyond scope.

What would you say are the essential traits of a tester?

Definitely patience. And the ability to think outside the box. A tester has to see things differently — think like a user, but also like a developer. You need imagination and curiosity — a real desire to find bugs. It’s not enough to just follow the manual. If someone tells you, “Go test document signing,” it’s not enough to do the basic scenario — open, sign, send.

You also have to try to break it. What happens when you enter the wrong data? When you close the page mid-signing? When you click where you shouldn’t?

So what’s the biggest misconception you encounter about your job?

The biggest one is that people think all bugs can be found. Everyone assumes their bug was so obvious that it must have been tested. But in reality, there are literally thousands of possible combinations, and it’s not realistic to test them all. Think of an average user — something doesn’t work, no error appears, an image doesn’t display properly — and they say, “How could you miss this?” But when you realize how many combinations there are — across devices, software, environments — it’s just impossible to test everything 100%.

Is there such a thing as a “typical tester”?

I don’t think so. I don’t know anyone who intentionally became a tester. Most of us just kind of “fell into it.” In my case, they basically threw me into it: “Here, you’ll do this — we don’t have anyone else.” And I thought, “Alright, I’ll give it a try.” And then I learned as I went.

Does professional deformation show up in your personal life?

Definitely. When someone shares their screen, I automatically watch how they click — whether they’re fast, confused, if they understand the navigation. I observe app interfaces, thinking about what could be improved and how it should work. When I fill out a form or find an error in an e-shop, I instinctively open the console, check the logs, and look for the cause. And I admit — sometimes I even fill out feedback forms, even though it slows me down, because I know there’s someone like me on the other side who’ll appreciate it.

Does one need special education or skills for this job?

I think what you need most is enthusiasm — and at least basic computer literacy. Things that I now consider common sense — like how to navigate a system, work with a browser, or test something yourself — aren’t obvious to everyone. For me, it was natural because I’ve been doing it for years. But without that foundation, it’s hard to get into testing.

Who would you recommend this job to?

To anyone who enjoys solving problems but doesn’t necessarily want to program. Someone who loves to dig into things, analyze, test, try to break stuff — and then figure out why it broke. Sometimes you get a bug that seems unsolvable, and when you finally find that one tiny detail causing it, it’s like a “boss fight” moment in a game. And that’s the best feeling.

You mentioned video games — you used to review them?

Yes, I wrote reviews for more than ten years. It was a hobby that grew out of my passion for games — and the fact that I could look at them from both a technical and a user-experience perspective.

And you still play games?

Of course, I still play. Sometimes it tempts me to think, “I could exploit this.” But I’ve learned not to — because it can ruin the whole experience. Like in games where you can drag and drop items — if you press another shortcut at the same time, you can duplicate the item. That kind of thing kills the challenge. In games like Dark Souls, it completely destroys the atmosphere if you “cheat” your way through it.

Best game you’ve played recently?

Elden Ring. It’s an RPG, primarily single-player, with a massive open world. But historically, I’d say Half-Life 2 is the best — it was groundbreaking because it brought physics into gaming. The interaction with the environment was completely different. Today, you see that same quality in something like Baldur’s Gate 3, which is exactly why it’s so successful.