Make use of existing information flows
For those using a RSS reader, subscribe here: rss.xml
Using git tag descriptions in your CI
This is one of those ideas that sound ridiculous because it is, yet it has interesting points. Let’s say you work with user stories for a group project, and that you are building software. You decide to work in sprints, meaning you will have an increment after each one.
How are you going to ensure all these new features will remain functional? You already have a perspective from which you can evaluate; the user stories. If all user stories are functional, so is your software is the promise.
It takes a lot of time to manually check all these stories. So you write your tests, fix bugs here and there but there still is doubt. But that still doesn’t guarantee that you didn’t miss some tests to write.
Is there a flow of information already providing the list of stories you want to support, and if so could you combine it with your tests? What if you did the following:
At the end of every sprint, print-out the completed story titles to a git tag. Concatenate all git tag descriptions that made after these sprints, to get your list of stories you should support. Build in a test in your test runner that checks if each of these story codes exists as descriptions of your tests.
Although this approach is extreme, I can see it’s value in critical software. The takeaway lesson is to make use of existing information flows.