INDIVIRTUAL - TECHNISCH PARTNER IN DIGITALE DIENSTVERLENING

Kwaliteitscontrole op webdevelopment: Software testing #2

July 11, 2011

Post 2: testrichtlijnen en aanpak

In de voorafgaande post heb ik geschreven over de kwaliteit van het ontwerpproces: Een goed ontwerp is het uitgangspunt voor goede software. In deze post ga ik ervan uit dat het ontwerpproces voorafgaand aan de bouwfase is afgerond en dat de ontwikkeling van de site met een solide ontwerp van start kan gaan.

vorige post (1): inleiding, wat voorafgaat en waarom het testen nooit is afgelopen

In post 3 en verder ga ik de afzonderlijke soorten tests in detail beschrijven, in deze post ga ik in op de richtlijnen die gelden tijdens de ontwikkelfase en het testplan.

Interne voorschriften

Indivirtuals testaanpak gaat uit van de volgende interne voorschriften:
  • Test vroeg en vaak:  Issues die gevonden worden in een acceptatietest kosten gemiddeld 10 keer minder om op te lossen dan als deze pas worden gevonden als de website al in productie is. Het bespaart zelfs nog meer geld om bevindingen al op te lossen tijdens een unittest.
  • Test geautomatiseerd: Handmatig testen leidt tot ongestructureerd testen, verschillen in aanpak tussen de projectdeelnemers, te laat testen en in het slechtste geval tot te weinig testen als de tijdsinspanning om te testen onder druk komt omdat developers teveel gefocust raken op deadlines.
  • Maak het schrijven van de testcases tot een integraal onderdeel van de software development: Schrijf als developer voordat je begint met het programmeren van een deelfunctionaliteit eerst het geautomatiseerde testscript waar deze aan moet voldoen. Nu gaat testen en programmeren hand in hand. Zodra de test succesvol doorlopen wordt is de deelfunctionaliteit klaar om opgenomen te worden in het systeem. (Hierna volgt refactoring van de code, waarbij dezelfde test dient om regressie te voorkomen.)

Testaanpak

Indivirtual schrijft een Testplan voor elk project. Zo'n Testplan is geen stand alone document. Zo is punt 1. gebaseerd op het Functioneel Ontwerp. De punten 3, 4 en 5. sluiten aan bij de planning zoals die al eerder in het Plan van Aanpak en de Projectplanning van het betreffende project is gespecificeerd.

Het testplan omvat:

  1. Een gedetailleerde beschrijving van de scope inclusief de functionele en non-functionele requirements waaraan het resultaat van het project moet voldoen. Er wordt expliciet aangegeven welke documenten (incl. de documentversie) de specificaties vormen waarop de tests gebaseerd zullen zijn. Dit zijn in ieder geval het Functioneel Ontwerp en Technisch Ontwerp. Bij de functionele acceptatietest van de site zullen echter ook het Grafisch en Interactie-ontwerp de input zijn om te bepalen of de op te leveren site voldoet aan vormgeving en werking voor de webgebruiker.
  2. De omschrijving van de tests die zullen worden uitgevoerd.
  3. De planning van het opstellen van de testcases, de testscripts, de testcriteria en de inzet van de betrokken personen.
  4. De planning van de uit te voeren tests, het oplossen van bevindingen, de inzet van de betrokken personen en hun rollen en verantwoordelijkheden.
  5. De randvoorwaarden waaraan moet zijn voldaan (zoals bijv. het beschikbaar zijn van het te testen onderdeel op acceptatie, het beschikbaar zijn van alle benodigde koppelingen met externe systemen etc.) op het moment dat elk van de geplande tests wordt uitgevoerd.
  6. De testtooling: Zoals de methodiek voor het opstellen van de testcases, -scripts en het rapporteren van de bevindingen.
  7. De afspraken tussen de klant en Indivirtual met betrekking tot het rapporteren en omschrijven van bevindingen, het toekennen van prioriteit, het geven van instructie aan de medewerkers van de klant die de acceptatietest zullen uitvoeren en het bieden van ondersteuning aan de klant tijdens de acceptatietest.
In de volgende posts vervolg ik met de tests zelf.

Post 3: unittest en systeemtest

Frank van de Velde

Frank van de Velde