Quality Assurance (QA) eller blot kvalitetssikring er et af de vigtigste områder at prioritere, når man udvikler en app. Hvis en app ikke fungerer optimalt eller endda falder helt igennem, kan du være sikker på, at QA er blevet overset i processen. QA spiller en vigtig rolle i appudvikling, og det er en fast del af enhver seriøs strategi. Alligevel er der mange virksomheder, der fravælger processen, selvom historikken viser, at QA sikrer en bedre app og samtidig minimerer risikoen for uforudsete udgifter. Hos Nodes arbejder vi altid målrettet med kvalitetssikring i alle vores projekter.
Hvad er QA?
Det er et godt spørgsmål. Begrebet blandes nogle gange sammen med test eller kvalitetskontrol, og selvom QA indeholder begge elementer, er det en langt større proces. QA strækker sig fra strategi og overvågning til evaluering og test. Det starter før koden er skrevet og fortsætter gennem udviklingsfasen, for til sidst at overvåge og vedligeholde appen efter lancering.
Hvorfor skal man bruge QA?
Virksomheder fokuserer i høj grad på design. Og med god grund. En app bør altid være visuel tilfredsstillende, men ideelt set skal der gerne være en balance mellem æstetik, forretningslogik og smart UX. En app kan være nok så lækker at se på, men er den ikke testet ordentligt, vil den være fyldt med fejl og bugs. Og når virksomhederne stræber efter det eksklusive design, kan user flow blive degraderet til en sekundær prioritet. Det er skidt for produktet. Er appen kluntet og besværlig at navigere rundt i, vil brugerne kvittere med dårlige anmeldelser og få tilbagevendende sessioner, og produktet vil ende på den digitale kirkegård.
Det første skridt
Selvom QA i høj grad fokuserer på udviklingsfasen, er der nogle ting, der skal være på plads, før man kan begynde. Stadiet før selve udviklingen af appen handler om at definere brugerkonteksten. Testforholdene skal være på plads, og derfor skal vi f.eks. afklare, hvilket operativt system, appen skal bygges op over. Derudover skal det være klart, om vores QA kun dækker appens funktionaliteter, eller vi også skal undersøge sikkerhed og tilgængelighed. For at dække alle aspekterne af processen laver vi et roadmap, hvor udviklere og QA-teamet arbejder side om side og opstiller en række mål i processen. Det sikrer, at alle arbejder i samme retning, er opmærksomme på overordnede mål og er enige om, hvordan vi opnår det.
Når virksomheder bygger og investerer i en app, vil de fleste gerne have en føling med hele processen. En stor del af QAs arbejde består i at samle resultater og levere feedback, som præsenteres for virksomhederne – eller privatpersoner, der gerne vil udvikle deres egne apps – på fastsatte datoer. Vi mener, at kommunikation mellem os og virksomheden er vital, og derfor deles og diskuteres resultater med hele dit team under og efter alle testrunder.
Hvilken slags test er det, vi taler om?
Her hos Nodes har vi udviklet en omfattende teststrategi, der dækker over flere forretningsområder. Tests foretages helt fra starten af og fortsætter gennem alle stadier i processen. Det er en holdindsats, hvor kunden, udviklerne og QA-teamet er involveret.
Vi mener, at en transparent proces er vigtig for alle parter, og det hjælper os til at udvikle det bedst mulige produkt.
Implementationstests
Et af vores mange værktøjer er implemtationstests, som bruges til at finde skjulte bugs i features og epics, før de implementeres i den endelige app. Disse tests, som foretages løbende igennem hele projektet, hjælper projektlederen til at forstå forholdene omkring den tekniske dybde bedre.
Eksplorative tests
Eksplorative test er en anden metode, vi bruger. Der findes ingen fast struktur, da vi gør, hvad navnet indikerer: eksplorerer (eller udforsker). Vi tester alle knapper features osv. For at undersøge funktionaliteterne til fulde, mens vi også kigger efter svagheder i opsætningen. Denne form for test er perfekt til at finde anormailteter og anderledes bugs, end hvad vores almindelige testprocedure ofte afslører. Eksplorative tests dækker også over connectivity og andre områder som f.eks. Tilfældige OS tests. Processen kan lyde hård og forstyrrende for det almindelige arbejde, men det sikrer, at vi tester appen fuldt ud og minimerer fejl senere hen. Det er naturligvis bedre at presse en app til bristepunktet under kontrollerede tests, end at brugerne får ubehagelige overraskelser efter lancering.
Strikse tests – UATs afgørende rolle
User Acceptance Testing (UAT) spiller også en vigtig rolle is vores tests. UAT udvikles af en af vores QA-specialister og digitale konsulenter tidligt i udviklingsstadiet, eller når projektets omfang defineres. Når alle er tilfredse med de opstillede parametre, det skal foregå under, giver kunden grønt lys, og testene gemmes til de senere stadier i processen. De foretages ofte lige inden appen uploades i App Store og/eller Google Play. Og, som navnet antyder, fokuserer UAT på brugeren og brugerens oplevelser. Vi får en fornemmelse af appens modenhed, og vi undersøger, om vi lever op til brugerens krav og forventninger.
Vi tester i bund og grund appen godt igennem, da alle de forskellige features burde være fastlagte på dette stadie. Appen er egentlig færdig, men vi undersøger potentielle fejl, bugs eller gnidninger, der står i vejen for en god brugeroplevelse. UAT skaber en række forskellige scenarier, der fungerer som realtidsbrug af appen (eller i det mindste så tæt på som muligt).
Hvornår skal den lanceres?
Når en testrunde er afsluttet, laver vi en rapport over de områder, vi har testet, og hvor appen består eller fejler. Når rapporterne præsenteres, skal kunden være klar til at træffe et vigtigt valg. Hvis der stadig er fejl og mangler, skal appen lanceres? Eller skal den tilbage på tegnebrættet? Det er et svært valg der skal vejes op mod forretningsspecifikke krav.
Der kan være en økonomisk grund til at en app skal lanceres hurtigt. Men de færreste vil have et produkt, der er af ringere kvalitet end konkurrenternes. I tilfælde af uløste bugs i appen efter UAT skal kunden i samarbejde med QA vurdere, om appen skal lanceres eller ej. Her er det selvfølgelig vigtig at tage forretningsbehov og strategi med i overvejelserne.
Hvor meget koster QA?
Når du lægger et budget til appudvikling, skal QA altid medregnes. Hos Nodes er det en fast del af den samlede pakke, og vi er skeptiske over for alle udviklingsteams, der ikke bruger det. Som en tommelfingerregel kræver QA ca. 15 % af det samlede budget til appen. Det kan lyde som meget, men på den lange bane er det et tilforladeligt beløb, der sikrer en driftsikker og problemfri app.
Hvem udfører de forskellige tests?
Hos Nodes er vi ekstremt heldige at have nogle af de bedste QA specialister på markedet. De er alle skarpe på hvert deres område, men fælles for dem alle er, at de har en omfattende teknisk viden og ekspertise, som er uundværlig for QA arbejdet. Deres erfaring og know-how gør, at de er bekendte med tests i alle faconer. De forstår kodning og design, og de er de perfekte kandidater til at identificere bugs, lave rapporter og skabe fremgang.
Stadig i tvivl?
Er du stadig i tvivl om QA er en god ide, kan et gammel ordsprog hjælpe dig: Et sting i tide sparer megen kvide. De ressourcer og den tid, du bruger på QA, betaler sig på den lange bane. Bugs fjernes og rapporteres inden produktet lanceres, og du får eksperter stillet til rådighed, som hjælper dit projekt sikkert igennem alle stadierne af appudvikling. Uden QA kan din app gå en hård tid i møde med negative anmeldelser i App Store og Google Play, og du risikerer, at brugerne flygter fra produktet og i sidste ende virksomheden.