Author: parwalrahul

Rahul Parwal is an Expert Software Tester. He is a recipient of the prestigious Jerry Weinberg Testing Excellence Award. Rahul is an avid reader, blogger, and conference speaker who likes to share his thoughts on various social media platforms. Recently, he has also been inducted as a LambdaTest Spartan, & a Browserstack Champion for his work in the field of software testing. Presently, he works as a Senior Software Engineer with ifm engineering in India.
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:

  • 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. 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)
  2. 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:
    1. Questioning Toolkit (fno.org)
    2. Context-Free Questions for Testing – DevelopSense
    3. Context-Free Questions for Automation – Testing Titbits – Rahul Parwal
xRxE0eVktHz8BoZTNb8DN3AHQ5aSuHpghMN4HNe43pBGl uX1 67gEQB3ZD6CA0hRbYuA6sc3bEWuE LcAdX7MtiYN5p8D5s9Y6a5rU5gOXkMTB8JdeXS6WH0OADNkCd3xmfm 1T4U f1iE9SFIvGw
  1. 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.
  2. General discussions: Engaging in discussions with colleagues, friends, family, or community members. Asking questions and trying to understand their perspectives.
  3. 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.
  4. 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:

  1. Increased customer satisfaction
  2. Reduced testing cycles.
  3. Shorter testing duration
  4. Low design bugs
  5. Feedback from sales & marketing team
  6. More focus on bug prevention
00
Requirement Gathering Blog Series, Part 4: Testing Requirements

This is Part 4 of the Requirement Gathering Blog series by Rahul Parwal where we explore more on Exploring Requirements. We’d like to thank him for sharing his expertise with the community through this information-packed piece. Check out the blog on exploring requirements for Part 3 of this series.

Here is a list of all the blogs in this series:

  • How can a tester be plugged in early at ideation stage, there could be a lot of testing issues raised which are too basic?

As a tester, being involved in the ideation stage is crucial in ensuring that the testing issues that may arise later on due to false assumptions are addressed early. This can help to minimize the risk of basic testing issues being raised later in the development process, which can be more time-consuming and expensive to resolve.

t30QamngstATRhss6EjMwfJ7Kxp62U0cPA7 8p8J9hfdw5G8P42GbHQZFtBHwSfB5WFg1aKgJz5HGnBiWLd8wnKgQVfoEQpmGIDEfp W7 tOac63YDibipwdJ9yIo3OW Ix1G5 TAHL4 ZgE5GsT8w

All development projects start by assuming a solution to a problem can exist. Testers can contribute by focusing on the starting point of the project and slowing down to think about the requirements. In the ideation or development phase it is important to not focus on the basics build of the app and instead focus towards identifying any ambiguity in the stated requirements, as this can lead to missing requirements. Example: Identify if there are ambiguous words in the requirements such as “small,” “fast,” “inexpensive,” or “group.” The cost of such ambiguity in the requirements increases exponentially as the project progresses, making it important to question assumptions and explore ways to remove any ambiguity as early as possible.

The order in which questions are asked is also important. Testers can prioritize the problem statement and purpose. They can also sort and filter their questions to ensure that they are relevant to the context. By doing this, testers can help to ensure that the requirements are clear and unambiguous, minimizing the risk of basic testing issues being raised later in the development process.

  • To what I have seen mostly many of the testers are skipped at this phase. How can we get them involved? OR What would be your approach to ensure that testing team is brought onto the table during requirements gathering phase?

To involve testers at the ideation stage, it is essential to break the myth that testers are only required after the product is built and that their involvement is expensive. This notion is long outdated, and the development industry has already realized that tests are first-class citizens. Read more about TDD and its importance to get a detailed commentary on this topic. It’s important to communicate to the larger audience that testers bring a lot more to the table than just testing and have deep investigative and critical thinking skills that they practice on a daily basis. These skills are very effective for exploring requirements and making sure that the requirements are well defined and effective.

Testers can start exploring requirements even before the build is available. Instead of waiting for builds to be ready, testers can use their skills to question and critique the requirements. This not only ensures that the requirements are of good quality but also that the testers are involved in the ideation process. By being involved in the early stages, testers can catch any missing or ambiguous requirements and suggest changes that can help to reduce the number of testing iterations and make the overall process more efficient.

