Seite - 211 - in The Future of Software Quality Assurance

Subconscious Requirements: The Fright of Every Tester 211 Theonlythingthat isleft is toapplyexperience-basedtechniques:errorguessing, exploratorytestingandchecklist-basedtesting(see[1]).Inexperience-basedtesting, tests are derived from a test basis consisting of the knowledge and experience of the testers themselves. Therefore, the big question is: how can a tester acquire the necessary, relevantknowledgeandexperience? The only answer to this question is: as a tester, apply requirements engineering techniques thataresuitable touncoversubconsciousrequirements.Such techniques canbe foundin the IREBbodyofknowledge(see [3,5]): ObservationTechniques • Field observation This technique is about observing the users during their work in their usual environment without interfering. The tester may notice certain unexpected or undescribedbehavior,strangesequencesinactivities,ormanualsidesteps.These are strong indicators for subconsciousrequirements. • Apprenticing Apprenticinggoesastepbeyondfieldobservation.Here, the testerconductsa shorthands-ontrainingintheenvironmentinwhichthesystemis tobedeployed. Keyusers teachhimtheirworkprocesses tobetterunderstandthedomain.When actually participating in the work to be done, subconscious requirements will easily cometo thesurface. • Contextual inquiry Contextual inquiry is an iterative, field data-gathering technique, studying a few carefully selected users in depth to arrive at a fuller understanding of the workpracticeacross theentireuserbase. Artefact-BasedTechniques • System archaeology System archaeology is a technique to gather information regarding a new system fromthe documentation,user interfaceorcode ofa legacyor competitor system. Of course, most of the requirements found by this technique will be present in the specifications of the system under test. The remainder will either notbe relevant in thisparticularcase or turnout to besubconscious. • Perspective-basedreading In this technique, the tester uses a specific perspective—in this case looking for unfamiliar requirements—in order to retrieve information from documents that are relevant for the domain in which the system will be used, e.g., process descriptions,companyregulations,andapplicable legislation. These techniqueshaveonemajordrawback: theyareusuallyquite timeconsum- ing. However, this time investment is inevitable to acquire the thorough domain knowledgenecessary to recognizesubconsciousrequirementsand todesign tests to mitigate related risks. AquitedifferentapproachtofindandtestunconsciousrequirementsisSpecifica- tionbyExample(see [6]).Thisworksbestwhenappliedby thewholedevelopment teamthroughout thedevelopmentprocess, as it promotessharedunderstandingand trustwithin the team.But evenfor testing itself, it canbeveryuseful.