Produkttesting (med Erin Hess fra Crema)

Michael Luchen

Det brukes så mye tid på å snakke om å bygge produkter, men hva med å teste produkter? Hvilke tilnærminger, holdninger og metoder inngår i å sikre at et produkt blir grundig testet, slik at det støtter brukerne det er bygget for? I dagens episode får vi besøk av en fagekspert innen testingeniørfaget, som skal gå i dybden sammen med oss på hva som definerer denne kritiske rollen i et produktteam, hvordan testingeniører samarbeider med produktledere, og hvorfor de kan være en viktig forkjemper for empati i produktteamet. Heng med.

Dette er podkasten The CPO Club – stemmene fra et fellesskap som skriver håndboken for produktledelse, utvikling og strategi. Vi sponses av Crema, et digitalt produktbyrå som hjelper enkeltpersoner og selskaper med å lykkes gjennom kreativitet, teknologi og kultur. Les mer på crema.us. Fortsett å lytte for å få praktisk og autentisk innsikt som kan hjelpe deg med å lykkes i produktledelsens verden.

Hei, alle sammen. Jeg er veldig glad for å kunne ønske Erin Hess velkommen til programmet i dag. Jeg har hatt gleden av å bli kjent med Erin etter at hun nylig tok med seg talentene sine til teamet vårt i Crema som senior testingeniør. Erin har et unikt sett med kreative og tekniske ferdigheter som hun har opparbeidet seg gjennom mer enn 12 års erfaring i flere ulike roller innen programvareutvikling og ingeniørarbeid.

Hun startet karrieren som kundestøtterepresentant før hun ble en selvlært programmerer som utviklet en kjærlighet for programvaretesting. Erin er en brukerforkjemper innerst inne, og noen av hennes viktigste styrker er empati, visualisering og evnen til å forutse atferd og kommunikasjon. Erin liker å lage kart over prosesser og forestille seg hvor smertepunkter kan oppstå. Ved å sette seg i andres sted, se på problemer fra flere vinkler og forstå de langsiktige konsekvensene og fordelene av dagens handlinger, har Erin klart å gjøre en forskjell for alle team og produkter hun blir en del av.

Erin hjelper også organisasjoner med å ta i bruk og implementere inkluderende designpraksis ved å skape og spre bevissthet om universelle brukbarhetsbarrierer. Hun er en forkjemper for tilgjengelighet og bidrar kontinuerlig med ressursmateriell til stadig voksende nettbaserte testfellesskap.

Hei, Erin. Velkommen til programmet.

Erin Hess

Tusen takk for den flotte introduksjonen, Michael. Jeg er glad for å være her.

Michael Luchen

Flott. Jeg må si at jeg personlig ser veldig frem til denne samtalen. Jeg tror noe av det som gjelder forholdet mellom testingeniøren og produktlederen, er at det kan skape noen av de beste resultatene, men likevel snakkes det ikke så mye om det.

Er du klar til å sette i gang?

Erin Hess

Ja, absolutt.

Michael Luchen

Greit.

Jeg vil begynne på et overordnet nivå, kanskje for noen av lytterne våre som prøver å forstå rollen, men som kanskje ikke har en testingeniør i teamet sitt. Kanskje du kan starte med å fortelle oss om noen av favorittaktivitetene dine som testingeniør?

Erin Hess

Ja, selvfølgelig. Det er mange, og dette er virkelig et tema jeg kunne snakket om i det uendelige. Det er så mange aktiviteter man får gjøre som tester. En av favorittaktivitetene mine generelt er å bygge relasjoner og bli kjent med teamene jeg jobber med. Det gjelder utvikleren, designeren, produktlederne, andre ingeniører, kundestøtte og noen ganger til og med markedsføring.

Og på unike prosjekter, for eksempel når man jobber med et samarbeidsprosjekt, får man også bli kjent med ressursene på kundesiden. Jeg har funnet en nisje innen skriving av teknisk dokumentasjon. Derfor setter jeg stor pris på å ha tid og rom til å gi riktig mengde detaljer og beskrivelser, sammen med nyttige visuelle hjelpemidler.

Hvis jeg kan være kreativ og legge til et bilde av en katt som sitter foran en datamaskin, så gjør jeg det. Og la meg se … Jeg liker å lære nye verktøy og samarbeide tett med andre ingeniører. Det er noe jeg virkelig ser frem til.

Michael Luchen

