Antwoord.

Handmatige integratietests zijn een belangrijke fase in de levenscyclus van software die na unit-tests worden uitgevoerd. Het doel is om te verifiëren dat afzonderlijke modules of componenten van het systeem correct met elkaar communiceren.

Achtergrond van de vraag: Aanvankelijk werden softwaretests geleidelijk uitgevoerd: eerst werden afzonderlijke modules getest (unit-tests), en vervolgens het systeem als geheel. Echter, in de praktijk bleek dat de meeste kritische fouten juist op de snijvlakken tussen modules ontstaan. Dit leidde tot de noodzaak van integratietests, die handmatig inconsistenties in het gedrag van verschillende delen van het systeem opsporen.

Probleem: De belangrijkste moeilijkheid is onvoldoende uitwerking van interactiescenario's tussen modules en vergeten afhankelijkheden. Dit leidt tot “onzichtbare” bugs: bij geïsoleerde tests werkt alles correct, maar na integratie ontstaan er storingen (bijvoorbeeld onjuiste gegevensverwerking tussen API en database).

Oplossing: Een goede organisatie van handmatige integratietests omvat:

Analyse van de architectuur van het systeem en het opstellen van een interactiekaart van componenten.
Ontwikkeling van integratietestcases op basis van gebruikersscenario’s en randgegevens.
Modelleren van partiële storingen (bijvoorbeeld de uitval van een van de diensten) en het evalueren van de reactie van het hele systeem.
Documenteren van de resultaten en vastleggen van afhankelijkheden tussen bugs.

Belangrijke kenmerken:

Bijhouden van een actuele architectuurschema.
Rekening houden met alle verborgen en zichtbare afhankelijkheden tussen delen van het systeem.
Speciale aandacht voor scenario's van gegevensoverdracht en -transformatie op de snijvlakken van modules.

Misleidende vragen.

Wat is het verschil tussen handmatige integratietests en systeemtests?

Integratietests richten zich op het testen van de verbindingen tussen specifieke modules, terwijl systeemtests de complete systeemfunctionaliteit vanuit de bedrijfsoptiek controleren.

Moet je bij integratietests echte externe diensten gebruiken, of zijn emulators voldoende?

Voor kritische integraties heeft een echte omgeving de voorkeur, maar je kunt beginnen met emulators (mock/stub). Finale tests moeten plaatsvinden in een omgeving die zo dicht mogelijk bij PROD ligt.

Kunnen alle integratiefouten alleen door automatisering worden opgespoord?

Nee: sommige defecten worden alleen handmatig ontdekt, wanneer de tester niet-voor-de-hand-liggende problemen in de bedrijfslogica van gegevensuitwisseling of in gebruikersscenario's die niet door automatisering worden gedekt, opmerkt.

Typische fouten en anti-patronen

Ontbreken van een duidelijke lijst van integratiepunten.
Het uitvoeren van tests zonder omgevingisolatie.
Onvoldoende detaillering van integratietestcases.

Voorbeeld uit het leven

Negatieve case

De integratie tussen de betalingsmodule en de bestellingsmodule werd alleen getest nadat alle andere tests waren voltooid en zonder aparte documentatie.

Voordelen:

Tijdsbesparing bij het voorbereiden van testcases.
Snelle start van tests zonder complexe coördinatie.

Nadelen:

Uitlekken van ernstige bugs naar productie, gerelateerd aan dubbele afschrijvingen.
Vertraging van de release om op het laatste moment gevonden fouten te corrigeren.

Positieve case

Integratiescenario's waren aanvankelijk gedocumenteerd en de testgegevens waren zo dicht mogelijk bij de werkelijke gebruikersscenario's.