Se for deg denne hypotetiske situasjonen: Du jobber i Easy LMS med et fantastisk GDPR-kurs. Det er fantastisk fordi du har gjort det morsomt med kule infografikker og tiltalende videoer. Farvel, farvel kjedelig opplæring i etterlevelse. All GDPR-informasjonen er der; du trenger bare å legge den inn i systemet. Alt går som smurt. Helt til du vil laste opp en video. Plutselig er hele kurset borte! Bare med ett klikk. Aaargh!
Dette er selvsagt noe du og vi ikke ønsker! Vi synes det er bedre å finne ut at noe er ødelagt før kundene våre gjør det. Derfor har vi en omfattende kvalitetssikringsprosedyre (QA) som inkluderer manuell og automatisk testing. I denne artikkelen vil vi kun fokusere på manuell testing. For noen ganger trenger du bare mennesker i stedet for roboter? Velkommen til vår verden av manuell testing!
Hva er kvalitetssikring? Og hvorfor trenger vi det?
QA-ansvarlige er ofte portvakten som avgjør om en funksjon eller en rettet feil er klar for lansering eller ikke
La oss først ta et skritt tilbake, i tilfelle du blir overveldet av begrepet kvalitetssikring? Hva er kvalitetssikring? Og hvorfor trenger du det? Kvalitetssikring (QA) er å sørge for at noe fungerer som tiltenkt. Etter vår mening er det å ha en QA-prosess avgjørende for vårt (programvare)produkt og kundetilfredshet, og dermed også for selskapets suksess. Kvalitetssikringsansvarlige er ofte portvokteren som avgjør om en funksjon eller en rettet feil er klar for lansering eller ikke.
Selv om noen kanskje reduserer kvalitetssikring til bare testing, mener vi at det er mer enn det. Å ha en god kvalitetssikring er like viktig som å bygge selv. Det sikrer at du kan oppfylle dine egne standarder for høy kvalitet! Det gjør også produktet ditt stabilt, og det gjør at teamet ditt føler seg trygt. Vi gjør alle feil; det er en uunngåelig del av det å være menneske, selv om du er en begavet utvikler (som vår?). Men å ha et sikkerhetsnett gjør at du føler deg fri i tankene og arbeidet, slik at du kan presse grensene dine. Dette vil føre til mer avanserte ferdigheter (utvikling, design, skriving, hva som helst) til slutt!
Hvem utfører testingen?
For ett år siden var Caroline vår eneste QA-ansvarlige. Hun testet alt som ble utviklet av utviklerne våre manuelt. Og vi kan fortelle deg at det var mye. Fordi vi etterstreber autonome team som kan operere helt på egen hånd, eksperimenterte vi med å kjøre en QA av utviklingsteamene selv. Eksperimentet var vellykket! "Å teste med teamet vårt føles som den riktige tingen å gjøre. Teamet vårt er tverrfaglig, så vi legger alle merke til forskjellige ting. Det gir oss mye større garanti for å oppdage små problemer enn om et enkelt medlem skulle teste på egen hånd. Vi vet også hvordan koden fungerer, så vi har en klarere idé om hvordan vi kan ødelegge den!", forklarer Bram, Back-End Developer.
Hvordan ser testprosedyren vår ut?
Vår manuelle testprosedyre består av seks trinn. La oss gå gjennom dem sammen!
Trinn 0: Kontroller om koden oppfyller kvalitetsstandarden vår.
Før vi begynner å teste manuelt, gjør vi en kodegjennomgang. En annen utvikler verifiserer kvaliteten på koden. Vi sjekker for eksempel eksplisitt for sikkerhetshull. I tillegg kjører vi automatiske tester som analyserer kvaliteten på koden. Disse testene må være vellykkede før vi fortsetter. Hvis testen mislykkes, går vi tilbake til tegnebrettet og løser problemene.
Trinn 1: Kontroller om alle akseptkriteriene er oppfylt.
Når vi bygger en ny funksjon, begynner vi med å skrive akseptkriterier. Akseptkriterier definerer hvordan en bestemt funksjon kan brukes fra kundens perspektiv. Vi tenker altså på hvordan en funksjon må fungere, slik at vi i etterkant kan teste om den fungerer som tiltenkt.
Trinn 2: Verifiser om vår definisjon av "ferdig" er oppfylt.
Definisjonen av "ferdig" er et avtalt sett med elementer som må være fullført før et prosjekt kan anses som fullført. Vår definisjon av ferdig inkluderer for eksempel
Trinn 3: Prøv å ødelegge ting
Vi tar kundens perspektiv. Først bruker vi funksjonen slik vi forventer at sluttbrukeren vil gjøre. Deretter tar vi det til det ekstreme. Vi gjentar handlinger mer enn én gang, bruker ekstreme testtilfeller og verifiserer at den nye funksjonen ikke ødelegger eksisterende funksjoner. Hva skjer med X hvis jeg trykker på den nye knappen Y? Vi tester også med ulike testkontoer med andre egenskaper.
Vi tar kundens perspektiv
Trinn 4: Test ut fra et sikkerhetssynspunkt.
Vi har som mål å være GDPR-kompatibel. Vi tar våre kunders data på alvor. Derfor tester vi for mulige sårbarheter med noen få vanlige hackingteknikker. Vi er gode mennesker, så vi bruker aldri disse teknikkene i det virkelige liv; ingen grunn til bekymring!
Trinn 5: Test de nye oversettelsene, og rediger dem.
Vi støtter 11 språk i dashbordet vårt, og spillergrensesnittet vårt er tilgjengelig på 24 språk. Vi har en gruppe frilansoversettere som oversetter all tekst manuelt i et eget oversettelsesverktøy. Vi kontrollerer at all tekst er lagt til i det verktøyet. Vi går også gjennom og redigerer dem, slik at de er klare til bruk med en gang!
Trinn 6: Vurder hvilket innhold som må oppdateres eller skrives.
En ny funksjon kommer som oftest med ny tekst. Vi forbereder alt internt eller eksternt innhold i forkant der det er mulig. Når vi lanserer en ny funksjon, vil vi at den skal være komplett! Det er i tråd med visjonen vår om én enkelt elementflyt!
"Å gjøre kvalitetssikring på en god måte kan være en tidkrevende oppgave. Jo flere perspektiver og øyne som er involvert, desto bedre. Det er en fordel å ha trinnene dokumentert slik at alle kan følge dem, i stedet for å stole på bare én person. Hos Easy LMS jobber vi i tverrfaglige team, med backend- og frontend-utviklere som jobber tett sammen med implementeringskonsulentene våre, som bringer inn kundeperspektivet. Det gir mening!", sier Caroline, QA Officer;
Når utfører vi manuell testing?
Hver eneste funksjon blir testet manuelt
Hver eneste funksjon blir testet manuelt og går gjennom den samme prosessen! Selv små funksjoner (som å bytte ut et bilde på hjemmesiden) som ved første øyekast ikke engang trenger å testes. Men djevelen ligger i detaljene og i små funksjoner? Vi gjennomfører vår manuelle testprosedyre når utviklingen er ferdig. Lyktes testen? Da er det på tide å lansere den slik at kundene våre kan få glede av den! Mislyktes testen? Da blir funksjonen undersøkt på nytt. Dette betyr at utviklingsteamet løser problemet og tester kvaliteten på nytt. Vi gjentar dette til alle boksene på sjekklisten for kvalitetssikring er krysset av.
