What does it take to be an Agile Tester?

In the agile testing methodology, the role of a quality assurance professional is much more dynamic and multi-faceted when compared to the traditional waterfall methodology offered. Traditional methodologies allowed QA to be experts at what they do. Agile expect QA to be geared up with all-round capabilities along with their expertise intact. In an Agile environment, QA is bound to face requests, changes, and challenges of various forms and from various teams. Being armed with the right set of skills, knowing the different expectations, and being aware of the challenges that might be encountered are a necessity.

User Story Completion/ Acceptance Criteria:

In the agile model, especially when the shift-left strategy is adopted, the testers would be actively involved in requirement discussions along with Business analysts and the stakeholders. Once the user stories are defined, it is the responsibility of the QA to clearly specify the criteria based on which the user stories can be marked as complete. This essentially means delivering to the development team a set of tests that the user story must pass in order for it to be marked as done and delivered to QA. These sets of tests should be written as unit tests and their reports should be a part of the release notes. QA is expected to review the unit test results before running the tests defined for the acceptance criteria, which are more or less similar to the completion criteria test cases and finally send a green flag signaling the acceptance of the build.

Be adept in providing estimates:

An agile tester would be expected to provide testing estimates for the user stories taken for each sprint. In order to provide an estimate that is more or less in the vicinity of the actual efforts, it is important for the tester to know/define the scope of testing, the complexity of the functionality, integrations involved, expected number of issues based on previous statistics and also have knowledge about the different test estimation techniques such as Work Breakdown Structure, Function point estimation, Three-point estimation, Use case point estimation or any other method he finds success with and is best suited to the project in hand. To account for unpredictability, the tester should always add a buffer to the estimate and should be wise enough to leverage past experience as a reference.

Be Collaborative, Interactive yet Critical & Quality Oriented:

In an agile environment, the interaction of the tester with other teams should be fluid and is one of the most important factors that ensure the quality and on-time delivery. An agile tester should be proactive and discuss the gray areas or doubts based on his analysis of the user stories, with the business analysts or stakeholders. Adequate knowledge should be acquired regarding the finer details of the requirements. The tester should actively test the requirements, design documents, and the code (white box testing) as part of the static testing process for the early detection of bugs and as a preventive measure to intercept bugs even before they appear in the application. The tester should frequently involve himself in mutually beneficial conversations with the developer during the course of the sprint to understand code logic and also share with the developer the different scenarios that need to be covered by the code. An Agile Tester should be congenial with the other teams but should always maintain a critical and skeptical approach toward the product and assume there is always a chance of finding an issue in the application. This balanced approach is especially important in Agile as the project runners expect feedback from QA as soon as possible. Only with the proper preparation can the user stories delivered be exhaustively tested and reported with all possible issues, fixed, retested, and then marked as done before the sprint closure.

Use Scrum Meetings and Team Discussions Effectively:

As an Agile tester, one should make the best use of the daily stand up and not just confine to reporting your previous day’s tasks and what tasks are you planning to do today. Report the issues that are absolutely critical for release — state the hurdles in fixing/testing such issues. Prioritization of the issues reported recently should be done prior to the stand-up. Report issues that are blocking you from performing testing a particular functionality. Clearly communicate the delay it would cause if the blocking issue isn’t fixed. If there are any doubts regarding the functionality implemented vs the requirements, get that sorted out during the stand up as it has the entire team. You can also ask for the availability of the developer or the business analyst in order to conduct a joint testing/test coverage review session, a bug triage session, or any other collaborative activity. During the stand-up, the project manager discusses the individual activities and efforts for each team member and hence it is the ideal time for anyone to state a request that involves a member of another team.

Also never hesitate to inform something that was promised to be available at a particular time but wasn’t provided or was provided but not with the desired quality. Time is of the essence in Agile and any delay in making such pressing issues known to the PM or the scrum master will only cause trouble to QA at the time of the release.

Wear Different Hats:

A tester should have different roles in the agile environment. Based on the needs of the project there should be cross-training done in terms of tools, test scripting languages, domain knowledge, and testing processes and strategies to other testers in the team who have little or no experience with it. An agile tester should be capable of changing the test strategy based on the run time constraints introduced in the project during the sprint without it affecting the quality. Be a part of Retrospective meetings and participate in activities in order to suggest improvements and point out the downside of certain decisions taken in the previous sprints. Use bug triage meetings effectively not just to prioritize but also to provide strong reasons behind the given priorities/severities of the issues. Provide constant reports, with great detail and legibility, regarding progress information and metrics, to the stakeholder to maintain credibility. Always be open to criticism and feedback. If a tester is not willing to take criticism in the right spirit, then that would be the height of hypocrisy. So it is important to consider feedback as improvement pointers and if in certain instances the feedback given is not acceptable, the tester is well within his/her right to provide reasons. Make sure all the tasks, issues, clarification pointers, and effort to burn down are created and maintained in the project management tool. The test case execution logs must be versioned and maintained and shared with stakeholders.

Sprint 0 — A sprint of supreme importance:

Sprint 0 is the period where the overall planning for the phase takes place. The first sprint which follows sprint 0 sets the tone and direction that would be followed throughout. So it is crucial that the tester understands this and does all that is to be done before the actual work starts. The tester should define the scope of testing, scope of the functional and non-functional testing requirements, acquire the necessary tools, and install them and acquire the necessary accesses required for testing, reporting, and continuous integration. It is also important to perform the initial quality risk analysis and mention the same in the test plan document. The tester should also define the entry and exit criteria and the specifications for marking the user story as completed. A clear cut definition of the bug workflow would also reduce status transition confusion during the sprint.

Plan for Automation and Integration:

Due to the agile methodology being time-critical and task intensive, it is important for the tester to plan for automation and continuous integration. For this to happen, it is essential for the tester to understand the architecture, design, and integrations to third party systems. Define with clarity, the scope of automation, the effort and resources involved, the browsers that would be considered, the continuous integration plan, and the schedule. Requirements such as tools, environment, data sets, the stability of the application for the automation to proceed as planned should also be stated and approved. In the agile development since the frequency of changes is high, manually regressing all the previous sprint functionality would be extremely difficult. So it is imperative to automate as much as possible and to check the status of each build deployed through continuous integration and automated test execution.

Author: Mohan Bharathi
Stream: QA