Hallo lezers, welkom! Dit artikel maakt deel uit van de Z to A Pulse: Report spotlight, waarin we onze gedachten publiceren over de bevindingen van gerenommeerde namen zoals: World Quality Report, Gartner, Forrester etc.. We analyseren hun bevindingen en trends met de hulp van onze engineering leaders en delen vervolgens de inzichten om u te helpen engineering excellence te bereiken. Abonneer u door op de knop hierboven te klikken om de volgende edities te lezen.

In het onderwerp…

Als eigenaar van de productkwaliteit heb je je huiswerk gedaan en budget gekregen voor testautomatisering.

…Nieuwe plug-and-play tools op de markt onderzocht

…het “perfecte” automatiseringsraamwerk gebouwd

…maar nog steeds geen echte voordelen…

Klinkt dat bekend?

Je bent niet alleen!

In het meest recente (2022-23) wereldkwaliteitsrapport staat dat,

We doen al vele jaren onderzoek naar het onderwerp testautomatisering en het is teleurstellend dat organisaties nog steeds worstelen om testautomatisering te laten werken. De resultaten van het onderzoek geven aan dat teams met een volwassen Agile-proces doorgaans meer voordeel halen uit testautomatiseringsactiviteiten.

Het rapport gaat verder en definieert de twee meest voorkomende uitdagingen voor bedrijven op het gebied van testautomatisering als volgt:

Testautomatisering wordt niet altijd op een natuurlijke manier geïntegreerd in het ontwikkelproces, maar wordt georganiseerd als een aparte activiteit, onafhankelijk van de ontwikkeling en het testen zelf.

Teams geven prioriteit aan het selecteren van testautomatiseringstools, maar vergeten een goed testautomatiseringsplan en -strategie te definiëren.

Maak kennis met onze bron:

Saif en Sujatha hebben meer dan 50.000 + uur besteed aan het helpen van engineeringteams om foutloze producten en naadloze gebruikerservaringen te leveren.

Dit is wat ze te vertellen hebben over het onderwerp.

Testautomatisering wordt niet altijd op een natuurlijke manier geïntegreerd in het ontwikkelproces, maar wordt georganiseerd als een aparte activiteit, onafhankelijk van de ontwikkeling en het testen zelf.

Keerthi: Sujatha, dit doet me afvragen of engineeringteams Agile-gedreven SDLC nog niet hebben gerealiseerd?

Sujatha: Er zijn tegenwoordig veel verschillende interpretaties van Agile. Voor sommige teams staat Agile gelijk aan snel dingen gedaan krijgen. Dit kan leiden tot een situatie waarin de testinspanning wordt geminimaliseerd en het team eindigt met een backlog voor testautomatisering.

Testautomatisering wordt meestal geïntroduceerd in een Agile team door een apart team te creëren dat verantwoordelijk is voor het ontwikkelen en onderhouden van de automatiseringsscripts. Dit team werkt parallel aan het ontwikkelingsteam, dat verantwoordelijk is voor het maken van nieuwe functies.

Deze benadering is niet per definitie verkeerd. Op een gegeven moment is testautomatisering nodig en dit is een goede manier om te beginnen. Uiteindelijk moeten de twee teams echter fuseren, en dit is waar er vaak problemen ontstaan.

Als de twee teams gescheiden zijn, werken ze vaak in silo’s en werken ze niet effectief samen. Dit kan leiden tot onsamenhangende inspanningen en een gebrek aan communicatie. Het resultaat is een enorme achterstand in testautomatisering en het team kan de veranderingen in het product misschien niet bijhouden.

Om deze problemen te voorkomen, moeten zowel de ontwikkel- als de testteams samenwerken om de juiste tests te identificeren om te automatiseren, en ze moeten een gemeenschappelijk automatiseringsraamwerk gebruiken. Dit zal ervoor zorgen dat hun testautomatisering effectief is en dat het team de veranderingen in het product kan bijhouden.