Testers should be seen as more than just testers, and their involvement in the early stages of product development should be encouraged. Also, if you are serious about this change, I would recommend you to read two books: Perfect Software and Other Illusions about Testing, and Secrets of Consulting by Jerry Weinberg. These books would help you to solve the people and mindset related challenges that often limits testers to just the testing phase or process.

  • What are you take on not to file “very basic issue” and resolve them on go?

Having a shared understanding of what constitutes a “very basic issue” is key to ensuring that it is handled appropriately. This will vary based on the organization and the product being developed, but in general, “very basic issues” refer to those that are relatively straightforward to fix and do not have a significant impact on the product.

While it can be tempting to simply resolve these issues on the go without filing a bug report, it is important to weigh the pros and cons and then decide if you want to make this tradeoff. On one hand, avoiding the creation of unnecessary bug reports can save time and reduce noise in the development process. On the other hand, if a fix for the issue is not well-documented, it may be difficult to track and understand later on.

To determine whether to file a bug report or resolve the issue on the go, consider the following factors:

  1. Impact: How significant is the impact of the issue on the product? If it is relatively minor, it may be reasonable to resolve it on the go.
  2. Complexity: How difficult is it to resolve the issue? If it is relatively simple to fix, it may be more efficient to handle it immediately.
  3. Documentation: Will the fix be well-documented so that it can be easily referenced later on? If not, it may be better to file a bug report.
  4. Future considerations: Could the issue resurface in the future and cause problems if not well-documented? If so, it may be better to file a bug report.

Ultimately, the decision of whether to file a bug report or resolve the issue on the go will depend on the specific circumstances of each case. The key is to weigh the pros and cons and make a well-informed tradeoff in the best interest of your projects long term needs.

  • How can I write maximum number of test ideas from minimum documented requirements?

To deduce the maximum number of test ideas from minimum documented requirements, you can follow the following steps:

  1. Review the existing requirements: Read through the available requirements and try to understand the product, its functionality, and the intended behavior.
  2. Identify gaps in requirements: Look for missing information, ambiguities, or other areas that need clarification. Use it to add test points.
  3. Collaborate with stakeholders: Engage with the product owner, stakeholders, and other team members to understand their expectations, and gather additional information. Use it to add test points.
  4. Use heuristics and risk-based testing: Utilize popular heuristics to generate a large number of test ideas. Focus on high-risk areas and identify where the most critical failures may occur. Check out some useful heuristics here:
    1. Resources | Quality Perspectives
    2. Test Heuristics Cheat Sheet | Ministry of Testing
    3. FEW HICCUPPS – DevelopSense

Utilize test design techniques: Use techniques such as test data tables, decision tables, and use cases to create a comprehensive set of test cases.

00
Requirement Gathering Blog Series, Part 3: Exploring Requirements

This is Part 3 of the Requirement Gathering Blog series by Rahul Parwal where we explore more on Exploring Requirements. We’d like to thank him for sharing his expertise with the community through this information-packed piece. Check out the blog on Requirements in The Agile World for Part 2 of this series.

Here is a list of all the blogs in this series:

What are some of the techniques I can learn to elicit requirements?

When eliciting requirements, here are some techniques to help you get better at it:

1. Ensure that all necessary stakeholders are involved: This helps to question assumptions, gain new perspectives, and overcome biases. Furthermore, explaining the requirements to new members can also help clarify thoughts and eliminate misunderstandings.

2. Identify & be aware of biases: One must be aware of potential biases, such as the “first love” syndrome, where a particular solution may be favored without considering other alternatives. It is also important to avoid the “I know it all” mode and pay attention to missing gaps, ambiguous words, and newly introduced elements.

3. Product Modelling: To help clarify requirements, it can be helpful to model the product through techniques such as mind mapping, sketching, or drawing and passing. It is important to take the time at the beginning to carefully consider the requirements and try to understand the perspective of different users and customers.

4. Consider user personas: Understanding the perspectives of different user personas can also help reduce ambiguity.

5. Consider alternate ways of information: There are various methods that can be used to gather information, such as context-free questions, user/client interviews, surveys, feedback from the marketing or sales team, or studying similar products. 

