3 ms·
Related question… Is your team even preserving requirements, especially once you’ve got a test suite? Traditionally, Systems Engineering views test as a method
by mch82 5y ago
Related question… Is your team even preserving requirements, especially once you’ve got a test suite?
Traditionally, Systems Engineering views test as a method to verify requirements. Other verification methods include inspection, analysis, and demonstration. But, as tests become more readable, maybe at some point the tests become the requirements…
- vladsanchez 5y agoThat's what's predicated by "Specification By Example" [1] practices. Gojko elaborates into the tooling and requirements preservation aspects in "Are tools necessary for acceptance testing, or are they just evil?"[2] [1] https://gojko.net/books/specification-by-example/ https://gojko.net/books/specification-by-example/ [2] https://gojko.net/2010/03/01/are-tools-necessary-for-acceptance-testing-or-are-they-just-evil/ https://gojko.net/2010/03/01/are-tools-necessary-for-accepta...
- mch82 5y agoThank you, I’ll give that book a look. I read the article. After a good amount of time trying Cucumber, I tend to agree with James Shore that specialized acceptance testing tools don’t add enough value to offset the added complexity. I’ve found it more efficient to simply add logging markup to the unit & integration test framework that goes with the language used to implement the app. The most tester-friendly approach I’ve found is to use Storybook for GUI acceptance and Postman for API acceptance. Those tools keep the tests close to the code, organize scenarios well, and are usable by true non-developers. Plus, test collections in Storybook/Postman double as valuable documentation. I hope Storybook stays focused on real, run-time web components and doesn’t get caught up in too much test-only code.