Skip to main content

10 soorten softwarefouten die testers moeten kennen (deel 2 van 2)

augustus 1, 2018oktober 14th, 2021

Deel twee van de 10 soorten softwarefouten die testers moeten kennen. Klik hier voor het eerst deel. 

6. Oude gegevens blokkeren het systeem.

Bij de introductie van een nieuw systeem moeten de oude gegevens ook nog beschikbaar zijn. Het invoeren van dit soort gegevens in het nieuwe systeem heet ‘migratie’, het aanpassen  ‘conversie’. Het komt regelmatig voor dat deze gegevens niet goed passen in de gegevensopslag, de database, van het nieuwe systeem. Dit blijkt dan pas in het gebruik en is lastig te testen omdat er zo veel verschillende soorten gegevens en uitzonderingen zijn. Een gegeven, bijvoorbeeld klantgegevens, of medische gegevens zijn niet vindbaar of leiden tot technische problemen zodra ze worden geopend. Dit kan zelfs betekenen dat een systeem vastloopt of dat werk van dagen verloren gaat!

Om dit te voorkomen moet je ervaren medewerkers aanhaken bij de testen: mensen die op de hoogte zijn van de verschillende varianten in de oude data zodat je deze kunt opvragen en bewerken in de testperiode.

7. De leverancier van software richt zich op nieuwe klanten, de wensen en bugs van oude klanten blijven achter.

Softwareleveranciers doen veel moeite om nieuwe klanten binnen te krijgen en zeker de eerste periode van een verbintenis doen ze veel beloftes aan deze klanten om ze definitief binnen te halen. Bovendien zullen ze veel beloftes doen en moeite doen om deze te realiseren. Maar na de wittebroodsweken worden nieuwere klanten interessanter. Waar blijven de wensen en de ingediende bugs dan?

Zorg dat je managers op de hoogte blijven van wat je wilt en wat er achter blijft in de releases zodat zij dit ook aankaarten bij de leverancier. Maak een lijst van topprioriteit-zaken en zoek steun bij bijvoorbeeld andere klanten.

8. IT-ers missen begrip van het werkproces waardoor een systeem technisch wel goed is maar toch niet goed functioneert.

Werkprocessen worden vaak onderschat door It-ers, maar ook door de gebruikers zelf. Men ziet niet dat jarenlange ervaring en begrip van de context belangrijk is en lastig voor anderen om te doorgronden. Hierdoor kan het dat een proces niet goed door een systeem heen loopt, er op onlogische plekken extra handelingen moeten worden verricht of delen zelfs onbegrijpelijk zijn.

Het is daarom van belang om in een project, al bij het ontwerp, ook ervaren gebruikers te betrekken. Laat hen de programmeurs de processen uitleggen. Dit geldt zeker voor de testen waar het werkproces het uitgangspunt moet zijn.

9. Door gebrek aan inzicht in risico’s worden delen te veel of te weinig getest, hierdoor worden fouten gemist terwijl men wel veel test.

Er wordt nog te vaak zo veel mogelijk getest. Vaak worden bekende testsets steeds maar herhaald omdat ze een vertrouwd gevoel geven. Dat is zonde, van de tijd en van de fouten die je mist.

Eén van de oorzaken is dat men slechte ervaringen heeft met risicoanalyses: deze verworden vaak tot het invullen van steeds hetzelfde checklistje. Een goede risicoanalyse betekent doorspreken van wijzigingen met programmeurs, beheerders én gebruikers: wat is er gewijzigd, hoe kan dit doorwerken en wat kunnen de gevolgen zijn voor het werkproces? Als je dit op een efficiënte manier doet en je laat de deelnemers daarna zien hoe je de hoogste risico’s extra test, de laagste risico’s niet of minder test en je geeft de deelnemers de gelegenheid mee te denken over testen, dan ben je op weg om een efficiënt en effectief testproces op te zetten.

10. Slecht versiebeheer laat eerder opgeloste bugs terugkeren.

Veel voorkomende en ergerlijke fouten zijn oude, al eerder geconstateerde fouten!

In een groot systeem werken verschillende programmeurs op verschillende versies van de software. Deze worden dan voor uitlevering weer samengevoegd. Hierbij kunnen wijzigingen en ook bugfixes verloren gaan. Bovendien kunnen andere programmeurs de programmeerfouten van andere programmeurs herhalen en zo bugs herintroduceren.

Zorg er voor dat een eerder gevonden bug als testgeval in je regressietestset zit. Niet alleen vind je een opnieuw geïntroduceerde bug dan weer, je verhoogt de kwaliteit van je regressietest omdat delen van het systeem waar vaak bugs optreden blijkbaar risicovoller zijn.