Producttesten (met Erin Hess van Crema)

Michael Luchen

Er wordt zoveel tijd besteed aan praten over het bouwen van producten, maar hoe zit het met het testen van producten? Welke benaderingen, houdingen en disciplines zijn nodig om ervoor te zorgen dat een product grondig wordt getest, zodat het de gebruikers ondersteunt voor wie het is gebouwd? Vandaag hebben we een expert op het gebied van testengineering te gast om samen diep in te gaan op wat deze cruciale rol binnen een productteam definieert, hoe testingenieurs samenwerken met productmanagers en waarom zij misschien wel een belangrijke voorvechter van empathie binnen een productteam zijn. Blijf luisteren.

Dit is de podcast van The CPO Club — de stemmen van de community die het draaiboek voor productmanagement, ontwikkeling en strategie schrijft. We worden gesponsord door Crema, een bureau voor digitale producten dat individuen en bedrijven helpt floreren door creativiteit, technologie en cultuur. Lees meer op crema.us. Blijf luisteren voor praktische, authentieke inzichten die je helpen succesvol te zijn in de wereld van productmanagement.

Hallo allemaal. Ik ben ontzettend blij dat ik Erin Hess vandaag in de show mag verwelkomen. Ik heb persoonlijk het genoegen gehad Erin te leren kennen toen zij onlangs haar talenten naar ons team bij Crema bracht als senior testingenieur. Erin beschikt over een unieke combinatie van creatieve en technische talenten, opgebouwd tijdens meer dan twaalf jaar ervaring in verschillende functies binnen softwareontwikkeling en engineering.

Ze begon haar carrière als medewerker klantenservice voordat ze een autodidactische programmeur werd die een liefde voor softwaretesten ontwikkelde. Als gebruikersvoorvechter in hart en nieren behoren empathie, visualisatie en het anticiperen op gedrag en communicatie tot Erins belangrijkste sterke punten. Erin maakt graag proceskaarten en stelt zich voor waar knelpunten kunnen ontstaan. Door in de schoenen van anderen te stappen, problemen vanuit meerdere invalshoeken te bekijken en de langetermijngevolgen en voordelen van de acties van vandaag te zien, heeft Erin het verschil kunnen maken voor elk team en elk product waar ze zich bij aansluit.

Erin helpt organisaties ook bij het invoeren en toepassen van inclusieve ontwerppraktijken door bewustwording te creëren en te verspreiden over universele bruikbaarheidsbarrières. Ze zet zich in voor toegankelijkheid en draagt voortdurend materiaal bij aan de steeds groeiende online testgemeenschappen.

Hallo Erin. Welkom bij de show.

Erin Hess

Heel erg bedankt voor die geweldige introductie, Michael. Ik ben blij dat ik hier ben.

Michael Luchen

Geweldig. Ik moet zeggen dat ik persoonlijk erg enthousiast ben over dit gesprek. Eh, ik denk dat een van de dingen rond de samenwerking tussen een testingenieur en een productmanager is dat die enkele van de beste resultaten kan opleveren, maar er wordt nog niet vaak genoeg over gesproken.

Klaar om erin te duiken?

Erin Hess

Absoluut.

Michael Luchen

Goed.

Ik wil op hoog niveau beginnen, misschien voor enkele van onze luisteraars die proberen te begrijpen wat de rol inhoudt en misschien geen testingenieur in hun team hebben. Misschien kun je beginnen door ons te vertellen wat enkele van je favoriete activiteiten als testingenieur zijn.

Erin Hess

Zeker. Eh, er zijn er veel en dit is echt een onderwerp waar ik eindeloos over kan praten. Er zijn zoveel activiteiten die je als tester kunt uitvoeren. Een van mijn absolute favoriete dingen in het algemeen is relaties opbouwen en de teams waarmee ik werk leren kennen. Dat zijn dus de ontwikkelaar, de ontwerper, de productmanagers, andere engineers, klantondersteuning en soms zelfs marketing.

