Auteur: Fatih Topcuoglu ● fatih.topcuoglu@pancompany.com
Redactie: Eric Spaargaren
Veel organisaties die aan modulair opgebouwde producten werken worstelen vaak met het kwaliteitsvraagstuk. Spotify, NetFlix en Bol.com zijn typische voorbeelden van modulair opgebouwde producten. Alhoewel de klantbeleving gebaseerd is op één product, is deze vaak te ontleden in kleinere technische componenten. Doorgaans ontwikkeld en beheerd door verschillende teams. Teams die volgens eigen tijdslijnen in Sprints (cycli van 2 weken) werk verzetten.
Achter een voor de gebruiker vanzelfsprekend product schuilt veelal een complexe architectuur. Een model met technische componenten die met elkaar gekoppeld zijn en onderling afhankelijk zijn. Daarbij kan het zijn dat er gebruik gemaakt wordt van externe componenten zoals ‘Ideal’. Hierdoor kan de complexiteit en afhankelijkheid toenemen, je krijgt namelijk te maken met externe organisaties. Ook dient men rekening te houden met de Android-, iOS- en browserplatformen waarop het product moet gaan draaien. Een update aan één van deze platformen kunnen nieuwe bugs introduceren of in het ergste geval de applicatie onbruikbaar maken.
In zo’n complexe- en dynamische omgeving is het een uitdaging om kwalitatieve producten op te leveren. Een andere uitdaging is om deze kwaliteit op de een of andere manier te borgen. Kwaliteit is een relatief begrip en wordt voornamelijk bepaald door de beleving van de eindgebruiker. Denk dus als een eindgebruiker bij de inrichting van je kwaliteitsvraagstuk. Door een fout in je applicatie of soms door onlogische ‘user-flows’ kun je gebruikers kwijtraken. Het streven moet niet alleen een bug vrije applicatie zijn, de gebruikerservaring dient dus ook een zware weging te hebben. Daarnaast is het belangrijk dat het begrip kwaliteit organisatie breed gedragen wordt en niet alleen een uitgangspunt is voor de afzonderlijke teams. Want een product is pas af als het in zijn totaliteit naadloos functioneert.
Veel uitdagingen en hobbels dus! Hoe zou je als organisatie dan invulling kunnen geven aan het kwaliteitsvraagstuk?
Een aanpak zou kunnen zijn om het principe van ‘contract-based-testing’ te gebruiken. Hierbij stel je alle interne- en externe teams verantwoordelijk voor de werking van het eindproduct. Dit houdt in dat er zodra er een wijziging aan een component wordt doorgevoerd het wijzigende team verantwoordelijk is voor het eindresultaat. Bij dit principe dient er altijd een recente en complete testomgeving en/of een mobiele test applicatie beschikbaar te zijn. De teams kunnen dan zelf het eindproduct testen op de eigen wijzigingen.
Een risico bij deze aanpak is de integratie van de meest recente aanpassingen. Stel dat twee teams op hetzelfde moment aanpassingen doorvoeren, testen en accorderen. De samenkomst van deze aanpassingen zijn nooit getest, dit kan dus nog regressie opleveren.
Een andere aanpak zou kunnen zijn om integratie testers in te zetten op de werking van het eindproduct. Hiermee verschuif je de kwaliteitscontrole (Quality Control) naar de teams zelf en de kwaliteitsverzekering (Quality Assurance) wordt een integratie aanpak over alle teams heen. Een uitdaging bij deze aanpak is dat deze testers op de hoogte moeten zijn van alle ontwikkelingen binnen en buiten de organisatie. Zij dienen dan ook in zekere mate betrokken te zijn bij alle teams.
Een goed hulpmiddel om de kwaliteit te borgen is het automatiseren van repetitieve teststappen. Dit verkleint de doorlooptijd van het testen en vermindert de kans op menselijke fouten. Dit kan zowel op ‘unit’ – als integratievlak, hoe hoger de integrale testdekking des te kleiner de kans op bugs tussen de modules/componenten. Om de integrale testen niet te laten verdwijnen in een grijs gebied dient zowel de opzet als onderhoud een joint-effort te zijn van alle betrokken teams.
Uiteraard hoeft de ene procesmatige- of technische aanpak de andere niet uit te sluiten. Belangrijker is dat kwaliteit een gedragen principe is voor alle teams, iedereen dient zich verantwoordelijk te voelen voor de kwaliteit van het eindproduct.