When I worked for the State of Wisconsin (as a contractor), I had many great conversations with Mark and Jon about agile software development.
One day I wrote down a list of 25 thoughts on risk management and testing. Eventually I’ll weave these ideas into articles, but for now, just a <ul>
* Everyone contributes risks
* No risk exists without probability and impact
* No impact is infinite
* All impacts are measurable
* Risks drive level of design
* Risks drive test plans
* Testing directly affects design
* TDD is not 100%. The decision heuristic is risk.
* Exploratory testing approach is publicly known so customers and decision makers can know what has been tested.
* The word “requirements” promotes simplistic thinking. We develop features up until the point at which a person or team decides to deploy. Some features are never implemented. Listing as requirements makes people think in binary mode instead of order of importance to the organization.
* Measure progress based on running features tested. Compare sum of the weights completed with the total targeted feature set weight.
* Features all have a “weight” relative to other features within the same project.
* A feature without a running test is analogous to “works on my computer.”
* In all projects there is a point at which the set of claims tests are a more accurate statement of what the software does than the list of features (or requirements for you old schoolers.)
* Some features like “easy to learn” are not testable claims. Are they?
* A goal of gathering and writing features is to have them written as claims.
* The best types of claims have inputs and outputs because there is less interpretation in the process from documenting the feature to writing the code and tests.
* Tests are either named or described in a way that relates them to a feature.
* The build process generates a list of all test results for a project. The tests for a project can exist in multiple places (web app, shared component, project specific component)
* Risks have the greatest focus of the project team. Not the “requirements” document. It is a fallacy that software development is about creating a 100% complete list of requirements and then coding to that list.
* Risks are the most managed “thing.” Later in the development process, issues become the primary management tool.
* A project has a list of tests and you are able to click a link to view the actual source code of the test.
* Each test has a history of pass/fail.
* When a developer completes an issue, they add a comment in the issue message that can be run by the reactor and will send a result to the nosy list.
* A daily email is sent of verification results. Project name -> className.testName of failures with link.
Tags: agile, requirements, risk management
Any sufficiently advanced bug is indistinguishable from a feature. ~Rich Kulawiec
One could say that if the “feature” isn’t tested, than it isn’t a feature. So, any *thing* that happens which is not explicitly tested is a bug.
I wonder if this is what Rich was talking about.
And this relates to a future post where the set of tests is the de facto description of the software, not any document which lists features or requirements.
Thanks for the comment Trevor.
I really like “* The word “requirements” promotes simplistic thinking.”. This goes with dumb concepts like eliciting requirements from users in a session. I’ve been looking at the Business Motivation Model (BMM), at first it didn’t seem to gel, but then I realized that software was only part of the ‘means’ to achieve the ‘end’. If you follow that to a logical conclusion you can never separate the requirement from the business system, you have to integrate the software with the business solution. And I reckon that is feature driven development.
I have some thoughts on risk too, maybe another day…
Thanks for the comment Mike. I’m not familiar with the BMM – will read up.
But yes, software is certainly a means to an end. Put cash in the bank account (in a for profit organization).
The ability to prioritize is often missing. A way to measure this is the degree to which people feel comfortable with a list of deferred features. I always felt a sense of accomplishment when I could say we were done with something without hiding the fact that there were features that weren’t done.
You can argue about whether any given non-implemented or not completely implemented feature is important. But stack it up against releasing the features that *are* implemented. Does the cost of its absence or the benefit of its presence outweigh the cost of not delivering what’s already done?
Talking about requirements often leaves unchallenged the notion that there is some System that is the full and complete set of requirements. Feature talk is all about a world of infinite variety and choice.
Web video at its best! Do you have any advice for someone just out of university