In conclusion, eliciting requirements is a crucial part of any project and requires a comprehensive approach to ensure success. By involving all necessary stakeholders, paying attention to potential biases and ambiguities, and using a variety of methods to gather information, you can increase your chances of obtaining the requirements that are actually needed.

How can I learn the product in the absence of requirements?

In the absence of requirements, there are several ways to learn the product. Professional testers often use these methods a lot and use them to actively seek out for more information instead of just waiting for the written requirement document.

1. User Feedback: Gather feedback from actual users of the product, this will give a real-world perspective on how the product is used and what features and functionality are important to them. This could come from social media, customer support records, sales team, etc.

2. Customer Interviews: Conduct in-depth customer interviews to understand the target market, their needs and pain points, and how the product addresses them. This is also the primary way how the product team captures and stores as the stated requirements which are then given to engineering teams.

3. Analyze Competitors: Study the competitors and their products to understand the market trends and what features and functionality are currently available in the market.

4. Conduct User Research: Conduct user research by observing users as they interact with the product. This will give insights into how they use the product and what their expectations are.

5. Play with the Product: Get hands-on with the product, use it, and explore it as a user would. This will help understand the features, functionalities, and user experience.

6. Talk to Stakeholders: Talk to stakeholders such as product owners, developers, and designers to get an understanding of their vision for the product and what they are trying to achieve with it.

7. FEW HICCUPPS: These are some oracles that can help you to investigate more information about your product. Read more about them here: FEW HICCUPPS – DevelopSense

By using these methods, you can learn about the product and form a comprehensive understanding of it, even in the absence of requirements.

How can we reduce testing iterations by exploring requirements well?

To answer this question, let’s first understand the core reasons behind multiple testing rounds:

1. Side-effects of Bug Fixes, Feature Additions, etc.
2. Low-hanging bugs that could have typically been found in unit tests.
3. Design changes at the end
4. Basic issues in build
5. Unstable builds or testing environment.
6. Development on unclear or ambiguous requirements.

While exploring requirements well can certainly solve some issues, a net reduction in total testing iterations would need an end-to-end quality consciousness software development. By thoroughly exploring requirements at the beginning of the software development process, potential issues can be addressed early on, which directly leads to reducing the need for multiple testing iterations.

One way to ensure a thorough exploration of requirements is to involve testers in the ideation stage of development. Testers can help identify missing or ambiguous requirements and question assumptions, which can help avoid costly issues down the road.

Additionally, prioritizing the problem statement and purpose can help ensure that the right questions are being asked and that all important requirements are being considered. Finally, reducing ambiguity in the stated requirements can help minimize the number of testing iterations required.

How do I quantify exploration?

Quantifying exploration is a challenge as it is a qualitative and subjective aspect. However, it is important to understand that exploration goes beyond simply testing against acceptance criteria. To quantify exploration, you can follow these steps:

1. Define the scope of exploration (charter): The scope of exploration should be defined based on the goals of the project and what the stakeholders expect to achieve. This will help you determine the areas that need to be explored and the depth of exploration required.
2. Document findings (note taking) : Document all the findings from exploration, including any issues found, insights gained, and suggestions for improvement. This documentation will serve as evidence of the work done and the value-added during exploration.

3. Use a tracking tool (Ex: SBTM): Use a tracking tool to record the progress of exploration, including the areas explored, the time spent exploring, and any issues found. This will provide a clear and concise record of the exploration process. Refer to Session Based Test Management (SBTM) to understand this in depth.

4. Evaluate the outcomes (Debriefing): Evaluate the outcomes of the exploration process, including the quality of the product, the time spent exploring, and the value added to the product. This will help you determine the effectiveness of the exploration process and identify areas for improvement.

5. Feedback and improvement: Use the evaluation of the exploration process to provide feedback and make improvements to the process. This will ensure that future exploration is more effective and efficient.

By following these steps, you can quantify exploration and measure its effectiveness. Additionally, documenting the findings and evaluating the outcomes will help you communicate the value-added during exploration to stakeholders.

00
Requirement Gathering Blog Series, Part 2: Requirements in the Agile World

This is Part 2 of the Requirement Gathering Blog series by Rahul Parwal. We’d like to thank him for sharing his expertise with the community through this information-packed piece. Check out the blog on Understanding Requirements for Part 1 of this series.

