6 triks innen kvalitetsteknikk for eksterne utviklerteam

Betydningen av kvalitetsutvikling har igjen blitt aktualisert ettersom hele bransjer går over til fjernarbeid, samtidig som de forsøker å opprettholde kvaliteten på prosessene og produktene sine. 

COVID-19 var en omveltende begivenhet for hele verden. Da myndighetene innførte tiltak for sosial distansering og karantene, måtte selskaper finne nye arbeidsmetoder. 

Som tester, SDET, QA-ingeniør eller i en annen rolle med ansvar for å fremme kvalitet i selskapet ditt, ble arbeidshverdagen din sannsynligvis forstyrret.

Effektiv kvalitetsutvikling i et fjernoppsett

Før pandemien jobbet jeg allerede helt eksternt i Auth0 (et globalt distribuert selskap med fjernarbeid), og jeg har også jobbet eksternt i andre selskaper. 

I denne artikkelen deler jeg tips, triks og prosesser for å håndtere fjernarbeid og praksis for kvalitetssikring. Ettersom trendene innen kvalitetsutvikling utvikler seg raskt, særlig i fjernmiljøer, er det viktig å holde seg oppdatert på verktøyene og strategiene som kan støtte denne overgangen.

Det viktigste generelle rådet jeg kan gi deg, er å være forberedt på asynkron kommunikasjon – du må ofte vente på å få samhandlet, og du må lære å håndtere det.

Når du innfører praksis for fjernarbeid, er det viktig å være klar over forskjellen mellom kvalitetsutvikling og kvalitetssikring. Mens kvalitetssikring gjerne fokuserer på å oppdage feil i etterkant, er kvalitetsutvikling en mer helhetlig og forebyggende tilnærming som sørger for at kvalitet bygges inn i alle utviklingsfaser.

Strategier og tips for QA-ingeniører som jobber eksternt

1. Ansvarsfraskrivelse: Dette er ikke helt som normalt 

Under pandemien opplevde fjernarbeidere ofte ekstra stress og press (barn hjemme, uegnede kontorforhold hjemme, dødsfall eller sykdom i familien osv.). Enten du er leder, fagansvarlig, senior eller junior, er det avgjørende at du forstår at det som skjer nå, ikke er det som er normalt. COVID-19 var et særtilfelle (forhåpentligvis!), og derfor krevde situasjonen ekstra tilpasning fra alle.  

Som leder bør du vise medarbeiderne som rapporterer direkte til deg, at du er der for å hjelpe. Som teknisk leder eller hovedansvarlig bør du gi teamet ditt retning, men samtidig vise at du også er menneskelig, slik at de føler seg trygge på å vise sårbarhet. Og for alle andre: Ikke føl press for å prestere slik du vanligvis gjør – det er forståelig at ting går saktere.  

Selskaper bør erkjenne at teamenes fremdrift vil reduseres, og at fjernarbeid ikke er årsaken til dette. Dette er en unik situasjon. Fjernarbeid gjør det mulig for selskapet å fungere, selv om det ikke skjer i full fart.  

2. Kodegjennomganger er en av dine beste kvalitetskontroller  

Selv om du tradisjonelt har hatt en mer manuell kvalitetsrolle i selskapet, bør kodegjennomganger allerede være på radaren din. De er ofte en viktig del av livssyklusen for programvareutvikling og fungerer som et kontaktpunkt der folk blir nødt til å kommunisere med hverandre for å forbedre kodekvaliteten og forhindre feil. 

I en ekstern arbeidssituasjon er de spesielt viktige fordi de er en naturlig rutine som vanligvis allerede er etablert, og derfor er enkle å håndheve. Hvis de brukes riktig, vil de hjelpe deg med problemene knyttet til asynkron kommunikasjon som jeg nevnte tidligere. Ved å ta i bruk riktig programvare for kvalitetsutvikling kan du forbedre kodegjennomgangsprosessene betydelig, effektivisere kommunikasjonen og redusere feil før de oppstår.

Mine beste tips for kodegjennomganger:

