Betatest er en af de mest populære former for test, fordi den giver mulighed for at indsamle ægte brugerfeedback – det hjælper virksomheder (og uafhængige udviklere) med at forbedre deres kode betydeligt. En organisations betateststrategi kan endda være en vigtig faktor for dens evne til at levere fungerende softwareprogrammer. Det betyder, at det er afgørende, at du og dit firma ved, hvordan denne teknik fungerer, og hvordan I kan navigere i dens udfordringer og sikre et stabilt produkt.
Ved at forstå de grundlæggende elementer i betatestning og den tilgængelige software, der kan hjælpe testerne, kan udviklingsteamet foretage de nødvendige ændringer før og efter udgivelsen. Denne metode passer bedst sammen med alfatestning – så udviklere og testere kan dække alle mulige baser i hele deres kvalitetssikringsproces.
I denne artikel ser vi på, hvordan en stærk tilgang til betatestning hjælper softwarefirmaer med at levere bedre programmer sammen med de specifikke trin og fejl, der er involveret.
Hvad er betatestning?
Betatest er en form for kvalitetssikring, der specifikt undersøger, hvordan brugerne vil bruge et produkt – og om der er nogle problemer med softwaren, der skal rettes op på. Dette omfatter primært testere fra den tilsigtede målgruppe, men kan også omfatte andre demografiske grupper for at sikre en tilgængelig brugeroplevelse.
Alle funktioner undersøges nøje under betatests; disse kontroller giver også et nyt perspektiv og hjælper testerne med at finde problemer, som udviklerne sandsynligvis vil overse. Afhængigt af hvornår disse tests finder sted, kan virksomheden muligvis rette eventuelle problemer, før programmet frigives.
1. Hvornår og hvorfor skal man lave betatest?
Betatestning starter typisk efter alfatestning, men før produktet lanceres; normalt når applikationen er omkring 95% færdig. Det betyder, at betatesternes oplevelse er meget lig, hvis ikke identisk, med de endelige brugeres – og det sikrer, at der ikke sker større ændringer i produktdesignet før udgivelsen, som kan påvirke testene.
Betatest er en chance for udviklere til at få et nyt perspektiv på deres arbejde. Dette er især nyttigt til at undersøge brugeroplevelsen, herunder hvor let det er for folk at finde ud af, præcis hvordan softwaren fungerer.
2. Når du ikke behøver at lave betatests
Virksomheder kan udføre deres alpha-test og andre former for kvalitetssikring fra et brugerperspektiv eller endda anvende testprogrammer med computersyn til at lette dette. Dette dækker ikke alle mulige vinkler, men kan være en effektiv erstatning, hvis organisationen mangler tid og penge til at udføre betatests.
Selv i disse situationer kan betatestning være en stor hjælp og spare virksomheden for flere penge på lang sigt. Der er meget få programmer, der ikke ville have gavn af betatest; det er næsten altid en god investering for enhver teststrategi.
3. Opklaring af lidt forvirring: Betatestning vs. alfatestning
Selvom disse to processer er ret ens, er det vigtigt, at du kender forskellene mellem alfa- og betatestning inden for softwaretestning.
Hvad er alfa-testning?
Alpha-test er en anden form for brugeraccepttest, der primært ser på en tidligere fase af et program for at vurdere både større og mindre udviklingsproblemer. Dette involverer normalt en tjekliste over komponenter og almindelige softwaretests, hvilket giver mulighed for omfattende dækning.
I de fleste tilfælde tager virksomhedens interne testteam sig af dette – hvilket betyder, at de typisk har et godt kendskab til applikationen, og hvordan den fungerer. Som følge heraf kan der være visse blinde vinkler i testproceduren, som kun betatestere kan finde.
Betatest vs. alfatest
Både alfatest og betatest er former for brugeraccepttest, hvilket betyder, at de supplerer hinanden, når de bruges sammen. Hver tilgang indebærer, at man tjekker for problemer i softwaren på forskellige udviklingsstadier, især dem, der kan påvirke den overordnede brugeroplevelse.
Betatest fokuserer dog på black-box-test uden at se på applikationens indre funktioner – alfatest kombinerer dette med white-box-test for at tjekke selve koden.
En anden stor forskel er, at betatestere typisk ikke er relateret til udviklingsprocessen eller endda virksomheden.
Denne adskillelse mellem tester og applikation er nødvendig for et upartisk, eksternt perspektiv. Betatest ser generelt på stabilitet, sikkerhed og pålidelighed, mens alfatest fokuserer mere på generel funktionalitet – men der kan være betydelige overlapninger.
En, der er ny i softwaren, kan bruge både forventede og uventede input til at se, hvordan de påvirker applikationen – og potentielt få den til at gå i stykker i processen. Selvom betatest stadig er normalt før softwarens officielle udgivelse, kan ændringerne være nødt til at vente til en day-one patch eller endda uger efter lanceringen.
4. Hvem er involveret i betatestning?
– Betatestere
De er typisk ikke tilknyttet virksomheden og har intet forudgående kendskab til produktet, og hvordan dets interne kode passer sammen.
– Ledere af kvalitetssikring
De definerer den overordnede QA-strategi og er ansvarlige for, hvilke specifikke metoder og kontroller testteamet bruger.
– Alfa-testere
De udfører deres kontroller, før betatesten starter, for at garantere, at de interne systemer fungerer efter hensigten og er klar til fremtidige testere.
– Softwareudviklere
De bruger de oplysninger, som betatesterne giver, til at afhjælpe problemerne så hurtigt som muligt – det kan endda være før lanceringen.
Fordele ved betatestning
Fordelene ved betatestning i softwaretestning omfatter:
1. Afspejler brugeroplevelsen
Betatestere har ikke noget indgående kendskab til softwaren og er måske personligt uerfarne med kodning – det betyder, at de bedre repræsenterer slutbrugerens perspektiv.
Betatestere kan bruge programmet præcis som kunder ville gøre det, så udviklerne kan se, hvor godt deres applikation formidler sine funktioner til brugerne. Det er kritisk, fordi udviklere og internt QA-personale allerede er fortrolige med, hvordan disse applikationer fungerer og deres funktionalitet.
2. Øger testdækningen
Betatests involverer forskellige kontroller, som interne teams ikke normalt udfører, herunder tests, der undersøger potentielle brugerinput. Hver ny test, der er en del af virksomhedens kvalitetssikringsstrategi, øger den samlede testdækning af hver applikation. Denne procentdel repræsenterer, hvor grundig den nuværende testproces er, og viser, hvilke komponenter der kunne have gavn af mere opmærksomhed; høj testdækning er altid målet, når man betatester software.
3. Omkostningseffektiv
Selv om tilføjelsen af en ny type test kan bidrage betydeligt til et projekts udgifter, især hvis de skal ansætte eksternt personale, er betatest meget omkostningseffektive.
Den øgede dækning kan endda spare teamet for en masse penge på længere sigt; IBM anslår, at det er op til 15 gange dyrere at løse disse problemer efter udgivelsen. En responsiv betateststrategi kan hjælpe teams med nemt at reducere omkostningerne til fejlrettelse.
4. Diversificerede enheder
Betatest kan involvere brug af testerens egne enheder, hvilket hjælper teamet med at køre disse kontroller på et større udvalg af maskiner. Programmet kan f.eks. have svært ved at fungere på visse grafikkort eller uden tilstrækkelig hukommelse, og betatests kan afsløre disse problemer.
Afhængigt af din tilgang kan betatesterne bruge en ekstern platform til at udføre disse tests og endda simulere enheder ved hjælp af cross-browser-tests.
Udfordringer ved betatestning
Betatests kommer også med forskellige udfordringer, herunder:
1. Kræver specifikke færdigheder
Selvom målet altid er at simulere en brugers oplevelse, og kodningsevner af enhver art er unødvendige, bør betatestteamet stadig have robuste kvalitetssikringsevner.
De skal være i stand til at inspicere hver eneste komponent udelukkende ved hjælp af black-box-metoder, samtidig med at de skal have en slutbrugers tilgang. Denne balance er en vigtig del af enhver betatestmetode og kræver som regel en erfaren betatester.
2. Begrænset tid
Da betatestning sker, når produktet stort set er funktionsklart, kan selv mindre forsinkelser i tidsplanen påvirke testerne og deres evne til at teste grundigt.
Deres kontroller kan endda strække sig ind i produktets udgivelse, selvom udviklerne stadig kan foretage kritiske ændringer efter dette tidspunkt som en patch. Dette kan stadig lægge pres på testerne for at gennemføre kontrollerne hurtigt, hvilket potentielt begrænser deres nøjagtighed i processen.
3. Usystematisk rapportering
Rapporteringsprocedurerne for betatest er generelt mindre grundige end andre former for kvalitetssikring, så udviklerne kan tage sig mere tid til at reagere på feedback. Det er muligt at afbøde dette ved hjælp af detaljerede testcases eller betatestsoftware, der automatisk kan generere en omfattende log. Udviklerne er heller ikke til stede under betatests, og det kan udgøre en ekstra barriere, der påvirker, hvor godt de løser disse problemer.
4. Generelle krav til personalet
Antallet af betatestere, en virksomhed har brug for, afhænger primært af produktets omfang – det er muligt for dem at fejlvurdere, hvor mange testere der er nødvendige for deres produkts omfang. Det kan føre til for mange testere, et betydeligt ressourcetræk, eller testerne kan have svært ved at dække softwarens komponenter tilstrækkeligt. Projektets kvalitetssikringsteam bliver nødt til nøje at undersøge kravene til betatestpersonalet.
Formål med betatestning
De vigtigste formål med betatest i softwaretest er følgende:
1. Adressering af fejl
Stort set alle applikationer har problemer i de tidlige udviklingsstadier, og betatest giver mulighed for større dækning og fejlretning. For eksempel kan testerne efterligne brugerinput eller bevidste forsøg på at bryde softwaren ved at overbelaste dens database, hvilket alfatestere måske ikke overvejer.
Det giver teamet en øget tillid til produktet og dets kommende modtagelse.
2. Forbedring af brugeroplevelsen
Betatests er hovedsageligt set fra et brugerperspektiv – og viser, hvordan folk uden kendskab til softwaren ville gribe det an. Hvis testerne for eksempel kæmper med et programs kernefunktioner, skal udviklerne måske strømline grænsefladen eller implementere bedre tutorials.
Udviklerne kan derefter foretage de nødvendige ændringer for at sikre, at programmet er tilgængeligt for alle brugere.
3. Få ærlig feedback
Betatestere kan udarbejde falske anmeldelser af den software, de tester, hvilket giver udviklerne mulighed for at få ægte brugerudtalelser; dette kan gå ud over testtilfældene.
Disse testere kan give feedback, der forbedrer produktet, selv om de ikke svarer til en testcase. Det viser også, hvordan teamets tiltænkte målgruppe vil reagere på applikationen, når den er udgivet.
Specifikt… hvad tester vi i betatest?
Her er de specifikke aspekter af en applikation, som betatestere kigger på:
1. Stabilitet
Betatestere ser på et program for at afgøre, hvor godt det fungerer på forskellige maskiner – herunder hvor let det er at ødelægge softwaren eller få den til at gå ned.
For eksempel kan en applikation, der er afhængig af en database, gå i ‘deadlock’, hvis den modtager for mange forespørgsler; betatests viser, hvor mange forespørgsler den kan håndtere.
2. Pålidelighed
Denne proces sigter mod at reducere antallet af fejl i en applikation for at gøre den mere pålidelig for brugerne; pålidelighedstest handler om at begrænse muligheden for fejl.
Testeren kan f.eks. bruge programmet i en længere periode og notere alle de problemer, de støder på, f.eks. at et visuelt element ikke gengives korrekt.
3. Funktionalitet
Softwarens evne til at levere de tilsigtede funktioner er en anden vigtig del af betatesten. Betatestere kontrollerer, at alle komponenter fungerer efter hensigten, og at alle funktioner er intuitive.
Hvis testerne f.eks. har svært ved at bruge applikationens vigtigste salgsargument, skal udviklerne straks rette op på det.
4. Sikkerhed
Denne tilgang indebærer også, at man forsøger at bryde applikationen, især med hensyn til dens sikkerhed. En betatester kan forsøge at bruge en bagdør til at få administrative rettigheder for at fremhæve eksisterende sårbarheder. De kan endda tjekke databasen og dens kryptering, da den kan indeholde private oplysninger, som ingen brugere bør have adgang til.
5. Modtagelse
Hvordan publikum reagerer på en applikation, er en vigtig del af kvalitetssikringsprocessen – og hjælper udviklerne med at garantere, at de er på rette spor. Betatestere giver deres ærlige indsigt i programmet som en form for bred feedback, samtidig med at de viser teamet, hvordan offentligheden sandsynligvis vil modtage softwaren.
Typer af betatests
Her er de fem hovedtyper af betatest inden for softwaretest:
1. Åben betatestning
Åbne betatests er fuldt tilgængelige for offentligheden, hvilket giver mulighed for en bredere vifte af perspektiver. Det kunne være en opt-in-tilgang, hvor alle interesserede brugere kan ansøge om at blive betatestere på virksomhedens hjemmeside.
I disse tilfælde er kontrollerne sjældent krævende og kan blot involvere indgivelse af fejlrapporter som reaktion på fejl.
2. Lukket betatest
Lukkede tests er kun åbne for private grupper, som f.eks. virksomhedens eget udvalg, hvilket giver teamet mere kontrol over, hvem der tjekker ansøgningen. De kan prioritere betatestere, der udgør deres målgruppe, så de kan se, hvordan forskellige grupper af mennesker sandsynligvis vil reagere på nuancerne i denne software.
3. Teknisk betatestning
Tekniske betatests ser på specifikke komponenter fra et teknisk perspektiv; selvom deres mål er at repræsentere slutbrugere, kræver disse kontroller mere ekspertise. Det er nødvendigt for at afsløre komplekse fejl, som stadig kan påvirke brugerens oplevelse, men som kræver mere end et overfladisk blik at finde; disse kontroller kræver et dybere blik.
4. Fokuseret betatestning
Nogle komponenter er mere modtagelige for problemer end andre; for eksempel interagerer databasen normalt med mange af et programs funktioner, så fejl i den kan påvirke hele programmet. Fokuserede betatests ser på specifikke dele af softwaren samt individuelle funktioner for at sikre, at der ikke er væsentlige problemer.
5. Betatest efter udgivelse
Nogle betatests finder sted, efter at applikationen er udgivet; det hjælper teamet med at opfange eventuelle problemer, som brugerne endnu ikke har bemærket. Et post-release check kan også hjælpe med betatest af softwareopdateringer og nye funktioner for at sikre, at eventuelle tilføjelser lever op til de samme standarder som resten af applikationen.
Strategier for betatestning
Der er forskellige planer og strategier, du bør implementere, mens du betatester, f.eks:
1. Planlæg test på en hensigtsmæssig måde
Da betatest normalt sker tæt på produktets udgivelse, skal testteams sørge for at balancere kvalitetssikringsfasen for at lette hver test, de håber at implementere.
For eksempel skal udviklerne opdatere testerne om eventuelle forsinkelser i projektet, og testerne skal vurdere, hvilke kontroller der er vigtigst for at imødekomme hurtigt nærmende deadlines.
2. Fokus på testens mål
Enhver teststrategi afhænger af et klart fokus, som nemt kan motivere den enkelte tester. For eksempel kan teamet prioritere en bestemt komponent, som applikationen er afhængig af.
Testerne sigter måske efter en vis dækningsprocent eller efter et program, som de kan bruge frit i en længere periode uden at støde på fejl.
3. Ansæt de rigtige testere
Dygtige testere ved, hvordan man nærmer sig software som en bruger, mens man stadig ser dybt på den programspecifikke oplevelse, hvilket endda kan være nødvendigt for tekniske betatests.
Applikationer, der passer til et bredt publikum (såsom videospil eller mobilapps), kan have større gavn af åbne betaer, der afspejler forskellige brugerbaser på alle niveauer.
4. Handle på testerens feedback
Teamet skal hurtigt svare betatesterne, når de giver feedback; det hjælper med at fastholde testernes engagement og giver udviklerne mulighed for at begynde at arbejde på en fejlrettelse. Hastighed er altafgørende på dette stadie af programmets udvikling, da udgivelsesdatoen normalt ikke er lang tid efter, at betatestprocessen er begyndt.
Betatest-processen
Her er de seks vigtigste trin til betatest af en applikation:
1. Forbered betatesten
Teamet skal udtænke et solidt antal testere, der matcher applikationens omfang, da nogle applikationer kræver over 300 betatestere. De bør også afgøre, hvilke typer betatest der skal bruges, og hvordan de kan supplere alfatestfasen.
2. Rekrutter betatestere
Når kvalitetssikringsteamet har fundet frem til deres tilgang til betatest, skal de rekruttere eksterne testere via deres foretrukne kanaler. De kan reklamere åbent for det på deres sociale medier eller bruge et testfirma; de bør også sørge for at budgettere med nok rekrutteringstid.
3. Frigiv beta-programmet
Når applikationen og testerne er klar til at gå i gang, frigiver virksomheden betaapplikationen og udsender invitationer til betatesterne. Testerne tjekker programmet gennem langvarige processer, der nemt kan vare i flere uger, og noterer eventuelle problemer eller relevant feedback.
4. Indsaml feedback fra testerne
Når kontrollerne er afsluttet, giver betatesterne deres mening om softwaren og detaljerede rapporter om de fejl, de er stødt på. Teamet kan også tale med betatesterne for at få flere detaljer om problemerne og deres mulige årsager.
5. Opdater applikationen
Ved hjælp af oplysningerne fra disse kontroller og den feedback, de giver, kan udviklerne begynde at ændre applikationen og rette de opdagede fejl. Nogle ændringer skal måske vente med at blive rettet til efter lanceringen på grund af den stramme tidsplan, som betatest ofte medfører.
6. Test igen, når det er nødvendigt
Interne testere tjekker normalt applikationen efter fejlrettelsesfasen for at sikre, at disse problemer ikke længere er til stede. Virksomheden kan involvere betatestere igen, hvis programmet gennemgår en væsentlig opdatering, som sandsynligvis vil påvirke programmets funktionalitet, herunder eventuelle nye funktioner.
Faserne i betatestning
Betatests følger en proces med flere faser; de sædvanlige faser er:
1. Planlægning
I denne fase udarbejder det interne team et dokument om målene for deres generelle betatesttilgang, herunder om de ønsker at have en åben beta.
Planlægningsfasen kræver input fra alle interessenter; teamledere og chefer skal have de samme mål.
2. Rekruttering
Den næste fase omfatter udvælgelse af testere og onboarding; dette giver testerne mulighed for at udvikle en foreløbig forståelse af applikationen.
Det skal passe til projektets nøjagtige krav. For eksempel bør applikationer, der passer til alle aldre, bruge testere fra forskellige aldersgrupper til at tjekke brugervenligheden.
3. Testning
Testfasen omfatter tre komponenter – engagement management, feedback management og distribution af resultater. Disse processer involverer at sikre testernes engagement, organisere deres feedback og sørge for, at udviklerne modtager resultaterne. Betatests foregår typisk i sprints på 1-2 uger, så der er rigelig dækning og tid til reparationer.
4. Opsamling
Når testen er færdig, afslutter holdene testcyklussen og forbereder sig på at frigive produktet. Det kan også omfatte udarbejdelse af en opfølgningsrapport.
Adgangskriterier til betatest
De generelle adgangskriterier for betatests omfatter:
1. Egnet testteam
Et tilstrækkeligt hold af betatestere er uden tvivl det vigtigste adgangskriterium for disse kontroller, da det påvirker, hvordan de engagerer sig i applikationen. For eksempel bør en betatest af et videospil repræsentere alle facetter af målgruppen – inklusive amatører og erfarne spillere.
2. Alpha-test er afsluttet
Betatestning bør begynde, når det interne team har afsluttet alfatestning; det fremhæver de fleste af problemerne med softwaren. Der er dog stadig nogle huller i kvalitetssikringen, som kun betatests og en udelukkende black-box-tilgang er i stand til at afhjælpe tilstrækkeligt.
3. En beta-klar applikation
Selve applikationen skal have en fungerende betaversion, der er fuldt opdateret og indeholder alle funktioner. Det skal være et uafhængigt testmiljø, hvor eventuelle fejl, som betatesteren støder på, ikke påvirker det overordnede program eller de andre testeres fremskridt.
4. Beta-test af software
Testere kan have gavn af et program, der hjælper med deres betatests; dette kan endda implementere robotprocesautomatisering for øget nøjagtighed på hvert trin. Det interne team bestemmer hovedsageligt, hvilket program betatesterne bruger, og skal omhyggeligt vælge den mest kompatible løsning.
Udgangskriterier for betatest
Kriterierne for at afslutte betatests omfatter:
1. Opdagede problemer er løst
Et vigtigt krav for at afslutte betatestfasen er, at udviklerne efter bedste evne løser alle de problemer, som testerne påpeger. Når teamet har identificeret og udbedret problemerne, kan testerne afslutte deres arbejde.
2. Resumé af afsluttet betatest
Når betatesterne var færdige med deres tjek, udarbejdede de resuméer af deres test sammen med de problemer, de stødte på i processen. Denne rapport fungerer som en nyttig ressource, når man tester fremtidige versioner af produktet eller lignende software, som virksomheden skaber.
3. Konklusion af testfasen
Teamet bør formelt afslutte testfasen, når betatesterne er færdige med deres tjek; det betyder, at kvalitetssikringsfasen er færdig. At skrive under på dette fungerer også som en måde at sikre, at teamet går videre til produktets udgivelse.
4. Produkt klar til forsendelse
Mange projekter afslutter deres betatestfase med at sende produktet afsted, især fordi applikationen kan være komplet på dette tidspunkt. Det er muligt, at betatests sker efter udgivelsen – men det er normalt kun, hvis der er forsinkelser i projektet.
Typer af output fra betatests
Betatests producerer flere vigtige resultater, herunder:
1. Testresultater
Betatests giver testere og udviklere en betydelig mængde data om, hvorvidt produktet er klar til at blive frigivet. Hvis kvalitetssikringsteamet har fundet frem til de specifikke kontroller, som betatesterne har brugt, vil de sammenligne resultaterne med de tilsigtede resultater. Disse resultater kan omfatte testens beståelsesprocent, nedbrudsfrekvens og endda systemets brugervenlighedsscore.
2. Testprotokoller
Selvom betatestere generelt kun ser på projekter fra et blackbox-perspektiv, genererer deres handlinger stadig data i programmets interne log. Udviklere kan bruge dette til at isolere de filer, stier og endda præcise kodelinjer, der er ansvarlige for eventuelle problemer, der opstår. Disse logfiler kan f.eks. vise, om systemet er under stor belastning.
3. Testrapporter
Disse resultater udgør i sidste ende hovedparten af et betatestresumé, som kombinerer dette med testerens specifikke konklusioner og tanker om applikationen. Hvis betatesterne har erfaring nok, kan de komme med ideer til, hvordan udviklerne kan begynde at rette softwarefejl. Betatestrapporter indeholder normalt en oversigt over et programs funktionalitet, pålidelighed, sikkerhed, stabilitet og generel feedback fra testerne.
Almindelige målinger af betatestning
Næsten hver betatest genererer unikke målinger, som f.eks:
1. Antal mislykkede tests
Hvis programmet fejler i nogle tests, er det nyttigt for testerne at holde styr på, hvor mange tests programmet ville have problemer med. Det kan være et tal, men det kan også være en brøkdel eller en procentdel af det samlede antal tests.
2. Testdækning i procent
Jo højere et teams testdækning er, jo mere sikre kan de være på, at de er i stand til at afdække så mange fejl som muligt. Betatestere bør fokusere på softwarekomponenter med lavere relativ dækning for at sikre, at de fungerer præcis, som udviklerne havde tænkt sig.
3. Kundetilfredshed
Betatestere kan give kundetilfredshedsscorer (eller CSAT-scorer) – som sporer testerens ægte respons på produktet, herunder deres niveau af tilfredshed. Det sker som regel på en skala fra 1 til 5, hvor en lavere score indikerer utilfredshed, mens 5 betyder fuld tilfredshed.
4. Sikkerhedsmæssig sårbarhedstæthed
Når man tjekker muligheden for sikkerhedsproblemer, kan betatestere spore den samlede tæthed af sårbarheder i programmet. Dette giver testerne og udviklerne en klar idé om applikationens generelle sikkerhed, herunder et kig på de mest fremtrædende sikkerhedsbrister i softwaren.
5. Netto promotor score
I lighed med kundetilfredshed undersøger programmets net promoter score (eller NPS), hvordan virkelige grupper af brugere sandsynligvis ville reagere på applikationen. Dette er på en 10-punkts skala, hvor 9-10 refererer til ‘Promoters’, mens 7-8 er ‘Passives’ – og alt under dette udgør en ‘Detractor’.
6. Maksimal responstid
Den tid, det tager en database at hente oplysninger, og generelt hvor lang tid det tager et program at gennemføre en anmodning, kan give problemer. Doherty Threshold antyder, at en peak-tid på over 400 millisekunder kan forhindre brugerne i at engagere sig i softwaren.
Typer af fejl og bugs opdaget gennem betatestning
Her er nogle af de fejl, som betatest i softwaretest kan hjælpe med at opdage:
1. Fejlfungerende funktion
Et stort problem, som betatests kan afsløre, er, hvis en af funktionerne ikke virker i nogen situation. Det kan involvere sammenhænge, som andre testere ikke tænker på, og derfor er det vigtigt, at teams bruger betatestning til at finde problemer på nye måder.
2. Sikkerhedsmæssig sårbarhed
Betatest kan afsløre en række mulige sikkerhedsbrister; det kan endda omfatte en administrativ bagdør, som brugerne kan få adgang til. Disse kontroller er altafgørende for at sikre, at applikationen er sikker og vil kunne modstå brugernes granskning.
3. Generelt nedbrud
Ethvert antal input kan resultere i et nedbrud – og betatestere inspicerer så mange realistiske brugerinput som muligt for at sikre, at der ikke er nogen udløsere for nedbrud. Hvis programmet crasher, når brugeren udfører en bestemt handling, skal udviklerne rette op på det.
4. Enhedens inkompatibilitet
Betatests ser på et større udvalg af enheder end andre kvalitetssikringsfaser og bruger cross-browser-test til at opnå dette. Disse tests afslører, hvor godt programmet fungerer på forskellige maskiner, da mindre forskelle i arkitektur kan påvirke programmets ydeevne betydeligt.
5. Langsom ydeevne
Disse kontroller viser, om der er situationer eller input, der dramatisk gør programmet langsommere, hvilket resulterer i en bemærkelsesværdig forsinkelse for slutbrugeren. Det kan have stor indflydelse på, hvor meget brugeren nyder denne software, så det er vigtigt at rette op på det.
Eksempler på betatests
Her er tre vigtige eksempler på betatest:
1. Android-app
Betatest af Android-apps indebærer, at man kører programmet på en passende enhed – eventuelt flere for at teste kompatibiliteten – og tjekker for eventuelle bemærkelsesværdige fejl. Da disse apps er meget komplekse, kan virksomheden få brug for op til 300 betatestere.
Mange apps reklamerer åbent med tilgængelige betatests før og efter lanceringen, hvilket giver firmaet mulighed for at sikre en komplet dækning fra mange forskellige perspektiver. Disse tests kan fokusere på specifikke funktioner i denne mobilapp, og hvordan de interagerer med hinanden.
2. Videospil
Videospil gennemgår en lang betatestproces på grund af deres iboende kompleksitet; her kigger man på alle spillets facetter, fra dets motor til dets ydeevne og grafiske troværdighed.
Disse kan være åbne udelukkende for folk, der forudbestiller spillet, eller endda bare alle interesserede spillere, selvom privat betatestning også er nødvendig. For multiplayer-spil giver åbne betaer udviklerne mulighed for at tjekke deres netkode og se, hvor godt den kan håndtere et stort antal spillere.
3. Hjemmeside
En virksomheds hjemmeside – især en med e-handelsfunktioner – kræver også grundig betatest, før firmaet lancerer den for offentligheden. Betatestere bør undersøge hver side for at sikre, at den vises godt på forskellige enheder, og at de inkluderede webapps fungerer.
På detailsider kan testerne forsøge at gennemføre et køb og se, om det går igennem systemet. Betatesterne skal også tjekke sidens funktionalitet på tværs af alle de populære internetbrowsere.
Manuelle eller automatiserede betatests?
Automatisering kan øge effektiviteten af enhver teststrategi, reducere risikoen for menneskelige fejl dramatisk og samtidig arbejde meget hurtigere. Det øger dækningen og den overordnede pålidelighed af projektets kvalitetssikringsfase – som regel ved hjælp af en tredjepartsapplikation.
Det er vigtigt for teams at undersøge alle mulige platforme, der kan automatisere deres tests; de har hver især forskellige funktioner, der kan være mere kompatible med bestemte typer software. Denne tilgang er dog generelt begrænset med hensyn til det menneskelige element; de fleste betatests er afhængige af brugerens perspektiv.
Der er måder, hvorpå automatisering kan omgå disse problemer; computersyn hjælper f.eks. automatiseringssoftware med at se på problemer fra et menneskeligt synspunkt. Hyperautomatisering kan også hjælpe teams med at kalibrere deres teststrategi på en måde, der intelligent anvender automatisering, hvor det er relevant, uden at overbruge den.
I begge tilfælde afhænger teamets tilgang (og dets eventuelle succes) af det program, de implementerer, og dets funktioner. Betatestere er stadig nødvendige for denne proces, og kvalitetssikringslederne skal revidere deres overordnede strategi for at se, hvilke kontroller der vil have gavn af automatisering, og hvilke der skal prioriteres af menneskelige testere.
Bedste praksis for betatestning
Her er nogle af de bedste fremgangsmåder, som betatestteams bør implementere:
1. Overvej kunden
Kundeoplevelsen er kernen i enhver betatest, og de kontroller, som dette team indfører, skal afspejle dette, hvor det er muligt. For eksempel bør testerne undersøge grænsefladen og se, hvor intuitiv den ville være for erfarne brugere i den pågældende sektor.
2. Tjek uden for målgruppen
Intet produkt eller program har kun brugere fra sin målgruppe, og det kan være første gang, nogen bruger et program af denne type. For eksempel kan betatestere gå til et videospil, som om de aldrig har spillet det før, for at sikre sig, at det er brugervenligt.
3. Et bredt udvalg af testere
På samme måde er det vigtigt at tjekke programmer med testere fra mange forskellige baggrunde, så teamet kan få et komplet billede af, hvordan kunderne vil reagere. Forskelle i erfaring kan også resultere i, at betatesterne undersøger softwaren på forskellige måder.
4. Tilskynd til konstant kommunikation
Der kan opstå informationssiloer mellem testere og udviklere – især hvis de førstnævnte kommer udefra. Det betyder, at kvalitetssikringslederne skal lette kommunikationen mellem disse to teams for at sikre, at udviklerne får de oplysninger, de har brug for til at rette fejl.
5. Vælg teststrategien med omhu
Nogle produkter har mere gavn af en åben beta, der genererer omfattende feedback på kort tid, men der er mange applikationer, der kræver privat testning. Holdene skal undersøge denne software og afgøre, hvilken tilgang der passer bedst.
6. Tilbyd incitamenter
Ubetalte betatestere har brug for en eller anden form for belønning for deres indsats – og tidlig adgang til programmet er måske ikke tilstrækkeligt. De kan blive nævnt i softwarens rulletekster eller få en anden form for gave, der opmuntrer dem til at gøre det bedst mulige arbejde.
Hvad skal du bruge for at begynde at betateste?
Der er flere vigtige forudsætninger, før betatestning kan begynde, herunder:
1. Omfattende teststrategi
Selvom betatestning er relativt fri, især for en åben beta, er det stadig nødvendigt med en robust plan for at sikre, at hver komponent får nok opmærksomhed fra testerne. Kvalitetssikringsteamet bør vide, hvad projektet kræver, f.eks. hvilke specifikke betatjek, de har tænkt sig at udføre.
Hvis programmet for eksempel har nogle komponenter, der kræver mere fokus, skal teamets strategi tage højde for det.
2. Motiverede testere
Teamet har også brug for testere, der er tilstrækkeligt motiverede til at hjælpe med beta-processen. Afhængigt af de specifikke kontroller kan virksomheden have gavn af testere, der er meget dygtige til kvalitetssikring og nøjagtigt kan vurdere, hvordan deres handlinger påvirker denne applikation.
Teamlederne skal være sikre på deres valg af testere, herunder om de er i stand til at afspejle hele spektret af produktets målgruppe.
3. Beta-test af software
Testværktøjer, herunder dem med automatiseringsfunktionalitet, har en plads i næsten enhver kvalitetssikringsplan; selv betatests, som normalt er afhængige af menneskelige perspektiver. Det kan hjælpe teamet med at implementere robotic process automation – det bruger softwarerobotter til at udføre forskellige testopgaver uden hjælp fra en menneskelig betatester. Det program, de bruger, afhænger af det aktuelle projekts specifikke testbehov.
4. Beta-program
Når betatestningen begynder, efter at teamet har afsluttet alfatestningen, skal de arbejde med det mest opdaterede program; det skal være tæt på at være komplet. Denne applikation skal være helt separat for at sikre, at den kan modstå de mange mulige måder, en betatester kan ødelægge den på, uden at skade den rigtige software. I mange tilfælde vil beta-programmet have få problemer på grund af omfattende alfa-test.
7 fejl og faldgruber i implementeringen af betatests
Med enhver teststrategi er der masser af fejl, som testere kan begå. Her er syv fejl, som betatestere bør undgå:
1. Ufleksibel tidsplan
Forsinkelser er almindelige i ethvert softwareprojekt, og testteamet bør tage højde for dette på hvert trin. Betatest sker tæt på udgivelsen, så det kan gå ud over produktet, hvis der sker ændringer i tidsplanen. Testerne kan have svært ved at gennemføre deres tjek på grund af disse forsinkelser.
2. Umotiverede testere
Især åbne betatests kan have svært ved at opmuntre deres testere til at rapportere de fejl, de finder – i nogle tilfælde ser de det måske som en gratis prøveversion af softwaren. Teamet skal tilbyde incitamenter, der fremmer kommunikation og omfattende rapportering, ellers er det ikke sikkert, at testerne vil påpege eventuelle problemer.
3. Begrænset repræsentation af publikum
Da betatests generelt simulerer brugeroplevelsen, hjælper det, at testerne nogenlunde afspejler applikationens målgruppe. I den forbindelse kan det være vigtigt at informere betatesterne om, hvem der skal bruge produktet, men også andre perspektiver kan være med til at sikre, at softwaren er brugervenlig.
4. Begrænsede enheder
Cross-browser-test og udforskning af en række enheder er afgørende for at sikre, at applikationen er brugbar for så mange mennesker som muligt. Dette er mere fremtrædende i betatestfasen; teamet skal sørge for, at kontrollerne altid repræsenterer en bred vifte af potentielle enheder.
5. Ikke nok testere
Antallet af nødvendige betatestere varierer fra projekt til projekt, men en fejlvurdering kan give alvorlige problemer. For eksempel kan for mange testere være en alvorlig belastning for ressourcerne, herunder pengene.
Alternativt kan et utilstrækkeligt antal testere have svært ved at sikre en stærk testdækning på tværs af alle komponenter i applikationen.
6. Ingen testplan
Betatestfasen lykkes sjældent, når testerne blot bruger softwaren og giver vag feedback. Kvalitetssikringsteamet skal udarbejde omfattende planer, der beskriver komponenterne og de specifikke kontroller.
I en åben beta skal testerne have en klar måde at rapportere eventuelle problemer, de støder på.
7. Ineffektivt testværktøj
Testteams kan ikke bare implementere det første eller billigste testværktøj, de finder. De bør i stedet søge efter en mulighed, der matcher deres projekt og dets præcise behov. Hvis man tager sig den tid, kan man undgå alvorlige testproblemer på lang sigt, samtidig med at testerne får bedre mulighed for at udnytte testværktøjets funktioner.
De 5 bedste værktøjer til betatest
Her er de fem mest effektive betalte eller gratis betatestsoftwareværktøjer:
1. ZAPTEST FREE & ENTERPRISE-udgaverne
ZAPTEST tilbyder både gratis og betalte betatestværktøjer, der hjælper virksomheder gennem hele deres kvalitetssikringsfase på ethvert budget.
ZAPTEST giver grundig testautomatisering på tværs af en række forskellige browsere, enheder, apps og platforme, så betatestere kan tjekke deres programmer på et dybere niveau. Mens gratisversionen har masser af nyttige funktioner, inkluderer Enterprise-versionen en dedikeret ZAP-ekspert, der arbejder sammen med kundens team, topmoderne RPA-funktionalitet uden ekstra omkostninger og et ubegrænset antal licenser.
2. Instabug
Instabug hjælper betatestere med at tjekke en række mobilapps på tværs af alle større operativsystemer og tilbyder fuld crash-analyse og registrering af brugerinput i processen. Dette betalte værktøj gør det lettere for testere at sende fejlrapporter, når de tjekker programmet.
Brugerne rapporterer dog, at platformen er relativt dyr, og at softwaren har begrænset funktionalitet til webapps og andre programtyper, hvilket kun gør den brugbar i visse sammenhænge.
3. BrowserStack
BrowserStack kan simulere over 3.000 enheder til både alfa- og betatest, hvilket sikrer en fuldt komplementær testproces. Platformen indeholder også detaljerede logningsfunktioner, som gør det muligt for testerne at identificere årsagen til problemer og kommunikere dem til udviklerne så hurtigt som muligt.
Denne løsning er mest effektiv med web- eller mobilapps og har begrænsede anvendelsesmuligheder for anden software – det kan også være en svær platform at lære for begyndertestere.
4. TestFairy
TestFairy har specialiseret sig i mobilapps med et stærkt fokus på Android-betatestning og er i stand til at registrere testerhandlinger (inklusive deres specifikke input) for at gøre det meget lettere at gentage deres opdagelser. Alle, der er involveret i udviklingen, kan se de resulterende videoer og bruge dem til at informere om deres forbedringer.
Men prisen og det begrænsede antal kompatible enheder er igen mulige problemer, som brugerne skal være opmærksomme på, når de vælger et testværktøj.
5. TestFlight
TestFlight er et Apple-program, der er specielt designet til betatest af iOS-apps. Det gør den særligt begrænset til andre programmer, herunder forskellige typer mobilapps.
TestFlight giver app-udviklere mulighed for nemt at distribuere nye versioner af programmet til testere og har en nem installationsproces. Selvom denne platform er ret nyttig for iOS-appudviklere, kan den selv i denne sammenhæng kun understøtte iOS 8 og fremefter.
Tjekliste, tips og tricks til betatest
Her er nogle yderligere tips til at få mest muligt ud af betatest i softwaretest:
1. Gør dokumentation lettere
Jo nemmere det er for betatestere (af alle slags) at rapportere de problemer, de løber ind i, jo mere præcis og effektiv er den samlede testproces. Det er vigtigt, at testteamet forfiner de sædvanlige feedbackrapporteringskanaler for at gøre disse kontroller mere smidige.
2. Fortsæt med at gentage betatests
Hver betatest, som en virksomhed foretager, bør informere om, hvordan de forfiner fremtidige kontroller for at imødekomme deres sædvanlige projekter. Disse erfaringer forbedrer betatestprocessen og sikrer, at de altid undersøger programmer på måder, der passer til virksomheden og dens unikke krav.
3. Brug automatisering sparsomt
Selvom taktikker som robotprocesautomatisering kan have en betydelig positiv indvirkning på teamets betatests, skal teamet implementere det med omtanke. Automatisering af hvert tjek kan begrænse deres nøjagtighed, især da mange betatests er afhængige af menneskelige slutbrugeres specifikke erfaringer.
4. Få testerne til at underskrive en NDA
Private betatestere kan se på følsom software, og det er vigtigt for organisationer og udviklere at beskytte deres interesser. Af denne grund kan virksomheden få testerne til at underskrive en fortrolighedsaftale, så de ikke afslører nogen hemmelige oplysninger om programmet.
5. Støt betatestere
Virksomheden og dens interne kvalitetssikringspersonale bør være til rådighed til at hjælpe med betatestfasen – denne støtte kan være uvurderlig. For eksempel kan testerne have brug for hjælp til at betjene programmet, eller de vil måske stille generelle spørgsmål om applikationen.
6. Tilskynd til frihed for testere
Selvom denne støtte nogle gange er afgørende for at garantere en grundig betatest, er det også vigtigt, at virksomheden lader testerne gennemføre deres tests i deres eget tempo. Testeren skal kunne give ærlig feedback, og det er kun muligt med fuld brugerfrihed.
Konklusion
Betatest er nødvendigt for næsten ethvert softwareprojekt på grund af dets evne til at tage højde for brugerne og deres unikke oplevelser med softwaren. Virksomheder kan vælge at integrere automatisering i deres betatestplaner – men de skal stadig overveje det menneskelige perspektiv i alle faser. De nærmere detaljer i en virksomheds strategi afhænger af projektet og den tilgang, der passer bedst til dets krav, herunder den enkelte testers færdighedsniveau.
Uanset testteamets nuværende budget kan ZAPTEST Free eller Enterprise lette intuitive beta-tjek på tværs af en lang række enheder og sikre høje standarder i hele kvalitetssikringsprocessen.