Flott. Hvordan går du frem for å bygge relasjoner med teamene dine, særlig med utgangspunkt i det en testingeniør må bidra med?

Erin Hess

Jeg er veldig åpen og vet at alle er litt forskjellige. Jeg kommer ikke til å ha den samme typen samtale med designeren som jeg kanskje har med utvikleren, og det samme gjelder produktansvarlig. Derfor er jeg svært åpen, og jeg prøver å gi teamet så mye rom og empati som mulig.

Michael Luchen

Hvordan finner du balansen mellom å skape dette rommet og vise empati, spesielt når du vet at alle er forskjellige og har sine egne ferdigheter og fagområder som de tar med seg inn i et produktteam?

Erin Hess:

For meg har den disiplinen vært tålmodighet og øvelse – å lære og gi meg selv og teamet mitt tilbakeblikk på hvordan vi gjorde det når det gjelder å ta vare på hverandre og komme oss gjennom denne sprinten. Hvilke ting kan ha vært vanskelige? Ikke bare selve arbeidet, men også som mennesker, og å gi dem rom til å snakke med meg og ha slike samtaler.

Michael Luchen

Det er flott. La oss ta et lite steg ut og se på dette på et mer overordnet nivå et øyeblikk.

Hva er noen av de typiske aktivitetene en testingeniør gjør i et produktteam? Det handler selvsagt ikke bare om å si at noe kan lanseres – dette er en spøk – men det er selvsagt ikke bare det, ikke sant?

Erin Hess

Nei, absolutt ikke. Jeg sitter ikke bare her med en stempelpute med ordet «bestått» eller «ikke bestått» på. Det er mange nyanser og mye mer relasjonsbygging enn man skulle tro i en teknisk rolle. Det innebærer mye arbeid med og samarbeid mellom ulike deler av teamet. Det kan være å samarbeide med utvikleren for å bli bedre på å lage og gjennomgå forespørsler om kodeendringer.

Det kan være å samarbeide med en produktleder for å få riktig detaljnivå i akseptansekriteriene, og for å fastsette standarden og forventningene til hva akseptansekriteriene skal inneholde.

Alle de ulike brukerhistoriene og funksjonene må vurderes, ikke bare av designerne, utviklerne og alle andre, men også av interessentene. Det er mange bevegelige deler. Som testingeniør er du en del av alt dette. Du må holde tritt med og kommunisere med alle disse menneskene, for hvis du ikke gjør det, kommer du til å gå glipp av noe, og risikoen for at produktet ikke oppfyller kravene, øker.

Michael Luchen

Interessant. Det knytter seg på en måte til det du snakket om når det gjelder å finne din egen nisje innen teknisk dokumentasjon, fordi det hjelper med å samle all denne konteksten, ikke sant?

Erin Hess

Jeg bruker det også som en ekstra hjerne. Jeg forventer ikke at jeg skal huske alt, men jeg vet at dokumentasjonen min er ganske god, så jeg kan slå opp i den når jeg trenger det i et prosjekt, eller slik at andre kan bruke den.

Michael Luchen

Når du viser til den ekstra hjernen, tror jeg i alle fall noe jeg har sett på nært hold, er at du holder all denne dokumentasjonen offentlig tilgjengelig for produktteamet, ikke sant?

Erin Hess

Ja.

Michael Luchen

Det er … beklager, fortsett.

Erin Hess

Jeg skulle bare si at den ligger der ute.

Den er ikke skjult, låst inne eller bak en merkelig betalingsmur. Den er tilgjengelig for teamet. Når jeg lager noe, deler jeg det definitivt.

Michael Luchen

Det er virkelig bra. Åpen dokumentasjon er noe jeg mener produktteam bør presse seg selv til å gjøre hvis de ikke allerede gjør det. Ikke bare innen testingeniørarbeid, men innen alle fagområdene som utgjør et produktteam. Med dette følger kontekst, og konteksten er grunnen til at kommunikasjonen fungerer – det er det som hjelper rollen din med å lykkes.

For andre som lytter og kanskje er nye i testingeniørrollen, eller som ikke har hatt muligheten til å samarbeide med en testingeniør i teamet sitt: Når er det beste tidspunktet for testingeniøren å begynne å samarbeide med teamet? Er det etter at produktarbeidet har startet? Mot slutten? Eller på et annet tidspunkt?

Erin Hess

