Conway's Law - sgml/signature GitHub Wiki

Phase         Description
Plan          Plan the work and document the plan
Design        Design the program
Code          Implement the design
Compile       Compile the program and fix and log all defects found
Test          Test the program and fix and log all defects found
Postmortem    Record actual time, defect, and size data on the plan

Manager       assigns responsibility
Owner         responsible for the success or failure
Consultant    offers input or advice
Helper        assists with or does some of the work
Approver      signs off on decisions

Common Mistakes

When working on a specification, there are common mistakes an editor can make when writing conformance requirements that makes them difficult, if not impossible, to test. For technical specifications, the testability of a conformance requirement is imperative: conformance requirements eventually become the test cases that implementations rely on to claim conformance to a specification. If no implementation can claim conformance, or if aspects of the specification are not testable, then the probability of a specification becoming a ratified standard, and, more importantly, achieving interoperability among implementations, is significantly reduced.

The most common mistakes that editors make when writing conformance requirements include, but are not limited to:

Creating conformance requirements for products that don’t have behavior, e.g. “an XML file must be well-formed.” — this cannot be tested since it doesn’t say what the outcome is on that condition.

Using a passive voice for describing the behavior, e.g. “an invalid XML file must be ignored” — this hides what product is supposed to follow the prescribed behavior.

Using under-defined behaviors, e.g. “a user agent must reject malformed XML” without defining the algorithmic process that is to “reject” something — this makes it impossible to define the outcome of the testable assertion.

Handling Complexity

Writing inline assertions helps immensely for large stories.

Every time you fix a bug, you want to avoid making the same mistake again. In order to do so, write down the problem, the workaround, and the permanent solution before you forget

Tracing function calls, generating a workflow data model, and visualization of the data flow is the best way to analyze all the code paths

Define an initialize cache for default data, a user-data cache for event-driven data, and a sync function to merge the two after initialization

References

Games

⚠️ **GitHub.com Fallback** ⚠️