Have you ever struggled to explain what you do as a tester — or what testing even means in your organization? You’re not alone!

1. “So… What Do You Actually Do?”

• Easy answer

I’ve come up with a few answers over time, like, “I work at an IT company, but I’m not a developer.” Sometimes that works, sometimes it doesn’t. I tell them I’m a tester, which doesn’t sound very natural in Spanish, so some people keep asking, “But what exactly do you do as a tester? And how did you end up there without an IT background?”

• Complex answer

Indeed, I’m not the only one working in IT without formal IT studies, but in my role, I’m responsible for software quality. I make sure the software meets specific criteria before it’s delivered to end users. Once again, it shuts down the conversation — clear and sharp, but it doesn’t really keep things going.

Honestly, I’m never quite sure if I’m actually answering this innocent question or just making it sound way more mind-blowing than it is. Every time this topic pops up, I catch myself wondering—usually in a very casual, slightly confused way: “Wait, what is a TESTER, anyway?”

2. Definition of Testing 

If I consult one of the main references, such as the ISTQB (International Software Testing Qualifications Board),  it defines “testing” as “The process within the software development lifecycle that evaluates the quality of a component or system and related work products”.

However, we can see that the definition has already gone through three versions in the glossary. This shows how difficult it is to find a clear, definitive one.

It’s easy to see why defining testing is so difficult, especially when you’re juggling terms like:

• Evaluation
• Quality
• Component
• System

Especially the term evaluation, which is broad enough that even companies striving for high-quality products—and hiring testers, QA managers, and entire test teams—often let their testers rely on their own experience rather than following a clearly defined workflow.

2.1. Role of Testers

Of course, some companies offer rough guidelines, but ultimately, it comes down to the tester’s attitude and approach within each system or team.

This is quite unique, isn’t it? Nonetheless, most other areas in IT have clearly defined roles—developers with specific coding expertise, scrum masters as team facilitators, product owners with their roadmaps and priorities, and so on.

In my early Agile projects, I was surprised to learn that the tester role isn’t defined at all in the theory, likely because software quality is considered a shared responsibility among team members. That’s partly true—but in reality, they’re definitely missing an “orchestrator” for quality.

Fortunately, companies working with an Agile mindset still include testers without hesitation, as they’re not willing to risk releasing a component or system without the basics of quality being covered.

In fact, one of the most challenging parts of being a tester is the ability to adapt and understand new ways of working in every project they encounter. Unfortunately, this high level of adaptability often goes unrecognized as a valuable soft skill, and many regard the QA role as easily replaceable.

3. QA: Beyond the boundaries

Indeed, testers don’t need to be highly technical developers, but they play a game-changing role. Companies can avoid massive losses by integrating testers early in the software development lifecycle and treating them as a true part of the team.

In my humble opinion, this is where many teams make a big mistake—testing is often misunderstood as simply executing test cases after a certain development phase. And by “development,” I don’t just mean coding—even requirements gathering is already a late stage for testers. For instance, QAs should be involved during the initial roadmap and the very first steps of building a project, when the fundamentals are being set.

3.1. Redefining quality

I truly believe that quality is a long-term commitment in the software lifecycle, and companies should invest accordingly. Quality, in fact, should be treated as a framework, a methodology, or even a product in its own right—where the main cost is seen as a future investment. It might not appear beneficial in the early stages, since the return isn’t always visible (and may even seem negative, as resources are allocated to something that feels abstract).

Be aware that a quality framework also needs to be flexible, allowing new ideas and areas for improvement to be discussed openly. Quality should never be seen as static; rather, it must be both robust and solid while remaining adaptable to emerging IT trends.

From a tester’s perspective—or that of a colleague performing this role—quality can mean anything, which is why it can be so complicated for them. It may include

• Static Testing
• Functional & Non-functional testing
• Performance Testing
• Robustness Testing
• Security Testing and more

If quality is not clearly defined within specific roles, QA colleagues’ knowledge and expertise may shape the team, but individual solutions without a solid foundation can be unstable and fail to cover other important areas.

3.2. Last thoughts

Therefore, to wrap up this discussion, my quality goals have covered many different areas across the companies and assignments I’ve worked on in each project. Some teams welcome critical feedback; others meet it with skepticism. In that regard, QA has been especially challenging for me due to the varying mindsets.

Going back to the initial question, I have to say, after all this thinking, I actually understand my friends a bit better now 🙂 — how hard it is to pin down the tester role, which is so broad and so open to interpretation depending on the tech, the company’s mindsets, and everything in between.

What about you? How do you see the quality role, and what’s your company’s take on QA?