Je bent misschien geïnteresseerd in:

Testautomatisering Enigma: Zuci View

Saif: Om mislukkingen in agile transformatie te voorkomen, zou het handig zijn om deze dingen in gedachten te houden -…

1. Agile bewustzijn is het absolute minimumvereiste in de organisatie. Als dit er eenmaal is, is het gemakkelijker om momentum op te bouwen.
2. Ik begin altijd met een matrix in mijn hoofd – wie is verantwoordelijk, wie is aansprakelijk, wie is de adviseur en wie zijn de mensen die op de hoogte moeten worden gehouden. Dit kan dan worden gepubliceerd naar de belanghebbenden, wat een goede gewoonte is.
3. Vervolgens komen de schattingstechnieken aan bod. Agile geeft je verschillende methoden zoals poker, intuïtie, enz. om de inspanningen die voor je liggen in te schatten. Het geeft je ook de flexibiliteit om terug te gaan naar de resource die aan de betreffende sprint werkt om de inschatting van de inspanning te krijgen, en het is belangrijk om hun concurrentievermogen te valideren. Op dit punt kun je bijvoorbeeld de pokermethode voorstellen. De schatting die door de meerderheid van de pokerkaarten aan de overkant van de tafel wordt getoond, wordt in beslag genomen en de middelen moeten in die schattingcategorie werken.
4. Zorg er ten slotte voor dat voor elke sprint de story points, de snelheid van het team en de prioritaire taken worden gepubliceerd aan de belanghebbenden en andere betrokkenen. Dit is zodat iedereen die beschikbaar is in de vergadering een afwijking of ad-hocprioriteit kan bespreken en er wat capaciteit kan worden gereserveerd voor dergelijke taken voordat je verder gaat.

Mensen moeten gaan geloven dat Agile geen one-stop oplossing is voor alle problemen, het zal je helpen om problemen in een vroeg stadium te identificeren zodat je de tijd hebt om ze te corrigeren. Het is dan aan de belanghebbenden om de nodige stappen te ondernemen.

Als je deze problemen ondermijnt en ze laat bestaan zonder ze permanent op te lossen, zul je falen.

Keerthi: Hoe weten we hoe volwassen de agile praktijken van een bedrijf zijn?

Sujatha: Veel teams proberen snel te gaan, maar soms gaan ze uiteindelijk de verkeerde kant op. Dit kan gebeuren wanneer teams zich richten op snelheid ten koste van kwaliteit.

Het is een rode vlag als je je concentreert op het bouwen van nieuwe functies en niet genoeg tijd besteedt aan testen. Dit kan leiden tot kwaliteitsleemtes die je uiteindelijk zullen vertragen.

Het is belangrijk om voor elk proces statistieken op te stellen en deze in de loop van de tijd bij te houden. Dit zal je helpen om je leidende en achterblijvende indicatoren te ontdekken. Als alles er goed uitziet, maar je ziet nog steeds veel P0 P1 defecten, dan is er iets mis.

En dit is waar teams het perspectief van een derde partij willen inbrengen. Een externe QA-consultant kan langskomen om naar je algemene engineering- en releaseprocessen te kijken en aanbevelingen te doen. Ze kunnen je helpen gebieden te identificeren waar je je kwaliteit en snelheid kunt verbeteren.

Hier zijn de volgende gebieden die geanalyseerd kunnen worden:

Hier is een voorbeeldvragenlijst om de QA-volwassenheid van je team te beoordelen.

Beoordelingsvragenlijst:

