9.5. Testing in the Dark: Should You Proceed without Documentation?
In order to design, develop, and run tests, you need what's often referred to as an oracle, something that tells you what the expected, correct result of a specific test should be. Specifications, requirements, business rules, marketing road maps, and other such documents frequently play this role. However, what if you receive no formal information that explains what the system under test should do?
In some organizations with mature development processes, the test department will not proceed without specifications. Because everyone expects to provide a specification to the test team as part of the development process, you are seen as reasonable and within the bounds of the company's culture when you insist on written specs.
Trouble arises, however, if you stiffen your neck this way in a company that operates in a less mature fashion. Depending on your company's readiness to embrace formal processes (and also on your personal popularity, tenure, and political clout), any one of a spectrum of outcomes could occur:
Your management, recognizing the need to formalize processes, backs you up 100 percent and institutes formal requirements and design specification processes throughout the organization as part of the planning phase of every new development project. Industry-standard templates for internal product documentation become the norm, and consultants are brought in to train people.
Your management, not knowing ...