Jeg har lært over tid at jo tidligere du får med testingeniøren, desto bedre. Noen selskaper har en holdning om at testingeniøren bare skal fylle ut en oppgave, skrive en test og markere den som bestått eller ikke bestått. Da er det ikke så mye involvering. Men hvis du ønsker gode testingeniører som tilfører mer enn bare testferdigheter, bør du ta dem med før oppstarten, involvere dem i kontekstuken og la dem se hva de går inn i. Da kan de begynne å forestille seg mye.

Helt fra starten kan de også bidra til å påvirke design for testbarhet, påvirke utviklingen og ta opp tilgjengelighetstesting, i stedet for at dette blir en ettertanke.

Michael Luchen

Det er flott. Jeg er helt enig. Det har alltid blitt en stor risiko for meg hvis jeg ser at et team starter uten en testingeniør fra begynnelsen, fordi konteksten du samler inn fra alle disse vinklene, er så viktig for å sikre at vi har et kvalitetstestet produkt som oppfyller brukernes behov. Det er mye mer enn den gummistemplingen du nevnte, som noen ganger sendes rundt.

Så som testingeniør: Hva vil du si er viktig å huske på under en sprint?

Erin Hess

Godt spørsmål. Jeg har et par ting å trekke frem. For det første vet du ikke det du ikke vet, så ikke vær redd for å ta kontakt med teamet når du har en tvil eller bekymring, uansett hvor alvorlig du synes den er. Noen ganger kan en liten bekymring utvikle seg til en betydelig forbedring. En annen grunn til å si fra er at det reduserer risikoen og kostnadene ved å rette et problem hvis du ikke sier fra og det blir lansert.

Og det finnes ingen «jeg» i produktutvikling, på samme måte som det ikke finnes noen «jeg» i team. Du gjør ikke dette alene. Du er en del av teamet, og du gjør ikke teamet noen tjeneste ved å ikke fortelle dem at du sliter. Noe av det verste du kan gjøre, er å vente til slutten av en sprint med å fortelle teamet at du ikke klarer å gjøre noe. Så si fra.

Michael Luchen

Ja, jeg synes det er helt avgjørende, særlig fra produktledelsessiden. Det hjelper med å identifisere om det finnes store risikoer i denne sprinten.

Når vi starter en sprint som et komplett produktteam, har vi begrensede antakelser om hvilke risikoer vi går inn i. Men som du sier, kan det fra testingeniørens perspektiv dukke opp noe tidlig i sprinten som kan endre retningen på sprinten – med svært gode hensikter.

Erin Hess

Ja.

Michael Luchen

La oss gå videre til litt samarbeid mellom fagområdene. Hvilke råd har du for hvordan testingeniører, designere og utviklere bør legge til rette for vellykket samarbeid?

Erin Hess

Jeg vil si at det absolutt er nyttig at designere og utviklere samarbeider tett med testingeniørene under utformingen og utviklingen av brukerhistoriene, når det er mulig.

Jeg kan si av erfaring at vi har lært at det finnes muligheter for å samarbeide med design og utvikling i de tidlige fasene av et prosjekt. Det gir meg mer informasjon til å forberede testscenarier og testfiler og skrive automatiseringsskript. Akkurat nå forbedrer jeg akseptansekriteriene og kravene våre ved å inkludere Gherkin, slik at en stor del av arbeidet allerede er gjort når vi er klare for automatisering.

Michael Luchen

Det er interessant. Jeg er nysgjerrig på flere av konseptene du nevnte, for eksempel testscenarier. Hva er det? Handler det om å gå gjennom akseptansekriteriene som jeg skriver som produktleder, eller er det noe mer detaljert?

Erin Hess

Det er litt av begge deler. Man tar akseptansekriteriene som teamet og produktlederen har utarbeidet sammen og forbedret. Deretter beskriver testscenarioene for eksempel hva en bestemt type bruker gjør på en bestemt type enhet, hva det forventede resultatet er, hvilke risikoer som finnes, og hvilke ting man kanskje vil prøve å gjøre feil med vilje. Det handler om å finne ulike komplette flyter for hva en bruker potensielt kan gjøre i testen.

Michael Luchen

Når vi lanserer et produkt, finnes det så mange steder og situasjoner der produktet kan bli brukt. Flere nettlesere, ulike skjermoppløsninger, forskjellige enheter og mer. Gjennom testscenarioene ønsker du å sette produktet i en litt vanskelig situasjon.

