Veel van ons kennen ‘Quality Street’ als de gekleurde doos vol chocolaatjes en karamelsnoepjes. Vroeger werd dit gezien als een luxe snoeptrommel en we aten deze niet in één keer helemaal leeg, omdat het een speciale traktatie was. Nu vindt de consument deze snoepjes helemaal niet meer ‘luxe’. Sterker nog, ze zijn bijna niet meer te vinden. Ons beeld van luxe is in de afgelopen jaren behoorlijk veranderd.
Hetzelfde geldt voor testing en experts op dit gebied. Zij waren vroeger een high-level team of een aparte afdeling waar tegenop werd gekeken. Deze groep van testers konden een systeem maken of breken met hun ‘raadselachtige’ manier van werken en maakten het werken voor programmeurs soms erg moeilijk. Testing is nu veel meer geïntegreerd binnen veel organisaties, maar of het al gemeengoed is?
De manier van werken die wij nu toepassen is er volledig op gericht om de twee disciplines zo dicht mogelijk bij elkaar te brengen. Deze methode noemen we ‘Quality Street’ om aan te geven dat het invoeren en vasthouden van hoge kwaliteit een doorlopend traject is en geen losse activiteit of fase in een ontwikkelproject.
Geschiedenis van softwareontwikkeling
Een aantal jaar geleden werd software nog ontwikkeld volgens het watervalmodel: iedere activiteit werd gefaseerd ingevoerd. Elke fase moest worden afgerond, voordat een volgende van start kon gaan. Dat betekende dat alle systeemeisen afgerond moesten zijn, voordat de ontwerpers aan de slag konden gaan en testing kon pas beginnen als de implementatie was voltooid.
Binnen deze methode was testing nog steeds exclusief. Testers waren een aparte groep medewerkers die soms zelfs vanuit een andere locatie werkten. Feedback over de kwaliteit van software werd meestal pas laat gegeven en analyses van fouten die werden gevonden namen veel tijd in beslag.
Verbeteringen in dit proces kwamen later met methodes zoals Rational unified process (Rup) en ‘incremental development’. Er werd geïnvesteerd om software in kortere termijnen op te leveren. De benodigde tijd voor iedere fase werd steeds korter, maar was nog steeds niet perfect. Systeemeisen werden veelal vooraf afgerond en bij oplevering waren deze soms al weer verouderd. Testing werd nog steeds in afzonderlijke fases gedaan en hierdoor werden fouten vaak te laat ontdekt. Testing was het vangnet waarin alle fouten, die eerder in het proces werden gemaakt, opgelost moesten worden.
De introductie van feedback-rondes tussen de ontwikkelfases en testing – alsook het proberen om software stapsgewijs op te leveren – bracht een aantal verbeteringen met zich mee. Met de toenemende grootte van de benodigde software en het aantal versies en updates die vandaag de dag nodig zijn, moet de manier van werken veranderen. Dit heeft ook invloed op testing, met name op het feit dat er niet langer tijd is om te stoppen met ontwikkelen omdat er nog getest moet worden. Software moet worden ontwikkeld, geüpdatet en geleverd op korte termijn en moet meteen inzetbaar zijn voor de eindgebruiker. Gewenste veranderingen moeten snel worden gemaakt, het liefst binnen een paar weken in plaats van maanden.
Vandaag: gewoonste zaak van de wereld?
Momenteel wordt tijdens projecten veel met Agile en Scrum gewerkt. Binnen korte en intensieve ontwikkelprocessen van een aantal weken wordt software opgeleverd. Bij deze methode wordt tegelijkertijd ontwikkeld en getest. Om de ontwikkeling bij te benen en werkende software te leveren aan het einde van iedere fase moeten veel tests worden geautomatiseerd.
Dit is waar Quality Street in beeld komt. Voor alle duidelijkheid is dit niet de snoeptrommel waar in het begin van het artikel over wordt gesproken, maar een ontwikkel-framework. Binnen dit framework wordt niet alleen de software snel gebouwd, maar worden ook de geautomatiseerde tests uitgevoerd. De resultaten van alle activiteiten binnen Quality Street zijn geautomatiseerd, waardoor altijd in één oogopslag inzicht is in de voortgang en kwaliteit van het proces.
Om Quality Street volledig op te zetten en te gebruiken moeten testers voldoende ontwikkelkennis hebben om tests te automatiseren en deze tests in het framework te plaatsen. Dit omvat niet alleen het functioneel testen van software, maar ook tests om een nieuw softwarepakket – een combinatie van geüpdatete software en de andere software-onderdelen of de systemen waar de software op draait – te ontwikkelen. Een logische volgende stap binnen Quality Street is om het softwarepakket daarna opnieuw onder de loep te nemen, het uit te rollen binnen een applicatieomgeving en dan opnieuw tests te doen.
Het inzetten van Quality Street brengt ontwikkelaars en testers dichter bij elkaar op het gebied van hun dagelijkse werkzaamheden. Betekent het dat we dan geen aparte testing-discipline meer nodig hebben? Op termijn misschien niet, maar op het moment zien we nog duidelijk een verschil in de manier waarop testers naar een systeem kijken ten opzichte van ontwikkelaars. Dit moet niet worden onderschat. Een ontwikkelaar wil meestal bewijzen dat de software werkt, terwijl een tester juist de software wil testen op fouten om risico’s zichtbaar te maken voor de eindgebruiker. Daarnaast zijn er altijd een aantal tests – hoewel wellicht maar weinig – die handmatig moeten worden uitgevoerd. Ten slotte kan de interpretatie van testresultaten het beste aan testers worden overgelaten. Op die manier zorg je ervoor dat fout-positieven (of negatieven) worden geanalyseerd en dat corresponderende tests worden aangepast.
Morgen: eisen aan testers
Het gebruik van de Agile-methode wil niet zeggen dat we er al zijn. Zelfs wanneer testing een geïntegreerd onderdeel is van het ontwikkelproces, dan nog zijn we niet klaar met testen. De volgende uitdaging is om de Agile manier van werken uit te breiden naar de high-level ontwikkelgroepen, omdat er meestal meerdere teams aan hetzelfde systeem werken. Aparte features of producten worden in verschillende teams gemaakt en deze teams kunnen ook op andere locaties werken.
Het Scaled Agile Framework (SAFe) zorgt ervoor dat de teams (tussen)opleveringen met elkaar afstemmen en beslissingen worden genomen over de te leveren functionaliteit. Ook worden binnen dit framework onderlinge afspraken gemaakt. Maar werkt het systeem dat uit de verschillende componenten bestaat wel? Geschiedenis leert ons dat dat vaak niet het geval is. Hier ligt dus nog een taak voor de tester: het integreren en testen van verschillende componenten in een groter systeem. Dit onderdeel wordt nog steeds onder de loep genomen. Veel projecten en organisaties zoeken naar de juiste manier om dit te doen, maar hiervoor is nog geen ‘standaard’ manier van werken ontwikkeld.
Conclusie
De rol van de tester is zeker niet achterhaald en waarschijnlijk gaat dat ook niet gebeuren. Agile- en SAFe-teams houden zich bezig met het breed integreren van verschillende perspectieven, maar dat betekent niet dat een ontwikkelaar een tester wordt of andersom. Ook zijn niet alle software-domeinen toepasbaar. In gereguleerde omgevingen zijn Agile of Scrum soms niet eens de beste ontwikkelmodellen.
Wat wel duidelijk is, is dat de rol van de tester en ook die van ontwikkelaar snel verandert. Testers moeten nauwer samenwerken met ontwikkelaars en ze moeten werken aan hun expertise in programmering en integratie. Ontwikkelaars moeten goed begrijpen dat ze verantwoordelijk zijn voor de kwaliteit van hun code in plaats van dit over te laten aan de testers. Alleen dan kan software op tijd en kwalitatief goed worden geleverd. De tijd van ‘luxe’ testers ligt achter ons.
Stephanie van Dijck, test manager bij Altran
