When starting a career in testing we often focus on the written requirements to guide our testing efforts. Yet over time, we discover hidden requirements are as just as important as explicit requirements.
We develop skills to tease out these hidden requirements. We aim to move them from implied and tacit information to explicit information. We help fill in the gaps.
Shared understanding is never complete yet thereâs power in discovering hidden requirements to help everyone on a team clarify what needs to get shipped and the risks that need to be mitigated before weâre good to ship.
What types of requirements are often hidden?
Can you share some examples where youâve had to work a bit harder to discover information that wasnât originally explicit? What approach did you take and what was the outcome? What was the process for turning them into an official requirement?
Hidden requirements often arise from assumptions, overlooked details, or implicit expectations. These can include usability considerations, edge cases, scalability needs, compliance standards, or even the unspoken priorities of stakeholders.
For example, during a project where I tested a new user interface, I realized the requirements didnât specify accessibility standards. This gap became apparent during exploratory testing, where I identified usability challenges for screen reader users. To address this, I facilitated discussions with the product owner and design team, highlighting the risks of excluding accessibility as a requirement.
To turn this into an official requirement, I documented the findings, aligned them with accessibility guidelines (e.g., WCAG), and presented a proposal to incorporate these standards into the project. Once the team agreed, we added it to the product backlog and tested against the updated requirements. This process not only improved the product but also fostered a culture of inclusivity in future projects.
Discovering hidden requirements often involves a mix of asking probing questions, reviewing real-world use cases, and conducting exploratory testing. Have you encountered situations where a hidden requirement significantly impacted your project outcomes? How did you handle it?
Written requirements and requirements arenât the same thing and a requirement is a subjective concern we may choose to share collectively to guide software development.
In light of that âhiddenâ might mean different things. Do we mean that we arenât yet aware of them because we lack information from other people? Are they hidden because we donât understand their meaning in the context of the business? Are they hidden because they are an emergent property of exploration? Are we aware of them but they remain tacit knowledge, such as âsoftware should not slow the platform to a crawlâ or âsoftware should not DDoS our APIsâ or âproduct shouldnât kill peopleâ?
I believe user experience is one of the requirements that is not explicitly mentioned in PRD but is as important as the user interface.
For say the requirement says the login page should be loaded, however, we rarely come across the requirement which says that the login page should load in 2-3 seconds.
Most of the time testers raise the issue based on their own experience that the experience is not good, which leads to discussion within the team and then the experience is modified or improved.
Hi Simon,
Iâm new here and from other background but learning software testing to change my domain, So in my point of view, issues like how application should perform under low/week network or about response time of application, user always expecting quick response time. this types of requirements might be hidden.
please correct me if Iâm wrong.
Thank you!
I think the most common way Iâve uncovered missing requirements comes from quite simply the testers skill to be able to look at a feature and see it from different perspectives.
I still see the mistake from Product Managers that talk to to the customer, come back with a feature theyâve made notes on, talk to designers and devs about the features, draft up epics and stories and the first time testers see this is in a refinement session.
I had a âworst caseâ example that actually happened. Where we saw a requirement for a messaging app where they could send a message to a lower level of identifying entity. The product manager had their discussions with the customers and the feature requirement was defined to allow the customer to select that lower level of detail. The devs put together a design that they could select to enable that extra level of criteria prior to the refinement. Job doneâŠbut when we saw the design, the front end immediately looked utterly cluttered with our gut instincts telling us âI wouldnât want to use thatâ. So we asked the questions in the refinement session:
Why does the customer want this? (So often the most powerful question to ask to unpick requirements)
How do they do this now?
Whats their decision making process when theyâre building the messages?
What we found was the new feature wasnât actually going to enhance or support the way the customer worked now. It was just going to add the extra detail they needed in addition to everything else already there.
So as part of the refinement, stories were then updated, more stories added and the designs needed to be revisited.
The lesson as always, bring us in sooner. If you donât, weâre going to stick our foot in the door anyway (nicely ) to find out more until you bring us in sooner
) to find out more until you bring us in sooner 