Hvordan avgjør du hvor du skal fokusere innsatsen, når omfanget av alt du kan teste, er så stort?

Erin Hess

Jeg har lært at det er mulig å overdrive testingen. Du kan overdrive tilgjengelighetstesting og gjøre for mye for ofte på sider som ikke nødvendigvis trenger å testes på den måten.

Du kan virkelig gå helt av hengslene med testing. For å få det under kontroll kreves det tid, øvelse og litt forhåndstenkning. Du må se på hva slags prosjekt du har. Er det en nettapp, en innebygd app, eller skal den bare kjøre på iPhone?

Når du tenker på de ulike tingene produktet skal fungere med, og alle måtene du skal teste det på, begynner du å luke ut tingene du vet at du ikke trenger å teste. Deretter bygger du opp testmatrisen: Jeg trenger denne enheten med denne nettleseren og denne typen oppsett for denne typen bruker.

Michael Luchen

Når du går gjennom testscenarioene og finner ut hvor du vil fokusere, ser du da jevnlig på statistikk over nettleserbruk og enhetsbruk? Og hvordan avgjør du hva som er relevant for produktet du jobber med?

Erin Hess

Det finnes mange ressurser jeg bruker, og mange testingeniører bruker, som hjelper oss med å forstå hvilke kombinasjoner som er mest praktiske å teste. Hva er nettleserbruken akkurat nå for en bestemt enhet eller nettleserversjon?

Hvor mange bruker faktisk disse tingene med denne typen applikasjoner, produkter og tjenester? Dette bruker vi til å bestemme at vi definitivt vil teste Safari og Chrome på iOS og Android. Deretter kan vi føre opp ting med lavere risiko som vi gjerne vil teste hvis vi har tid, for eksempel Edge eller en annen mindre viktig nettleser. Det hadde vært fint å vite om appen fungerer der også.

Michael Luchen

Det er veldig interessant. Jeg er også nysgjerrig på om brukertesting eller undersøkelser kan gi informasjon om hvor man bør teste.

Erin Hess

Når du sier skjemaer, mener du skjemaer fra en tjeneste eller et nettsted du bruker?

Michael Luchen

Jeg mener undersøkelser.

Erin Hess

Jeg har personlig ikke gjort så mye med brukerundersøkelser, men jeg liker å fylle dem ut og gi tilbakemeldinger. Det hadde vært en interessant måte å få tilbakemeldinger fra de faktiske brukerne på. Jeg tar definitivt hensyn til hva den gjennomsnittlige brukeropplevelsen forventes å være for denne typen applikasjon, og så går jeg ut fra det.

Michael Luchen

Før vi går videre, må jeg også spørre om noe annet du nylig har snakket om: at du skriver automatiseringsskript. Hva er verdien av automatisering i et produkt, og hvorfor og når bør den innføres?

Erin Hess

Det er et veldig godt spørsmål. Dette er også en av de situasjonene der svaret er «det kommer an på». Hvis prosjektet er langsiktig og kontinuerlig, har et robust team og ikke har noen synlig ende, kan det være godt egnet for automatisering. Du kan begynne med de manuelle testene og rangere dem etter risiko og funksjon.

Deretter kan du tenke gjennom hvilket automatiseringsrammeverk du vil bruke, eller om du vil velge en lavkodebasert, nettbasert løsning. Det finnes mange alternativer for automatisering og måter å gjøre det på. Så handler det om å finne ut hva som gir mest mening å gjøre først. Dette kan gjelde et prosjekt som er helt nytt og bygges fra grunnen av.

Det skader ikke å tenke på automatisering, fordi det finnes deler av forutviklingen og designet der du kan samarbeide med disse teamene. Det kan for eksempel være å lage tilgjengelighetstagger på komponenter.

Det er noe vi faktisk gjør nå i Gherkin, for å ha kode og skript klare før det finnes et produkt. Det kan spare tid og hjelpe deg med å planlegge bedre hvis du gjør det parallelt med design, utvikling og testing.

Det legger også et ekstra kompleksitetslag til testingeniørens oppgaver i hver sprint. I tillegg til akseptansekriteriene og arbeidet med å skrive og gjennomgå testtilfeller, blir du nesten litt utvikler når du skriver og gjennomgår akseptansekriteriene som er utformet for automatiseringsskriptene.

