Forestil dig denne hypotetiske situation: Du arbejder i Easy LMS på et fantastisk GDPR-kursus. Det er fantastisk, fordi du har gjort det sjovt med cool infografik og tiltalende videoer. Farvel, farvel til kedelig compliance-træning. Alle GDPR-oplysningerne er der; du skal bare lægge dem ind i systemet. Alt går som smurt. Indtil du vil uploade en video. Pludselig er hele dit kursus væk! Bare med et enkelt klik. Aaargh!
Det er selvfølgelig noget, du og vi ikke ønsker! Vi synes, det er bedre at finde ud af, at noget er i stykker, før vores kunder gør det. Derfor har vi en omfattende kvalitetssikringsprocedure (QA), der omfatter manuel og automatisk testning. I denne artikel vil vi kun fokusere på manuel testning. For nogle gange har man bare brug for mennesker i stedet for robotter? Velkommen til vores verden af manuel testning!
Hvad er kvalitetssikring? Og hvorfor har vi brug for det?
QA-ansvarlige er ofte dem, der afgør, om en funktion eller en rettet fejl er klar til udgivelse eller ej.
Lad os først tage et skridt tilbage, hvis du skulle blive overvældet af begrebet kvalitetssikring? Hvad er kvalitetssikring? Og hvorfor har du brug for det? Kvalitetssikring (QA) er at sørge for, at noget fungerer efter hensigten. Efter vores mening er en QA-proces afgørende for vores (software)produkt og kundetilfredshed og dermed for vores virksomheds succes. QA-ansvarlige er ofte gatekeeperen, der afgør, om en funktion eller en rettet fejl er klar til udgivelse.
Mens nogle måske reducerer QA til blot at teste, mener vi, at det er mere end det. At have en god QA er lige så vigtigt som at bygge selv. Det sikrer, at du kan opfylde dine egne standarder for høj kvalitet! Det gør også dit produkt stabilt, og det får dit team til at føle sig trygge. Vi begår alle fejl; det er en uundgåelig del af det at være menneske, også selvom man er en dygtig udvikler (som vores?). Men at have et sikkerhedsnet får dig til at føle dig fri i sindet og arbejdet, så du kan flytte dine grænser. Det vil i sidste ende føre til mere avancerede færdigheder (udvikling, design, skrivning, you name it)!
Hvem udfører testen?
For et år siden var Caroline vores eneste QA-ansvarlige. Hun testede alt, hvad vores udviklere udviklede, manuelt. Og vi kan fortælle dig, at det var meget. Fordi vi stræber efter autonome teams, der kan arbejde helt alene, eksperimenterede vi med at køre en QA af udviklingsteamet selv. Eksperimentet var en succes! "At teste med vores team føles som den rigtige ting at gøre. Vores team er tværfagligt, så vi lægger alle mærke til forskellige ting. Det giver os en meget større garanti for at opdage små problemer, end hvis et enkelt medlem skulle teste alene. Vi ved også, hvordan koden fungerer, så vi har en klarere idé om, hvordan vi kan ødelægge den!", forklarer Bram, Back-End Developer.
Hvordan ser vores testprocedure ud?
Vores manuelle testprocedure består af seks trin. Lad os gennemgå dem sammen!
Trin 0: Kontrollér, om koden lever op til vores kvalitetsstandard.
Før vi begynder at teste manuelt, laver vi et kode-review. En anden udvikler verificerer kodens kvalitet. Vi tjekker f.eks. eksplicit for sikkerhedshuller. Vi kører også automatiske tests, der analyserer kodens kvalitet. Disse tests skal lykkes, før vi fortsætter. Hvis testen fejler, går vi tilbage til tegnebrættet og løser problemerne.
Trin 1: Kontrollér, om alle godkendelseskriterier er opfyldt.
Når vi bygger en ny funktion, begynder vi med at skrive acceptkriterier. Acceptkriterier definerer, hvordan en bestemt funktion kan bruges fra en kundes perspektiv. Så vi tænker på, hvordan en funktion skal fungere, så vi bagefter kan teste, om den fungerer efter hensigten.
Trin 2: Kontrollér, om vores definition af Done er opfyldt.
Definitionen af Done er et aftalt sæt af elementer, der skal være afsluttet, før et projekt kan betragtes som færdigt. Vores definition af færdig omfatter f.eks:
Trin 3: Prøv at ødelægge ting
Vi tager klientens perspektiv. Først bruger vi funktionen på den måde, vi forventer, at slutbrugeren ville gøre. Derefter tager vi det til det ekstreme. Vi gentager handlinger mere end én gang, bruger ekstreme testcases og kontrollerer, at den nye funktion ikke ødelægger de eksisterende. Hvad sker der med X, hvis jeg trykker på den nye knap Y? Vi tester også med forskellige testkonti med andre egenskaber.
Vi tager kundens perspektiv
Trin 4: Test ud fra et sikkerhedsmæssigt synspunkt.
Vi tilstræber at være GDPR compliant. Vi tager vores kunders data alvorligt. Derfor tester vi for mulige sårbarheder med nogle få almindeligt anvendte hacking-teknikker. Vi er gode mennesker, så vi bruger aldrig disse teknikker i det virkelige liv; ingen grund til bekymring!
Trin 5: Test de nye oversættelser, og rediger dem.
Vi understøtter 11 sprog i vores dashboard, og vores spillerinterface er tilgængeligt på 24 sprog. Vi har en pulje af freelanceoversættere, som oversætter al tekst manuelt i et separat oversættelsesværktøj. Vi kontrollerer, om al tekst er tilføjet til det værktøj. Vi gennemgår og redigerer dem også, så de er klar til brug med det samme!
Trin 6: Overvej, hvilket indhold der skal opdateres eller skrives.
For det meste kommer en ny funktion med ny tekst. Vi forbereder alt internt eller eksternt indhold på forhånd, hvor det er muligt. Når vi frigiver en ny funktion, vil vi gerne være komplette! Det hænger sammen med vores vision om single item flow!
"At gøre QA godt kan være en tidskrævende opgave. Jo flere perspektiver og øjne, der er involveret, desto bedre. At have trinene dokumenteret, så alle kan følge dem, virker i stedet for kun at stole på én person. Hos Easy LMS arbejder vi i tværfaglige teams, hvor backend- og frontend-udviklere arbejder tæt sammen med vores implementeringskonsulenter, der bringer kundeperspektivet ind. Det giver mening!", siger Caroline, QA officer;
Hvornår skal vi teste manuelt?
Hver eneste funktion bliver testet manuelt
Hver eneste funktion bliver testet manuelt og gennemgår den samme proces! Selv små funktioner (som at udskifte et billede på hjemmesiden), som ikke engang behøver at blive testet ved første øjekast. Men djævlen ligger i detaljerne og i små funktioner ? Vi udfører vores manuelle testprocedure, når udviklingen er færdig. Er testen lykkedes? Så er det tid til at frigive den, så vores kunder kan få glæde af den! Fejlede testen? Så bliver funktionen undersøgt igen. Det betyder, at udviklingsteamet løser problemet og tester kvaliteten igen. Vi gentager dette, indtil alle felter på vores QA-tjekliste er afkrydset.