En bij unieke projecten, bijvoorbeeld wanneer je aan een samenwerkingsproject werkt, leer je ook de mensen aan de klantzijde kennen. Ik heb een niche gevonden in het schrijven van technische documentatie. Ik waardeer het dus enorm wanneer ik de tijd en ruimte krijg om de juiste hoeveelheid detail en uitleg te geven, met nuttige visuele hulpmiddelen.

Als ik creatief kan zijn en een afbeelding van een kat die voor een computer zit kan toevoegen, dan doe ik dat. En eens kijken. Ik vind het leuk om nieuwe hulpmiddelen te leren en samen te werken met andere engineers. Daar kijk ik echt naar uit.

Michael Luchen

Geweldig. Hoe pak je het opbouwen van relaties met je teams aan, vooral vanuit het perspectief dat een testingenieur nodig heeft?

Erin Hess

Ik sta heel open voor verschillende perspectieven en weet dat iedereen een beetje anders is. Ik zal niet hetzelfde gesprek voeren met een ontwerper als met een ontwikkelaar, en hetzelfde geldt voor de producteigenaar. Ik probeer dus heel ruimdenkend te zijn en zoveel mogelijk ruimte en empathie voor het team te hebben.

Michael Luchen

Hoe vind je de balans tussen het creëren van die ruimte en empathie, vooral wanneer je weet dat iedereen anders is en zijn eigen vaardigheden en disciplines naar een productteam meebrengt?

Erin Hess:

Voor mij is die discipline vooral geduld en oefenen geweest: leren en mezelf en mijn team retrospectieven geven over hoe we het hebben gedaan wat betreft zorg voor elkaar. Tijdens een sprint kijken we bijvoorbeeld welke dingen moeilijk kunnen zijn geweest. Niet alleen het werk zelf, maar ook als mensen, en door hen de ruimte te geven om met me te praten en zulke gesprekken te voeren.

Michael Luchen

Dat is geweldig. Als we even een stapje terug doen: wat zijn enkele typische activiteiten die een testingenieur binnen een productteam uitvoert? Het is zeker niet — en dit is een grapje — alleen maar zeggen dat iets kan worden uitgebracht, toch?

Erin Hess

Nee. Ik zit hier niet alleen met een stempel met het woord geslaagd of mislukt erop. Het gaat om veel nuances en veel meer relatieopbouw dan je zou verwachten van een technische rol. Je werkt veel samen met verschillende onderdelen van het team. Dat betekent bijvoorbeeld samenwerken met de ontwikkelaar om beter te worden in pull requests en het beoordelen van pull requests.

Je werkt samen met een productmanager om het juiste detailniveau in je acceptatiecriteria te krijgen en om de norm en verwachting voor die acceptatiecriteria vast te leggen.

Alle verschillende gebruikersverhalen en functies moeten worden bekeken, niet alleen door de ontwerpers en ontwikkelaars, maar ook door belanghebbenden, waarbij al deze verschillende bewegende onderdelen samenkomen. Als testingenieur maak je deel uit van dat geheel. Je moet dus al deze mensen bijhouden en met hen communiceren, want als je dat niet doet, mis je iets en gaat er iets verloren, waardoor het risico toeneemt dat het product niet aan de vereisten voldoet.

Michael Luchen

Interessant. Dat sluit volgens mij ook aan bij wat je zei over het vinden van je niche in technische documentatie, omdat die helpt om al die context samen te brengen, toch?

Erin Hess

Ik gebruik het ook als mijn tweede brein. Ik verwacht niet van mezelf dat ik alles onthoud, maar ik weet dat mijn documentatie uitstekend is. Ik kan er dus naar verwijzen wanneer ik die nodig heb voor een project, of wanneer iemand anders ermee aan de slag wil.

Michael Luchen

