Automated testing - Waarom zou je het doen?
Gerelateerde blogs.
Inspiratie
In ons vorige blog-bericht over automated testing (zie Automated testing ? Wat houdt het in?) kon je lezen wat automated testing is en op welke momenten deze uitgevoerd kunnen worden, maar waarom zou je eigenlijk automatisch testen?
Waarom zouden we eigenlijk automatisch willen testen? In het vorige blog-bericht gaf ik al aan dat wij als MaxServ kwaliteit als speerpunt hebben en dat testen het belangrijkste onderdeel is om deze kwaliteit te garanderen. Er werden al enkele tests automatisch uitgevoerd, maar er waren ook nog een aantal tests die we nog handmatig uitvoerden. Waarom zouden we dit automatiseren? Ik heb toen eens onderzoek gedaan naar een aantal veelgehoorde stellingen.
Testen is simpel, waarom moeilijk doen?
Als er één stelling niet waar is, dan is het wel dat testen simpel is. Een goede tester is kritisch, denkt buiten de standaard denkwijzen en heeft het liefst niet te veel kennis van het systeem. Alleen een combinatie van deze eigenschappen maakt iemand een goede tester.
Het spreekt voor zich dat je bij het testen kritisch moet zijn. Ben je niet kritisch genoeg, dan kunnen er fouten tussendoor sluipen.
Denk je als tester te veel volgens de standaard denkwijzen, dan zal je bijvoorbeeld nooit proberen om een telefoonnummer in een e-mailveld te plaatsen. Dit gebeurt echter vaak genoeg en je wilt dan toch dat er een nette foutmelding komt. Als tester moet je dus alle mogelijke (en soms ook onmogelijke) scenario's testen.
Ten derde is het het beste als de tester niet te veel kennis heeft van het systeem en dus niet onderdelen overslaat omdat hij weet dat het niet goed werkt. Als dit gebeurd heb je eigenlijk een zwarte vlek in je tests en kan er toch een functie opgeleverd worden die wellicht toch niet helemaal werkt.
Testen is dus alles behalve simpel! Zelfs de beste tester heeft wel eens een mindere dag. Om dit soort afhankelijkheden uit te sluiten kunnen we het beste uit gaan van een computer. Deze heeft geen mindere dagen, voert altijd alle tests uit die je wilt dat hij uitvoert en kan buiten de standaard denkwijzen opereren. Uiteraard is het zo dat een test nog steeds geschreven moet worden en dat dit grondig gedaan moet worden met bovenstaande eigenschappen in het achterhoofd, maar het voordeel is dat als de test eenmaal geschreven is hij eenvoudig nog een keer uit te voeren is en je voor de tweede keer niet meer afhankelijk bent van deze specialist.
Mijn code werkt toch! Waarom zou ik ook nog eens tests schrijven?
Dit is een vaak gehoorde stelling onder ontwikkelaars. Het kan heel goed zijn dat de code die op dit moment geschreven is werkt, maar hoe vaak horen we in onze branche: als ik aan de linker kant iets aanpas, valt er rechts iets om. Dat is iets wat we willen voorkomen en dit is alleen te voorkomen door na iedere aanpassing alles te testen en niet alleen het nieuwe of gewijzigde onderdeel. Ook bij nieuwe versies van TYPO3, maar ook van bijvoorbeeld de onderliggende software, moet de gehele website opnieuw getest worden. Hoe makkelijk zou het dan zijn als de tests met een druk op de knop worden uitgevoerd.
Het schrijven van tests kost te veel tijd!
Dit is de hardnekkigste stelling die ik hoor en dit kan ik me ook wel enigszins voorstellen. Ik heb zelf namelijk ook heel lang zo gedacht. Het klopt dat het schrijven van goede tests best enige tijd kost. Zeker als je haast hebt om op tijd de functies af te ronden, wordt er vaak gedacht: ik sla de test wel even over. En juist op die momenten gaat het vaak mis. Onder druk van tijd, maken mensen fouten. Dat is helemaal niet erg, maar juist dan wil je dat je tests hebt die controleren of de werking van de code goed is. Een test is dus gewoon heel erg belangrijk en ja daar gaat tijd in zitten.
Maar dan het goede nieuws: het schrijven van tests levert je tijdswinst op! Een simpel rekensommetje:
Stel je hebt een functie die bijvoorbeeld de datums van een evenement toont met een begin- en eventuele einddatum en deze wil je bijvoorbeeld opmaken in het formaat 3 mei 2016, maar bijvoorbeeld ook 28 april - 1 mei 2016 als het evenement over meerdere dagen loopt. Het schrijven van een dergelijke functie neemt zo'n 2 uur in beslag. Het schrijven van een test om heel veel verschillende scenario's te testen kost misschien ook 1 uur. Je zou dan zeggen: dat kost me dus 1,5x de tijd! Dat klopt, maar de code is nu geschreven en de ontwikkelaar heeft de code middels deze automatische tests al getest en heeft dus ook al direct de eerste "kinderziektes" uit de code gehaald. Dat is dus al direct een winst in kwaliteit. Maar laten we deze kwaliteitsverbetering nog even buiten beschouwing laten.
Bij iedere update van TYPO3 moeten dit soort functies getest worden of de uitkomst nog daadwerkelijk zo is als verwacht. Een dergelijke functie in alle scenario's testen neemt al snel 20 minuten in beslag. Van TYPO3 versie 7 LTS zijn inmiddels al 4 nieuwe updates uitgekomen in slechts 6 maanden. Laten we er vanuit gaan dat op jaarbasis er minimaal 8 updates uitkomen van TYPO3. Op jaarbasis houdt dat dus in dat er 8 keer 20 minuten aan deze "simpele" functie getest moet worden, wat inhoudt dat je op jaarbasis 2 uur en 40 minuten bezig bent.
Als we dit doen middels automatisch testen, kost het ons in het begin 2 uur voor het schrijven van de tests. Het uitvoeren van een automatische test duurt echter nog geen 5 minuten. In plaats van 2 uur en 40 minuten ben je er dan nog maar 40 minuten mee bezig op jaarbasis. Dit is dus een winst van 2 uur terwijl het schrijven van de test maar 1 uur duurde. Op deze kleine functie scheelt dit dus al een uur op jaarbasis en uw website is vaak voor meerdere jaren.
Kortom: automatisch testen verhoogt de kwaliteit, maar levert ook nog een tijd op!
Automatische tests zijn niet opgenomen in mijn project!
Het controleren van de code op leesbaarheid en het schrijven van unit- en functionele-tests is tegenwoordig standaard opgenomen in onze projecten. In oudere projecten werd dit vaak nog optioneel aangeboden, maar vanaf nu zal MaxServ dit standaard voor je doen. Je kiest voor MaxServ vanwege de kwaliteit en zo kunnen wij die kwaliteit voor jou waarborgen.Het uitvoeren van automatische acceptatie-tests is iets wat wij nog wel als optie aanbieden. Wil je controleren of je website goed werkt in de allerlaatste versies van browsers en of je website doet wat je verwacht dat hij doet? Neem dan contact met ons op en wij kunnen je meer vertellen over hoe we voor jou automatische acceptatie-tests in de procedures kunnen verwerken.
Conclusie
Ik hoop dat duidelijk is geworden dat het automatisch testen van je website goed is voor de kwaliteit van de website, het (uiteindelijk) ook tijd oplevert en dat het bovenal je een goed gevoel geeft over de werking van je website. Wij als MaxServ geloven heilig in automatische tests en vertellen je er graag meer over! Schroom dus niet om contact met ons op te nemen als er vragen zijn.
Dit blog bericht is onderdeel van een serie blog berichten over automated testing. Eerder verscheen al: Automated testing: wat houdt het in? Ben je meer een techneut en wil je weten hoe je zelf tests moet schrijven? Houdt dan onze website of Twitter in de gaten: het volgend blog bericht in deze serie zal je meer duidelijkheid geven.
Gerelateerde berichten
This list contains no blog posts.