What nifty tips and tricks do you have for finding testing opportunities in requirements?

🙋 Questions
, , ,
1

Does it say “should” but doesn’t say “shouldn’t”?
Does it say “it may” instead of “it will”?

There are plenty of places we can find opportunities to question and explore with requirements.

What nifty tips and tricks do you have for finding testing opportunities in requirements?

2 Likes
2

I love writing out scenarios using given/when/thens. Not cucumber/gherkin as in the framework but using that simplified format to document expected behavior. Test cases will just start falling in to your lap.

I also do this before implementing. It’s like a step before TDD where your writing abstract cases before writing any code. Almost testing the ticket. Info you’re missing will becomes apparent. It also makes it easier to know if a story is too big.

4 Likes
3

Oof Simon! If it says “Should” then it’s already bad. Should implies an assumption. So looking for nifty tips & tricks. I like to remove all the “should, normally, maybe” words.

Thinks I often ask myself during refinement

  • Something else I look for is that everything is testable. Testability is a big thing.
  • I often “demand” non-functional requirements
  • Think about edge cases
  • Are there any dependencies?
3 Likes
4

Well spotted, @kristof. I left that one in there. :wink:

1 Like
5

Hello @simon_tomes ,
Here are a few tips I’ve found helpful for uncovering testing opportunities in requirements:

  1. Look for Ambiguity: Phrases like “may,” “should,” or “as needed” are red flags. They often indicate areas that require further clarification or could lead to misinterpretation.
  2. Challenge Assumptions: Ask “What if?” scenarios. For example, “What if the user doesn’t follow the expected path?” or “What if the system is under heavy load?” This helps identify edge cases and potential gaps.
  3. Compare Related Requirements: Look for inconsistencies or conflicts between requirements. For instance, if one requirement emphasizes speed while another focuses on detailed validation, explore the trade-offs.
  4. Focus on the Negative: If the requirement specifies what the system should do, ask what it should not do. Testing for constraints or boundaries can reveal important scenarios.
  5. Engage Stakeholders: Walk through requirements with developers, product owners, or users. Their perspectives can highlight overlooked areas or provide clarity.

Do you have any specific methods or tools you use to dig deeper into requirements? I’d love to learn about them!

Thanks,
Ramanan