In many software projects, some requirements are clearly documented (explicit), others are implied by user expectations (implicit), or exist only in the teamâs shared knowledge and experience (tacit). As testers, understanding these layers is crucial to ensure no important details slip through the cracks.
Below is a short activity to help you identify explicit, implicit, and tacit requirements in a familiar scenario: an online grocery storeâs shopping cart.
Scenario
The shopping cart feature allows users to:
Add items
Remove items
View the total price
Proceed to checkout
Your challenge
List explicit requirements you can identify.
Write down possible implicit requirements users might expect.
Identify tacit requirements based on your experience with similar applications.
Reflect on the following questions:
Did you spot any gaps or ambiguities?
What questions would you ask stakeholders to clarify these requirements?
Share your findings:
Reply to this post with:
A summary of your findings from the task
A list of any questions you would raise with stakeholders to clarify ambiguities or confirm assumptions.
Exploring these hidden layers of requirements will sharpen your ability to see beyond the obvious and deliver features that genuinely align with user needs. Youâll also help others discover new ways of thinking about hidden requirements. I look forward to seeing what you uncover!
I ask questions from my gut. I have several years of experience as both a developer and tester (this combo is critical here). Iâve seen and experienced a lot of pain during that time from the earliest product conversations to getting the first POC out the door, balancing delivering fast with not painting ourselves into a corner. Experiencing the consequences of technical and product decisions. Maintaining, extending, integrating with legacy systems.
All of that as both a developer and tester rally fine tuned my ability to see problems coming. Years of designing, implementing, and testing these things has given me the confidence to voice concerns.
I know this isnât a super helpful answer on what questions to ask.
If I had to give advice it would be focus on the user, focus on expected behavior not existing behavior, focus on risks (identification, observation, possible mitigation), develop personas for the product and start asking questions on their behalf. Honestly Iove writing out given/when/turns scenarios. Not even full gherkin but to get ideas out.
With these just 4 points for the groceries application, there are a lot of ambiguities in the requirement as proper detail is required for clarity.
However, based on my understanding of the 4 points, these are Some of the questions that I can think are :
What kind of application we are developing mobile or web application or both?
What are the categories of the items we are targeting to sell on applications?
What are the delivery options available to the customers?
Will the payment button be available on the checkout page,? If yes then will we show a single button âProceed to paymentâ or will all the available payment options be visible on the checkout page itself?
If user search any item and the item is not available on Add Items page, will we show any recommended item or âNo Item Foundâ message or both?
What are the cities we are targeting with this application?
How will the delivery charge be created?
If someone adds items to the cart then for how long will the item be present in the cart?
Will there be any wishlist also?
What is the maximum quantity a user can add for any items?
Will there be any search field for searching any grocery?
Will we show items âOut of stockâ also in the items list when someone is looking for grocery items?
When user remove the last quantity of items from their cart will we show any error message?
If the user adds items and returns after some time, and at that moment the price is revised, what will we show to the user, a warning pop-up modal, or simply revise the items?
What are the maximum and minimum items users can order at a time?
Can the user add items to the cart without login in?
If the user adds items in the cart and logs out, then returns after some time will the items in the cart be retained?
Will we give any option for the checkbox to select/unselect GST invoice on the checkout page then users can choose in case they want an invoice on the successful delivery of pages.
If the user adds any item and leaves the application and if the item demand is very high will we send any notification to checkout before it goes out of stock?
Will we send any reminder notification to the user by email or message if they have added items to the cart but havenât checked out? If yes then after how much time?
If the user selects âCash on Deliveryâ will there be any extra charge as compared to other payment options?
When the user adds items what are the details of the items that will be visible to the user, will reviews also be visible on the add items page?
If someone tries to checkout at night or other times when we deliver orders, then what error user will see while adding items?
On what basis listing on the landing page will be visible like popularity, relevance, etc.?
On Add items, how many items will be visible on one page i.e. after how many items will the pagination start?
What details we will be asking the user for address before they checkout e.g. Street, city, town, etc,
Can the user select a future date and time for grocery delivery before checking out and if so then which is the maximum days they will be allowed for future dates for order deliveries?
Will we show item count in the count anywhere on the page which will dynamically update as the user adds or removes items?
Can the user manually enter the number of items on the Add page or manually enter items on the Remove Item page?
Will there be any surcharge fees also, if so what kind of warning message will we show to the user on the checkout page a warning pop-up modal or tooltip info icon with the message?
JokinglyâŠ(but seen something like this more or less transparent a couple of times):
Why would we keep you in this role if you canât work independently?
Why would we pay you this much money?
Why havenât you been paying attention and reading all the tickets, technical and business docs, specifications, all the discussions, etc?
Why do you ask these questions when the others understood it so well?
Why do you go too far outside and not focus on the scope described in this âticketâ?
Common question we often ask when looking at a feature thatâs been raised by a stakeholder: What is the goal?
In this case: is it to get as many people buying your product as possible? Have people come back and buy more stuff?
If so, you want to the shopping experience for the user to be as seamless as possible, which in the current requirements - itâs pretty vague.
Further questions:
What devices/operating systems will it work on?
User flows - what happens if the user adds something to cart, then navigates away, the item in cart should stick.
Design of the cart needs to be intuitive - user should be able to add/remove/adjust items without instructions. Should be easy to navigate and readable text and clear buttons
Stock control at the cart, nothing more frustrating than getting to the checkout and entering your credit details, hitting pay, only to find out the item is sold out!
What security will be at cart/checkout- encryption, SSL certs?
Manual Testing plays a crucial role in identifying these real-world scenarios helping uncover usability issues, unexpected failures. Itâs often these âwhat-ifâ questions that lead to truly user-friendly software-
Explicit-
User should be able to add/remove items from cart.
Total price should update dynamically.
Checkout process should be smooth.
Implicit-
A confirmation message before removing an item.
The cart should persist even if the user refreshes/logs out.
Discount/promo codes should be applied before checkout.
Stock availability should be checked before finalizing a purchase.
Multi-tab behavior: what if cart is open in multi tab/window.
Tacit-
Payment failure - if payment fails, should the cart items remain reserved?
Performance Concerns - how does cart handle bulk additions?
Concurrency issues - What happens if two users try to buy the last item simuntaneously?
Cross-device experience - If a user adds an item on mobile, should it reflect on deskop version?
Edge cases- what happen s if user deleted all items and click checkout?
Security- can you manipulate item price via brower console?
For Stakeholders -
What happen if an item is out of stock?
How to handle item with limited time discounts?
Is there a maximum number of items a user can add?
Should we auto remove the items from cart after a certain period of inactivity?
What the hell are âhidden requirements?â lol
Focus on illuminating such stuff as a phenomenon. I ask for requirements if I need them for proper testing. If they are âhiddenâ - not present in any form anywhere - and I donât need them to successfully finish my work, I wonât ask for them. No one will. Weâre not mind readers.
Asking questions to clarify implementations and requirements is the right thing to do, but itâs not about looking for âhidden requirements.â This isnât a game where you try to ask as many questions as possible, sometimes, you wonât get answers at all. If stakeholders decide one day that they have requirements that werenât passed to the team, thatâs completely okay.
As QA engineers, weâre responsible for quality, for sure, but weâre not Product Owners or Business/System analysts. We canât be as good at their job as they are
