Organisaties willen applicaties steeds sneller naar de markt brengen. Een nieuwe versie is klaar en we willen er direct mee aan de slag. Voor nieuwe, handige app’s is dit niet zo’n probleem. Werkt de app niet, dan trek je hem terug of los je het probleem in een nieuwe versie op. Maar er zijn ook core-applicaties die altijd moeten werken en die je niet terug kunt trekken om eens rustig te onderzoeken.
Van dergelijke cruciale applicaties wil je snel kunnen bepalen of de software nog goed werkt. Een van de oplossingen om dit snel te bepalen is het implementeren van een testautomatiseringsoplossing. Ik merk echter dat er bij klanten nogal eens misverstanden zijn rondom dit onderwerp.
Het implementeren van testautomatisering kan door een deel van het gebruikelijke testwerk te automatiseren. Het voordeel hiervan is dat er sneller en vaker getest kan worden, waardoor je sneller inzicht krijgt in de correcte werking van je applicatie en uiteindelijk sneller naar de markt kunt met je applicatie. Of dat je applicatie, net zoals een winkel tijdens een verbouwing, gewoon operationeel blijft.
Door middel van testautomatisering blijf je de applicatie continu testen. Het is dus niet een oplossing die je alleen projectmatig inzet tijdens de bouw- of ontwikkelfase, maar in feite kun je testautomatisering zien als een complete it-oplossing, die 24×7 inzicht kan geven in de conditie en kwaliteit van je applicatie. Op basis van die gegevens krijg je inzicht in wat er nodig is voor bijvoorbeeld onderhoud en beheer van de applicatie.
Het betekent ook niet dat de testautomatiseerder verdwijnt. Die functie blijft nodig om bij te blijven met het automatiseren van nieuwe of gewijzigde functionaliteit, het runnen van scripts en het maken van analyses. Ook kan deze automatiseerder de omgeving van de applicatie en testdata managen en het versie- en licentiebeheer doen. Uiteraard samen met de specialisten van de infrastructuur, beheer en hosting.
Door op deze manier te werken kun je snelheid houden en meer snelheid maken in de ontwikkeling van applicaties en releases. De komende jaren maak je hét verschil in jouw markt met de combinatie van ontwikkel snelheid en software van hoge kwaliteit.
Herkenbaar dat er bij klanten misverstanden (kunnen) zijn bij introductie van de term testautomatisering. Het is niet alleen een kwestie van het aanschaffen van een tool en vervolgens testscripts maken. Naast de focus op de techniek is het ook belangrijk om na te denken over het proces en (beoogde) resultaat.
In een Agile context valt bijvoorbeeld te denken aan Behavior Driven Development (BDD) als aanpak zodat betere communicatie plaatsvindt tussen (de behoefte van) de business en het developmentteam. Door samenwerking worden hier in feite specificaties gemaakt en direct geautomatiseerd in een leesbare taal voor alle belanghebbenden. Naast (ontwikkel)snelheid zorgt dit ook voor meer transparantie, betere feedback en uiteindelijk een beter product.
Hiermee is er geen sprake meer van dé testautomatiseerder. De kwaliteit van de testscripts is dan een team-verantwoordelijkheid geworden. Desalniettemin is het wel raadzaam om een tester in het team te hebben met ervaring op dit vlak. Immers, testen blijft een vak (apart).
Henri,
Mooi verwoord alleen is er vaak nog een te grote nadruk op het functionele testen wat voor cognitieve dissonantie zorgt als het om de non-functionele aspecten zoals schaalbaarheid gaat. Laat test weg en het gaat om automatisering, organisatorisch best moeilijk als je het business proces opdeelt in allerlei units.
Wie roept mij? 🙂
Wat ik zie als test-automatisering is o.a. nieuwe releases testen op basis security zaken; sql injection, is alle input validated? cross site scripting toegestaan? En zoals “wie roept mij?” schrijft doet het schaalbaar zijn het nog? En wat is de reactie tijd van bestaande functies? Schiet die niet uit de bocht?
Ben het absoluut mee eens dat test automatisering werk aan de voorkant is, maar waar je aan de achterkant heel veel mee wint.
Ook niets zo saai als handmatig de scenario’s afwerken…..
Henri,
‘….a journaling file system may only keep track of stored metadata, resulting in improved performance at the expense of increased possibility for data corruption.’
Uiteraard wil een ontwikkelaar zich niet druk maken om de infrastructuur maar juist hier gaat het nog vaak mis als we kijken naar je genoemde aspecten van sql injection en cross-site scripting binnen de keten die ook mid- en backoffice omvat. Want vergeet niet de Kendall wachtrijtheorie die een aantal ‘scheduling’ disciplines kent welke een grote impact hebben op de integriteit van informatie als je het aspect tijd in de keten uit het oog verliest. Het meervoud van datum is data, de exponentiële toename aan metadata als gevolg van het opdelen van de waterval in de ‘paddenpoelen’ met agile-methodiek is lang niet altijd efficient.
Ooh… Verstappen, ik snap hem;-)
Voor wat meer diepgang kan ik
https://www.computable.nl/artikel/opinie/development/5433654/1509029/principes-voor-testautomatisering.html
aanbevelen (en vooral mijn reacties hierop).
Met de achterliggende gedachte: ontwikkelsnelheid krijg je pas echt met testscriptgeneratoren (op basis van templates).
Kort maar krachtig stuk over testautomatisering Wilbert. Leest lekker weg en maakt nogmaals duidelijk hoe belangrijk dit is, nu en in de toekomst.
Testen en programmeren komen al jarenlang dichter bij elkaar. Neem bijvoorbeeld Test Driven Development, waar programmeurs eerst een automatische test case maken en daarna pas de code. Levert hogere kwaliteit, betere code, en maakt het bewaken van de functionaliteit eenvoudiger.
Niet nieuw, maar wel belangrijk dus!