Page - 214 - in The Future of Software Quality Assurance

214 H. van Loenhoud • The most “problematic” category is that of the chaotic projects: not chaotic in the senseofbadprojectmanagement,butchaotic in relation to the topic thathas tobedeveloped.This isabout the“unknowables.”Theteamexplorescompletely new fields of IT, like the Internet of Things, Artificial Intelligence or machine learning. In these kinds of projects, not only the exact features, but even the futureusersareuncertain.Butanyhow, thesesystemswill interactwithusers, so thechanceofmeetingsubconsciousrequirementsafter implementationis100%. The only thing that can help you there may be a quote from Steve Jobs [10]: “Have the courage to followyourheart and intuition.”Asa tester, youwill have todetectyourownsubconsciousrequirementsandmake themconscious inyour test cases. The Cynefin framework can also be read as a timeline. In the early decades of IT, most projects were in the obvious quadrant, automating “islands” of single, strictly demarcated business processes. Somewhere from the 1990s onward, we started trying to integrate these islands, and projectsbecamecomplicated.With the breakthrough of internet and mobile apps, we saw the arrival of complex projects that createdand triggeredcompletelynewbusinessprocesses. As IT extends its scope beyond the original domain of computers, invading products likecars, refrigerators, lightbulbs,orweapons, thepartofchaoticprojects isgrowingrapidly.Soasatester,bepreparedtodealwith theunknowables;youwill findmoreandmoresubconsciousrequirementsonyourpath.Consider, for instance, the requirements for a “friend-or-foe” system in an autonomous combat robot, let alone the challengeof testing suchasystem . . . 5 Conclusion Subconscious requirements are requirements for a feature that users in a certain domain take forgrantedoronlybecomeawareofwhen it isnot implemented.Such requirementsareeasily overlooked,evenbyexperiencedanalysts anddesigners, so there isagoodchancethat someof themwillbemissingfromthespecificationsfor a system. Testers still have the responsibility to test the relevant subconscious require- ments, but fear overlooking some of them, because they cannot rely on the specifications.Theabsenceorfailureofsuchafeaturewilloftenseriouslyaffect the system, leadingtoexpensiverepairsorevenrejection.To test subconsciousrequire- ments, testerscannotrelyontheircommonlyusedspecification-andstructure-based testing techniques, so theyswitch toexperience-basedtechniques. This raises the question of how testers should acquire the necessary domain knowledgeandexperience.In thefirstplace, testers should(beable to)applyobser- vation and artefact-based techniques from the requirementsengineeringdiscipline. Such techniques are especially suitable for finding subconscious requirements. Learning and applying these techniques is very relevant but will significantly add to theworkloadof the tester.