Bij Enrise automatiseren we sinds onze start in 2000 bedrijfsprocessen van klanten tot onder andere webapplicaties, sites en api’s. Maar hoe zit het met ons eigen proces? Software-ontwikkeling is een ambacht en blijft mensenwerk, maar je kunt er veel in automatiseren. Dat we daar heel ver in gaan bij Enrise hebben we gisteren laten zien tijdens de vierde editie van CodeCuisine®Live, het kennisevenement waar tech en business elkaar ontmoeten.
Goede software-ontwikkeling kan niet zonder een degelijk testproces. We werken veel samen met softwaretesters van Polteq en vroegen hen als gastspreker meer te vertellen over hoe je een goed geautomatiseerd testproces opzet.
Daarnaast vertelden de experts van Enrise over hoe je je een ontwikkel-test-acceptatie-productie-proces supersnel en flexibel kunt maken, zodat je op feature-niveau vele malen sneller live kan met vernieuwingen aan je online product.
Testautomatisering van Flop naar Top
Voor het testen van de software die we bouwen, nodigen we vaak de testers uit. Gedurende een ontwikkeltraject zijn de testers onderdeel van onze ontwikkelteams. Zij controleren, onderzoeken en beproeven de functionaliteit en de processen die we maken. We geven dus in feite de taak om de software kapot te krijgen, zodat we al in een vroeg stadium weten waar het mis kan gaan.
Flop-testautomatisering
Sprekers Frans van As en Wim ten Tusscher, testspecialisten bij Polteq, namen de 52 bezoekers mee naar wat je wel en niet moet doen als het gaat om het opzetten van een testproces. Zij pleiten voor vaker, beter en eerder testen. Zo voorkom je dat je naar een speld in een hooiberg zoekt als fouten na livegang aan het licht komen.
Je geautomatiseerde testproces flopt als je:
- Testen ziet als apart technologieproject met lage prioriteit;
- Geen strategie en deadlines hebt als het gaat om testen en uitkomsten;
- Bestaande handmatige tests automatiseert;
- Alleen tools die checken leidend laat zijn.
Te vaak is het testen van software een sluitpost van een project. En wordt er getest, dan zijn het vooral de visuele checks (GUI-tests) die worden gedaan: Zit alles erin wat we hadden afgesproken, werkt het? Dan is het goed. Development-tests worden minder vaak uitgevoerd, maar zouden eigenlijk belangrijker moeten zijn dan de GUI-tests. Want door op codeniveau te testen wat er niet zichtbaar is, kom je erachter wat niet werkt of wat niet werkt in hele specifieke situaties die je vooraf niet kon weten.
De ijshoorn
Deze manier van testen (Meer op zichtbaarheid en minder op code/onzichtbaarheid) is als een omgekeerde driehoek, met veel aandacht bovenin en weinig aandacht onderin.
Daarmee laat het zich nog het best vergelijken met een ijshoorntje. Het ziet er prima uit en iedereen kan er mee uit de voeten, maar een ijsje houdt nooit lang stand, vroeg of laat is het gesmolten of het hoortje gebroken.
Top-testautomatisering
Zeker in complexe developmentprojecten moet je testen belangrijk maken. Bij Enrise noemen we dat een testgedreven ontwikkelproces. Daarbij werk je gezamenlijk aan nieuwe code en zodra het eerste brokje functionaliteit klaar is, gaat een tester ermee aan de slag. ‘Breekt’ er iets, dan kun je snel schakelen door dat brokje functionaliteit beter te maken.
Je geautomatiseerde testproces is top als je:
- Voor alles wat je van tevoren weet checks kunt opzetten en automatiseren;
- Alles wat je vooraf niet kunt weten laat testen door mensen;
- Als je alles wat je vooraf niet kunt weten laat onderzoeken door een goede tester.
Een tester legt vooral geen nadruk op die GUI-test. Dat zijn namelijk controles die geautomatiseerd kunnen worden. Het zijn de checks waarvan je weet wat ze moeten doen, wat de uitkomt moet zijn. Dus kun je die automatiseren als test. Desgewenst met groene lampjes bij een geslaagde test en rode lampjes voor een falende test.
Een goede tester is een onderzoeker die software zodanig aan de tand voelt, dat je heel veel scenario’s afvangt. Situaties van wegvallende verbindingen tot onmogelijke apparaten met een scherm en een browser. Bij wijze van spreken zelfs van situaties waarbij een kat over een toetsenbord loopt van de gebruiker loopt. Een goede tester kan z’n creativiteit maximaal kwijt in zijn onderzoeken en tests.
De belangrijkste genoemde punten van Polteq:
- (Geautomatiseerd) testen is een must voor deugdelijke software die niet stuk gaat;
- Er is kennis en ervaring nodig van goede testers om scenario’s te bedenken, te onderzoeken en te testen;
- Testen begint al vroeg, bij de ontwikkeling van code, niet pas aan het eind, als de deadline morgen is;
- Testen zorgt voor vertrouwen in je product, bij jezelf als producteigenaar en je mensen, maar ook bij de eindgebruiker.
De piramide
Met deze manier van automatiseren werk je ook volgend een driehoek, maar dan eentje die rechtop staan, zoals een stevige, degelijke pyramide.
Pyramides zijn 4000 jaar geleden gebouwd en staan nog steeds. Door je testautomatisering als een pyramide in plaats van als ijshoorntje te benaderen, heb je een bestendige testoplossing. Pyramides blijven staan, ijshoortjes breken.
Done is live: Continuous development met Review Applications
Allround developers Rick van der Staaij en Stefan van Essen van Enrise gaan verder met de tweede talk van de avond. Zij leren de bezoekers hoe je veel sneller live kan met je digitale product, door op featureniveau te deployen.
De klassieke werkwijze voor het publiceren van nieuwe features op je site of in je app is OTAP, met minimaal vier servers:
- Een Ontwikkelomgeving, waar developers aan werken
- Een Testomgeving, waar de ontwikkelingen getest worden
- Een Acceptatie-omgeving om als opdrachtgever te controleren en accorderen
- Een Productieomgeving, de plek waarop je site draait, je live-omgeving.
In dit proces bundel je nieuwe features die als ze allemaal ontwikkeld zijn, doorgezet worden naar de volgende fase: het testen. Komen er verbeterwensen uit, dan gaan alle features terug naar de ontwikkelfase.
Het voordeel van deze opzet is, dat je een compleet werkende set aan features publiceert. Het nadeel is dat het langer kan duren, omdat je telkens met de hele set aan vernieuwingen de hele OTAP-straat door moet.
De veerpont
Een OTAP-straat laat zich het best vergelijken met een veerpont die wacht tot alle auto’s, fietsen en voetgangers aan boord zijn, om met een volle lading naar de overkant te varen.
Bij Enrise onderzochten we manier om dat te versnellen. Meer als een snelweg, waarbij elke auto als zelfstandige naar de andere kant kan, alleen of met heel veel tegelijk. Die mogelijkheid en oplossing hebben we uitgewerkt tot Continuous Deployment met Apps. We schreven er eerder al een artikel over, maar nu hebben Rick en Stefan het nader toegelicht tijdens CodeCuisine®Live.
Review Applications
Een snelweg met ‘losse auto’s’ staan gelijk aan losse features voor je digitale product. Het directe voordeel: je kunt op featureniveau nieuwe functionaliteit, een nieuwe look of een bugfix live zetten en je hoeft dus niet meer te wachten tot alle features gereed zijn.
Het werkt als volgt: Als een ontwikkelaar een nieuwe of verbeterde feature heeft gemaakt en oplevert, wordt er een Review Application live gezet. Dit houdt in dat er een nieuwe omgeving automatisch wordt opgetuigd, met de actuele productieomgeving inclusief de nieuwe feature. Doordat het allemaal cloudgebaseerd is, krijgt elke Review Application een eigen url die je naar de acceptant (product owner, klant of andere) kunt sturen.
Voor de Review Application worden geautomatiseerde tests uitgevoerd, maar hier kan ook direct al door een tester en de acceptant worden getest of alles naar wens is. Slaagt het testproces en accepteert de opdrachtgever, dan kan de nieuwe feature direct naar de live-omgeving, zonder dat het hoeft te wachten op alle andere features.
Elke organisatie die snel wil reageren op wijzigingen in de markt krijgt met Continuous Deployment een methode om dit daadwerkelijk te kunnen doen. Dankzij de Review Applications is het veel eenvoudiger om snel nieuwe functionaliteit op te leveren.
Hoe garandeer je dat het werkt?
Als je features los van elkaar ontwikkelt, test en publiceert, is het uiteraard wel van belang dat de features onderling samenwerken. Een Review Application is daarom een keten, een zogeheten pipeline. Daarin wordt eerst de geleverde code automatisch getest. Vervolgens wordt de container gebouwd met alle functionaliteit, gebaseerd op de huidige website of app die in de productieomgeving draait. De container wordt op de hostingomgeving geplaatst, waardoor het voor iedere stakeholder met een url beschikbaar is voor het testen. Is de nieuwe functionaliteit eenmaal live, dan worden alle containers met features die nog niet geaccepteerd zijn geüpdatet naar de meest recente live-omgeving. Zo blijf je er continu voor zorgen dat bestaande en nieuwe features blijven werken.
Gloednieuw
Bij Enrise werken we al enige tijd met Continuous Deployment en Review Applications en geloven dat ze veel voor ons gaan betekenen in de toekomst. Onze klanten hebben er directe voordelen van:
- Een razendsnelle time-to-market;
- Je kunt continu bijsturen en prioriteiten bepalen;
- de zekerheid dat je met werkende versies live gaat;
- Snel inspelen op feedback en verbetering;
- En hotfixes zijn verleden tijd (waarbij je voorheen buiten de OTAP-straat om op productieomgeving een bug fixt), want je kunt razendsnel reparaties en verbeteringen door de pipeline halen.
Stof tot nadenken
De bomvolle editie van CodeCuisine®Live heeft met het onderwerp Automation voor bijna iedereen stof tot nadenken gegeven. We merkten dat aan de vragen en complimenten tijdens het walking diner. Logisch, want het automatiseren van test- en ontwikkelprocessen gaat de komende jaren zoveel verbeteren in de digitale setup van je organisatie, dat je daar vandaag al meer van wilt weten. Bel Erwin Schoonderbeek van Enrise op 088-5553300 voor nadere toelichting en mogelijkheden van automation voor jouw bedrijf.