Met die verwijzing naar het tweede brein bedoel je volgens mij — en dat heb ik zelf ook gezien — dat je al deze documentatie openbaar toegankelijk houdt voor het productteam, toch?

Erin Hess

Ja.

Michael Luchen

Dat is... sorry, ga je gang.

Erin Hess

Ik wilde zeggen dat het er gewoon staat.

Het is niet verborgen, opgesloten of achter een vreemde betaalmuur geplaatst. Het staat er gewoon, zodat het team het kan gebruiken. En wanneer ik iets maak, deel ik het zeker.

Michael Luchen

Dat is echt goed. Transparante documentatie is volgens mij iets waar productteams zichzelf toe zouden moeten aanzetten als ze het nog niet doen. Niet alleen vanuit testengineering, maar vanuit alle disciplines die samen een productteam vormen. Daarmee komt namelijk context, en die context is waarom je iets hebt gecommuniceerd en wat je rol helpt floreren.

Voor anderen die misschien luisteren en nieuw zijn in de rol van testengineering, of die nog niet de kans hebben gehad om met een testingenieur in hun team samen te werken: wanneer kan een testingenieur het beste beginnen met samenwerken met dat team? Is dat ergens nadat het productwerk begint, tegen het einde, of op een ander moment?

Erin Hess

Ik heb in de loop der tijd geleerd dat het beter is naarmate je de testingenieur eerder kunt betrekken. Sommige bedrijven hanteren de houding dat testingenieurs er alleen zijn om taken uit te voeren, een test te schrijven en die goed of af te keuren. Er is dan weinig betrokkenheid. Maar als je goede testingenieurs wilt — mensen die meer aan tafel brengen dan alleen testvaardigheden — betrek ze dan bij de voorbereiding, bij de contextweek, en laat ze zien waar ze aan beginnen. Dan kunnen ze al vroeg veel gaan verbeelden.

Vanaf het allereerste begin kunnen ze zelfs helpen bijdragen aan het beïnvloeden van ontwerpen voor testbaarheid, ontwikkeling beïnvloeden en toegankelijkheidstesten aankaarten [00:09:00], in plaats van dat dit achteraf wordt toegevoegd.

Michael Luchen

Dat is geweldig. Ik ben het er volledig mee eens. Het is voor mij altijd een groot risico geworden wanneer ik zie dat een team zonder testingenieur aan het begin van start gaat, omdat de context die je vanuit al die invalshoeken verzamelt zo belangrijk is om ervoor te zorgen dat we een kwalitatief getest product hebben dat aan de behoeften van de gebruiker voldoet. Het is veel meer dan, zoals je zei, die rubberen stempel die soms wordt rondgegeven.

Wat zou je als testingenieur zeggen dat je tijdens een sprint in gedachten moet houden?

Erin Hess

Goede vraag. Ik heb hier een paar punten voor. Allereerst: je weet niet wat je niet weet. Wees dus niet bang om contact op te nemen met je team wanneer je twijfels of zorgen hebt, ongeacht hoe ernstig je ze vindt. Soms kan een kleine zorg uitgroeien tot een aanzienlijke verbetering. Een andere reden om je uit te spreken is dat het risico en de kosten om een probleem op te lossen kleiner worden. Als je niets zegt en het probleem wordt uitgebracht, kan dat veel duurder zijn.

En er bestaat geen ‘ik’ in productontwikkeling, net zoals er geen ‘ik’ in team zit. Je doet dit niet alleen. Je maakt deel uit van het team en je helpt het team niet wanneer je niet vertelt dat je ergens mee worstelt. Een van de slechtste dingen die je kunt doen, is wachten tot het einde van een sprint om je team te vertellen dat je iets niet kunt doen. Spreek je dus uit.

Michael Luchen

