Panel Discussion | How to deal with bad requirements in testing?
summary
Claim: perfect requirements rarely exist; aim for good enough and conversations that turn vagueness into testable outcomes. Practical fixes: link tests to specs (HP ALM/Microfocus experience), push requirements-as-test-scenarios into GitHub PRs so product managers review, use specification by example and Gherkin for living docs, and enforce a definition of done. Evidence: a team saved rework by experimenting and measuring, while at scale roughly 60% of built features never get used.
AI-written summary · about
chapters (14)
- 0:00Panel introduction
- 3:08Bad requirements in testing
- 8:42Bad or misunderstood requirements
- 15:20Turning requirements into discussions
- 19:16Engaging teams on user needs
- 22:05Soft skills for requirements gaps
- 27:38Workarounds and experiments
- 34:21Bad requirements inevitability
- 35:45Mapping requirements to test cases
- 37:50Requirements after testing
- 38:34Who details unclear requirements
- 39:58Hypotheses over rigid requirements
- 42:06Balancing quality and velocity
- 44:36Closing remarks
related talks
42mHow a Tester Can Help Improve the Quality of Requirements
36mHow Testers Can Help Paving the Future of Modern Requirements Engineering
37mBest Practices for Accelerating Delivery
01h 00mQuality Begins With Requirements
53mLeadership In QA: The Future of Enterprise Software: Requirements, Domain Knowledge, & Beyond
28mYour Testing Strategy is broken - lets fix it!
26mPanel discussion
15mHow to NOT waste time