Requirement Gathering Blog Series, Part 5: Dealing with Objections
This is Part 5 of the Requirement Gathering Blog series by Rahul Parwal where we explore more on Dealing with Objections. We’d like to thank him for sharing his expertise with the community through this information-packed piece. Check out the blog on Testing Requirements for Part 4 of this series.
Here is a list of all the blogs in this series:
- Part 1: Understanding Requirements
- Part 2: Requirements in The Agile World
- Part 3: Exploring requirements
- Part 4: Testing Requirements
- Part 5: Dealing with Objections
- How to deal with test case design/ testing when there is no proper documentation about requirements. Problem faced here can be: When you write defect most of the time it gets rejected by developer saying there is no such requirement. What to do then?
When facing the issue of lacking proper documentation of requirements, it is important for testers to shift their perspective and focus on the needs and wants of the end-users or customers. The ultimate goal is to provide a solution that satisfies the customers, even if the written requirements do not fully capture their needs.
In this scenario, the tester should approach the situation with the objective of uncovering missing requirements, rather than solely relying on the documentation provided. This can be done by actively engaging with stakeholders, conducting exploratory testing, and leveraging their own experience and understanding of the product.
If the tester encounters a potential defect, it is crucial for them to communicate the issue effectively and clearly to the development team, highlighting the impact it could have on the end-users. Bug advocacy is a valuable skill to deal with such situations. If the development team rejects the defect citing that it is not in the written requirements, the tester can offer evidence of the customer’s needs or expectations that the issue should be addressed.
Ultimately, it is important for the tester to be proactive and advocate for the customer’s needs, even if that means updating the requirements. This helps ensure that the final product meets the needs of the customer and provides a better user experience.
If you are interested to learn the skill of advocating for bugs in other such similar cases, then I would recommend you to checkout this book on the same topic: Bug Advocacy by Rahul Parwal et al. [Leanpub PDF/iPad/Kindle].
Post Workshop
You can check the workshop by heading over to the Worqference 2023 recordings page.
- Does this workshop have a follow up exercise or activity for us?
Yes. Here are few follow-up exercises to enhance the learning from the techniques for exploring requirements:
- Group Activity: Divide the participants into small groups and assign each group a product/project. Ask them to apply the techniques mentioned in the workshop to gather requirements for the assigned product.
- Role Play: Ask the participants to act out a scenario where they are eliciting requirements from stakeholders. One participant plays the role of the requirement elicitor and the other plays the role of the stakeholder.
- Review of a Product: Ask the participants to pick a product and apply the techniques mentioned in the workshop to analyze the requirements of the product. Have them present their findings to the group.
- Mind Mapping: Ask the participants to create a mind map of the requirements of a product or project of their choice. Have them share their mind maps with the group and discuss the different techniques they used to gather the requirements. Ex: Product coverage outline, Context free questions, etc.
- Feedback Collection: Ask the participants to conduct a survey or gather feedback from users, customers or stakeholders to understand their perspectives on a product or project. Have them present their findings to the group and discuss the importance of considering different perspectives while eliciting requirements.
These exercises will help the participants to reinforce their learning and apply the techniques discussed in the workshop in a practical setting.
- How do we as a tester practice questioning skills in our free time post workshop?
As a tester, you can practice questioning skills in your free time by:
- Games & Puzzles: Engaging in activities that require critical thinking, such as solving puzzles or playing strategy games. You can refer to a collection of such games here: Testers Playground (unicornplatform.page)
- Active questioning: Asking questions in everyday situations and trying to understand the motivations and perspectives of others. Most of it is also driven by curiosity. Here are few ready to use toolkits on questioning:
- Reading: Books, articles, and blogs that encourage and challenge you to question assumptions and think deeply. You can go for any moral or ethical or philosophical books/short stories/articles. I also like mythology material.
- General discussions: Engaging in discussions with colleagues, friends, family, or community members. Asking questions and trying to understand their perspectives.
- Practicing active listening: Paying attention to the words, tone, and body language of the person speaking and asking follow-up questions to gain deeper understanding.
- Journaling / Note-taking: Keeping a journal of questions that come to mind, exploring them, and writing down your thoughts and observations.
- How do I measure value I provide?
Measurement is often a double edge sword. In modern teams, setting up and tracking various parameters have become easy and simple due to the availability of powerful tools that we use for our project and task management. However, if the focus on measurement has gone to extreme, it can also lead to people optimizing what we measure them against, at the expense of what we don’t measure them.
A measurement system yields “distortion” if it creates incentives for a person to make the measurements look better rather than to optimize for achieving the organization’s actual goals. A system is “dysfunctional” if optimizing for measurement yields so much distortion that the result is a “reduction of value”.
Having said that here are few parameters that can certainly showcase the value that testing adds by being in requirement process:
- Increased customer satisfaction
- Reduced testing cycles.
- Shorter testing duration
- Low design bugs
- Feedback from sales & marketing team
- More focus on bug prevention