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.

For many software teams the requirements document is the king of documents.

You know the routine. The software team works with the customer (or customer proxy) to put together a “complete” list of “requirements”. Once that is done, the team writes the software implementing the requirements and voila! the project is done.

Or maybe not.

Every software project I’ve ever been on has involved scope management. This is a process of determining if a requirement is truly a requirement for right now and whether it could be delayed until part of a future version or release. This is performed not only when “requirements” are being first developed, but also during development/testing/deployment in an effort to meet a project timeline constraint.

Words Matter

In the Agile development world, “requirements” is sometimes replaced with “features”.  This is a very important change, mostly related to the meaning of words and cognitive dissonance.

Think about it.  “Requirement” is based on the word “require” – something compulsory or necessary by rule. For someone to agree to postpone a “requirement”, you are basically asking them to admit it wasn’t actually required in the first place – thus, it wasn’t a “real” requirement.  And therein lies the problem…

Asking someone to postpone a “requirement” is asking them to admit a mistake.

This points to the beauty of using the word “feature” when describing the software desired.  Features connote desires.  And it is OK for customers to desire pretty much everything.  “You want features, load me up!”  Throw features on the deck, list them like crazy.  Pile them on, as project managers, we’re not afraid of hundreds or thousands of features.  Knock yourself out – as long as they are prioritized.

Once we start developing, we can then start having conversations such as:

• Do we have enough features to deploy?
• Would you like to change the priorities of the features you’ve listed?
• Any new features?”

Those are much, much easier conversations to have and project decisions will be made much quicker without the debates about whether a “requirement” is actually a requirement.