Ja, ik denk dat het cruciaal is. Vooral vanuit productmanagement helpt dit om vast te stellen of er grote risico's in deze sprint zijn. Wanneer we als volledig productteam aan een sprint beginnen, hebben we maar een beperkt beeld van de risico's die eraan komen. Maar zoals je zegt, kan er vanuit het perspectief van een testingenieur vroeg in de sprint iets worden gesignaleerd dat het verloop van die sprint kan veranderen, met zeer goede bedoelingen.

Erin Hess

Ja.

Michael Luchen

Als we kijken naar samenwerking tussen disciplines: wat zijn enkele tips om ervoor te zorgen dat testingenieurs, ontwerpers en ontwikkelaars succesvol kunnen samenwerken?

Erin Hess

Het is zeker nuttig als ontwerpers en ontwikkelaars waar mogelijk tijdens het ontwerpen en ontwikkelen van gebruikersverhalen samenwerken met testingenieurs.

Uit ervaring weet ik dat er kansen zijn om in de vroege fasen van een project met ontwerp en ontwikkeling samen te werken. Dat geeft me meer informatie om testsituaties en testbestanden voor te bereiden en automatiseringsscripts te schrijven. Op dit moment verbeter ik onze acceptatiecriteria en vereisten door Gherkin toe te voegen, zodat het grootste deel van het werk al gedaan is wanneer we klaar zijn voor automatisering.

Michael Luchen

Dat is interessant. Je noemde net verschillende concepten, zoals testsituaties. Wat is dat precies? Is het gewoon het doorlopen van de acceptatiecriteria die ik als productmanager schrijf, of is het iets ingewikkelders?

Erin Hess

Het is een beetje van beide. Je neemt de acceptatiecriteria die het team en de productmanager samen hebben opgesteld en verbeterd. Vervolgens beschrijven de testsituaties bijvoorbeeld: als dit type gebruiker op dit type apparaat, wat doe ik dan, wat is de verwachte uitkomst, welke risico's zijn er en wat zou ik kunnen proberen te verstoren? Je bedenkt verschillende eind-tot-eindprocessen van wat een gebruiker tijdens die test zou kunnen doen.

Michael Luchen

Wanneer we een product uitbrengen, zijn er zoveel plaatsen en omstandigheden waarin het kan worden gebruikt: meerdere webbrowsers, verschillende schermresoluties, verschillende apparaten en meer. Met die testsituaties wil je het product als het ware in een moeilijke situatie brengen. Hoe bepaal je binnen die enorme reikwijdte waarop je je inspanningen moet richten?

Erin Hess

Ik heb geleerd dat overdrijven bij testen echt bestaat. Je kunt het zeker overdrijven met toegankelijkheidstesten, door te vaak te veel te testen op pagina's die niet per se op die manier getest hoeven te worden.

Je kunt volledig doorslaan met testen. Om het terug te brengen, zijn tijd, oefening en enig voorwerk nodig. Kijk eerst naar het soort project dat je hebt: gaat het om een webapplicatie, een native app of iets dat alleen op iPhones draait?

Je denkt na over alle manieren waarop je dit kunt testen en begint de dingen weg te strepen waarvan je weet dat je ze niet hoeft te testen. Daarna bouw je de belangrijkste testcombinaties op: dit apparaat met deze browser en dit type gebruiker.

Michael Luchen

Wanneer je je testsituaties bepaalt en beslist waarop je je richt, kijk je dan regelmatig naar statistieken over browsergebruik en apparaatgebruik? En hoe bepaal je wat relevant is voor het product waaraan je werkt?

Erin Hess

Er zijn veel bronnen die ik gebruik, en die veel testingenieurs gebruiken, om te bepalen welke combinaties het meest praktisch zijn om op te testen. Hoe groot is het browsergebruik op dit moment voor een bepaald apparaat of een bepaalde browserversie? Hoeveel mensen gebruiken deze apparaten, toepassingen, producten en diensten daadwerkelijk?

