Page - 210 - in The Future of Software Quality Assurance

210 H. van Loenhoud phone, everybody takes for granted that it will have a camera, so it has become a subconsciousrequirement. Conscious requirementsare theeasiest category todealwith forboth theanalyst andthetester.Theyareexplicitlymentionedbythestakeholders,sotheywillclearly bepresent in the specificationsof the systemunder test (assuming that the business analystsanddesignersdida goodjob). Unconsciousrequirementsarealso relativelysimple to test.Stakeholdersdidnot ask for them, so the designers have incorporated them deliberately in the system and will have added them prominently to the specifications. The only problem for the tester is that these requirements are based on assumptions of the designers about the system’s attractiveness for the customer. These assumptions may be wrong,so theyshouldbetested too.Unfortunately,designersoftenforget tospecify their assumptions, so as a tester, you should ask for them. However, even if an unconsciousrequirementremainsuntestedandsubsequentlyfails inproduction,the userswillnotcomplainbecausetheydidnotaskfor thefeaturein thefirstplace(but beaware that such failuremayinvolveextra risk thatactuallydoesneed testing). Thechallengeforthetester lies inthesubconsciousrequirements.Thestakehold- ers do not ask for them, so they are quite likely to be missing in the specifications, provided by analysts and designers as input for the tester. But they still need to be tested, because failure of a system to meet the subconscious requirements will almost certainly lead to rejection. Therefore, the tester faces the task of testing features that arenotpresent in the specifications. In practice, this usually does not concern the main functionality of a system, being described in detail in the specifications and thus belonging to the con- scious requirements.Often, subconsciousrequirementsrelate to some“nittygritty” functionality details and exceptions, to user-related quality criteria like usability, security,orperformance,or to implicit technical, infrastructural,organizational,and legalconstraints.Ofcourse,dependingonthedomainknowledgeoftheanalystsand designers, a certainpartofall subconsciousrequirementswill still bepresent in the specifications of a system. But on average, one can be quite sure that a significant portion is missing. If a certain requirement is missing from the specifications, the chance that it is implemented in thesystem isminimal. 3 HowtoDeal withSubconsciousRequirements? The problem for the tester lies in the (mostly subconscious) requirements that are missing from the specifications of the system under test. In such a case, common black-box testing techniques cannot be used, as they depend on the analysis of the specifications in the test basis. White-box techniques, depending on the documented structure of the system are equally inapplicable, as the structure of a system normally is derived from its specifications.