Historically, the responsibility of tester was limited to proving the requirements are met, ensuring that the software works and finding bugs just in an almost completed product. And so a role of the tester used to come into picture only after the development cycle was completed.
But since Agile is all about being flexible enough to cater all the changing requirements and the process or tool is driven development is less responsive to the changes and less likely to meet the customer requirements, hence Agile Manifesto flips around titles and says to focus on individuals and interactions over processes and tools.
And so, the role of a tester in agile goes beyond “just testing” and logging bugs. They should work with everyone in the team to build and improve the quality of a product as early as possible. Hence they should have the ability to wear many hats & support other team members i.e. if they see a task that needs to be done and have skills to do it, they must do it regardless of their titles.
Below are few roles Navyug’s testers often take up & you can see them fulfilling the inherited responsibilities splendidly:
i. The tester as an Architect:
As a tester, they participate in the design meetings which happen every now and then before the features are written down as stories. They contribute to design meetings asking “What if … ” questions and creating a modal of how the system will look like. This also helps to identify the dependent areas in the future in case of any changes or bug fixes or find the ambiguity in the features before the testing even begins.
• Define “done” for every story by listing down the acceptance criteria for each of them.
• List down the scenarios that they will be including as a part of testing a particular feature.
• Create mockups for the upcoming features.
• Suggest improvements.
• Offer suggestions to ease testing if the development gets completed in a certain way.
ii. The tester as an Explorer:
Exploratory testing uncovers bugs that no automated tests will ever find. Also due to tight timelines, exploratory testing becomes a valuable skill. Being an explorer means, mapping the system on the run, they discover interesting information about the system and reassess the moves. It is more about what the product actually does rather than what we believe it should do as per the documents.
Being an explorer does not mean they approach the system in an unplanned or unstructured manner. It means they behave more systematic and document whatever they have tested, as they discover more about the system.
• List down all the scenarios covered during exploration.
• Discuss all new scenarios discovered during exploratory testing, with the team.
iii. The tester as a Reporter:
Tester’s responsibility is not limited to sharing simple pass/fail details, they also share valuable information like:
• Issues or bugs they have uncovered.
• Areas they didn’t have time to explore.
• Recurring defects that could be prevented.
• Blocks, wait for states, and other problems obstructing additional testing.
A good tester always keep his/her team informed about their findings – issues or bugs found should not come as surprises to other team members during scrum meetings.
• Reporting defects.
• Work with team to resolve them by reporting maximum possible scenarios around any uncovered bug.
• Create a bug report and share it with the team by end of every sprint.
• Regularly discuss bugs that need urgent attention, with the team, by scheduling a triage meeting.
iv. The tester as an Automator:
Knowing how to code is always a useful skill and can be of great help to the team. But one doesn’t need to be a skilled programmer to start using automation. There are many frameworks for automation that use English words and phrases like Gherkins etc.
Automating the tests not only reduces redundancy of work (especially during smoke) but also saves a lot of time and improves the efficiency of the tests.
• Write an automation script.
• Execute the script.
• Update the script with changing requirements.
• Create a dashboard to display the result of every run of the automation script.
By – Tanvi Dang, Sr. Software Engineer (QA)