Op basis daarvan bepalen we bijvoorbeeld dat we zeker Safari en Chrome, iOS en Android willen controleren. Daarna kun je zaken met een lager risico opsommen die je zou willen testen als je tijd hebt, zoals iOS, Edge of een andere willekeurige browser. Die zijn niet essentieel, maar het zou prettig zijn om te weten of de applicatie erop werkt.

Michael Luchen

Dat is interessant. Ik ben ook benieuwd of gebruikerstests of enquêtes kunnen helpen bepalen waar je moet testen.

Erin Hess

Bedoel je formulieren, bijvoorbeeld van een dienst of website die je gebruikt?

Michael Luchen

Enquêtes, ja.

Erin Hess

Persoonlijk heb ik niet veel gedaan met gebruikersenquêtes, maar ik vul ze graag in en geef graag feedback. Het zou bijzonder waardevol zijn om die diepgaande feedback van echte gebruikers te krijgen. Ik houd zeker rekening met de gemiddelde gebruikerservaring die voor dit type toepassing wordt verwacht, en van daaruit ga ik verder.

Michael Luchen

Voordat we verdergaan, moet ik je ook vragen naar iets anders waar je onlangs over hebt verteld: je schrijft automatiseringsscripts. Wat is de waarde van automatisering voor een product, en waarom en wanneer moet je die introduceren?

Erin Hess

Goede vraag. Dit is ook zo'n situatie waarin het ervan afhangt. Als het project langdurig en doorlopend is, een stevig team heeft en eigenlijk geen einde in zicht heeft, kan het geschikt zijn voor automatisering. Je kunt beginnen met handmatige tests en die rangschikken op basis van risico en functie.

Daarna denk je na over welk automatiseringsraamwerk je wilt gebruiken, of dat je voor een webgebaseerde oplossing met weinig code kiest. Er zijn veel opties voor automatisering en voor de manier waarop je die uitvoert. Vervolgens vraag je je af wat het meest logisch is om als eerste te doen. Dat kan ook bij een volledig nieuw project dat vanaf de grond wordt opgebouwd.

Nadenken over automatisering kan geen kwaad, want tijdens de voorontwikkeling en het ontwerp zijn er kansen om met die teams samen te werken, bijvoorbeeld door toegankelijkheidstags op componenten te maken.

Dat doen we momenteel met Gherkin: we schrijven in feite al code en scripts voordat er überhaupt een product is. Dat kan tijd besparen en helpt je beter te plannen wanneer je ontwerp, ontwikkeling en testen parallel uitvoert.

Het voegt ook een extra complexiteitslaag toe voor testingenieurs en voor wat zij tijdens elke sprint doen. Naast het opstellen en beoordelen van acceptatiecriteria en testgevallen ben je bijna een kleine ontwikkelaar, omdat je de acceptatiecriteria voor je automatiseringsscripts schrijft en beoordeelt.

Vroeg beginnen is dus goed, maar het komt erop neer dat je automatisering introduceert wanneer je echt voelt dat die nodig is. Meestal is dat omdat je het testproces wilt versnellen en de tests stabieler wilt maken.

Michael Luchen

Interessant. Ik ben benieuwd hoe je samenwerkt met productmanagers.

Erin Hess

Dat is leuk. Zoals ik eerder zei, vind ik het leuk om relaties met mijn team op te bouwen. Het gaat dus niet om hiërarchie. Ik wil dat iedereen in het team samenwerkt en met elkaar werkt, en ik help dat proces graag vooruit. Ik werk net zo graag met productmanagers als met ontwikkelaars en ontwerpers.

Dat betekent bijvoorbeeld samenwerken aan acceptatiecriteria, helpen met onderzoek of informatie verzamelen over iets waarin zij meer geïnteresseerd zijn. Misschien kunnen we een bepaalde aanpak gebruiken voor een bepaald type test. Eigenlijk geldt dat voor elke taak: als de productmanager iets nodig heeft en ik kan helpen, dan stap ik in.

