Betydningen af kvalitetsudvikling er dukket op igen, efterhånden som hele brancher skifter til fjernarbejde, samtidig med at de forsøger at opretholde kvaliteten af deres processer og produkter.
COVID var en omvæltning for hele verden. Da regeringer indførte krav om social afstand og karantæneforanstaltninger, måtte virksomheder gentænke deres arbejdsmetoder.
Som tester, SDET, QA-ingeniør eller i en hvilken som helst anden rolle med ansvar for at fremme kvaliteten i din virksomhed blev din dagligdag sandsynligvis forstyrret.
Effektiv kvalitetsudvikling i en fjernopsætning
Før pandemien arbejdede jeg allerede fuldt ud på afstand hos Auth0 (en globalt distribueret fjernvirksomhed), og jeg har også tidligere arbejdet på afstand i andre virksomheder.
I denne artikel vil jeg dele mine råd, kneb og processer til at håndtere fjernarbejde og kvalitetssikringspraksis. Da tendenserne inden for kvalitetsudvikling udvikler sig hurtigt, især i fjernmiljøer, er det vigtigt at holde sig opdateret om de værktøjer og strategier, der kan understøtte denne ændring.
Det vigtigste generelle råd, jeg kan give dig, er at være forberedt på asynkron kommunikation – du vil ofte være nødt til at vente på at kunne interagere, og du bliver nødt til at lære at håndtere det.
Når du implementerer fjernarbejdspraksis, er det vigtigt at forstå forskellen mellem kvalitetsudvikling og kvalitetssikring. Mens kvalitetssikring typisk fokuserer på at opdage fejl efterfølgende, er kvalitetsudvikling en mere holistisk og forebyggende tilgang, der sikrer, at kvalitet er indbygget i alle udviklingsfaser.
Strategier og tips til QA-ingeniører, der arbejder på afstand
1. Ansvarsfraskrivelse: Dette er ikke helt det sædvanlige
Under pandemien oplevede fjernarbejdere ofte ekstra stress og pres (børn derhjemme, uhensigtsmæssige arbejdsforhold i hjemmet, dødsfald eller sygdom i familien osv.). Uanset om du er leder, teamleder, senior eller junior, er det afgørende at forstå, at det, der foregår lige nu, ikke er et billede på det normale. COVID var et særtilfælde (forhåbentlig!), og derfor krævede det ekstra tilpasning fra alle.
Som leder skal du vise dine direkte medarbejdere, at du er der for at hjælpe. Som teknisk leder eller principalingeniør skal du give dit team retning, men også vise, at du er et menneske, og at de også skal føle sig trygge ved at vise sårbarhed. Og for alle andre: Føl ikke et pres for at præstere, som du plejer – det er forståeligt, at tingene går langsommere.
Virksomheder bør anerkende, at deres teams hastighed vil falde, og at fjernarbejde ikke er skyld i det. Det er unikke omstændigheder. Fjernarbejde gør det muligt for din virksomhed at fungere, selv om det ikke sker i fuldt tempo.
2. Kodegennemgange er en af dine bedste kvalitetsporte
Selv hvis du traditionelt har haft en mere manuel kvalitetsrolle i din virksomhed, bør kodegennemgange allerede være på din radar. De er ofte en vigtig del af livscyklussen for softwareudvikling og fungerer som et kontaktpunkt, hvor folk er nødt til at kommunikere med hinanden for at forbedre kodekvaliteten og forebygge fejl.
I en fjernsituation er de særligt vigtige, fordi de er en naturlig rutine, som normalt allerede er på plads, og derfor er de nemme at håndhæve. Hvis de bruges korrekt, hjælper de dig med de problemer med asynkron kommunikation, som jeg nævnte tidligere. Ved at anvende den rigtige software til kvalitetsudvikling kan du forbedre kodegennemgangsprocesserne betydeligt, effektivisere kommunikationen og reducere fejl, før de opstår.
Have an account? Log In
Mine bedste tips til kodegennemgange:
- Opfordr folk til først at gennemgå deres egen kode: Selvgennemgang er en praksis, hvor den person, der foreslår kodeændringen, også gennemgår sin egen kode og skriver nyttige kommentarer, før vedkommende beder om en offentlig gennemgang. Det reducerer den tid, som fremtidige reviewere spilder, og kan endda hjælpe personen, der gennemgår sin egen kode, med at finde små, fjollede fejl på forhånd;
- Gennemfør kodegennemgang i par eller gruppesessioner: Det er især nyttigt i tilfælde, hvor en PR berører følsom kode eller er en forholdsvis stor ændring (såsom en refaktorering). Den person, der foreslår en ændring, kan deltage i et videomøde, dele sin skærm og forklare sin PR for teamet eller en kollega. Det hjælper virkelig med hurtigt at få alle på samme side og kan i høj grad bidrage til at forbedre kodekvaliteten.
- Involvér udviklere i gennemgangen af kode til automatisering: Det er vigtigt, at udviklere deltager i gennemgangen af kode til automatisering/test. Det holder deres forståelse af, hvordan applikationen testes, opdateret og hjælper med at håndhæve den samme form for kodekvalitet på tværs af al kode;
- Sørg for, at SDET'er/testere gennemgår applikationskode: Dette er virkelig afgørende. Kvalitetsingeniører bør deltage i kodegennemgange. Du kan endda gøre dette, hvis du ikke er særlig teknisk (det er en god start på at finde ud af, hvad du skal lære!). Ikke alene kan du give værdifuld feedback, men du får også viden om, hvad der præcis ændrer sig i applikationen (noget, du måske går glip af på grund af den nye asynkrone opsætning). Denne viden hjælper dig med at træffe bedre testbeslutninger for teamet.
Hvis I endnu ikke har en streng proces for kodegennemgang, er dette et godt tidspunkt at argumentere for at forbedre den. Det er et grundlæggende værktøj i en tid, hvor synkron kommunikation kan være vanskeligere.
Vær ikke bange for at benytte værktøjer til kodegennemgang til at hjælpe jer med at organisere og samarbejde.
3. Udnyt styrken ved programmering i par
Jeg vil ikke gå i detaljer med programmering i par eller programmering i grupper, da det ville være en helt anden artikel, og der findes masser af information om det online.
Jeg ville dog gerne påpege, at dette er et meget værdifuldt værktøj i en tid som denne. Uanset om du arbejder sammen med en anden SDET på testkode, eller om du arbejder sammen med en udvikler på applikationskode, synes jeg, at det er en fantastisk praksis, som hjælper med at styrke sammenholdet i teamet, dele viden og øge kvaliteten af kode og applikation.
Her er nogle ofte stillede spørgsmål om programmering i par samt svarene:
Hvad er programmering i par?
Som navnet antyder, er programmering i par en aktivitet, hvor to personer bidrager sammen til den samme kode. Det kan også gøres med flere personer, og det kaldes typisk programmering i grupper.
Hvordan fungerer programmering i par?
Ved programmering i par har man normalt en chauffør (som skriver koden) og en navigatør (eller observatør). Det fungerer godt med værktøjer til fjernmøder, hvor den ene person kan dele sin skærm og skrive koden, mens den anden kan komme med forslag, kommentarer eller påmindelser eller hjælpe med at opdage og forhindre fejl.
Hvilke værktøjer bruger I til programmering i par?
Hvis du har lyst til at samarbejde, har VS Code (for eksempel) udviklet fremragende samarbejdsfunktioner med (Visual Studio Live Share), som gør det muligt for flere personer at arbejde på et delt projekt. Det fungerer meget bedre, end man skulle tro – det er meget kraftfuldt, og det fungerer rigtig godt med personer, der allerede kender hinanden, eller som har lignende arbejdsstile.
Kan man programmere i par med personer uden teknisk baggrund?
Ja, og det er en fantastisk mulighed for at udvikle mentorfærdigheder såvel som teknisk viden i teamet.
Har I udviklere, som er særligt interesserede i at undervise, eller som måske har erfaring med at afholde workshops eller vejledninger? De kan arbejde sammen med dig for at føre dig gennem kodebasen, så du kan få mere erfaring, hvis du endnu ikke har stor teknisk viden.
Hvad med test?
Til test kan du prøve noget, jeg vil kalde "omvendt programmering i par". Det vender programmering i par på hovedet og handler i stedet om test i par eller grupper. Arbejd sammen med udviklere for at vise dem, hvordan du tester applikationen, eller lad dem hjælpe dig med at teste den – eller omvendt! Det er en virkelig nyttig måde at håndtere komplekse problemer på. Læs nogle idéer om det i endnu en fremragende artikel af Maaret Pyhäjärvi.
4. Afhold fjernsessioner til test for at samarbejde som et team: fejlfindingssessioner, spildage osv.
Testsessioner (nogle gange kaldet fejlfindingssessioner, spildage osv.) er en samarbejdsaktivitet, der typisk udføres af et team.
Det kan være for at teste en specifik ny funktion, eller det kan foregå regelmæssigt for at teste applikationen. De rigtige QE-værktøjer kan gøre en stor forskel under disse samarbejdssessioner, da de giver indsigt i realtid og forenkler komplekse testmiljøer.
Idéen er at samle personer fra og uden for teamet fra mange forskellige fagområder (udvikling, test, produkt, design, forretningsinteressenter osv.) for at teste applikationen. Som udviklere eller testere kan vi nogle gange have en teknisk forudindtaget idé om, hvordan applikationen bør se ud, så det kan give meget værdifuld feedback at få andre interessenter til at se på den.
Jeg syntes, det var vigtigt at fremhæve dette, fordi jeg mener, at det er en god aktivitet at have i disse tider. Det bringer teams sammen og fremmer kommunikation og samarbejde mellem forskellige afdelinger, hvilket potentielt kan afdække fejl eller forkerte specifikationer, som ellers kunne være blevet overset.
Det kan selvfølgelig være en udfordring at afholde disse sessioner på afstand, så her er nogle tips til det (og til at afholde dem generelt).
Tips til afholdelse af testsessioner på afstand:
- Du bør kunne afholde disse sessioner via et videokonferenceværktøj. Sørg også for, at der er en chat til rådighed (hvis I bruger Slack, kan I eventuelt oprette en separat Slack-kanal til det);
- I situationer, hvor der er brug for enheder (f.eks. mobiltelefoner eller enheder til stuen osv.), skal du sørge for på forhånd at vide, hvad folk har til rådighed. Hvis du tester en iOS-app og inviterer en person uden en iPhone, er det spild af alles tid;
- Hav altid en eller flere personer, der er ansvarlige for hver af disse sessioner. Det betyder, at de skal hjælpe med at organisere den på forhånd, forberede den nødvendige dokumentation eller opsætning for deltagerne og facilitere sessionen;
- Du bør udarbejde tydelige installationsinstruktioner til deltagerne og gøre dem tilgængelige før sessionen. Tiden under sessionen skal bruges på test, ikke installation;
- Du bør også have tydelige instruktioner om, hvordan problemer skal rapporteres, selv hvis det blot er “slå det op i kanalen” (i stedet for at alle forsøger at rapportere problemer på et konferenceopkald på samme tid);
- Hav en plan for sessionen. I situationer som denne er det nyttigt, at folk følger en eller anden form for manuskript eller i det mindste en plan for, hvad de skal se på;
- Når det er sagt, skal du stadig opfordre til eksplorativ test, men husk på, at nogle personer måske har brug for et lille skub for at komme i gang med at udforske.
- Du kan stadig afholde disse sessioner på systemer med fokus på backend. En interessant øvelse kunne være at omdanne det til et eksperiment med kaosteknik med en mere teknisk orienteret gruppe. AWS har en version af disse, der kaldes spildage, som du kan hente inspiration fra.
- Opfordr til sjov! Disse sessioner kan være meget underholdende, hvis de udføres rigtigt – jeg plejede at gøre testsessioner til en leg med karakterer fra Game of Thrones, da jeg afholdt dem hos Miniclip for mange år siden.
Du kan også finde mere detaljerede oplysninger om det i dette blogindlæg, som gennemgår flere af de ting, jeg nævnte ovenfor.
5. Administrer din fritid fornuftigt – styrk dine færdigheder inden for kvalitetsudvikling
Som jeg har nævnt, bliver du nødt til at vænne dig til asynkron kommunikation. I testverdenen (afhængigt af teamets dynamik) kan en testers opgaver ofte afhænge af, at udviklingsarbejdet bliver færdiggjort. Når teams arbejder langsommere, og kommunikationen foregår på en anden måde, kan du opleve at have lidt fritid til rådighed.
Jeg husker, at jeg i en tidligere virksomhed havde en kollega, der ofte sagde under statusmødet: “Jeg er blokeret af x”, hvorefter han brugte dagen på at vente på at blive frigivet. På et tidspunkt hjalp jeg ham med at forbedre sine færdigheder på forskellige områder, og en af de ting, der skulle arbejdes med, var netop denne indstilling. Det gælder især nu, hvor du ud over potentielt flere perioder uden opgaver også befinder dig i hjemmets trygge rammer med masser af distraktioner lige ved hånden.
Det er vigtigt, at du administrerer din tid og fører en backlog over ting, du er interesseret i at lære.
Her er nogle eksempler på ting, du kan gøre i din fritid:
- Har du hidtil primært arbejdet med manuel QA? Måske vil du bruge tid på at lære om automatisering.
- Har du stor viden om brugerfladen? Måske bør du bruge noget tid på også at opnå viden om serverdelen.
- Der findes mange gode gratis ressourcer som freeCodeCamp eller YouTube, eller billige alternativer som Udemy (de kører ofte tilbud). Derudover er der mange konferencer, der er blevet virtuelle på grund af coronavirus, og nogle er gratis at deltage i (f.eks. OnlineTestConf)!
- Eller måske vil du lære mere om applikationen ved at gennemgå applikationskoden.
- Eller måske ved du, at der kommer et nyt projekt, og at du skal tilegne dig en ny færdighed til det.
- Derudover kan du også bruge tiden på at lave prototyper af nye idéer, rydde op i teknisk gæld, dokumentation osv.
Det er egentlig ikke afgørende. Vælg det, der passer dig, men investér i din personlige udvikling.
Det betyder ikke, at du ikke må holde en pause (det er trods alt en global pandemi). Folk vil forstå det. Men det er værdifuldt at øge dit QA-kompetencesæt eller forbedre dig selv, især i tider som disse, hvor arbejdsmarkedet er gået kraftigt tilbage.
More Articles
6. Brug teamaktiviteter til at opbygge relationer
Som en sidste bemærkning vil jeg sige, at jeg synes, det er vigtigt at opmuntre til aktiviteter i teamet, selvom dette ikke ligefrem er et testrelateret forslag. Disse relationer er vigtige og fungerer som en kærkommen afledning fra arbejdet. Man får dem som regel mere naturligt i et kontormiljø, måske under frokosten eller en kaffepause eller blot gennem en tilfældig kommentar i det samme rum.
Nogle tips til at opbygge relationer i et virtuelt arbejdsmiljø:
- I mit nuværende team har vi netop opsat Donut Slack-appen på vores teamkanal. Den sætter os tilfældigt sammen med et teammedlem hver uge til en samtale – vi kan tale om hvad som helst der.
- Vi har også en fredagsbogklub, hvor vi skiftes til at dele viden med hinanden (vi fokuserer på emner, der er relevante for arbejdet, men det kan være hvad som helst!);
- Opret fælles frokoster eller kaffepauser på kanalen, hvor I tilbringer noget tid sammen, ligesom I ville gøre på et kontor. Det fungerer naturligvis bedst, hvis I alle befinder jer i lignende tidszoner;
- Lav quizzer eller spil onlinespil sammen en gang imellem. Jackbox Party Pack er et godt eksempel på noget, der fungerer rigtig godt i virtuelle arbejdsmiljøer.
Tilmeld dig for at få flere indsigter
Hvis du vil have flere tips, råd og strategier inden for kvalitetssikring, kan du tilmelde dig The CTO Clubs nyhedsbrev for at få de seneste indsigter. Vi hjælper dig med at skalere mere intelligent og lede stærkere med vejledninger, ressourcer og strategier fra førende eksperter!