Here is a list of all the blogs in this series:

In the agile world, do we still have a requirement gathering phase? Isn’t it a feed for waterfall?

In the Agile methodology, the requirement-gathering “phase” is not as rigid and formal as in the traditional Waterfall method. In Agile, the requirement-gathering “process” is more iterative and collaborative, with ongoing communication and feedback between the software development team and the stakeholders.

Instead of gathering all the requirements upfront and basing the entire project on them, Agile allows for the requirements to evolve and change as the project progresses. This allows for more flexibility and adaptability, as well as a better alignment with the changing needs and priorities of the stakeholders.

However, Agile still emphasizes the importance of clearly understanding the requirements and goals of the project, and incorporates mechanisms for capturing and refining requirements throughout the development process.

In the agile world, is there still a thing called the requirement? Hasn’t it changed to Acceptance criteria or Definition of Done?

Yes, in the Agile world, there is still a concept of requirements. Requirements refer to the needs and expectations of the stakeholders in terms of what they want the project to deliver. As explained in the previous answer, In Agile, the requirements are typically captured in a flexible and iterative manner, with the understanding that they may change and evolve as the project progresses.

The Agile approach recognizes that requirements can be difficult to fully specify in the beginning of a project and that it is more efficient to develop a minimum viable product (MVP) and iterate based on feedback from stakeholders. This allows for the requirements to be refined and refined as the project progresses, leading to a better alignment with the changing needs and priorities of the stakeholders.

However, the requirement still plays a critical role in guiding the development process and ensuring that the end product meets the needs of the stakeholders. Regarding, acceptance criteria or definition of done, they are just a form of documenting the requirements from the end-user or technical perspective. Refer to the image below to understand the various forms in which requirements are available in the modern software development processes:

requirement gathering 1
Acceptance Criteria

Curious about Agile Testing? Dive into our dynamic course and learn Agile testing principles from an agile expert. Ready to adapt and thrive? Join us today.

As a tester working in agile environment, how can we prepare ourselves to ask good questions during the requirement meeting itself?

As a tester working in an agile environment, it is crucial to be proactive and ask good questions during the requirement meetings. To prepare ourselves, we can make use of Context Free Questions (CFQs) which are important early on in the process. CFQs can be used to ask questions about both the process and the product. 
For the process, we can ask questions like:

1. Who is the client?
2. What is a highly successful solution really worth to this client?
3. What is the real reason for wanting to solve this problem?
4. Should we use a single design team, or more than one?
5. Who should be on the team(s)?
6. How much time do we have for this project?
7. What is your trade-off between time and value?
8. Where else can the solution to this design problem be obtained?
9. Can we copy something that already exists? 

For the product, we can ask questions like:
1. What problems does this product solve?
2. What problems could this product create?
3. What environment is this product likely to encounter?
4. What kind of precision is required or desired in the product?

Along with these Context Free Questions (CFQs), it is also important to ask Meta questions (i.e., questions about questioning) like:
1. Am I asking too many questions?
2. Are my questions relevant? (Which one not? Why not?)
3. Are you the right person to ask these questions?
4. Is it okay if I write down the answers?
5. Can I also share you one copy of that?
6. Can we plan a F2F meeting?
7. Is there someone else whom I should ask questions?
8. Is there something else that I should be asking you?
9. Can I come back with more questions later?

Asking CFQs and meta questions can have several advantages. It saves us from situations like “Oh! We thought you knew this!”, which can arise when assumptions are made about what is already known. 

By asking CFQs and meta-questions, we can ensure that all relevant information is captured, assumptions are challenged, and ambiguities are cleared. This helps us to have a clear understanding of the requirements, which in turn leads to effective testing.

How will you deal with frequently changing requirements in agile world where you are releasing every week in production?

Dealing with frequently changing requirements in an Agile environment can be challenging. In some cases, quality also gets compromised due to mismanagement or partial implementation of agile. Here are some strategies that can be used:

