Many of us know that agile software delivery embraces Built-In Quality, in which teams apply defined practices to create high-quality, well-designed solutions that support ever-evolving business needs.
In this context, after having been worked with a variety of agile teams, I take liberty at this time to summarise as to what it takes to be a bold QA engineer in an agile team, that typically ships new changes every two weeks.
A QA Engineer in a team comes up with a unique strength that few others in the team have: his in-depth knowledge on the products that he tests.
It’s to say the least that he could thoroughly understand every nuance of a product under test, by continuously knowing ins and outs of its features, about its responsiveness (or performant capabilities), or even about the points that it breaks.
Being Bold — Aforementioned, a product acumen of a QA engineer will certainly be beneficial to the whole team in many different ways to achieve high quality standards:
— To start with, this will undoubtedly be useful in backlog grooming sessions, in which he/she could add values by validating the defined acceptance criteria of a story(or a feature) are in fact logical and consistent with existing behaviours of the product, by sorting out the inconsistencies.
— Working alongside developers & having a keen eye on the context of a story/task, testers could help to clearly call out testing scopes, regression impacts of new changes. Besides, Knowing a high level of technical details on undergoing changes will surely help one to decide if they can be tested at all, from a functional standpoint. For an instance, a spike or investigation story may not have any testable change.
— Knowing the background, scope and impact of the changes, during planning and estimation sessions, it’s crucial as a tester not only to provide testing story points factoring a number of scenarios, test data needs etc., but also to foresee and highlight potential dependencies and risks in completing them within the sprint.
Embrace change — To put it lightly, a battle starts by the time a sprint starts:) Although how much planning a whole team may put in to achieve all sprint goals efficiently, most of the times, sprints in reality do not go as exactly as planned. In the midst of chaos, what testers still can contribute to the sprint goals by creating and modifying scenarios, selecting regression scenarios(including automated tests) and setting up necessary pre-requisites if any.
— Being a tester in scrum team (or a squad), it is also essential to keep a tab on development progress of the tasks/stories in the current sprint so that he/she can assure to have sufficient time in completing testing tasks on time within the sprint by knowing tentative code drop dates well in advance.
— He/she needs to make sure that test plan, timelines and coverage are clearly communicated and visible to all team members including product team and also ensures to include feedbacks if any from team members.
— Lastly, He/she communicates progresses on testing tasks on a regular sync-up accurately, which primarily includes completion percentage, issues and dependency he/she expects other team members to resolve etc.
Finish strong — Every sprint in a product development is an iteration and aspires to improve continually in the next one. In this sense, the QA engineer in the team consciously take an effort to share his/her opinion/feedbacks on retrospective sessions, mostly from a view point that his/her capacity is utilised in best possible ways (or over-utilised or under-utilised)
— Besides, tidying up un-finished qa tasks is as important as getting started with the goals for an upcoming sprint.
— The QA engineer on the team would know by this time that the latest changes on the product would also require him/her to add new scenarios or update existing scenarios in automated regression tests to keep them relevant. The best time to finish them up is in the beginning of next sprint, ideally before taking up test executions for the next sprint changes.
I hope that you find this post useful, and feel free to drop in you feedbacks if any.
Thank you for reading,
Veera.
