As @andres_gr mentioned dealing with vague requirements, it really got me thinking. Curious to know - do you lean more on intuition, product knowledge, user behavior…Or something else entirely?

[image] ansha_batra: do you lean more on intuition, product knowledge, user behavior…Or something else entirely? Great question! I see this way to often when I coach people, there is no documentation or requirements and people tend to go by intuition. Sometimes you almost have too… But I str…

From my own experience, i would say incomplete requirements will always hinder the successful delivery of the project. So back in 2022 I was working as software tester on application which has stripe payment gateway integration and real time payment status updation for payment/refund. The project …

Proceeding without clarification is dangerous, but so is waiting endlessly for clarity. It’s a risk when requirements are vague… The trick is to acknowledge the risk upfront n communicate it effectively. document it as a known risk and the proceed with … As per agile principles it value responding …

Lets build more context on this. We can fall in a couple of scenarios like: There are no requirements at all. Or maybe there are and we don’t know of them. There are some explicit requirements or only explicit requirements. There are implicit requirements we gathered with time (in business domain…

I start by asking the product owner what their expected behavior is. Then talk to the dev and confirm that was their approach and get additional feedback. I update the story with the details from these conversations and then bring it up in the retrospective to try to avoid this happening again. If t…

I like @parwalrahul ’s comparable definitions and examples to help share thoughts on this question: Tacit requirements Implicit requirements Explicit requirements Note, if you’re a MoT Professional Member, you can add your own definitions to the MoT Software Testing Glossary . Always good to get a …

I can think of a couple of situations where requirements were both implicit and tacit. Situation 1 I ran a 45-minute time-boxed exploratory testing session for a web app I’d used for the first time. My goal was to explore to discover any useful information I could observe. I wrote down notes base…

Really like the way you broke it down. That “never use intuition to assume the product works like that” really stuck with me. I have definitely leaned on intuition in fast-paced situations, but I am learning that asking the right questions early saves a lot of back and forth later. Appreciate your …

Thanks for sharing your experience Ujjwal. That real-life context and the shift in requirements really hit home-its something many of us can relate to but don’t always speak about openly. Totally agree that unclear documentation can derail even the most well-planned sprints. Your point about gettin…

How do you usually approach testing when the requirements are vague or incomplete?

Discussions

mariam-sargsyan (Mariam Sargsyan) 7 April 2025 19:41 7

When there are no requirements, I explore. Even if I have clear requirements, I still explore — it’s how I “test” them too. I assume the basics, outline a bunch of questions, and use my findings to start building the requirements collaboratively with stakeholders.

Topic		Replies	Views
Testing without requirements? Archive communication , collaboration , process	13	2315	22 December 2020
Follow up question - Should you take a project or job which has no test cases? Archive strategy	23	1240	19 May 2022
How to perfrom testing activities, when we dont have any requirements documents and the product is very old Archive tools , learning , process , career-development	17	902	25 March 2022
Ask Me Anything: Exploratory Testing 🗓️ Events exploratory-testing , ask-me-anything	16	1480	22 April 2021
Testing Against Implicit Requirements with Nicola Lindgren 🪐 TestBash collaboration , testbash-home , requirements	3	708	18 June 2021

How do you usually approach testing when the requirements are vague or incomplete?

Related topics