Is het kennen van application architecture en code als QA engineer een blessing of een curse?

Vraagstuk 1: Is het kennen van application architecture en code als QA engineer een blessing of een curse?

Vandaag wordt er van QA Engineers steeds vaker verwacht dat je vanuit een development standpunt kan redeneren. Maar tot welk niveau is dit opportuun? Volgens Matthias laat enerzijds kennis van code je als QA engineer toe om meer geïnformeerde beslissingen te maken wanneer je moet uitzoeken wat er juist getest moet worden. Je kan beter begrijpen welke delen van de applicatie mogelijks wel of geen impact hebben gehad door changes en nieuwe features. Dit kan zeer tijdbesparend werken. Je bent hierdoor namelijk in staat om delen van de applicatie of testsets die niet geïmpacteerd zijn efficiënter te identificeren en onverwachte bugs beter te lokaliseren. Zeker bij een grote applicatie of veel legacy code kan dit van groot belang zijn. Ook in een agile omgeving waarbij testing dikwijls alvorens de development fase betrokken wordt, is affiniteit met code opportuun. Zo kunnen testers voor de start van de ontwikkeling al mogelijke bugs of logica fouten detecteren.

Anderzijds kan kennis van code ook als een curse werken. Er is namelijk een continu aanwezige bias die tot uiting kan komen in elke beslissing die je neemt. Je voorkennis kan maken dat je minder onbevooroordeeld testings uitvoert. Het kan je beeld vertekenen bij zowel het ontwikkelen van geautomatiseerde testen als het handmatig testen van nieuwe features. Deze vooringenomenheid zal er bijgevolg wellicht net voor zorgen dat onbewust bijvoorbeeld bugs gemist worden of triviale scenario’s overgeslagen.

Eindstand: Kennis van code kan zowel een blessing als een curse zijn. Het is vooral belangrijk om je bewust te zijn van de bias die mogelijks aanwezig is en dat je hiervoor voldoende vangnetten voorziet. Zo kan je bij je eigen opgestelde testen een extra controle door een andere tester laten uitvoeren of andere bestaande toolings in de testomgeving integreren. Een veelzijdig team dat in verschillende mate kennis heeft van code kan leiden tot een mooie allesomvattende oplossing die zowel tijdbesparende elementen heeft alsook voldoende gedachtewisselingen om de bias te compenseren.

Vraagstuk 2: Wat is de best-practice benadering in de samenwerking tussen QA en DEV?

Bij ICT-projecten bestaan er verschillende methoden en structuren die worden toegepast bij de ontwikkeling van software. In sommige bedrijven worden development en testing strikt gescheiden. Dit heeft als gevolg dat testers weinig zicht hebben op de code, net zoals developers minder in contact komen met de testings die worden opgezet. Hoewel ze samen een team vormen en in dezelfde applicatie werken, zijn ze niet op de hoogte van wat er aan iedere kant gebeurt. Dit komt zeker tot uiting in een traditionelere waterfall werkmethode waarbij er sequentieel pas een nieuwe fase ingegaan wordt zodra de vorige fase is afgerond. Hierbij werken development en testing zelden op eenzelfde moment aan hetzelfde topic.

Matthias is eerder liefhebber van de agile projectmethode aangezien daarbij de splitsing tussen QA en DEV lichtelijk verdwijnt en dit een meer actieve samenwerking teweegbrengt. Matthias en zijn team van testers trachten op hun project zo agile mogelijk te werken. Hiervoor kiezen ze voor de ‘shift-left’ methodologie. Shift-left testing is een methode waarbij software testers al vroeger in het proces betrokken worden en gaan kijken waar de mogelijke pitfalls zitten alvorens development van start gaat. Shift-left slaat dus letterlijk op het naar links verplaatsen in de projecttijdlijn. Samen met agile is dit een opkomende manier van werken. Het vraagt meer engagement van een tester, maar heeft tot gevolg dat je meer kennis hebt over de applicatie en dat heeft op verschillende vlakken voordelen. De hele context van de applicatie kennen, toont zijn nut in het begrijpen van features en complexe delen van de implementatie. Bovendien maakt dit het makkelijker om samen met developers na te denken over mogelijke oplossingen voor issues die reeds voor de aanvang van development gevonden werden. Zo is QA beter op de hoogte van de denkwijze van development en worden misinterpretaties al in een vroege fase weggewerkt.

Vraagstuk 3: Kan je de doorlooptijd steevast verkorten dankzij test automation?

Op vlak van test automation tracht Matthias zoveel mogelijk te automatiseren waar dat kan. Test automation zorgt namelijk niet enkel voor een snellere doorlooptijd, maar ook voor een continu kwaliteitscontrole. Door zoveel mogelijk manuele testen te automatiseren, krijg je testsets die manuele acties sneller en op regelmatige basis kunnen uitvoeren. Indien een mogelijke impact vergeten wordt, zullen goed uitgewerkte automatische testen deze impact vaak oppikken. Van zodra je niet met geautomatiseerde testen aan de slag gaat, dreig je echter achter te blijven met veel legacy code. Hierdoor is een testing team genoodzaakt om eindeloos bezig te zijn met het moderniseren en verbeteren van reeds aanwezige features en procescontrole methoden. De grootste reden dat bedrijven niet kiezen voor automatisatie is dat het initieel tijd kost om dit op te zetten. Deze tijdsinvestering is niet altijd mogelijk voor bepaalde projecten. Daarnaast is er natuurlijk ook de nodige kennis nodig om testautomatisering op te zetten. Maar eens je de investering doet heb je op lange termijn meer en meer voordeel van het automatiseren. Zeker bij grote applicaties heeft test automation absoluut een grote positieve impact.

De voordelen drijven Matthias om steevast te kijken naar test automation mogelijkheden. Hiervoor heeft hij geprefereerde tools. Voor Angular en AngularJS applicaties geeft hij de voorkeur aan het framework Protactor. Hij is ook erg tevreden van Playwright, een end-to-end testing tool dat gebruik maakt van Selenium. Dit is een oplossing van Microsoft dat development georiënteerd is, wat ondanks de verdeelde meningen volgens Matthias gunstig is.

Vraagstuk 4: Is een technische achtergrond vereist voor een carrière als software testing engineer?

In Matthias zijn situatie was hij als student geïnteresseerd in wetenschappen en studeerde hij oorspronkelijk af binnen Chemie. Echter had hij ook steeds affiniteit met programmeren en koesterde hij een statistische interesse. Om deze reden koos hij na Chemie voor ‘Statistical Data Science’. Na zijn studies was het duidelijk dat hij energie haalde uit een combinatie van code schrijven en uitzoeken hoe iets werkt en hoe je dit kan verbeteren.

Volgens Matthias kan het zeker helpen als je wat kennis hebt van coderen, al is dit in zijn ogen geen vereiste. “Een gevarieerd team met verschillende invalshoeken heeft ongetwijfeld een positieve invloed op applicaties.” concludeert Matthias.