• Worden de vereisten aan de testers gegeven? Hoe en wanneer?
• Zijn de vereisten voldoende gedetailleerd geformuleerd in het FRD?
• Zijn de vereisten gedocumenteerd met eventuele aannames?
• Neemt QA focal deel aan besprekingen/verduidelijkingen over vereisten met Business Analyst/ Klant/ Ontwikkelaar.
• Worden de vereisten geanalyseerd en begrepen vanuit zowel het systeem- als het bedrijfsperspectief door ontwikkelaar en qa?
• Worden de wijzigingen in de vereisten doorgegeven aan de testers? Hoe en wanneer?
• Traceerbaarheid van vereisten – Is de van de vereisten naar de code traceerbaar? Hoe?
• Hoe worden de vereisten en de reikwijdte gewijzigd? Archief/Tools?
• Wie controleert (keurt goed/weigert) de wijziging van de vereisten? (Soort Change Control Board)
• Is de verandering in vereisten gedetailleerd vastgelegd?
• Hoe vaak wordt een wijziging in de vereisten geaccepteerd zonder de mijlpaal in gevaar te brengen?
• Is er een experimenteel ontwerp beschikbaar om een oorzaak-gevolgrelatie te vinden?
• Is er gedetailleerde documentatie beschikbaar voor functies die op vlaggen zijn gebaseerd?
• Is er documentatie beschikbaar voor het voorbereiden van testgegevens?

Als je de volledige vragenlijst over Testplanning, Testen, Algemene analyse van testmetriek en Automatisering wilt bekijken, klik dan op sales@zucisystems.com of reageer hieronder in dit artikel.

Lees meer: Sujatha brieft – 4 meest cruciale software test metrics uit haar lijst.

Keerthi: Ik denk dat niet veel bedrijven de voordelen van testautomatisering inzien omdat ze volwassen genoeg zijn in hun testpraktijken en onsamenhangende inspanningen leveren. Wanneer weet je dat je org klaar is voor testautomatisering?

Sujatha: Je regressie backlog moet niet te groot zijn of een lange roadmap. Probeer niet alles te automatiseren, maar probeer te automatiseren wat essentieel is voor het bedrijf. Bouw een backlog van regressieautomatisering die in kortere tijd kan worden gerealiseerd en begin vanaf week 1 met het consumeren van de scripts.

Vervolgens moet je langzaam automatisering in het sprintteam brengen, zodat ze kunnen werken aan de huidige user stories en de regressiemastersuite en in-sprint automatisering kunnen bereiken.

Wanneer er een wijzigingsverzoek binnenkomt, controleer dan of er relevante testscripts zijn die moeten worden aangepast. Vind de bedrijfskritische testgevallen en werk ze bij in de master suite.

Voeg het testautomatiseringsteam en het sprintteam samen, zodat het regressieteam continu feedback heeft op het gebied van testdekking, enz. Dit zorgt ervoor dat de regressiesuite up-to-date blijft en dat het team snel regressies kan identificeren en oplossen.

Voor een van onze klanten was het bereiken van in-sprint automatisering een van de doelen en we hielpen bij het opstellen van een stappenplan dat hen geleidelijk hielp bij het bereiken van hun doelen.

1. Het sprintteam van de klant bestond uit een ontwikkelteam + een handmatig testteam
2. Zuci’s testautomatiseringsingenieurs (TA) werden geïntegreerd in het team
3. TA-ingenieurs werkten aan de UAT-automatiseringssuite
4. Ons team sprak met PO en begreep bedrijfskritische testcases die essentieel zijn voor de productietoekenning
5. Ons team pakte de draad weer op en begon te werken aan de backlog van testcases voor automatisering.
6. UAT & Regressie automatisering over een periode van 6 maanden
7. Vervolgens werden we geïntegreerd in N-1 sprintteams
8. Eindelijk N/In-sprint automatisering

Keerthi: Verrassend genoeg vertelt het rapport ons dat niet ROI maar “onderhoudbaarheid” de belangrijkste factor is bij het bepalen van de aanpak van testautomatisering door bedrijven.

Sujatha: Dat is waar. We zien een verschuiving in de gesprekken over testautomatisering naar testonderhoud en testtools. Daar zijn een paar redenen voor. Ten eerste verandert software voortdurend, dus is het belangrijk dat testscripts eenvoudig kunnen worden bijgewerkt om deze wijzigingen te weerspiegelen.

