Om effectief te testen willen we weten hoe een applicatie gebruikt gaat worden. Domeinkennis kan ons helpen om realistische scenario's en bijbehorende risico's te bepalen. Domeinkennis kan echter ook misleidend zijn. Domeinen veranderen in de loop der tijd en iedere organisatie doet zaken op haar eigen manier. Daarom moeten we de business leren kennen en niet het domein.
Verschilt het testen van software tussen het ene domein en het andere? En zo ja, hoe belangrijk is domeinkennis in het omgaan met dit verschil? In dit artikel zal ik de geldigheid onderzoeken van de veronderstelling dat domeinkennis een voordeel is voor een softwaretester.
Software als instrument
In sommige gevallen is software het product. Dit geldt bijvoorbeeld voor games. Het product is een verzameling bestanden die rechtstreeks waarde levert aan de gebruiker. In andere gevallen is software onderdeel van het product. Dit geldt voor mobiele telefoons, navigatiesystemen en vrijwel elk ander elektrisch apparaat dat tegenwoordig wordt geproduceerd. Ook hier levert de software zijn waarde direct aan de klant. Vaak echter maakt software geen deel uit van het product, maar ondersteunt het de levering van een dienst. Dit geldt voor informatiesystemen in banken, verzekeringsmaatschappijen overheidsinstanties. Elke denkbare organisatie maakt gebruik van software ter ondersteuning van haar activiteiten. Dit soort software levert zijn waarde direct aan de professionals en slechts indirect aan de klanten. Dit soort software is een instrument.
In dit artikel, zal ik het hebben over het testen van software die wordt gebruikt als instrument. Het is dit soort software dat door professionals wordt gebruikt in verschillende domeinen.
Domeinkennis
Het helpt om ervaring te hebben met een specifieke applicatie. Je kent de menustructuur al. Misschien heb je ook een paar fouten gemaakt, waarvan je hebt geleerd. Met andere woorden, je bent het steile stukje van de leercurve voorbij. Sommige applicaties zijn domeinspecifiek, hetgeen betekent dat er domeinkennis is ingebouwd. Echter, het hebben van kennis van een dergelijke applicatie is niet hetzelfde als het hebben van domeinkennis.
Domeinkennis is kennis over feiten en regels in een bepaalde tak van bedrijvigheid. In hoeverre moeten we domeinkennis hebben om software te testen?
Testen en controleren
Onafhankelijk van de testmethodologie zijn er twee fundamentele stijlen van softwaretesten, bevestigend en niet-bevestigend. Het doel van bevestigende tests is om aan te tonen dat de software werkt zoals het hoort. Het doel van de niet-bevestigende tests is om aan te tonen dat de software niet werkt zoals het hoort. Dit zijn zeer verschillende doelen die om verschillende middelen vragen.
Bevestigende tests vereisen één of andere vorm van documentatie. Deze documentatie vertelt ons hoe de software zou moeten werken onder specifieke omstandigheden en met specifieke inputs. Vervolgens controleren we dit. Hierbij maken we vaak gebruik van scripts. Omdat bevestigende tests gebaseerd zijn op specificaties, moeten ze objectief worden gedaan. Eerdere ervaringen in hetzelfde domein zijn waarschijnlijk eerder een belemmering dan een voordeel.
Bevestigende tests worden gedaan in de vroege fases van softwareontwikkeling. Zodra het systeem zo ver is dat het min of meer doet wat het moet doen, dan pas kunnen we gaan testen op een niet-bevestigende manier.
Niet-bevestigende tests vereisen verbeelding. We stellen ons voor wat er kan gebeuren en observeren de manier waarop de software reageert op verschillende inputs en omstandigheden. Vervolgens beoordelen we of deze reactie adequaat is. Om dit te doen, hebben we inzicht nodig in de manier waarop de software wordt gebruikt. Bij niet-bevestigende tests maken we geen gebruik van scripts maar testen we op een verkennende , onderzoekende manier, waarbij we realistische scenario's bedenken en direct uitvoeren. Om hierin doeltreffend te zijn, is een bepaalde mate van domeinkennis nodig.
Deze kennis kan worden verworven door te praten met vertegenwoordigers van de business. Het is gevaarlijk om te vertrouwen op kennis die verworven is in eerdere opdrachten.
Feiten en regels
Stel, je hebt gewerkt als tester voor een verzekeringsmaatschappij. Tijdens deze opdracht heb je enige kennis verworven omtrent verzekeringen. Je volgende opdracht is bij een andere verzekeringsmaatschappij. Vanwege je domeinkennis ben jij degene die de klus kreeg. Na een tijdje kom je erachter dat veel dingen die je wist over de oude verzekeraar niet van toepassing zijn op de nieuwe.
Een verzekeringsmaatschappij verkoopt tal van verschillende verzekeringen met verschillende voorwaarden. Iemand die voor de verzekeringsmaatschappij werkt, moet zoveel mogelijk verschillende verzekeringen kennen, vooral in een rol waarin deze kennis nodig is in de communicatie met klanten of collega's. Bij het testen van de software in deze verzekeringsmaatschappij, is het hoogstens handig om uitgebreide kennis over alle verschillende verzekeringen te hebben. Omdat je niet in direct contact staat met klanten of verzekeringsprofessionals, is het genoeg dat je weet waar je de informatie over de verschillende verzekeringen kunt vinden. Kennis van de specifieke kenmerken van verzekeringen zal je ook niet helpen als je software gaat testen bij een andere verzekeringsmaatschappij met andere verzekeringen.
Voorafgaand aan het testen moet je weten wat de requirements zijn, en niet alleen de gedocumenteerde. Daarvoor is het nodig om de gebruikers te leren kennen. Hoewel er overeenkomsten zijn tussen bedrijven in hetzelfde domein, zijn er ook verschillen. Zelfs binnen bedrijven zijn er verschillen tussen afdelingen. Specifieke kennis, op basis van gebruikersgroepen die je eerder hebt gekend, kan je visie op de requirements vertroebelen.
De feiten en regels van een domein liggen niet vast. Zoals gezegd verschillen ze tussen, en zelfs binnen, organisaties. Ook op een meer algemeen niveau kunnen ze, na verloop van tijd, veranderen. Voorschriften, en zelfs wetten, zijn niet geschreven voor de eeuwigheid. Daarom moet je domeinkennis, die je hebt opgedaan in eerdere opdrachten, altijd verifiëren. Daarbij kom je misschien nog wel iets nieuws te weten.
Softwarekwaliteit
Testen kan nooit volledig zijn. Wanneer de software daadwerkelijk gebruikt wordt door professionals in hun dagelijks werk,dan zullen zich combinaties van omstandigheden en inputs voordoen, die niet zijn getest. Om de optimale subset van alle mogelijke combinaties te testen, hebben we een oprechte interesse nodig in de software en de gebruikers ervan, een beetje fantasie en, natuurlijk, onze vakkennis.
Logischerwijs kunnen we nooit hetzelfde niveau van domeinkennis bereiken als de dagelijkse gebruikers van de software. Dit is omdat we ons eigen domein hebben, namelijk softwarekwaliteit. Softwarekwaliteit manifesteert zich in de interactie tussen gebruikers en software. We moeten weten wat de gebruikers doen en hoe ze dat doen. Kennis over het gebruik van software is een onderdeel van ons domein.
Als softwaretesters opereren we op het raakvlak tussen business en techniek. Om ons werk goed te doen, moeten we beide tot op zekere hoogte kennen. We moeten meer over de techniek weten dan mensen van de business en meer over de business dan mensen van de techniek. Er is maar één soort domeinkennis die ons echt beter maakt in ons werk, en dat is kennis van het testdomein.
Een Engelstalige versie van dit artikel is eerder gepubliceerd in Testing Experience.
Goed artikel en heel herkenbaar.
De bevestigende testen kan je eigenlijk heel goed overlaten aan de enthousiaste gebruiker. Die is blij met zijn nieuwe ‘speeltje’ en zal willen bewijzen dat het goed werkt.
Het niet-bevestigende testen kan je om die reden helemaal NIET aan de gebruiker overlaten – daar heb je echt een tester voor nodig.
Heb ik wel een vraag: wat bedoel je precies met ’testdomein’. Bedoel je simpelweg dat de tester zijn vak moet verstaan?
Dankjewel Simon.
Ik heb de term testdomein gebruikt om te benadrukken dat we ons eigen domein hebben. Kennis van dit domein is inderdaad een noodzakelijke voorwaarde voor vakmanschap, maar geen voldoende voorwaarde. Ook vaardigheden zijn onontbeerlijk.
Mooi artikel.
Wat mij betreft onderstreept dit het belang van communicatief vaardige en samenwerkingsgerichte testers.
Omdat je als tester nooit de volledige domeinkennis hebt is het je taak om de nodige kennis te halen bij de mensen die de businesskennis hebben.
Een goede tester ben je pas als je dit begrijpt en de samenwerking opzoekt.
Testen hoort een integraal onderdeel van het ontwerp te zijn verder uitgewerkt door test specialisten ism eindgebruikers.
In principe test je datgene wat in het functioneel ontwerp staat. Hier kun je dan weer je testscripts op baseren (bevestigend). Bij het niet-bevestigend testen weet je eigenlijk ook al wat het resultaat moet zijn. En daar is volgens mij geen domeinkennis voor nodig.
In de traditionele werkwijze heeft de tester ook geen contact met de eindgebruiker.
Een functioneel ontwerp is nooit volledig. Een aantal requirements dat niet gespecificeerd is, ken je inderdaad ook zonder domeinkennis wel. Het gaat dan om algemene vanzelfsprekendheden. Andere vanzelfsprekenheden zijn minder algemeen en daarvoor is wel degelijk domeinkennis nodig.
Contact met eindgebruikers is de beste manier om deze domeinkennis op te doen. Dat het daar in de traditionele werkwijze aan ontbreekt, is misschien wel één van de oorzaken van de vele mislukte projecten in ons vakgebied.
Eindgebruikers hebben vaak geen testkennis. Het belang van gebruikersacceptatietests moet dan ook niet overschat worden. De echte gebruikerstest heet productie. Om productie-issues te voorkomen zijn testers nodig met domeinkennis.