Testen van een onbekende applicatie

Het mag niet. En toch komt het voor. Een applicatie testen waarvan je niet weet hoe die werkt. Ook in de Agile wereld. Want Agile wordt soms gebruikt om geen documentatie te schrijven. Tenslotte is werkende software belangrijker. Met als gevolg dat je als tester geen idee hebt wat je moet testen. Kan je dan wel testen?

Het beste voor het testen zou zijn als je zou weigeren. Als je totaal geen informatie hebt over de applicatie, dan is goed en betrouwbaar testen eigenlijk niet mogelijk. Maar weigeren is niet altijd een optie. Soms houdt weigeren in, dat een applicatie zonder getest te zijn naar productie gaat. Of je bent in een organisatie waar ze de informatie misschien wel willen geven, maar niet kunnen geven. De kennis is in de organisatie niet meer aanwezig of erg verspreid over verschillende mensen. Dan kan het verstandig zijn om toch te testen. Naar beste kunnen gezien de omstandigheden en garantie tot de deur. Maar toch, testen is dan de beste optie.

Hoe pak je dat aan? Het belangrijkste is je insteek als tester. Waar je anders test wat je weet of op papier hebt staan, moet je nu op een meer lerende manier testen. Je test wat je weet, maar zorgt er tegelijkertijd voor dat je via vragen meer te weten komt. De door mijzelf ontwikkelde aanpak bestaat uit vier stappen:

• Testen
• Noteren
• Informeren
• Doel bepalen

Testen

Als je niets weet, begin je met testen. Dit klinkt vreemd, maar er zijn testen die je altijd kan uitvoeren. Tijdens deze testen leer je de applicatie kennen, waardoor je leert welke vragen je moet stellen en welke onderdelen je uitgebreider moet testen.

Hieronder drie voorbeelden van testen die je altijd uit kan voeren

Navigatie-items test
Klik in een menu elk menu-item of klik in een knoppenbalk elke knop aan. Test voor zover je kennis nu reikt. Hoewel bij deze test de testwaarde minder is, is het een ideale manier om voor het eerst kennis te maken met de applicatie.

Twee test
Voer in elk veld twee waardes in. Vul elke tabel met twee rijen en elke verzameling met twee waardes. Bekijk elk getoond gegeven met minimaal twee waardes. Twee is hierbij belangrijk. Hiermee voorkom je dat je fouten mist, waarbij in een functie steeds dezelfde waarde wordt gebruikt. Of dat er in een verzameling of tabel slechts 1 item wordt getoond of opgeslagen.

Leeg test
Begin bij het invoerscherm met een volledig leeg scherm. Klik op Opslaan en vul vervolgens alleen de gevraagde waarde(s) in. Klik hierna weer op Opslaan. En ga hiermee door tot de invoer geaccepteerd wordt. Als je dit al weet of kan voorspellen, ga dan naar andere schermen, waar de ingevoerde gegevens gebruikt worden. Op deze wijze kan je nagaan of de applicatie goed kan omgaan met lege waardes. Worden deze goed getoond? En kunnen deze ingevoerde gegevens later nog goed gebruikt worden.

Noteren

Het verstandigste is om het noteren vrij vlak na het testen te doen. Het kan zelfs verstandig zijn om tijdens het testen al kort aantekeningen te maken. Het doel van het noteren is om vast te leggen waar je nog kennis te kort komt. Ongeacht of je hier antwoord op kan krijgen of niet. Als je antwoord kan krijgen, kan je later verder testen. Anders dient het als basis om anderen te informeren wat je niet hebt kunnen testen. En later om aan te kaarten over welke onderdelen er een kennisgat is.

Bij het noteren zijn er onderdelen die bijna altijd om meer kennis vragen

• Berekende gegevens
• Beslissingsprocessen
• Verdwijnende en verdwijnende velden

Informeren

Informeren is twee-ledig. Het belangrijkste deel is het verkrijgen van informatie over de genoteerde onderdelen. De vragen over deze onderdelen kan je het best stellen aan gebruikers of andere niet-IT'ers die kennis hebben. Dat is het meest objectief. Daarna komt de groep IT'ers die de software niet gebouwd hebben, denk hierbij vooral aan Functioneel Ontwerpers of andere functies die de software ontwerpen of bij het ontwerpen betrokken zijn. Maar je kan soms bijvoorbeeld ook heel veel kennis bij een helpdesk vandaan halen. En als derde kan je altijd de ontwikkelaar vragen hoe het moet werken. Dit is het minst objectief en zal dan ook voornamelijk tot doel hebben de bestaande applicatie in beeld te brengen. Toch kan je ook op deze wijze fouten ontdekken, omdat een ontwikkelaar ook als hij weet wat hij wil bouwen, regelmatig toch net iets anders bouwt.

Als het niet meer mogelijk is meer informatie te achterhalen, wordt het tijd om je teamleden en eventuele andere betrokkenen te informeren. Laat aan de hand van je notities weten wat je wel en wat je niet hebt kunnen testen. En bespreek met je team en eventueel met andere betrokkenen of dit voldoende is. Zo nee, kijk dan of zij nog een mogelijkheid zien of hebben om meer informatie te achterhalen.

Doel bepalen

Na het informeren heb je meestal meer kennis van hoe de applicatie moet werken. Vervolgens moet deze kennis weer omgezet worden in testen, b.v. met testtechnieken of checklists. Je zet de nieuw verkregen kennis dus om naar nieuwe testdoelen, om vervolgens de cyclus weer opnieuw in te gaan.

Tot slot

Ideaal blijft het niet om een onbekende applicatie te testen. En het blijft goed om ernaar te streven dit te voorkomen. Maar als het toch moet kan je door te testen ontdekken wat je niet weet. Vervolgens kan je dit vastleggen en ernaar informeren. Waarna je kan bepalen hoe je verder test. Op deze wijze kom je nog vrij ver. En je hebt een beter beeld van welke kennis je niet hebt. Beide zijn waardevol, voor nu en in de toekomst.