Ten tweede kunnen testscripts na verloop van tijd complex worden, dus is het belangrijk dat ze eenvoudig te begrijpen en te onderhouden zijn. Ten derde kan testautomatisering duur zijn, dus het is belangrijk om er zeker van te zijn dat de investering de moeite waard is.

Hier zijn een paar dingen die organisaties kunnen doen om de onderhoudbaarheid van hun testautomatiseringsscripts te verbeteren:

• Een modulaire benadering van testautomatisering gebruiken
• Goed gedefinieerde naamgevingsconventies gebruiken
• Opmerkingen gebruiken om het doel van elk testscript uit te leggen
• Een versiebeheersysteem gebruiken om wijzigingen in testscripts bij te houden
• Documentatie voor testautomatisering maken

Lees hier meer over best practices voor testonderhoud

Keerthi: Wat zijn volgens jou manieren waarop we samen testen en ontwikkelen kunnen stimuleren?

Sujatha: Het moet meteen vanaf de vereisten beginnen. Bijvoorbeeld, in de eisenfase – ontwikkelaars geven meestal alleen om het tweaken van modules, code of tech stack die binnen hun scope vallen.

Maar wat hier gedaan kan worden is het testteam erbij betrekken en samen met de ontwikkelaars de impact van wijzigingen in vereisten op het testen analyseren en voorzien, testbaarheid in overweging nemen tijdens het ontwerpen, enz.

Testbaarheid – Ontwikkelaars kunnen code schrijven met het oog op testbaarheid door technieken te gebruiken zoals mock objects en unieke identifiers voor UI/visuele componenten. Dit maakt het makkelijker voor testers tijdens automatiseringen en zorgt ervoor dat de software gemakkelijker te testen is.

Ontwikkelaars kunnen complexe taken opsplitsen in kleinere brokken die gemakkelijker te testen zijn. De architectuur van een applicatie kan bijvoorbeeld zo worden ontworpen dat testen eenvoudig wordt en er niet meerdere stappen nodig zijn.

Saif:

Ik geloof dat kwaliteit een gedeelde verantwoordelijkheid is, niet alleen van de tester.

In veel teams sturen ontwikkelaars alleen maar rotzooi naar het testteam en nemen ze geen verantwoordelijkheid voor hun werk. Dit druist volledig in tegen de geest van Agile, want in Agile faalt het hele team als één team faalt.

Ontwikkelaars moeten hun code valideren terwijl ze die schrijven. Bij het definiëren van user stories moet het hele team betrokken zijn, inclusief ontwikkelaars, handmatige testers en automatiseringstesters. Dit zorgt ervoor dat iedereen inspraak heeft in de definitie van het verhaal en dat de criteria voor “klaar” duidelijk zijn. Als testautomatisering niet wordt meegenomen in de “klaar”-criteria, dan zal de regressie backlog zich opstapelen en het team een paar jaar later weer lastigvallen.

We moeten teams aanmoedigen en belonen waar ontwikkelaars en testers samenwerken. Dit zal teams helpen om kwaliteit als een gedeelde verantwoordelijkheid te zien. In mijn ervaring heb ik gezien dat dit de magie doet en het zal er ook voor zorgen dat de software met minder bugs wordt uitgebracht en dat het team sneller waarde aan de klant kan leveren.

Teams geven prioriteit aan het selecteren van testautomatiseringstools, maar vergeten een goed testautomatiseringsplan en -strategie te definiëren.

Keerthi: Sujatha, betekent het bovenstaande: Voor veel teams is een plan gewoon een formaliteit! Hoe beoordelen we vandaag het “testplan” en geven we het groene licht?

Sujatha: Traditioneel zijn testplannen lange, breedsprakige documenten. Volgens mij kan een testplan bevatten – wat gaan we testen voor deze release op basis van de user stories en hun impact. Met de komst van testmanagementtools kunnen testplannen nu echter beknopt en licht zijn.

