Timeline for Software Quality - preventing regressions with documentation
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 29, 2019 at 4:16 | vote | accept | dtj | ||
| Sep 27, 2019 at 8:44 | comment | added | Doc Brown | @dtj: see my edit | |
| Sep 27, 2019 at 8:43 | history | edited | Doc Brown | CC BY-SA 4.0 | added 810 characters in body |
| Sep 27, 2019 at 6:02 | history | edited | Doc Brown | CC BY-SA 4.0 | added 641 characters in body |
| Sep 26, 2019 at 21:47 | comment | added | dtj | and yes, i am also concerned about documentation deviating from the actual behavior. I hadn't thought it was called user documentation since it would outline finer points than any end-user would necessarily need to know to use our software | |
| Sep 26, 2019 at 21:46 | comment | added | dtj | I understand your point, however, I feel like that hasn't worked in practice, at least for me. The new employee may not know all the finer points of feature 2345 just by loading it up and trying it out. Furthermore, there could be 10s or 100s of features that could touch this change in some fashion, and they might not even know that. | |
| Sep 26, 2019 at 21:40 | history | answered | Doc Brown | CC BY-SA 4.0 |