• Oppmuntre folk til å gjennomgå sin egen kode først: Egen gjennomgang er en praksis der personen som foreslår kodeendringen, også gjennomgår sin egen kode og legger igjen nyttige kommentarer før vedkommende ber om en offentlig gjennomgang. Det reduserer tiden fremtidige gjennomgåere bruker på unødvendig arbeid, og kan til og med hjelpe den som gjennomgår sin egen kode, med å oppdage små, dumme feil på forhånd; 
• Gjør kodegjennomgang i par eller som gruppeøkter: Dette er spesielt nyttig når PR-en berører sensitiv kode eller er en ganske omfattende endring, for eksempel en refaktorering. Den som foreslår endringen, kan delta i en videokonferanse, dele skjermen sin og forklare PR-en for teamet eller en kollega. Dette hjelper virkelig alle med å raskt få en felles forståelse, og kan bidra mye til å forbedre kodekvaliteten. 
• Involver utviklere i gjennomgangen av kode for automatisering: Det er viktig at utviklere deltar i kodegjennomgangen av automatiserings- og testkoden. Dette holder forståelsen deres av hvordan applikasjonen testes, oppdatert, og bidrar til å håndheve den samme typen kodekvalitet i all kode; 
• Sørg for at SDETer/testere gjennomgår applikasjonskode: Dette er virkelig viktig. Kvalitetsingeniører bør delta i kodegjennomganger. Du kan til og med gjøre dette selv om du ikke er særlig teknisk (det er en flott start for å finne ut hva du må lære!). Ikke bare kan du gi verdifulle tilbakemeldinger, du vil også tilegne deg kunnskap om hva som faktisk endres i applikasjonen (noe du kanskje går glipp av på grunn av den nye asynkrone arbeidsformen). Denne kunnskapen vil hjelpe deg med å ta bedre testbeslutninger for teamet.

Hvis dere ikke allerede har en streng prosess for kodegjennomgang, er dette et godt tidspunkt å argumentere for å forbedre den. Det er et grunnleggende verktøy i en tid der synkron kommunikasjon kan være vanskeligere. 

Ikke vær redd for å ta i bruk verktøy for kodegjennomgang for å hjelpe dere med å organisere og samarbeide.

3. Utnytt kraften i parprogrammering

Jeg skal ikke gå inn på detaljene i parprogrammering eller gruppeprogrammering, siden det ville blitt en helt egen artikkel, og det finnes rikelig med informasjon om dette på nettet.

Jeg vil imidlertid påpeke at dette er et svært verdifullt verktøy i en tid som dette. Enten det er du som samarbeider med en annen SDET om testkode, eller du som jobber sammen med en utvikler om applikasjonskode, mener jeg at dette er en flott praksis som vil bidra til å knytte teamet tettere sammen, dele kunnskap og øke kvaliteten på koden og applikasjonen. 

Her er noen vanlige spørsmål om parprogrammering, med svar:

Hva er parprogrammering?

Som navnet antyder, er parprogrammering en aktivitet der to personer bidrar sammen på den samme koden. Det kan også gjøres med flere personer, og kalles vanligvis gruppeprogrammering. 

Hvordan fungerer parprogrammering?

Vanligvis har man i parprogrammering en sjåfør (som skriver koden) og en navigatør (eller observatør). Dette fungerer godt med verktøy for fjernkonferanser, der én person kan dele skjermen sin og skrive koden, mens den andre kan komme med forslag, kommentarer eller påminnelser, eller bidra til å oppdage og forhindre feil.

Hvilke verktøy bruker dere til parprogrammering?

Hvis dere ønsker å samarbeide, har for eksempel VS Code utviklet utmerkede samarbeidsfunksjoner med Visual Studio Live Share, som gjør at flere personer kan jobbe på et delt prosjekt. Det fungerer mye bedre enn man kanskje skulle tro – det er svært kraftig, og fungerer veldig godt med personer som allerede kjenner hverandre eller har lignende arbeidsstiler.

Kan man parprogrammere med personer uten teknisk bakgrunn?

Ja, og det er en flott mulighet til å utvikle mentorferdigheter så vel som teknisk kunnskap i teamet. 

Har dere utviklere som er spesielt interessert i å undervise, eller som kanskje har erfaring med å holde kurs eller opplæring? De kan jobbe sammen med deg for å veilede deg gjennom kodebasen, slik at du får mer erfaring hvis du ennå ikke har så mye teknisk kunnskap.

