Werken in een Agile-omgeving is geen garantie voor een ‘shift left’. Als je de rol van Software Tester in een team aanneemt, kom je na een tijdje in een routine terecht. Je reageert op tickets in de kolom ‘Klaar voor test’, hoopt dat de Acceptatiecriteria duidelijk genoeg zijn zodat je je Test Cases dienovereenkomstig kunt aanpassen, plant de verkennende tests, denkt na over welke functies moeten worden toegevoegd aan je Test Automation-script… Dus eigenlijk werk je aan de ‘rechterkant’ van het scrum-bord.

Misschien is het tijd om de ‘shift left’ praktijken toe te passen.

Neem de tijd om na te denken over het proces. Zijn er stappen die genomen kunnen worden om het ontwikkelproces efficiënter te maken? Wat kan QA doen om het proces te versnellen, monitoring te bieden, versiebeheer te verzorgen, documentatieafspraken te maken, teamoverschrijdende communicatie te optimaliseren? Een goed startpunt zou Team Retrospective kunnen zijn – wat dacht je van het nemen van ownership over een van de actiepunten die als resultaat naar voren komen, of zelfs schijnbaar minder belangrijke maar terugkerende kwesties op post-it briefjes? Zijn er frustraties binnen het team die QA kan oplossen (of in ieder geval kan proberen op te lossen)?

Probeer ontwikkelaars te overtuigen van het belang van het daadwerkelijk testen van hun code. Kunnen ze het gecompileerde resultaat bekijken voordat ze de code verzenden? Stel voor om tools te gebruiken die de Unit Tests analyseren, het code review proces ondersteunen, pair programming sessies… Dit zorgt voor een hogere kwaliteit van de code voordat het ticket in Test komt.

Boehm’s Curve stelt in wezen dat het duurder is om bugs later in het proces op te lossen. Het voorkomen van bugs is een van de resultaten van ‘shift left’. De nieuwe functie wordt geanalyseerd door de UX of analisten, ontwerpers leveren de ontwerpprototypes. Op dit punt kan QA al beginnen met abstract verkennend testen en kritische vragen stellen, zoals “levert deze functie de verwachte waarde voor de gebruiker?”, “lost deze functie een bestaand probleem op?”, “draagt de functie bij aan de complexiteit van het hele systeem?” …

De belangrijke stap is om van ‘reactief’ naar ‘proactief’ te gaan. Praat met teamleden, andere QA collega’s, teamleiders… over de huidige uitdagingen. Deelnemen aan vergaderingen eerder in het proces, waar vereisten, ontwerp, verfijningen… worden besproken, is een goede gewoonte. Het is niet voldoende om alleen aanwezig te zijn bij deze vergaderingen, maar ook om deel te nemen aan discussies. Dit is waarschijnlijk gemakkelijker voor ervaren Software Testers, maar toch de moeite waard om in de praktijk te brengen.

Blog: Darko Grabovac, M2Q