How does a junior tester analyse requirements?

Hi all,

This week was our final task analysis session for the Junior testing curriculum Job Profile that we captured with the support of the testing community.

Specifically, for this session, we were considering the following task:

Analyse requirements

Combining a series of community activities including social questions and our curriculum review sessions to identify the steps we need to take to successfully achieve this task and have listed them below.

  • Read through requirements to understand their scope and intent
  • Listen to additional details being shared about the requirements
  • Use heuristics and tools to identify and raise questions related to requirements
  • Learn about the testability of the requirements

What we would like to know is what do you think of these steps?
Have we missed anything?
Is there anything in this list that doesn’t make sense?

Those items make perfect sense but it feels to me there’s one aspect missing and that is ambiguity. Are the requirements clear, specific and unambiguous. You can look at that in many ways from calling out language like ‘could’ and ‘should’ etc. Making sure acronyms are fully explained etc.
I love the exercise, 'what does “Mary had a little lamb mean?” Whether you know the nursery rhyme or not there are so many meanings of that I’ve seen people genuinely shocked that is could mean a sheep gave birth.
So it would be good I think to have something about that in there.

1 Like

I think it is important to know that your understanding of the requirements is not critical. What is important is that the person realising the requirements understand them. Or to put it bluntly, if the developer misunderstand the requirement there will be a bug. So a cool pattern I like to do when I see that someone else is not understanding the requirement, even if I am, is to ask the question, “I don’t understand that, can you explain it more?”.

I also think it is good to understand the difference between verification (making sure it is behaving as intended) and validation (should it behave like this) when analysing requirements as it might be easy to get caught up in “how is this supposed to work” and forget “should it work like this”. One heuristic to help with this is the “consistency” heuristic. As in have the product already established an expected user behaviour for this and is this requirement consistent with that. As with all heuristics it is fallible so don’t fight for 100% consistency.

1 Like

Thanks both for your feedback. I made a minor tweak to the following task:

Use heuristics and tools to identify and raise questions related to requirements

And modified it to take ambiguity on board:

Use heuristics and tools to identify and raise questions to clarify requirements further

I went with the focus on clarity as I feel it’s the opposite to ambiguity in this context.