
“Testing is pointless. Just check the code and deploy to production.”
You hear that a lot. But in reality, testers play a crucial role in a team! Let’s take a closer look at what they actually do.
The tester’s main mission is to check whether a new IT product (software, hardware, system, etc.) meets the requirements. To ensure compliance, the tester must:
review the product specifications and applicable standards;
create test tools to outline and define all points that must be checked;
run tests until every point has been validated;
accurately report results once all tests have been completed.
Testing involves three essential actions:
Verify: ensure that things are done according to what was defined.
It’s about asking, “Does it work?” based on what was explicitly defined beforehand (technical specifications or a user story).
Validate: confirm that the initial goal has been achieved.
It’s asking, “Does this meet my user’s needs?”
Explore: ensure that implicit specifications are considered in the testing activity.
It means asking, “Is the system robust?”, “Does it perform well?”, “Are there any hidden bugs?”
A tester’s tasks can vary greatly depending on their skills and the projects they work on. They may:
be a “button-presser” tester, meaning they simply execute an existing test plan, mark tests as passed or failed, and report any issues;
automate tests by creating scripts that run without human intervention;
help design new features and support Developers in improving code quality;
run performance, load, and stress tests;
handle test management;
track bugs;
promote a culture of quality within the team.
Now that you're familiar with a tester’s main tasks, keep in mind that they work as part of a team. They must be someone you can rely on and trust. This leads us to the tester’s place within a team and the people they collaborate with.
Whether you’re in an agile team (iterative development) or not (sequential development), the roles are largely the same.
In an iterative (agile) team, you’ll typically find:
the Product Owner (PO), who represents the customer and defines new features or improvements;
the Scrum Master, who ensures proper understanding and application of Scrum. They support the entire Scrum team and help maximize the value delivered;
UX/UI Designers, who create user flows and visual designs:
The UX Designer maps out the sequence of screens for a website or app.
The UI Designer arranges and styles each screen to make it clear and intuitive.
Together, they ensure the smoothest possible user experience.
Developers, who determine how to implement the PO’s requirements and code the features;
Testers, who verify that what Developers build matches the specifications.

In a sequential method (V-cycle or waterfall), the same roles exist except for the PO, who is replaced by a project manager.

Now, let’s explore the tester’s relationship with specific team members.
Testers and Developers work closely together and communicate regularly. Both aim to ensure product quality. But this hasn’t always been the case.
In early development projects, there were no testers—Developers checked their own code. They tested what they wrote, but not the entire end-to-end experience. Over time, it became clear that an external, unbiased person was needed. That person is the tester.
Developers and testers approach software differently:
The Developer builds the software based on specifications.
The Tester uses every possible method to ensure the software is free of bugs.
Developers follow specifications to build nominal cases—the scenarios the software was designed for. The tester also checks those cases but additionally tests unexpected or unusual user behaviors.
A nominal case might be clicking a button in a checkout process to confirm an order.
A non-nominal case might be double-clicking that button, causing two orders to be submitted.
This is why both roles must work together to deliver the best possible software. 😉
Yet in some teams, you might hear:
“Another bug reported by the tester—they’re doing it wrong; that’s not how it’s supposed to work!”
“Ugh, the Developer didn’t test their code. Look at all these bugs.”
Or when a tester provides too little information in a bug report, you may hear:
“It works on my machine. No bug here.”
Both parties need to understand each other’s role:
Developers must understand that users won’t always follow the nominal path—hence the need to test many different scenarios.
Testers must understand that the Developer’s job isn’t to test everything, but to deliver software that matches the specifications.
Let’s move on to the tester’s relationship with another team member: the Product Owner.
The Product Owner is the voice of the customer and writes the User Stories.
In non-agile teams, the business analyst writes the specifications instead.
The tester intervenes at several stages of the product cycle, working closely with the PO. For example, testers help define the acceptance criteria.
The roles of Developers, Testers, and the PO are clearly defined but not rigid:
A Developer may identify a user issue after speaking with actual users.
The PO may find a bug while checking that the team is on the right track.
Everyone contributes to software quality. Breaking down silos reduces the feedback loop within the team, resulting in faster and better user satisfaction.
A tester’s tasks are varied and diverse.
Testers must work as part of a team.
They have a close relationship with Developers.
They help the Product Owner define acceptance criteria, giving them insight into user expectations.
Now that you know more about the tester’s role, the next chapter will explore the benefits of testing and the types of tests testers may encounter.