Det er flott å begynne tidlig, men tidspunktet avhenger av når du faktisk føler at behovet er der. Vanligvis handler det om at du ønsker å gjøre testingen og hele prosessen raskere, samtidig som du ønsker å stabilisere testingen.

Michael Luchen

Interessant. Jeg er nysgjerrig på hvordan du samarbeider med produktledere.

Erin Hess

Dette er gøy. Som jeg nevnte tidligere, liker jeg å bygge relasjoner med teamet mitt. Det handler ikke om hierarki. Det handler om at jeg ønsker at alle i teamet skal samarbeide og jobbe med hverandre, og jeg liker å bidra til at den prosessen fungerer. Derfor liker jeg å jobbe med produktlederne like mye som med utviklerne og designerne.

Noe av dette innebærer å samarbeide om og hjelpe til med akseptansekriterier, gjøre undersøkelser eller samle inn informasjon om noe de er mer interessert i. Kanskje vi kan bruke en bestemt tilnærming for denne typen test. Hvis produktlederen trenger noe og jeg kan hjelpe, trår jeg til.

Michael Luchen

Det er bra. Som jeg antydet tidligere, mener jeg at partnerskapet mellom testingeniøren og produktlederen er et av de mest virkningsfulle i et produktteam. Det skyldes særlig fokuset på akseptansekriteriene og hvordan ting skal valideres før de lanseres for brukerne.

For meg personlig oppstår det en god balanse når produktledere og testingeniører samarbeider tidlig om akseptansekriteriene. Produktlederne kan bidra med et fokus på hvilke resultater vi prøver å oppnå for brukeren, mens testingeniøren bidrar med detaljene.

Hvordan sikrer vi at alle hullene er dekket på et passende nivå, samtidig som resten av produktteamet fortsatt har rom for kreativitet, slik at vi kan lansere og teste noe av høy kvalitet som støtter brukernes behov? Vil du si deg enig i den balansen?

Erin Hess

Ja, absolutt.

Michael Luchen

Jeg tror det kan skje veldig mye når dette samarbeidet starter tidlig. Det er en av grunnene til at jeg alltid argumenterer for at testingeniører må begynne i starten av produktarbeidet, på samme måte som alle de andre rollene.

Erin Hess

Jeg er helt enig. Jeg har opplevd situasjoner der man ikke blir involvert, og nå har jeg et veldig godt perspektiv på hvor mye jeg setter pris på å bli tatt med helt fra starten.

Michael Luchen

Når man først har opplevd et produktteam uten testingeniør, blir forskjellen veldig tydelig. Det er tydelig hvor galt ting kan gå.

Et annet tema du har snakket om tidligere, er at du er en stor forkjemper for tilgjengelighet. Kan du fortelle litt om hva det innebærer?

Erin Hess

Ja. Ordet tilgjengelighet brukes mye for tiden. Det er et aktuelt tema. Det er også kjent som «A11Y», fordi det er elleve bokstaver mellom A-en i accessibility og Y-en. Det en forkjemper gjør, er å være en stemme for alle de ulike sluttbrukerne. Du kjemper for at funksjoner og utvikling av produkter og tjenester skal være tilgjengelige for alle. Det handler om mye inkludering, mye samtale og om å finne ut hvordan man kan bruke stemmen sin til å hjelpe andre.

Michael Luchen

Jeg er nysgjerrig på noe jeg dessverre har sett: Noen ganger sier interessenter at de ikke har mulighet til å prioritere tilgjengelighetstiltak. Hvordan utfordrer du det, eller hvordan håndterer du en slik situasjon?

Erin Hess

Jeg har gjort dette på flere ulike måter, og jeg har funnet ut at den mest effektive metoden for enkelte interessenter er å vise dem hvor dyrt det kan bli for virksomheten hvis nettstedet ikke følger kravene. Risikoen for å bli saksøkt gjør situasjonen vanskelig.

Det er virkelig vanskelig å håndtere, og det kan gi et dårlig inntrykk hvis folk oppdager at du ikke brydde deg om en hel gruppe sluttbrukere. Det var kanskje ikke det som faktisk skjedde, men det er det de kommer til å tro.

Michael Luchen

Kan du si litt mer om empati som grunnlaget for testing?

Erin Hess

De fleste har sannsynligvis hørt uttrykket «å sette seg i andres sted», som også er en annen måte å beskrive empati på. Det er evnen til å forstå eller føle det en annen person opplever, fra vedkommendes eget perspektiv. Definisjonen av empati kan derfor omfatte et bredt spekter av følelser.