Hva med testing?

For testing kan du prøve noe jeg vil kalle «omvendt parprogrammering». Dette snur parprogrammering på hodet og handler i stedet om par- eller gruppetesting. Jobb sammen med utviklere for å vise dem hvordan du tester applikasjonen, la dem hjelpe deg med å teste den, eller gjør det omvendt! Dette er en svært nyttig måte å håndtere komplekse problemer på. Les noen ideer om dette i en annen utmerket artikkel av Maaret Pyhäjärvi.

4. Gjennomfør eksterne testøkter for å samarbeide som et team: feiljakter, spilldager og mer. 

Testøkter (noen ganger kalt bugjakter, spilldager osv.) er en samarbeidsaktivitet som vanligvis gjennomføres av et team. 

Det kan være for å teste en bestemt ny funksjon, eller det kan gjennomføres med jevne mellomrom for å teste applikasjonen. De riktige verktøyene for kvalitetsutvikling kan være avgjørende under disse samarbeidsøktene, ved å gi innsikt i sanntid og forenkle komplekse testmiljøer.

Ideen er å samle personer fra og utenfor teamet, fra mange fagområder (utvikling, testing, produkt, design, forretningsinteressenter osv.), for å teste applikasjonen. Som utviklere eller testere kan vi noen ganger ha en teknisk fokusert og forutinntatt oppfatning av hvordan applikasjonen bør se ut, så det å få andre interessenter til å se på den kan gi svært verdifulle tilbakemeldinger. 

Jeg syntes det var viktig å trekke frem dette fordi jeg mener det er en flott aktivitet å ha i disse tidene. Den samler team og oppmuntrer til kommunikasjon og samarbeid mellom ulike avdelinger, og kan avdekke feil eller uriktige spesifikasjoner som ellers kunne blitt oversett.  

Det kan selvfølgelig være utfordrende å gjennomføre disse eksternt, så her er noen tips til dette (og til gjennomføring generelt).

Tips for gjennomføring av eksterne testøkter:

• Du bør kunne gjennomføre disse via et videokonferanseverktøy. Sørg også for at du har en chat tilgjengelig (hvis du bruker Slack, kan du kanskje opprette en egen Slack-kanal for dette); 
• I situasjoner der det er nødvendig med enheter (f.eks. mobiltelefoner eller enheter i stuen osv.), må du sørge for å vite hva folk har på forhånd. Hvis du tester en iOS-app og inviterer noen uten iPhone, er det bortkastet tid for alle; 
• Ha alltid én eller flere personer som er ansvarlige for hver av disse øktene. Det betyr at de bør bidra til å organisere den på forhånd, forberede eventuell nødvendig dokumentasjon eller oppsett for deltakerne og lede økten; 
• Du bør lage tydelige instruksjoner for installasjon for deltakerne og gjøre dem tilgjengelige før økten. Tiden i økten skal brukes på testing, ikke installasjon; 
• Du bør også ha tydelige instruksjoner for hvordan problemer skal rapporteres, selv om det bare er «legg det ut i kanalen» (i stedet for at alle prøver å rapportere problemer i en konferansesamtale samtidig); 
• Ha en plan for økten. I situasjoner som dette er det nyttig at folk følger et slags manus, eller i det minste en plan for hva de skal se på;
• Når det er sagt, bør du fortsatt oppmuntre til utforskende testing, men husk at noen kanskje trenger litt hjelp for å komme i gang med utforskingen. 
• Du kan fortsatt gjennomføre disse på mer baksystemorienterte systemer. En interessant øvelse kan være å gjøre dette om til et eksperiment innen kaosteknikk, med en mer teknologiorientert gruppe. AWS har en versjon av dette kalt spilldager, som du kan hente ideer fra.
• Oppmuntre til moro! Disse kan være svært underholdende hvis de gjennomføres riktig – jeg pleide å gjøre testøkter til et spill med Game of Thrones-karakterer da jeg gjennomførte dem hos Miniclip for mange år siden. 

Du finner også mer detaljert informasjon om dette i dette blogginnlegget, som dekker flere av tingene jeg nevnte ovenfor.

