Extreme Shift Left / Out with the Requirement Engineer?
summary
Argues testers can take on requirements engineering to reduce duplicate work and write more testable requirements, citing that over 50% of defects originate in requirements and that one third of requirements change during a project. Lists concrete techniques to apply: observations, prototypes, FMEA/paradox brainstorming, the Six Thinking Hats, decision tables, UML/BPMN models and Gherkin (Given‑When‑Then). Warns model-based test generation is not a turnkey tool and cautions about losing specialist depth, bottlenecks and confirmation bias.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:31Speaker introduction
- 3:15Generic activities
- 7:25ISTQB and IREB tasks
- 11:57Test planning vs requirements
- 19:05Reviewing, modeling, traceability
- 23:02Shift left principle
- 26:14Merging tester and RE roles
- 31:27Disadvantages of merging roles
- 32:11Requirement sources
- 36:26Kano model for requirements
- 42:11Elicitation techniques
- 48:47Learning from each other
- 50:33Key takeaways
- 51:57Q&A
related talks
36mHow Testers Can Help Paving the Future of Modern Requirements Engineering
42mHow a Tester Can Help Improve the Quality of Requirements
24mQuality Engineering: A Journey from traditional testing to ‘Shift-Left’ Mindset
28mYour Testing Strategy is broken - lets fix it!
55mQuality Engineering Evolution: What Lies Ahead in
52mShift Left or Squish Right - Testing in a Shifting World
31mQuality Engineering mindset and TBS
10mThe value of testing