I frequently hear questions like:
“If the team has only one tester and goes on vacation or is absent due to a medical issue, or for any reason, is it okay for the team to do a release without us being there?”
“If in a squad the quality analyst leaves for vacation, illness, or any reason for 2 weeks, and the squad needs to deliver software, do you suggest that the devs can do functional tests in the quality environment?”
This is supported by statements such as:
“Although it is a multidisciplinary team, only quality analysts have the necessary expertise for this role.”
And yes, we testers are the ones who have the expertise to perform tests, but have you thought about the thousands of development teams that do not have testers dedicated to the testing role? What do these teams do differently? Why don’t they have testers and still have products/services that they regularly deliver to their clients/users?
Have you ever questioned whether testing is a role or an activity?
For most testers, testing is a role, we design, plan, execute tests, measure results, make reports, keep the team aware of the status of the project (product/service), and work with developers and the product team, we also automate and document, but… are we the only ones who can test?
¿Can we separate testing as a role from testing as an activity?
Without a doubt, YES! other team members can test! And I think that this is the ideal state of the teams, but what do we need to make that possible:
First of all, the whole team must be committed to quality and it means that, together, we decide/establish what our quality standard is. What does quality mean to our team?
Being committed to quality leads us to:
- The entire team knows what, how, and when we test; and it does not mean that they know every detail to the letter, but it does mean that they know which suites we are going to run in each release, whether or not there is an automated regression suite, whether we do performance testing or accessibility testing; And how do we run them if the tester is not there, and how do we see the report to see if something failed and we have to fix it?
- We must properly document our test cases/scenarios.
- We must document our testing processes (testing plan and strategy, testing cycles).
- We must automate everything we can, and if we don’t know how to code, today there are many low-code tools that allow us to automate our tests. We can also set the tests to run in pipelines automatically and thus, no one has to trigger them manually.
Imagine that you are on vacation for 2 weeks and no one on the team can do manual testing or run automated tests, what do they do? Don’t they deliver any increment to clients/users because the tester is not there? And if we resign and we are the only tester on the team… aren’t there releases until a new tester joins the team, adapts to the company/process, and gains enough knowledge about the product to be able to actively contribute?
Definitely NO! It is not the process we want to implement in any team/project/organization. We cannot become a bottleneck, especially if we work in a startup or agile team in which we want to deliver changes to our clients and users as soon as possible and receive feedback as soon as possible.
¿How do we achieve that everyone gets involved in testing?
The whole team must know how, when, and what we test. And the entire team should participate in that process (of deciding which tests are applied). What types of tests do we do? Who implements and designs them? How often do we run them?
Documentation is important, always have the cases, scenarios, test plan, and strategy updated. If you are away for 2 weeks and you have to release… do the developers/product people on your team have access to your test case management tools to consult the test cases (in which you describe how to test each case: preconditions, action, and expected result)? Do you leave a suite with the tests that must be run to verify that we can confidently release this new version of the product/service to clients/users? The rest of the team must know what to look for and where they can run the tests.
Now imagine something even better: You managed to create/update all the necessary test cases for the tickets/stories/requirements in the current sprint when the tickets were still in To Do or In Progress, and the developer can see the test cases (linked in the ticket) and can run those tests locally (before uploading their changes and requesting a Code Review and before they reach Testing). If you achieve this, believe me, you will be able to reduce a lot of the errors found while testing. If we find an error, it would be a case that we did not contemplate at the beginning or, a case with a very low probability of occurrence or, very low severity, and the process will improve for the entire team.
Imagine that we have an emergency release (not ideal but sometimes happens), and we have only 2 hours to test and the regression suite (which we run manually) takes 2 days to be run (by a single person); if you have well-documented cases/scenarios, we can split the tests/ scenarios between all team members (prioritizing the most important ones) and thus in 2 hours we can go to production (because we all care equally about quality and we provide everyone the resources needed to collaborate in Testing).
If we have automated suites, we can run them frequently (not just when we’re in the middle of a release), maybe once a day, and we can quickly capture if we broke something in the release or if an API stopped working at any time, if the system It is very slow, and also, many more scenarios.
Involving other team members also helps everyone better understand why we don’t complete the regression in 15 minutes and that we are not just waiting for features to be ready to be tested. There is a lot behind testing: planning, documenting, searching for information, writing tests, generating reports, and being prepared at all times. And if we add these actions that I described before, we are going to become a team that moves faster without sacrificing quality and I assure you that we can do it if we give our teams the right tools and resources.