Alle, fra ladestasjonen nedi gata til TV-kanalene satser på interaksjon via mobile applikasjoner for å knytte sine kunder og sitt publikum nærmere til seg. Ofte uten å teste at disse løsningene tåler trykket de utsettes for. Her er hvorfor og hvordan du bør teste din app før lansering.
I sommer har apper og ytelse/tilgjengelighet igjen fått endel fokus i pressen, nærmere bestemt ladestasjon-apper for å få ladet elbilen. Vi elsker elbiler, men hater appene.
Ser du på Google Play, så har for eksempel følgende ladeapper tilnærmet «slakt-karakter» (du kan gi karakter 1 til 5):
- 1,7 til Shell Recharge
- 1,8 til Ladeklubben
- 2,0 til Fortum Charge & Drive
- 2,6 til IONITY
- 2,8 til Mer Connect
- 3,3 til Cirkle K Charge
Det er jo helt katastrofalt dårlig, kanskje spesielt ille er det at Elbilforeningens egen app som liksom skal gjøre det enklere å lade får omtrent dårligst score. Primært går tilbakemeldingene fra brukerne på manglende ytelse, at appen henger, man får ikke registrert seg og lignende ting som er helt primær funksjonalitet som bare må fungere!
Har hele bunten glemt å teste appene og ikke minst, API’ene appene skal snakke med?
For noen år siden skrev jeg en bloggpost på Sopra Steria sin blogg om dette temaet. Sopra Steria har etterpå byttet publiseringsplattform sånn at innlegget har forsvunnet litt. Derfor har jeg lagt artikkelen ut her med noen endringer og oppdateringer.
Lørdag 25. mars 2017 hadde Lost in Time premiere. Dette skulle være TVNorges store satsning på interaktiv tv-titting. Kort tid etter sendestart sluttet den mobile appen å fungere. Dette resulterte i en klagestorm fra de mange sofabrukerne. Det er liten tvil om at dette skyldes manglende testing. Etter flere forsøk og frustrerte brukere ble hele satsingen skrinlagt.
Vi har testet og testet og testet. Men det er ikke mulig å teste for det trøkket som blir.
Hanne McBride
Dette sa mediesjefen i Discovery Norway (eier av TVNorge) til Dagbladet dagen etter premieren. Etter andre episode ble programmet tatt av lufta og kom aldri tilbake. Tenk på hvor mange millioner TVNorge må ha tapt på dette!
- Jeg har skrevet om Lost i Time før, les mer her…
NRK har feilet flere ganger
Da NRK den 13. januar 2018 hadde premiere på Alle for 1, hadde de også laget en app slik at publikum kunne delta i programmet hjemmefra. Selv om dette var en relativt enkel app, hadde også denne sine utfordringer.
En halvtime ut i programmet fungerte ikke lenger brukerregistrering. Visningen av seer-stemmene var ustabil. Flere fikk ikke stemt innen tidsfristen. Dette bærer kommentarene og karakteristikkene i App Store ett tydelig preg av.
Vi har mottatt flere meldinger om problemer med «Alle mot 1»-appen, og jobber med å utrede hva feilen skyldes. Beklager så mye til alle som er rammet.
— NRK (@NRKno) March 3, 2018
Om NRK hadde ytelsestestet appen er ukjent, men det viser krystallklart behovet for å simulere store brukermengder før man slipper en mobil app eller nettjeneste tiltenkt større brukergrupper.
Fra vondt til verre
…men NRK lærte likevel ikke av denne tabben. Bare to år senere lanserte NRK igjen en app der seerne skulle delta, og denne gangen gikk det enda mer galt. Melodi Grand Prix finalen i 2020 gikk ned i historiebøkene som tidenes MGP skandale da stemmegivningsfunksjonen havarerte fullstendig på grunn av noen gule smile-emojier.
Som dere kanskje har merket har vi ikke klart å ta i mot stemmene via nett. Derfor vil en forhåndsvalgt folkejury stemme frem gullfinalistene
— Melodi Grand Prix (@NRKmgp) February 15, 2020
Det som skapte problemene var en script-kid som kjørte et ganske enkelt skript for å generere smiley-emojier i appen. I praksis en veldig enkel form for stresstest som NRK burde ha kjørt selv under utviklingen av appen.
Hvorfor testes det ikke?
Ytelsestesting blir ofte utelatt av en eller flere årsaker:
- Ytelsestesting er ikke en del av budsjettet.
- Ytelsestesting blir rett og slett glemt.
- Prosjektet sklir ut på tid og testing blir nedprioritert for å nå deadline.
- Kostnadskutt. Ytelsestest i denne skalaen er dyrt. Samtidig er det sjelden kompetanse og forståelse av verdien for denne type testing og risikoen ved at den utelates.
Appens ytelse bør testes før lansering og regelmessig etter dette. En undersøkelse fra AppDynamics i 2014 viser at 86 prosent av oss sletter apper etter første gangs bruk fordi den var treg eller ikke fungerte slik man ønsket. I følge Google har du ett sekund på å gi brukerne innhold på skjermen før tjenesten din oppfattes som treg. I praksis betyr det at du må levere til alle dine brukere innen sekundet er omme. Og, du får bare ett forsøk på å lykkes.
Fortsatt sikker på at du ikke skal teste litt til før du lanserer?
Ytelse som en tjeneste
Hva skjer når flere hundre tusen brukere prøver å logge seg på tjenesten din samtidig etter ett nyhetsinnslag på Dagsrevyen eller en reklamefilm under VM på ski?
Jeg husker godt at de snakket om den såkalte «Dagsrevy-effekten» da jeg implementerte AppDynamics hos NAV. Altså, når et nyhetsinnslag engasjerer flere hundretusen nordmenn til å søke mer informasjon umiddelbart.
Da jeg jobbet i Sopra Steria kjørte jeg flere prosjektet hvor vi hadde svært gode erfaringer med ytelsestesting kombinert med applikasjonsovervåkning. Vi overvåket alt fra selve appen til applikasjonsserveren, databaser og integrasjonspunkter med en såkalt Application Performance Management (APM) løsning. Kombinert med kompetanse og erfaring ble «ytelse som en tjeneste» et trygt startpunkt før lansering av en applikasjon.
Eksempler på godt kjente bedrifter jeg jobbet med denne type problematikk var REMA 1000, Coop og Vipps, i tillegg til flere store offentlige tjenester.
Jeg jobber ikke lenger som konsulent, men trenger du denne type assistanse; les mer hos Sopra Steria.
Hva er en ytelsestest?
En ytelsestest kan raskt defineres og utføres; utfordringen er å tolke resultatene på en god og måte. Ofte er det vanskelig å være sikker på hva resultatene egentlig betyr. Reflekterer de virkeligheten, eller ikke?
For å utføre vellykkede ytelsestester er man avhengig av god kunnskap og en strukturert tilnærming, i tillegg til gode verktøy. Vi har sett at dette er komplisert og krever en del prøving og feiling. Derfor satte vi da jeg jobbet i Sopra Steria sammen ytelsestesting som en tjeneste ved å kombinere testverktøy, overvåkningsverktøy og kunnskap, slik at kunden slipper å gå opp løypa på nytt og heller kan nyte godt av konsulentenes erfaring og kompetanse.
Hva får du ut av det?
Ved å kombinere ytelesesverktøy med APM verktøy kan du analysere nøyaktig årsak til ytelsesproblemer og rapportere feil tilbake til utvikling. Dette minimerer utviklernes tid brukt på å gjenskape feil, og gjør det enklere å ta høyde for ytelsesutfordringer før de treffer sluttbrukeren.
Leveransen blir ikke lenger bare en ytelsestest som gir deg ett teoretisk grunnlag for å si om appen tåler mange brukere, men også faktiske målinger på hva som skjer med hele løsningen når den utsettes for trykk samt gi forbedringsforslag til hvor utviklere og arkitektur kan utbedre applikasjonen.
Ytelsestesting i SuperOffice AS
Etter at jeg sluttet i Sopra Steria så tok jeg med meg disse erfaringene til SuperOffice hvor vi nå kjører ytelsestester automatisk hver eneste morgen med Apica ASM/ALT og bruker Microsoft Application Insights til måling og analyse av hele miljøet.
Resultatet fra testene blir postet automatisk i en egen kanal i Webex (vår interne samhandlingsplattform).
Vi kjører også stresstest med et høyere antall virtuelle brukere manuelt etter hver akseptansetest. Jeg har en kollega i Sri Lanka som sammen med meg har ansvar for å vedlikeholde testskriptene, kjøre testene og lage en analyze på slutten av hver sprint.
Ytelsestest kan være det som skiller mellom katastrofe og suksess for din neste app eller tjeneste! Har du råd til å la være?