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:
- 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 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.
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:
- 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.
- 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.
- 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.
- 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:
- Review the existing requirements: Read through the available requirements and try to understand the product, its functionality, and the intended behavior.
- Identify gaps in requirements: Look for missing information, ambiguities, or other areas that need clarification. Use it to add test points.
- 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.
- 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:
Utilize test design techniques: Use techniques such as test data tables, decision tables, and use cases to create a comprehensive set of test cases.
