Kvalitetssikring i udviklingsprocessen er kendt stof for de fleste. Kvaliteten i al softwareudvikling skal først og fremmest etableres i selve udviklingen. Men det er også vigtigt at fortsætte kvalitetssikringen, når I er gået live med appen.

Vi anbefaler fire metoder til kvalitetssikring af apps efter udviklingen. Det er brugertestgrupper, eventlogging, staged roll-out og hypercare.

1.Brugertestgrupper: Få feedback fra de første 100 brugere af din app

Med brugertestgrupper sender man appen ud til en lille gruppe medarbejdere, der tager appen i brug. Det er ikke en beta-version, men den faktiske app, der er live. På både Google Play og i App Store er der nogle værktøjer til at styre, at en begrænset gruppe får appen, og til at samle feedback op – enten automatiseret eller manuelt. Det betyder, at man får viden om, hvordan appen rent faktisk bliver brugt, inden man lægger den live til tusindvis af kunder.

Beta-apps og grundig test inden man har en release-kandidat er naturligvis også vigtig. Men der sker noget, når den første rigtige version af appen kommer ud på en masse forskellige devices uden for det trygge testmiljø, man har i udviklingsprocessen.

1. Man laver en brugergrupper typisk bestående af 10 til 100 testbrugere. Det kan være en fordel at rekruttere testbrugere internt i organisationen, da testen kan have den anden funktion, at den udbreder viden om projektet.
2. Brugerne modtager en mail om releasen og installerer appen.
3. Platformen opsamler information om brugen og eventuelle problemer.
4. Der er lette feedback-muligheder fra brugerne til projektgruppen.

• Det er nemt.
• Det er præcist den samme kode og en stort set identisk distributionsform der testes på, som den version der senere sendes til slutbrugerne.
• Notifikationer kan testes i Produktion. Fordi notifikationer afhænger af en hel række IT-systemer og konfigurationer, er notifikation ofte det, der fejler.
• Der kommer “timer” og “brugere” i appen. Med apps er en af de helt store udfordringer fragmentering. Det er ikke usædvanligt at en populær dansk app afvikles på over 1.000 forskellige Android-devices, på en række forskellige operativsystemer og i mange vidt forskellige brugssituationer. Selv den mest flittige og ressoucestærke test-afdeling kan umuligt teste alle disse variationer.

For nogle lyder brugertestgrupper som overkill. Men sandheden er, at når man står med sin releasekandidat og er færdig, så går tingene pludselig hurtigt – marketing presser på, ledelsen presser på og man er træt efter en lang proces. Og så sender man af og til appen ud for hurtigt, hvor 1-2 uger med en brugertestgruppe kan forbedre appen de sidste 10% eller sikre beslutningerne til den næste opdatering.

Den største investering i brugertestgrupper er derfor tid – som man ofte ikke synes man har, når appen faktisk er moden til at blive sluppet løs i verden.

2. Eventlogging: Find ud af, hvad der ikke fungerer i din app

Eventlogging er analyse af forskellige events og triggers, man har sat ind i appen. Hvis man har betaling i appen, så kan man sætte triggers op, så et bestemt mønster udløser en alarm og en eventuel handling – mønsteret kan f.eks. være, at betalingen fejler.
Man har jo altid indbygget fejlbeskeder indbygget til brugeren, og sikkert også almindelig Analytics. Eventlogging er anderledes, idet systemet holder øje med adfærd i appen, som ikke nødvendigvis kan ses på Analytics eller nedbrud. Det er med andre ord en måde at sikre data på, om kritiske flows i appen faktisk fungerer efter hensigten.

Der er på det seneste kommet nogle standardværktøjer som gør det prismæssigt overskueligt at arbejde med. Tidligere har det været forholdsvis dyrt, og det har været svært at overbevise f.eks. en ledelse om, at man skal have event-logging oveni almindelig Analytics. Vi laver altid Analytics, men det er ikke alle, der laver eventlogging. Vi håber at priserne snart bliver så gode, at eventlogging bliver standard.

Vi er selv meget glade for toolet Crashlytics, men det vigtigste er ikke, hvilket værktøj der bruges. Det vigtigste er, at man får en fast proces i gang, hvor man som en del af det løbende vedligehold af appen overvåger logningen og især allokerer tid til at få rettet fejl eller crashes i de forskellige releases.

3. Staged / Phased Rollout

• Det er nemt.
• Hvis fejl eller mangler skulle være sluppet gennem kvalitetskontrollen, så rammer problemet kun få brugere, og man kan nå at rette op.
• Ofte er et af problemerne ved releases, at brugen belaster de bagvedliggende servere på en uforudset eller forkert måde. Ved at lave en Staged Rollout kan man nå at se konsekvenserne af udrulningen hen af vejen og nå at rette op, hvis der er noget galt.

4. Hypercare: Lad ikke appen være alene på sin første tur ud i verden
Det er helt almindeligt, at man er meget lettet og glad, når appen går live første gang. Marketingindsatsen kører, og man er selv videre til andre projekter. Hvis man oveni købet er blevet lidt forsinket, så opløses projektgruppen omkring appen meget hurtigt.
Men vi kunne godt ønske os, at man ikke forlod appen, så snart den var kommet til verden. Det er en rigtig god idé at sætte projekttid af til at holde ekstra godt øje med appen de første dage og uger, den er live. Man kalder det hypercare, og det er en god investering. Kig i Analytics, hold øje med kommentarer i App Store og Play, se på eventlogging data osv. Det kan være der skal justeres noget i appen – eller i den måde I kommunikerer om den.

Feedback (eller mangel på samme) fra Android-brugere på Google Play plejer at være en god indikator for, hvordan det går. Det er altid klogt at besvare brugerfeedback på Google Play.

Vi mener, som de fleste andre i vores verden, at software ikke er en statisk ting, der bygges én gang for alle og derefter efterlades. Og vi kan se, at det også er sådan, det bliver opfattet hos dem, vi arbejder sammen med. Men af og til skal man også have overbevist en ledelse, der ikke arbejder med software hver dag. Så vi prøver løbende at indarbejde ovenstående i vores processer – og hører meget gerne fra dig, hvis du har tips til, hvordan man gør.