This is a guest post by Nishi Grover Garg.
A walkthrough is a great review technique that can be used for sharing knowledge, gathering feedback and building a consensus. Typically, walkthroughs take place when the author of a work item explains it in a brief review meeting — effectively walking the team through the work — and gathers people’s feedback and ideas about it. These meetings may be as formal or as informal as needed and may also be used as a knowledge-sharing session with many relevant stakeholders at once.
Let’s look at three ways agile testers can make use of this type of review for their sprint- and release-level test plans and test cases to get the entire team involved in the quest for quality.
Defining Scope
When my team does a walkthrough for a document like a test plan for a release, we are not only describing the contents of the plan but also automatically excluding things that are not specified in that plan.
Our test plan may contain sections for “Features to be tested” and “Features not to be tested,” or similar headings like “Test items in scope.” What we specify here as per our knowledge and perception, we will adhere to throughout our testing cycle.
By having all other stakeholders look at the test plan as we explain our perception of scope, we open ourselves up to their review and feedback. And even if they do not have any feedback or change suggestions, it becomes an unsaid contract that everyone approves to the set scope of testing. There will not be any discrepancies or disagreements later about what could or should have been tested!
Generating Test Ideas
I use walkthroughs in my agile team as a mechanism to review our sprint test scenarios with the entire Scrum team.
Our agile team struggled with time constraints and constant changes, which led to our frequently creating very broad test scenarios for every user story before it was developed. During execution, we found more ways to test the story, which may or may not have been documented by all testers. Also, we were frequently faced with questions or comments from developers at the end of the sprint, saying we didn’t test a story correctly, telling us how we should have tested it, or sometimes finding out that we were not driving our tests correctly all along.
I find the walkthrough technique immensely helpful in this regard. The testers now create broad test scenarios for all assigned user stories at the beginning of the sprint, even before any code is ready for testing. We then organize a walkthrough with the entire team, including developers, the ScrumMaster, and the product owner, wherein we walk them through these tests and our perception of that feature and ask for more test ideas.
This process forces testers to write more detailed tests with better coverage in the beginning, even before the walkthrough. This acts as a means of test idea generation with all team members on board, sort of like brainstorming. It sometimes brings all-new perspectives into the discussion, and it highlights areas that the tester thought about but may not have been incorporated by the developer yet.
Building a Consensus
Walkthroughs also are a wonderful way of creating a consensus among the team about the test effort for every user story.
If something was missed when we created our test scenarios, it gets brought up during the walkthrough. And if no ideas come up, it means the entire team is on board. If any questions are raised later, that indicates a miss by the entire team, not just by the tester.
Similarly, if we do a walkthrough for a requirement description or a test plan, everyone present at the meeting would be considered on board with the contents. Their feedback and review comments are considered and incorporated, and thereafter they are considered in accordance with all the ideas presented.
It makes the team think as one entity and consider the work as their communal thought project, instead of belonging to a single owner. As the team takes collective ownership, it shapes their way of thinking in the long run, and there is less blame and finger-pointing later.
Walkthroughs are a quick and easy review technique to adopt, and they can be especially useful for testers on an agile team to get reviews on their test plans, test cases, and scripts. Give this technique a try, even if in an informal sense, and see how beneficial it can be.
Nishi is a corporate trainer, an agile enthusiast and a tester at heart! With 11+ years of industry experience, she currently works with Sahi Pro as an Evangelist and Trainings Head. She is passionate about training, organizing testing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