1. Collaboration: Ensure that the entire team including the stakeholders, developers, and testers are aligned and communicating regularly to understand the changing requirements and their impact on the project.
2. Prioritization: Prioritize the requirements based on their importance and impact on the project and the users. This will help in focusing on the most critical changes and adapting to them quickly.
3. Documentation: Use agile documentation practices like user stories, acceptance criteria, and agile templates to capture the requirements effectively and quickly.
4. Continuous Testing: Implement continuous testing practices like test driven development, unit testing, different levels of automation in testing, continuous integration, and continuous delivery to ensure that the application is tested thoroughly and the changes are integrated and deployed to production quickly and efficiently.
5. Adaptability: Be adaptable and flexible in your approach, as requirements can change frequently in an Agile environment. Be open to new ideas and be ready to make changes to your testing approach to accommodate the changing requirements.

How to overcome from trend of testing against acceptance criteria only and think beyond acceptance criteria for testing?

Let’s understand a core problem with basing development and testing only on the stated acceptance criteria, or requirement.

1. Requirements are often not complete or full.
2. There will be gaps, and inconsistencies.
3. Interpretation by different people is different causing more ambiguity.

Now, if the design and development has been done on this half-baked base, it would mostly be half baked. Doing testing on that half-baked design / development can be risky and unprofessional. 

It’s crucial to remember that the requirement documents or software requirements specifications (SRS) are just maps of the requirements, and not the requirements themselves. As a tester, it’s important to bring in your own insights, experience, understanding, and exploration to the table. When the map (the requirement document) and the territory (the actual product) don’t match, it’s always important to trust the territory.

By thinking beyond the acceptance criteria and taking a holistic approach to testing, we can ensure that the development and design are based on a solid foundation, and that the final product meets the needs of the client and end-users.

00
Requirement Gathering Blog Series, Part 1: Understanding Requirements

This is the Part 1 of the Requirement Gathering Workbook by Rahul Parwal. We’d like to thank him for sharing his expertise with the community through this information-packed piece.

Here is a list of all the blogs in this series:

The purpose of this Workbook | Session Notes | Summary Document is to help testers understand the importance of requirement gathering and how it can add massive value to the testing process. The document will provide insights and guidance on how to gather and analyze requirements effectively, with the aim of testing beyond the written requirements. The document will highlight the importance of exploring the requirements thoroughly, considering the perspectives of all stakeholders, and utilizing the tester’s own knowledge, experience, and insights to create a comprehensive and effective testing plan.

Prepared By:

tdUs6OPxpVJ3vVziTWS6o0Miv7u6o95II0kSsiK89cw1QPA4hWg

These session notes are the result of incorporating feedback and addressing questions raised by Chandra Pandey, Brijesh Deb, Sahil Kaushal, Mayuri Ubhad, Aravind M, Shoaib Ahmed, Balaji Ponnada, Apoorva Ram, Mayuri Ubhad, Jim, Ralf Roeber, and Anees Shaikh. Their insights have enabled me to tailor the workshop to address the most common and relevant concerns of participants. The notes serve as a reference guide for review, reinforcement, and further learning after completion of the workshop, organized by section.

Understanding Requirements

  • How we decide that we have understood the requirements as it is required? OR what all parameters should be considered to ensure that requirements are clear? OR how you can make sure not just you but your fellow testers are also clear with requirements?

Determining that requirements have been properly understood is crucial for the success of any project. However, in reality it often gets difficult to know if the requirements have actually been understood correctly as we mostly work with the requirement documents and multiple sources of ambiguities. The more time and resources spent upfront to understand and verify the requirements, the better the chances of success. This includes effective communication with stakeholders, thorough analysis, and proper documentation. The following strategies can help increase the odds of achieving this goal of understanding requirements fully:

  1. Technical Reviews: Technical reviews of requirements help to identify any gaps, ambiguities, or misalignments with the intended project outcome. This can involve subject matter experts, architects, testers and developers to ensure that the requirements meet the necessary technical standards.
  2. Project Reviews or Demos: Regular project reviews are a valuable opportunity to assess the status of the project and ensure that the requirements are aligned with the project objectives. These reviews also provide a platform for stakeholders to ask questions, provide feedback, and raise any concerns.
  3. Summary Reports: Regularly updated summary reports provide a high-level overview of the project’s progress and highlight any deviations from the original requirements. This helps to identify and address any issues early on, before they become significant roadblocks.
  4. Measure Communication: Effective communication is crucial to understanding requirements. Regularly tracking the effectiveness of communication channels and identifying areas for improvement can help ensure that all stakeholders are informed and on the same page.
  5. Measure Satisfaction – Take Feedbacks: Regular feedback from stakeholders is crucial to understanding their level of satisfaction with the project. This can help identify any areas where the requirements are not being met, and corrective actions can be taken to improve the overall project outcome.
  6. Include everyone who might object later: It’s essential to engage with all stakeholders who might have a direct impact on the project later. This includes end-users, customers, and stakeholders who might not be involved in the day-to-day project management but can have a significant impact on the project’s outcome.