5. Forvalt fritiden din klokt – styrk ferdighetene dine innen kvalitetsutvikling

Som jeg har nevnt, må du venne deg til asynkron kommunikasjon. I testverdenen (avhengig av teamdynamikken) kan en testers oppgaver ofte være avhengige av at utviklingsarbeidet blir ferdigstilt. Når team beveger seg i et lavere tempo og kommunikasjonen foregår på en annen måte, kan du oppleve å få litt fritid til overs. 

Jeg husker at jeg hadde en kollega i en tidligere bedrift som ofte sa i statusmøtet «Jeg er blokkert av x», og deretter brukte dagen på å vente på å bli avblokkert. På et tidspunkt hjalp jeg ham med å forbedre ferdighetene sine på ulike områder, og én av tingene som måtte bearbeides, var nettopp denne tankegangen. Dette gjelder spesielt nå, når du i tillegg til mulige økninger i perioder uten oppgaver også befinner deg hjemme i komfortable omgivelser, med mange distraksjoner tilgjengelig. 

Det er viktig at du håndterer tiden din og fører en liste over ting du er interessert i å lære. 

Her er noen eksempler på ting du kan gjøre på fritiden: 

• Har du hovedsakelig jobbet med manuell QA? Kanskje du bør investere tid i å lære om automatisering.  
• Har du mye frontendkunnskap? Kanskje du bør bruke litt tid på å lære deg backend også.
• Det finnes mange gode gratisressurser, som freeCodeCamp eller Youtube, og rimelige alternativer som Udemy (de har ofte tilbud). I tillegg finnes det mange konferanser som har blitt digitale på grunn av koronaviruset, og noen er gratis å delta på (f.eks. OnlineTestConf)!
• Eller kanskje du ønsker å lære mer om applikasjonen ved å gå gjennom applikasjonskoden. 
• Eller kanskje du vet at et nytt prosjekt kommer, og at du må tilegne deg en ny ferdighet til det. 
• I tillegg kan du bruke denne tiden på å lage prototyper av nye ideer, rydde opp i teknisk gjeld, dokumentasjon osv.  

Det spiller egentlig ingen rolle. Velg det som passer, men invester i din personlige utvikling. 

Det betyr ikke at du ikke kan ta deg en pause (det er tross alt en global pandemi). Folk vil forstå det. Men det er verdifullt å øke QA-kompetansen din eller utvikle deg selv, særlig i tider som dette, når arbeidsmarkedet har fått en kraftig nedtur. 

6. Bruk teamaktiviteter til å utvikle relasjoner 

Som en siste bemerkning vil jeg si at jeg synes det er viktig å oppmuntre til aktiviteter i teamet ditt, selv om dette ikke egentlig er et testrelatert forslag. Disse relasjonene er viktige og gir et kjærkomment avbrekk fra arbeidet. På et kontor får man vanligvis slike relasjoner mer naturlig, for eksempel under lunsjen, i en kaffepause eller bare gjennom en tilfeldig kommentar i samme rom. 

Noen tips for å bygge relasjoner når dere jobber eksternt: 

• I teamet jeg jobber i nå, har vi nettopp satt opp Donut Slack-appen i teamkanalen vår. Den kobler oss tilfeldig sammen med et teammedlem hver uke for en samtale – vi kan snakke om hva som helst der.
• Vi har også en bokklubb på fredager, der vi etter tur deler kunnskap med hverandre (vi fokuserer på emner som er relevante for arbeidet, men det kan være hva som helst!); 
• Sett opp lunsjer eller kaffepauser for teamet i kanalen, der dere tilbringer litt tid sammen slik dere ville gjort på et kontor. Dette fungerer selvfølgelig best hvis dere befinner dere i omtrent samme tidssone; 
• Arranger quiz eller spill nettspill sammen av og til. Jackbox Party Pack er et godt eksempel på noe som fungerer svært godt i eksterne arbeidsmiljøer.

Bli med for mer innsikt

For flere tips, råd og strategier om kvalitetssikring kan du abonnere på The CTO Clubs nyhetsbrev for den nyeste innsikten. Vi hjelper deg med å skalere smartere og lede sterkere gjennom veiledninger, ressurser og strategier fra ledende eksperter!