Augmented Testing

U heeft een geolied CI/CD proces voor uw software ontwikkeling, denkt u. Hoe kan het dan dat die beoogde versnelling van releases toch nog hapert?

Vraagt u zich bijvoorbeeld weleens af:

  • Waarom testen, ondanks geautomatiseerd, toch een belemmering blijft in het snel(ler) naar productie brengen van een build?
  • Of alle geautomatiseerde testen die gemaakt worden voor elke release even relevant zijn en altijd gedraaid moeten worden?
  • Of u met minder soorten testen mogelijk ook genoeg dekking kan halen om in productie te gaan?
  • Hoe u overzicht houdt over de complete testset van verschillende teams, zodat er geen dubbele testen ontstaan of juist zaken gemist worden?
  • Waar in de toekomst nog versnelling te behalen is in de Continuous Deployment pipeline?

Continuous Integration

In een Agile werkomgeving is wendbaarheid erg belangrijk. Continue aan kunnen passen aan nieuwe inzichten en korte feedbackcycli zijn essentieel om software op te kunnen leveren, die het beste aansluit aan de wens van de opdrachtgever. Een belangrijk onderdeel bij het realiseren van deze wendbaarheid is Continuous Integration (CI) en Continuous Deployment (CD). Het sneller en vaker releasen van software wordt steeds belangrijker. Kritiek onderdeel van dit proces is de inrichting van de Continuous Deployment pipeline.

De pipeline en testen

Snelheid is belangrijker geworden, maar dit betekent niet dat dit ten koste moet gaan van de kwaliteit. De geautomatiseerde testen die draaien binnen de pipeline moeten waarborgen dat er geen software in productie komt die niet voldoet aan de gestelde eisen. Testen is in het Continuous Deployment paradigma dus nog altijd essentieel. Maar zijn alle testen die gemaakt worden voor elke wijziging even relevant? Unit testen, systeemtesten, integratietesten, ketentesten, acceptatietesten, security testen, performance testen… en veelal allemaal geautomatiseerd. Heel veel testen die vaak gemaakt worden door verschillende mensen in verschillende teams. Hoe lang duurt het om al deze testen te draaien? Hoe lang mag het duren? Bewijst die ene acceptatietest niet in de praktijk exact hetzelfde als die andere systeemtest?

Hét antwoord op het gevecht tussen snelheid en kwaliteit

De tijd die nodig is om van een ‘check-in’ tot een ‘deployment’ in productie te komen mag niet te lang zijn. Bij een productie-issue moet het team in staat zijn om snel een fix te kunnen uitrollen zonder het normale release proces te hoeven omzeilen. Dit ‘normale’ proces moet dus zowel snel zijn als kwaliteit waarborgen.

Zorgen voor een zo snel mogelijke testset, die zoveel mogelijk relevante requirements dekt is essentieel. Door inzet van ‘Augmented Testing’ van Praegus wordt de bestaande testset doorlopend geoptimaliseerd en inzichtelijk gemaakt door – geautomatiseerd – te prioriteren op basis van onder andere:

  • Testen met overlappende dekking.
  • Testen die lang duren en/of altijd slagen.
  • Welke testen, bij welke wijziging als eerste uitgevoerd zouden moeten worden.

Met deze inzichten kan de delivery pipeline versneld worden; fouten worden eerder gevonden, software kan sneller naar productie en het onderhoud op geautomatiseerde testen wordt geoptimaliseerd omdat dubbele testen uitgezet worden. Dit inzicht helpt in het gesprek over de inrichting en de dekking van de testset met objectieve informatie. Daarmee wordt uw Continuous Delivery proces aanzienlijk verbeterd en krijgt u de gewenste releaseversnelling wél voor elkaar!

Wilt u meer lezen? Klik dan door naar onze blogs over dit onderwerp van 17 en 24 mei en 1 juni 2018 op onze blogpagina.

Meer weten? Neem contact met ons op