In conclusion, ensuring that requirements have been understood correctly is essential to the success of a project. A combination of technical reviews, project reviews, summary reports, effective communication, stakeholder feedback, and engagement with all relevant parties can help improve the odds of success and looking beyond the explicit requirements.

Requirement Gathering Pyramid
Requirement Pyramid
  • How to keep track of all the information we receive on daily basis related to the product/project? Some good tips and tricks to efficiently manage all the information gathered by the testers.

Note taking is an essential skill for any tester. It requires consistent practice to get good at it and once you get good at it, it will give you exponential results. It’s a powerful meta skill.

I would recommend you read this paper by Michael Bolton on this topic, i.e., Microsoft Word – An Exploratory Tester’s Notebook – 63.doc (developsense.com)

Here is a quick summary if you want to just have a high level gist of it:

Exploratory Tester's Notebook by Michael Bolton
Michael Bolton’s
  • How to deal with situation when you are onboard for testing late in the project and there are many issues with unclear requirements?

When you are on board for testing late in a project with unclear requirements, it can be challenging to catch up with the project and ensure proper testing is performed. However, there are several steps you can take to address this situation:

  1. Get up to speed on the project: Start by getting a clear understanding of the project requirements, timeline, and goals. This can be done through meetings with project managers, stakeholders, and team members. Use context free questions to get this info. Refer to Context-Free Questions for Testing – DevelopSense
  2. Assess the requirements: Evaluate the existing requirements and identify any gaps, ambiguities, or inaccuracies. Document these issues and work with the project team to resolve them. You can use a query tracker to track and discuss these issues. Ex: Shared google sheet document or a OneNote notebook.
  3. Collaborate with the team: Work closely with the development team and other stakeholders to ensure that all requirements are well understood and properly defined. This can help you to ensure that your testing is aligned with the project goals and requirements.
  4. Focus on risk-based testing: In a situation where requirements are unclear, it is especially important to focus on testing areas that pose the greatest risk to the project. This can help you to ensure that critical issues are identified and addressed as soon as possible.
  5. Document your testing: Keeping a clear and detailed record of your testing activities and results can help you to demonstrate the value of your work and ensure that any issues you identify are taken seriously by the project team. Debrief your test notes with the team to get a feed for your next testing cycles. 

By taking these steps and working closely with the project team, you can help to ensure that the project is properly tested and delivered successfully, even when requirements are unclear.

Requirements and Dilbert
Requirements and Dilbert
  • When you are new in any domain and how to acquire more knowledge about that domain so that you will understand requirement better. Is it really necessary to have more knowledge in specific domain to understand project requirements correctly, with this can we achieve customers perspective while writing tests.

Acquiring more knowledge about a domain when you are new to it is important in order to better understand the project requirements. This can be done through various methods such as:

  1. Reading relevant material – Start by reading up on the industry, market trends, and any relevant technical material related to the domain.
  2. Interacting with domain experts – Speak with experts in the field to gain a deeper understanding of the domain and its challenges. Join communities or follow relevant handles on social media.
  3. Attending relevant trainings and workshops – Attending training, conferences, workshops and other events related to the domain can provide a wealth of information and also help you network with other professionals in the field.
  4. Participating in hands-on projects – Hands-on experience is a valuable way to gain knowledge about a domain. You can contribute to projects that are relevant to the domain or take on a personal project to build your knowledge.

By having more knowledge about the domain, you can develop a deeper understanding of the requirements, and better anticipate the needs and perspectives of the customers. This will result in more effective and comprehensive testing, and better products that meet the needs of the customers.

This concludes the Part 1 of the Requirement Gathering Workbook. Stay tuned to The Test Tribe blog for the upcoming parts. Till then, keep learning!

00