Michael Luchen

Zoals ik eerder aangaf, denk ik dat de samenwerking tussen een testingenieur en een productmanager een van de meest impactvolle samenwerkingen binnen een productteam is, vooral vanwege de focus op acceptatiecriteria en op de manier waarop zaken vóór de release naar gebruikers worden gevalideerd.

Persoonlijk merk ik dat er een mooie balans ontstaat wanneer productmanagers en testingenieurs al vroeg samenwerken aan de acceptatiecriteria. Productmanagers brengen bijvoorbeeld de focus mee op de resultaten die we voor de gebruiker willen bereiken, terwijl de testingenieur kijkt naar de details en ervoor zorgt dat alle hiaten zijn afgedekt, op een passend niveau dat de rest van het productteam nog ruimte laat voor creativiteit.

Zo kunnen we ervoor zorgen dat er een kwalitatief goed, getest product wordt uitgebracht dat de behoeften van de gebruiker ondersteunt. Zou je die balans ook zo beschrijven?

Erin Hess

Absoluut. Ik heb ook meegemaakt hoe het is wanneer je niet vroeg wordt betrokken, en nu heb ik daar goede inzichten in. Ik waardeer het enorm dat ik vanaf het allereerste begin kan worden betrokken.

Michael Luchen

Zodra je een productteam zonder testingenieur hebt meegemaakt, is het verschil enorm. Het is heel duidelijk hoe slecht dingen kunnen worden, denk ik.

Iets waar je eerder over hebt verteld, is dat je een groot voorstander van toegankelijkheid bent. Kun je daar iets meer over vertellen?

Erin Hess

Zeker. Het woord toegankelijkheid wordt momenteel vaak gebruikt. Het is een actueel onderwerp. Het staat ook bekend als ‘A11Y’, omdat er elf letters tussen de A van accessibility en de Y staan. Met voorvechter bedoel je volgens mij dat je een stem bent voor alle verschillende eindgebruikers. Je zet je ervoor in dat functies en producten en diensten voor iedereen toegankelijk zijn. Het gaat dus om veel inclusie, veel gesprekken en ontdekken waar je je stem kunt inzetten om iemand anders te helpen.

Michael Luchen

Soms zeggen belanghebbenden misschien dat ze niet de mogelijkheid hebben om toegankelijkheidskwesties prioriteit te geven. Hoe ga je daarmee om?

Erin Hess

Ik heb dat op verschillende manieren aangepakt. Voor sommige belanghebbenden werkt het het beste om te laten zien hoe duur het voor het bedrijf kan worden als het geen conforme website heeft. Het risico op een rechtszaak is rommelig. Het is echt rommelig, moeilijk te herstellen en het laat een slechte indruk achter wanneer mensen ontdekken dat je geen aandacht had voor een hele groep eindgebruikers. Misschien was dat niet je bedoeling, maar dat is wel wat ze zullen denken.

Michael Luchen

Kun je iets meer vertellen over empathie als basis voor testen?

Erin Hess

De meeste mensen hebben waarschijnlijk wel eens de uitdrukking ‘in de schoenen van iemand anders staan’ gehoord. Dat is een andere manier om empathie te omschrijven. Het is het vermogen om te begrijpen of te voelen wat iemand anders ervaart vanuit diens eigen referentiekader. De definitie van empathie kan dus een breed scala aan emoties omvatten.

Ik heb specifiek over empathie en testen gepresenteerd tijdens een evenement van Ministry of Testing, TestBash Home, eerder dit jaar, samen met mijn vriendin Jenny Bramble. We spraken over onze gevoelens en over hoe ‘empathie de basis van testen is’, hoe dat eruitziet en hoe onze geschiedenis ons in een unieke positie plaatst om over empathie en klantbehoeften te praten.

Michael Luchen

Wat maakt empathie nu precies de basis van testen? Welke praktische aanpakken horen daarbij?