For å gå litt dypere inn i temaet har jeg faktisk holdt et foredrag om empati og testing. Det var på Ministry of Testings TestBash Home-arrangement tidligere i år, der jeg presenterte sammen med venninnen min, Jenny Bramble. Vi snakket om følelsene våre og om hvordan «Empati er grunnlaget for testing», hva det innebærer, og hvordan historiene våre gir oss et unikt utgangspunkt for å snakke om empati og kundebehov.

Michael Luchen

Så, kort fortalt: Hva er det som gjør empati til grunnlaget for testing? Hvilke metoder bruker man?

Erin Hess

Det finnes et overlapp mellom testing og empati. Du kan ikke kjenne noens forventninger hvis du ikke kjenner erfaringene deres.

Å sette seg inn i en annens erfaring er en viktig del av testing, og vi gjør det hele tiden uten å tenke over det. Det kan for eksempel være å teste et tema med høy kontrast eller en dysleksivennlig skrifttype. Det finnes en grunn til at disse tingene er der. Dette overlappet mellom testing og empati hører derfor tydelig hjemme innen tilgjengelighetstesting.

Michael Luchen

Det er interessant å snakke med deg. På de siste 25 minuttene har flere temaer blitt tydelige, blant annet hvordan det å være en forkjemper for tilgjengelighet henger sammen med alt du gjør som testingeniør, og hvor viktig samarbeid er for testingeniørrollen.

Ikke bare med produktlederen, men med produktteamet som helhet.

Før vi avslutter, vil jeg gjerne stille noen personlige spørsmål i lynrundeformat, hvis det er greit.

Erin Hess

Bare spør.

Michael Luchen

Det første er: Hvilken personlig vane har bidratt mest til suksessen din?

Erin Hess

Jeg vil si at det definitivt er evnen min til å skape struktur og organisere store mengder informasjon, noe jeg har utviklet over tid.

Det er en av superkreftene mine. Jeg tror dette kommer fra besettelsen min av organisering generelt, og fra lidenskapen for å skrive god, nyttig og meningsfull dokumentasjon.

Michael Luchen

Flott. Og hva er favorittverktøyet ditt som du bruker regelmessig?

Erin Hess

Det må være Chrome DevTools, av mange grunner. Jeg vil særlig trekke frem enhetsmodus, som du kan bruke til å simulere mobile enheter, teste responsivitet og ulike spesifikke visningsområder. Nettverkspanelene er min beste venn. Jeg bruker dem definitivt når jeg går inn i utviklerverktøyene for å rapportere noe hvis jeg finner en feil. Jeg begynner ofte å undersøke der først. Og så har vi Lighthouse og Axe til tilgjengelighetstesting.

Michael Luchen

Flott. Siste spørsmål: Hva er ett råd du vil gi til noen som er i starten av reisen sin innen produktarbeid?

Erin Hess

Et råd jeg vil gi til noen som er i starten, er å være åpen for å lære hva som helst, uansett hvem det kommer fra. Hvis en utvikler, designer eller produktleder ønsker tiden eller oppmerksomheten din for å gjøre noe, så grip muligheten. Bruk det som en læringsopplevelse og få noe ut av den.

Michael Luchen

Veldig godt sagt. Jeg har absolutt lært mye i dag. Tusen takk for at du ville være med i programmet, Erin.

Erin Hess

Bare hyggelig. Takk for invitasjonen. Jeg ser frem til å snakke enda mer om tilgjengelighetstesting og testingeniørarbeid generelt.

Michael Luchen

Jeg gleder meg til å gå dypere inn i dette. For dere som lytter og vil lære mer av Erin, kan dere finne mer informasjon om arbeidet hennes på crema.us. Finn henne på LinkedIn. Erin er også aktiv på Twitter, der dere finner henne under brukernavnet @QueenTester.

Hvis du likte dagens episode, kan du sjekke ut vår relaterte publikasjon, QA Lead, der vi utforsker det nyeste og beste innen automatisering og testing. Du finner den på theqalead.com.

Nok en gang: Tusen takk for at du ble med i programmet i dag, Erin. Dette har vært en fantastisk episode. Takk til alle som lyttet. Husk å legge igjen en anmeldelse av denne podkasten. Jeg vil gjerne høre tilbakemeldingene dine. Husk også å følge og bli med i fellesskapet vårt på theproductmanager.com. Takk.