Details zoals – wat zijn de geplande testtypes, wat zijn de testgevallen en wanneer moeten ze worden uitgevoerd en wat moet aan wie worden toegewezen, kunnen worden opgeslagen in een testmanagementtool zoals TestRail, Xray, Zephyr enz. die zijn geïntegreerd in JIRA, zodat teams alles kunnen bijhouden en eventuele wijzigingen kunnen aanpassen. Dergelijke integraties geven analytisch inzicht in de eerdere releases, zodat het team meer kan leren over de defecttrends en dienovereenkomstig kan plannen.

Keerthi: Heb je tips voor het kiezen van testautomatiseringstools? Ik denk ook dat het succes van testautomatisering vooral zal afhangen van de manier waarop mensen ermee omgaan en niet van toolsets. Wat vinden jullie ervan?

Sujatha: Dat klopt. Testautomatiseringstools die synchroniseren met de ontwikkelomgeving zijn erg handig. Als de webapp bijvoorbeeld is ontwikkeld in C sharp, is het gunstig om testautomatiseringscode in C sharp te schrijven omdat de logica eenvoudig te begrijpen is en als we vastlopen, staan de ontwikkelaars klaar om te helpen.

Je krijgt ook de steun van het gereedschapsecosysteem omdat we niets vreemds inbrengen. Nogmaals, het is geen must-have maar een nice-to-have aspect van het kiezen van automatiseringstools. Soms is het nodig om over te stappen op een andere technologiestack omdat de huidige niet volwassen genoeg is en er onvoldoende vaardigheden beschikbaar zijn om bepaalde dingen te bereiken.

Maar nogmaals, het succes van testautomatisering hangt niet alleen af van toolsets. Je moet duidelijk zijn over je sollicitatie en een strategie bepalen:

• Wat automatiseren we?
• Hoe automatiseren we?
• Wat automatiseren op welk niveau (UI, API, services)?
• Identificeren waar het is mislukt en begrijpen waarom
• De juiste toolsets en mensen identificeren

Succesvolle testautomatiseringstrajecten gaan niet over tools en processen, maar over mensen en hun aanpak om problemen op te lossen. Het maakt de weg vrij voor al het andere – Vasudevan Swaminathan, Oprichter & CEO, Zuci Systems

De commerciële tools kunnen veel voordelen beloven, maar als je niet weet wat het “Waarom” is achter wat je doet, zul je vroeg of laat falen.

Hier volgen enkele laatste gedachten uit het rapport over: Waar moeten organisaties zich op richten?

• Eerder samenwerken met experts op het gebied van kwaliteitsautomatisering.
• Automatisering begint al bij het maken van de requirements; bouw een automation-first benadering in de requirements en stories.
• Zorg dat je het eens bent over de automatiseringsvereisten voordat je begint met automatiseren.
• Focus op wat de beste voordelen oplevert voor klanten en het bedrijf in plaats van op het rechtvaardigen van de ROI. Herzie je tooling en frameworks regelmatig.
• Plan een stappenplan voor ten minste de komende drie jaar.
• Eén hulpmiddel doet niet alles. Kies het beste gereedschap voor de klus. Probeer niet om één gereedschap alles te laten doen.
• Investeer in mensen.
• Stop met het najagen van eenhoorns en werk met de mensen die je hebt – zij kennen je bedrijf

Vraag voor jou:

Hoe volwassen zijn jullie testautomatiseringspraktijken?

1. 30%
2. 30-60%
3. 60-100%

Bedankt voor het lezen! We kijken er naar uit om in onze toekomstige edities dieper in te gaan op de inzichten uit het World Quality Report.

Als je onze inhoud leuk vindt, laat ons dan je steun zien door –
je hier in te schrijven voor onze driemaandelijkse nieuwsbrief, Sound bytes.
en door dit artikel te delen met je team. Uw steun betekent de wereld voor ons!