|Don't kill the messenger
- Provide a safe and transparent environment. Celebrate inquisitiveness.
- Scorecard each result.
- Provide opportunity for timely reporting. Avoid accumulating a surprise.
- Look to the underlying cause with reasoned analysis.
|Make every requirement testable; every test must relate to a requirement.
- Decompose user stories until they are actionable. Involve users in the interpretation of stories into the actionable descriptions.
- Link specific requirements to test, and the other way around.
- Apply test-driven-design (TDD) techniques that translate user stories directly into test scripts.
- Provide a means for users to understand and approve test scripts at the functional level.
|Anticipate some failure and make room for correction and retest.
- Plan effort and duration, anticipating failures and correction tasks.
- Update a working plan from actual test results.
- Plan regression tests that do not cause the entire iteration test series to be re-executed.
- Allow for regression testing after refactoring.
- Involve more than one person in the test scripting and execution. Build off of pair programming if that practice is in place.
- Follow proven "lessons learned" techniques: Ask "Why?" at least five times to push down through a hierarchy of related reasons.
- Apply logical reasoning:
- Abduction: Imagine that A is a possible explanation for B, although B may have many causes.
- Deduction: B is a likely consequence of A.
- Induction: A is a likely antecedent or condition of B
- Educate others on the team with the lessons learned.
- Apply what has been learned; modify best practices where necessary.
- Use the buddy system. Design/implement in pairs, test in pairs, or at least engage your others for critique and advice.
- Cross-check with others.
- Embrace socialization: Sit together; communicate daily, if not more often; and communicate with a sense of time urgency.
- Integrate objects into the design base often and maintain awareness of the evolution of the project.