Skip to main content

Kan een automatische unittest-tool effectieve regressietests uitvoeren?

Geschreven op . Gepost in Geen onderdeel van een categorie, Testing. Geen reacties op Kan een automatische unittest-tool effectieve regressietests uitvoeren?

Het testen van code is een cruciale stap om de kwaliteit van een informatiesysteem te waarborgen. Niet enkel tijdens het ontwikkelen van de software maar nog meer bij regresssietesten, waarbij wordt gecontroleerd of bestaande functionaliteit nog steeds correct werkt na het doorvoeren van wijzigingen. Met de opkomst van automatisering zijn er tools ontwikkeld die beweren volledig automatisch unittests te kunnen genereren. Maar kunnen deze tools daadwerkelijk effectieve regressietests uitvoeren?

Automatische unittest-tools zijn softwaretoepassingen die op basis van de verstrekte code automatisch testgevallen genereren. Dergelijke tools maken vaak gebruik van statische analyse om automatisch tests te schrijven voor diverse functies en methoden binnen de software. Een van de belangrijke voordelen van deze tools is dat ze ontwikkelaars en testers aanzienlijk vrijwaren van handmatig werk, waardoor het testproces aanzienlijk wordt versneld.

Bij het gebruik van automatische unittest-tools is het van cruciaal belang dat zowel de unittests als de gegenereerde resultaten volledig transparant zijn. Transparantie garandeert dat alle betrokken belanghebbenden een duidelijk inzicht hebben in de testcases en de bijbehorende uitvoer. Dit bevordert de geloofwaardigheid van de tests en biedt de mogelijkheid om eventuele discrepanties tussen de verwachte en daadwerkelijke resultaten efficiënt te identificeren en op te lossen.

Het handmatig uitvoeren van regressietests is een tijdrovend en foutgevoelig proces, vooral in complexe systemen. Helaas wordt het vaak verwaarloosd, waardoor de testset niet up-to-date blijft. Bij onderhoudswerkzaamheden worden nieuwe testcases toegevoegd, die soms aanzienlijke overlap vertonen met reeds bestaande testcases. Dit leidt tot legacy-problemen, redundantie en regressie in de testset, wat de effectiviteit van het testen van het informatiesysteem aantast.

Automatische unittest-tools kunnen een waardevolle bijdrage leveren aan het ontwikkel- en testproces. Voor effectieve regressietests moeten ontwikkelaars verschillende testmethoden gebruiken, waaronder handmatige tests, geautomatiseerde tests en menselijke expertise om ervoor te zorgen dat de code correct functioneert, zowel op het moment van implementatie als in de toekomstige ontwikkelingsfasen.

Maar wat als automatische unittest-tools nu niet alleen veel tijd bespaart en frustratie wegneemt bij de ontwikkelaar en tester. Wat als een dergelijke tool snel en effectief een slecht onderhouden testset kan vervangen of zelfs een geheel niet aanwezige testset van een legacy-systeem kan opbouwen. Wij gaan de komende tijd onze visie op geautomatiseerd maken van een unittest met je delen. Wil je meer weten, neem dan gerust contact met ons op.

Teamuitstapje

Geschreven op . Gepost in Geen onderdeel van een categorie. Geen reacties op Teamuitstapje

Onlangs hadden we ons teamuitje op 14 juni op het strand van Scheveningen, Denhaag. Het was een geweldige ervaring voor iedereen. Van teambuildingactiviteiten tot spannende spelletjes, we hadden het allemaal. Het werd gevolgd door heerlijk eten tijdens het diner. Het weer was zo goed, zonnige dag. Na motivatie te hebben gekregen van onze collega Mart van Werkhoven beachvolleybalster. We kregen training van Wies Bekhuis (Topspeler Beachvolleybal) en het team speelde beachvalleybal. Dit was een verpakt vermaak voor iedereen in ons team.

Het Scheepvaart museum bezoek

Geschreven op . Gepost in Geen onderdeel van een categorie. Geen reacties op Het Scheepvaart museum bezoek

Dus de museumdag is er weer met veel leuke activiteiten. Deze keer bezochten we Het Scheepvaartmuseum in Amsterdam. Het Nationaal Scheepvaartmuseum bewaart een van de grootste en meest vooraanstaande maritieme collecties ter wereld en omvat schilderijen, scheepsmodellen, navigatie-instrumenten en zeekaarten. We genoten ook van een VR-reis waarin het mogelijk is om terug te gaan in de zeventiende eeuw. De VR is te zien aan boord van het VOC-schip Amsterdam.


In de VR reis zijn we getuige van een aantal gebeurtenissen, zoals het ontstaan van de indrukwekkende scheepswerf en het Zeemagazijn – het huidige museum – en de bouw en tewaterlating van een oorlogsschip. Ook de Montelbaanstoren is te zien, waar op de kade ook het afscheidsmoment plaatsvindt. Matrozen, matrozen en soldaten gaan aan boord van de VOC en nemen afscheid van hun familie.

Na de heerlijke lunch in het museum hadden we een kennissessie over cryptovaluta. Waarbij Mart en Sebastiaan hun kennis deelden en over de feiten spraken. Het was een goed uitje met team en enthousiast voor volgend museumbezoek….

Integrated unit-testen

Geschreven op . Gepost in Geen onderdeel van een categorie. Geen reacties op Integrated unit-testen

Na een lange dag noeste arbeid, knikt de ontwikkelaar tevreden. Het stuk code dat hij schreef om een leenbedrag in termijnen terug te betalen is klaar. Hij heeft een aantal testjes uitgevoerd al is dit eigenlijk niet nodig, hij maakt zelden fouten. Nog snel even inchecken en dan kan hij naar huis. Morgen zal zijn programmatuur geïntegreerd zijn in het financiele systeem en is het de beurt aan de testers.

De volgende ochtend start de tester vol goede moed. De geautomatiseerde testen zijn goed doorlopen. Hij wil allen nog wat laatste functionele testen uitvoeren voordat de module die verantwoordelijk is voor termijnbetalingen op leningen uitgerold kan worden. Meer uit nieuwsgierigheid dan dat het een van te voren gedefinieerde test is, voert de tester een terugbetaling is van 0 termijn. Het systeem loopt onmiddellijk vast. Dit is toch niet te geloven? Slechts 1 test en het systeem loopt vast?! Dit had de ontwikkelaar moeten vinden!!

Bovenstaande is een goed voorbeeld van de frustratie waar testers en ontwikkelaars dagelijks mee te maken hebben. Welke bevindingen horen uit een unittest te komen en welke testen voer je uit tijdens de functionele acceptatietest? Had de tester überhaupt een division by zero uit moeten voeren of had hij erop moeten vertrouwen dat de ontwikkelaar dit reeds gedaan had.

Hoe mooi zou het zijn als de verschillende testsoorten geen losse quality gates waren maar een onderdeel van cumulatieve kwaliteitszorg. Iedere testsoort is het begin van de volgende. Geen dubbel werk, geen irritatie en frustratie maar fantastisch teamwerk tussen de ontwerpen, ontwikkelaar en tester? In de komende blogs laten wij zien hoe Qualitier dit principe voor ogen heeft.