Erin Hess

Uiteindelijk is er een kruispunt tussen testen en empathie. Je kunt iemands verwachtingen niet kennen als je diens ervaring niet kent.

In de ervaring van iemand anders stappen is dus een belangrijk onderdeel van testen. We doen het voortdurend, zonder er misschien bij stil te staan. Denk aan het testen van een thema met hoog contrast of een lettertype voor mensen met dyslexie. Dat bestaat met een reden. Uiteindelijk valt het kruispunt van testen en empathie rechtstreeks binnen het domein van toegankelijkheidstesten.

Michael Luchen

Het is interessant om na dit gesprek van 25 minuten enkele thema's te zien ontstaan: de combinatie van het zijn van een voorvechter van toegankelijkheid, hoe empathie door alles heen loopt wat je als testingenieur doet en hoe belangrijk samenwerking is voor de rol van de testingenieur.

Niet alleen met de productmanager, maar met het productteam als geheel.

Voor we afronden, wil ik graag enkele persoonlijke vragen in een snel tempo stellen, als dat goed is.

Erin Hess

Kom maar op.

Michael Luchen

Welke persoonlijke gewoonte heeft het meest bijgedragen aan je succes?

Erin Hess

Mijn vermogen om grote hoeveelheden informatie te creëren, structureren en organiseren, dat ik in de loop der tijd heb ontwikkeld. Dat is een van mijn superkrachten. Volgens mij komt dat voort uit mijn obsessie met organiseren en organisatie in het algemeen, en uit mijn passie voor het schrijven van goede, nuttige en betekenisvolle documentatie.

Michael Luchen

Wat is je favoriete hulpmiddel dat je regelmatig gebruikt?

Erin Hess

Dat is zeker Chrome DevTools, om veel redenen. Ik wil vooral de apparaatmodus noemen, waarmee je mobiele apparaten kunt simuleren, responsiviteit kunt testen en verschillende specifieke weergavegebieden kunt bekijken. De netwerkpanelen zijn mijn beste vriend. Wanneer ik DevTools gebruik en een defect vind, begin ik daar meestal met onderzoeken en rapporteren. En dan zijn er Lighthouse en Axe voor toegankelijkheidstesten.

Michael Luchen

Laatste vraag: welk advies zou je geven aan iemand die aan het begin van zijn reis in productontwikkeling staat?

Erin Hess

Sta open voor alles wat je kunt leren, ongeacht van wie het komt. Als een ontwikkelaar, ontwerper of productmanager je aandacht of tijd wil en je ergens bij wil betrekken, doe het dan. Gebruik het als een leermoment en haal er zoveel mogelijk uit.

Michael Luchen

Heel goed gezegd. Ik heb vandaag zeker veel geleerd. Heel erg bedankt, Erin, dat je in de show wilde komen.

Erin Hess

Graag gedaan. Bedankt dat je me hebt uitgenodigd. Ik kijk ernaar uit om nog meer te praten over toegankelijkheidstesten en testengineering in het algemeen.

Michael Luchen

Ik kijk ernaar uit. Voor degenen onder jullie die luisteren en meer van Erin willen leren: je kunt meer te weten komen over Erins werk op crema.us. Zoek haar op LinkedIn. Erin is ook actief op Twitter; je vindt haar onder de gebruikersnaam @QueenTester.

Als je de show van vandaag leuk vond, bekijk dan onze gerelateerde publicatie, QA Lead, waarin we de nieuwste en beste ontwikkelingen op het gebied van automatisering en testen bespreken. Je vindt die op theqalead.com.

Nogmaals heel erg bedankt, Erin, dat je vandaag bij de show was. Dit was een fantastische aflevering. Bedankt allemaal voor het luisteren. Laat vooral een beoordeling achter voor deze podcast. Ik hoor graag jullie feedback. Volg en word ook lid van onze community op theproductmanager.com. Bedankt.