Our current role is a long way from just designing and executing test cases. We are no longer here to find bugs or “ensure” that we are meeting requirements, much less to break the software.

We are part of software engineering teams, in which we do “code management”, we manage: risks and impact of changes for users, time, scalation, and so forth… and we provide tools, practices and knowledge necessary to build systems, applications and/or platform with maximum collaboration with the rest of the parties that build these products/services.

We all understand the importance of code and development activities but we often forget the impact of testing on estimation, deadlines and the effort required to successfully deliver a product/service.

We all think about how we are going to develop a functionality, we participate in requirements definition, we design solutions, we validate at different stages of the process with our clients and users; And I frequently ask myself, why don’t we also think about how we are going to test?

We also think about the best development practices to achieve more maintainable systems; But, have we ever thought about how to make our products/services (apps, websites, systems, platforms) more testable?

Do we think about making the processes of our team more efficient, beyond testing?

What activities should we be doing from our role as testers to add more value to our teams?

As a first task, we need to get rid of that “software-breakers” mindset to become true sources of value for our team requires a lot of this:

Starting the project or sprint

At the beginning of the project we must seek understanding of the business. What is our product/service and its purpose? What need do we want to solve? What is the industry we are entering and its future perspectives?

This allows us to visualize the “big picture” of our project/product/service and thus be able to test much better.

This also helps us establish our quality standard or philosophy. What does quality mean to us? What does quality mean for our customers/users?

In some projects “zero tolerance for errors” is applied, while in others it is applied that if it is less broken than yesterday, we release it. In some projects we can do daily releases (such as web platforms), in others it is very difficult (such as desktop software). We need to adapt our processes in order to make a good fit into our SDLC without sacrificing quality.


When we are planning releases or stories/features we must actively participate by asking the right questions, designing stories, defining good user acceptance criteria and user acceptance tests, bringing to the table the risks we can foresee, and always questioning our assumptions about the product/service/business.

In each iteration

We estimate stories/tasks, we monitor the regression suites (and all the necessary tests) and their results, we collaborate with our entire team (managers, developers, business analysts), we write, automate and execute tests, we do pair sessions with developers or others testers.


We monitor the production environment, and participate in retrospectives.

Undoubtedly, retrospectives are among the most important meetings of our team and it is our perfect opportunity to bring to the table what we did well, what we did wrong, what we can improve, which new techniques/tools/actions we can implement to improve the quality of the product and, also, the team.

Agile Testing for the Whole Team

This Quality approach consists of:

  • We don’t test at the end.
  • The team solves problems together.
  • The whole team thinks about the tests.
  • All team members collaborate.
  • The entire team is committed to quality.

This means that the tester is not the only one responsible for quality, the whole team is responsible.

Of course, it implies a change in our mindset, we are no longer here to find defects/errors, nor to “ensure” that the requirements are met or to “break the software”. We have to ask ourselves “how can I collaborate more and better to deliver quality software to users and clients?”.

So, how do we add more value to our teams and projects?

Understanding the business

The more we understand the business, the more we can understand the product or service, the industry we are part of, who our users are, and what value our product/service brings to the industry.

This allows us to understand the challenges that our team will solve and leads us to ask the right questions, participate in the processes of defining and refining stories and epics, and constantly validate with the business.

It also allows us to question our assumptions.

Understanding the technical challenges

Understanding the technical challenges helps us design better tests.

If our project is developed in React and Laravel, we must understand how they work. It does not mean that we are going to know/understand everythingt about these frameworks, but what the architecture is, what are the best practices to make it more testable, and everything that helps us anticipate possible risks associated with the technologies we are using.

Getting sure that testing resources are available

This is not just a task for the tester. In each team we must ensure that all resources are available. Accounts for services, servers, data and whatever is needed according to our project.

Planning release activities

We must actively participate in release planning. How are we going to test them? When do we consider that they are ready to be delivered to the end user? What dependencies do we have and how do we manage the packaging of features?

Train, document and interact with third parties

We also have to involve the rest of the team in testing activities and above all, bring to the team the understanding that quality is everyone’s responsibility.

We can train others in testing activities (without necessarily making them testers or requiring great knowledge about testing).

We can document our tests, risks and much more; so that in our absence, any other person can check that documentation and carry out activities for quality. This documentation also helps our team have full visibility into what tests we apply.

We must get the whole team to think about quality and what tests we are going to apply to our project/product. For this we can rely on the testing quadrants.

We can schedule 1:1 sessions with developers to discuss how a feature is going to be tested. Surely this helps even improve the integration tests they write. This collaboration can also occur in refinement and planning sessions where the whole team meets.

Communicating constantly (Visibility)

One of the things that our team expects from us is that we constantly communicate the current status of our platform/app/system. It also means Visibility. This way we can change priorities (planning) based on our current state.

How can we plan better?

Asking the right questions when refining, planning, defining how we are going to test and constantly validating with our clients/users if we are on the right path.

Defining better User Acceptance Criteria and User Acceptance Tests. Again, it is not just a task for the tester.

Understanding our short, medium and long term goals. This allows us to see the “big picture” of what we are building and how we add value to our users/teams/projects.

Actively participating in the definition and estimation of epics, stories, tasks. Especially the estimation, since in many teams it is common that only development efforts are taken into account when estimating, but there are many other activities that we carry out to finally deliver that functionality in production and all this effort/complexity should be taken into account as well.

How do we involve the whole team into quality?

  • Bringing conversations about quality. What is quality for us? what are our standards? what are we doing to improve quality throughout the software lifecycle?
  • Making quality decisions together. Testers are not making decisions about quality alone. We must involve the whole team.
  • Pair sessions, with developers, with other testers, with business people, to maximize collaboration.
  • Actively participate in retrospectives pointing out aspects related to how to improve quality and teamwork. This meeting is the perfect occasion to propose ideas, show new ways of working and to reflect on what we did well, what did not go so well and how we can improve one thing at a time.
  • Bringing risks to the table… what’s the worst that can happen?
  • Documenting processes, cases, how we use certain technologies or external services.


The world no longer needs bug hunters.

You are part of a software engineering team, you are participating in the creation and maintenance of software. Think of all that that implies, far beyond designing and executing test cases (and automating).

Understanding our role and the value it brings to our team completely changes the perspective of what we do.

Participating in all stages of the development process of our product/service not only allows us to see “the big picture” of what we are building and its purpose, it helps us understand our technical and business challenges, which will improve the contribution we give to our teams, and makes us even better testers.

Our teams expect permanent visibility of the state of our product/service from us, however, other things are also very relevant, such as bringing risks to the table, making the whole team think about the tests and that we are all responsible for the quality, not only the testers.

Getting involved in each area of the product will make you a better tester and improve collaboration and the impact of what we do every day.