It finally clicked, what nostr:nprofile1qqs06gywary09qmcp2249ztwfq3ue8wxhl2yyp3c39thzp55plvj0sgprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qguwaehxw309a6xsetrd96xzer9dshxummnw3erztnrdakj7qgmwaehxw309amksetpwshxsctswpuhgctkv4exutnrduhsw0qlr4 has been writing about in regards to Agile methodology. I've been developing in features, rather than user stories. Time to break down the work further and deliver one user story at a time.
Keep an eye out for more PRs on the #aedile, #alexandria, and other #gitcitadel repos as well realign to more bite-sized chunks of work.
Some of the best defects I've found have been from pretending to be a user (veteran, new, etc) with a specific goal (generating a year-over-year profit-loss report, adjudicating a claim with Coordination of Benefits, adding a transportation dept to an existing accounting structure, etc).
Sit in the driver's seat. Have a destination, and a reason to get there; then observe what the process entails.
This is good advice. In testing, we call these "paths". And there are "happy paths" (where the outcome is positive), and "sad paths" (where the outcome should be an error message or similar.
One of the goals of good design is to reduce the occurance of traversing of sad paths, by nudging the user to make fewer errors, and making those sad paths less sad, by giving users a chance to continue on or correct their entry.
Finding out common paths makes for the most-efficient integration test.
