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:
- Part 1: Understanding Requirements
- Part 2: Requirements in The Agile World
- Part 3: Exploring requirements
- Part 4: Testing Requirements
- Part 5: Dealing with Objections
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:
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.
