Continuous Delivery i en ikke perfekt verden

I mit forrige indlæg skrev jeg om de ting jeg synes er vigtigst for at få testen til at være effektiv når man kører continuous delivery. Nogle af de råd forudsætter dog, at man ikke har alt for mange afhængigheder, teknisk gæld og lign. Det er jo desværre ikke altid tilfældet. Så hvad gør man, når man ikke har et nyt projekt fyldt med microservices, featuretoggles og containere, men derimod arbejder i en reguleret industri med regler om hvem der kan få adgang til produktion, hvordan der skal dokumenteres, sikkerhedskrav osv.? Jeg har fire bud på det:

Bud 1: Erstat det der ikke kan lade sig gøre

Nogle gange er man i den situation, at et element i agile eller continuous delivery ikke kan lade sig gøre. Det kan være pga. love, konventioner, tidligere tiders synder, eller noget helt fjerde. Min erfaring er dog, at hvis man finder ud af, hvorfor det element er der, så kan man normalt godt finde på noget, der opfylder det samme formål. Det bliver ofte dyrere, eller kræver lidt mere bureaukrati, men kan trods alt lade sig gøre. Et eksempel kunne være adgang til produktion. Hvis det kun er udvalgte personer fra driften, der kan få adgang til produktion og man ikke kan få en af dem på teamet, så må man finde på noget andet. Ved at booke en person fra driften til at deltage i stand-up hver dag, kan man opnå næsten det samme, som hvis teamet selv havde adgang. Hvis det ikke kan være hver dag, så hver anden dag - osv. Det er sup-optimale løsninger, men man opnår trods alt nogenlunde det samme, som hvis teamet havde adgang, men det koster lidt mere både i tid og penge.

På længere sigt er det også en god ide at arbejde på, at få fjernet begrænsningen. Hvis det er lovkrav kan det være svært, men det er ret få gange jeg har oplevet at det er juraen der sætter begrænsningerne. Langt de fleste gange er det et spørgsmål om kapacitet, økonomi eller “sådan plejer vi ikke at gøre”.

Bud 2: Få styr på ansvarsfordelingen af test - hvem tester hvad

En af de problemer jeg oftest ser i agile setups er, at teams ikke er uafhængige, og derfor bliver nødt til at release sammen. Når man laver store komplekse systemer, kan det være svært at undgå, men det gør desværre også at man ikke kan holde testen inden i teamet.  Det er derfor vigtigt at få afklaret, hvem der tester på tværs. Teams tester selvfølgelig deres egen software, men hvem tester integrationerne?

En strategi kunne være, at det team der er afhængig af en anden integration står for testen. Det kræver dog at de vender tilbage til testen, når komponenten i den anden ende ændrer sig. Det kan endda også være, at komponenten slet ikke klar, når det afhængige team koder deres integration (mod en stub). Endelig er der også end-to-end-testen, der går på tværs af hele løsningen. Hvem skal teste den?

SAFe har nogle løsningsforslag, der dog ikke er særlig specifikke. Det ene er shared services, og det andet er systemteams. Shared services er specialister og services, som ikke er tilknyttet et bestemt team, og typisk skal bookes på forhånd. Systemteams er specielle teams der oprettes for at opfylde en bestemt funktion. F.eks. tværgående test. Personligt hælder jeg mod systemteams, men det vigtige er sådan set bare at man får det aftalt. Både hvem der designer testcases, finder testdata og udfører testen.

Bud 3: Overblik over afhængigheder

For at vide hvad der skal testes på tværs, er det nødvendigt at have overblik over, hvilke afhængigheder, der er mellem løsningens komponenter. Det lyder måske åbenlyst, men når et system har eksisteret i 30 år, kan man nemt have mistet overblikket, og nogle gange opstår integrationer simpelthen uden at nogen opdager det. F.eks. kan et system skrive et CPR-nummer med bindestreger i databasen, hvorefter det bliver replikeret over i et datawarehouse, hvor et andet system læser det. Hvis man nu fjerner bindestregerne, vil det andet system måske fejle, hvis man har kodet det lidt sjusket.

Det er en afhængighed, der er svær at opdage, og jeg har ikke nogen fremragende løsning på problemet udover tæt samarbejde og et par gode råd:

  • Hvis det er muligt, så undgå at bruge databasen som integrationspunkt. Brug i stedet webservices, hvor man i højere grad specificerer strukturen af data, og kan validere at den overholdes.

  • Hvis man bruger databasen som integrationspunkt, så få styr på hvilke systemer der har login til dem. Giv dem hver deres, hvis de tidligere har benyttet et fælles. På den måde ved man, hvem der skal potentielt skal koordineres med. Det kan dog desværre ofte blive en lang liste.

Bud 4: Få styr på testdata

Testdata er næsten altid besværligt, men når man skal teste på tværs af mange teams der løbende laver ændringer, bliver det ekstra slemt. Mange forsøger at løse problemet, ved at bruge en kopi af produktionsdatabasen, men pga. af datamængderne kan det ofte være et problem og efter GDPR er kommet, kan man næsten ikke slippe afsted med det. (Pseudo)anonymisering af produktionsdata er en mulighed, men det er typisk ret dyrt og komplekst og det er også svært at holde opdateret.

Min foretrukne metode er sæt statiske grunddata, der er tilpas varieret til at dække alle testscenarier og så genereret data for resten. Det betyder, at hvert team løbende skal vedligeholde et sæt testdata, der repræsenterer deres komponent og basere dem på et fast sæt nøgler som alle bruger (f.eks. cpr/cvr-numre). På den måde har man f.eks. 100 kunder som alle kan teste på, og hvis man vil teste noget specielt (f.eks. load)  så må testen generere data først. Det kræver noget koordination mellem teams, specielt i starten, for at få og bevare den nødvendige variation, men metoden gør det nemt at teste og man skal ikke jonglere rundt med meget store databaser i testmiljøerne.

Det var så de fire bud jeg har på, hvordan man kan mitigere nogle af de problemer man løber ind i, hvis ens kontekst ikke er helt perfekt. Det er ikke tænkt som at være udtømmende, men jeg håber det kan inspirere.


Fem erfaringer med continuous delivery

Der tales meget om continuous delivery(CD) for tiden - nok ikke mindst fordi SAFe rammeværket er blevet meget populært, og CD er en central del af SAFe, og er en af nøglerne til virkelig at få værdi ud af SAFe. Der findes mange definitioner af CD, men generelt er det noget i stil med:

Continuous delivery er en metode, der lader teams hurtigt, sikkert og fortløbende levere ændringer til slutbrugere når forretningen ønsker det.

Måden man gør det på er ved at lave en eller flere processer, der mere eller mindre automatisk kan skubbe en lille ændring af softwaren op igennem en række testmiljøer der ligner produktionssystemet mere og mere og til sidst frigiver ændringen ud i produktionsmiljøet.

Der er naturligvis mange dele i sådan en proces, og det jeg vil dele her er de vigtigste erfaringer jeg har gjort mig i forhold til at implementere testen i CD.

Erfaring 1: Lad ikke test blive en silo (igen)

I agile giver man teamet ansvar for kvaliteten. Der kan dog stadig godt være en tendens til at det er specifikke personer på teamet der tager ansvaret - specielt hvis man har dedikerede testere på teamet. Det er helt fint, hvis man releaser hver 14. dag, og på mange måder giver det god mening, at de personer der brænder mest for test også står for det meste af testen. Når man går over til en proces der potentielt kan release flere gange dagligt, bliver det ofte en eller to personer der driver en ændring hele vejen igennem, og så bliver det dog enormt vigtigt, at det er hele teamet der føler ansvar for kvaliteten. Ikke bare at acceptkriterierne på en userstory er opfyldt, men også at slutbrugeren får en god oplevelse med at bruge softwaren.

Erfaring 2: Fokuser på produktdækning frem for kodedækning

Når vi skal release ofte kan man ikke nå at teste alt - heller ikke selvom testen er automatiseret! Det er en kamel der lige skal sluges, men når man har gjort det, så er der nogle ting man kan gøre i stedet. Den første er en gammel kending: risikobaseret test! En af nøglerne for mig har været at få produktrisikoanalysen integreret dybt ind i den agile proces. Ikke i den traditionelle form med møder og skemaer, ved at gøre det til en vane i teamet at vurdere og løbende diskutere sandsynlighed og konsekvens hver gang vi arbejder med en story eller feature. Den anden ting jeg har gode erfaringer med, er at fokusere testen på de dele af produktet der er vigtige for slutbrugerne. Hvis man ellers laver sin risikoanalyse rigtig, så kommer normalt også til at teste der hvor konsekvensen for brugerne er høje, men jeg har fået god værdi ud af, også at bruge lidt tid på, at finde ud af, hvilke brugere der er vigtigst, og hvilke dele af applikationen der er vigtigst for dem.

Erfaring 3: Mål kvaliteten via flere kanaler

De fleste af os er vant til at måle kvalitet via manuel eller automatisk test, og evt. fra værktøjer der kan udføre statisk analyse på koden. Hvis vi skal release hurtigt og ofte, så er dog vigtigt at få flere andre kilder med. Dels bliver det endnu vigtigere løbende at overvåge ikke funktionelle karakteristika som svartider, men logfiler og produktionssystemet bliver også vigtige kilder. Ligesom med erfaring 2 er der lidt en kamel der skal sluges i forhold til, at man også “tester” i produktion. Det er ikke fri leg, men når man releaser så ofte, vil der nogle gange slippe fejl igennem. Ved at overvåge svartider, logfiler osv. kan man spotte de fejl inden brugerne oplever dem. Traditionelt har driftsorganisationen måske gjort det samme, men i CD bliver det et vigtigt værktøj for teamet.

Det er et stort emne, og ikke alle teams vil få lige store mængder af adgang til produktion, men løbende overvågning af logfiler og svartider på testmiljøerne i forbindelse med test, vil alle kunne få gavn af.  Man kan evt. overveje at bruge aggregerings værktøjer som ELK-stack der kan indsamle logs og metriker fra flere kilder, for at gøre det lettere at overskue.

Erfaring 4: Test løbende, og ikke i slutningen

Jo hurtigere vi finder fejlen, jo hurtigere kan vi rette den. Derfor er det vigtigt at teste ting så hurtigt, som muligt. Det betyder normalt, at man tester detaljer på de lavere miljøer - dvs. dem uden så mange integrationer, og sammenhænge og værdi for slutbrugere på de højere miljøer. Det er derfor vigtigt at fokusere på, hvad der testes hvornår i de enkelte features og stories. Husk også at teste de mere operationelle sider af applikationen. Husk f.eks. at udarbejde og teste effektive roll-back rutiner, så man kan rulle en ændring tilbage. Det gør det langt mindre risikofyldt at release noget til produktion, hvis man kan tage det af igen.

Erfaring 5: Få infrastrukturkompetencer ind i teamet

Når man kører CD skal teamet være endnu mere tværfunktionelt end tidligere. Der kræves mere viden om netværk, firewalls, scripting, osv. end normale applikationsudviklere typisk har. Ved at få personer fra infrastruktur eller drift ind på teamet, får man de kompetencer, og samtidig får man folk der er vant til at håndtere produktionssystemer, og har fokus på kvaliteten af de føromtalte operationelle sider af en applikation.

Det var mine fem bud på, hvordan du får en god og effektiv test når du kører continuous delivery. Den her slags indlæg er i sagens natur aldrig udtømmende, og vil ofte skulle justeres til den kontekst man er i, men jeg håber de kan inspirere. Flere af dem laver også nogle forudsætninger om uafhængige teams, og løst koblede systemer, som ikke altid er opfyldt. Hvis du er i den situation, kan du måske få gavn af det her indlæg: Continuous Delivery i en ikke perfekt verden


Nyt job!

Bloggen er jo ikke så aktiv, men i morgen kommer der et par nye indlæg. Jeg kiggede derfor mine tidligere indlæg igennem og opdagede, at jeg flere steder nævner, at jeg arbejder for Capgemini Sogeti. Det gør jeg dog ikke længere!

Efter 6-7 gode år, besluttede jeg mig for at prøve noget nyt, og fik job hos Q Nation. i august 2017. Q Nation er et konsulenthus ligesom Capgemini, men nystartet, fokuseret på test, og selvfølgelig MEGET mindre. Jeg laver nogenlunde det samme som før - mest konsulentarbejde, men også lidt rådgivning, undervisning osv.

Her efter halvandet år, er jeg rigtig glad for mit job, og det går også fint med Q Nation. Vi er efterhånden 30+ ansatte.

Vi ses derude! :-)

Hvorfor tager jeg til konferencer?

Jeg er lige nu til konferencen StarEast i Orlando, Florida. Det er planen at blogge om de forskellige indlæg, men før det tænker jeg, at det også er interessant at tale lidt om hvilken værdi jeg selv, og den virksomhed jeg arbejder for får ud af det.

En dag på en konference består normalt af en såkaldt “keynote”, hvor en af de kendte/dygtige indlægsholdere fortæller om et emne. Keynotes har ofte et visionært emne, og er ikke så detaljerede som de efterfølgende indlæg. Efter keynoten opdeles konferencen normalt i et antal spor med individuelle temaer. Hvert spor har et antal indlæg på ca. 45 minutter. Et spor kunne f.eks. handle om agil test, eller automatisering. Normalt kan du hoppe rundt mellem de forskellige spor som du har lyst. Ud på eftermiddagen, afsluttes dagen normalt med endnu en keynote.

Hvis konferencen er kort, dvs. to dage, så følger begge dage denne model. Hvis konferencerne er længere, så der det normalt i form af en eller to dage med “tutorials” før selve konferencen. Tutorials er en form for minikurser på en halv eller en hel dag som man vælger når du tilmelder dig konferencen. De har normalt en ret høj kvalitet, men være tidligt ude med tilmeldingen, da de populære emner hurtigt bliver udsolgt. 

Så hvad er det jeg får ud af det, og hvad får min virksomhed ud af det?

  1. Inspiration og motivation: Den primære personlige grund til at jeg deltager i konferencer er at de inspirerer mig. I løbet af året kan jeg godt falde ind i en tankegang om at test bare er test. Når jeg så deltager i en konference hører jeg mange nye ideer omkring test, og taler med andre mennesker der også brænder for test. Jeg kommer hjem med masser af ideer til, hvordan jeg kan forbedre den test jeg pt. sidder og arbejder med, og til hvor jeg skal bevæge mig hen i fremtiden. Det kan både være simple ting som hvad jeg skal prøve næste gang jeg laver planlægning af en test, og det kan være en hel ny strategi for testautomatisering. Alt i alt vender jeg hjem med en kriblen i fingerne for at arbejde med mit fag, og motiveret for at forbedre den måde jeg arbejder på.

  2. Ny viden: Dem der tager til konferencer er næsten altid meget engagerede. Det giver rig mulighed for at med de andre deltagere om hvordan de tester, og derudover hører man masser af oplæg fra nogle af de største eksperter inden for test. Der er masser af viden, og hvis du har specifikke spørgsmål du gerne vil have svar på, er det bare at spørge.

  3. Deling med andre kolleger: Når jeg har været til en konference holder jeg normalt et eller flere oplæg for mine kolleger om, hvad jeg har hørt, og hvordan jeg kan se det brugt i min hverdag. På den måde får vi delt den viden, og virksomheden får yderligere gavn af min deltagelse. Hvis du ikke er så vant til at holde præsentationer, er det også en god og tryg mulighed for at øve sig.

  4. Arbejdsglæde: Inspiration og motivation er selvfølgelig en del af arbejdsglæde, men at min virksomhed er villig til at investere i mig, og at komme væk fra dagligdagen for at tale om mit fag sammen med andre testere, er bestemt også en kilde til at føle større arbejdsglæde.

  5. Networking: På konferencen er der rig mulighed for at opbygge netværk med andre testere, men hvis du er afsted med kolleger, er der bestemt også mulighed for at komme nærmere på de kolleger du arbejder sammen med i hverdagen.

At tage på konferencer koster ca. det samme som at tage på kursus, men for os danskere er konferencerne dog ofte i udlandet, så rejseomkostningerne er lidt højere. Det giver til gengæld masser viden, inspiration og motivation - både til dig der deltager, men også til kolleger og til virksomheden generelt. Hvis du har muligheden, så prøv det!

En oplagt første konference er TestEXPO som vi (Jeg arbejder for Capgemini Sogeti) afholder i starten af året. Den minder meget om de store konferencer, men tager kun en dag. TestEXPO er gratis, så det er nemt at overtale chefen, men til gengæld skal du være hurtig, da billetterne går som varmt brød.  Den næste er i 2017, så hold øje med testexpo.dk eller meld dig ind i LinkedIn-gruppen

Hvilke mobile platforme skal du teste på?

Tester du din mobile løsning på de samme platforme, som dine brugere har? Når du tester jeres apps eller andre mobile løsninger, er det altid et spørgsmål, hvilke platforme der skal teste på. Dvs. hvilke kombinationer af enheder og versioner af operativsystemet skal ens testcases køres på?

Hvis du ser på enhederne først, så kan de have mange forskellige egenskaber, der kan påvirke, om der skal testes på dem. Det kan være fingeraftrykslæser, ForceTouch, eller noget helt andet, men den egenskab, der påvirker vores test mest, er skærmstørrelsen. Dvs. du skal have et udvalg af skærmstørrelser, der svarer til de skærmstørrelser, der bliver brugt i produktion. Hvis løsningen allerede er i produktion, kan du få den information fra app-storen, hvis det er en app, eller fra webserveren, hvis det er en webløsning.

Hvis løsningen ikke er i produktion, eller du af andre grunde ikke har adgang til informationen, kan du bruge statistikker, som frigives af forskellige virksomheder. Nogle koster penge, men der findes også gratis løsninger. Et eksempel er StatCounter, hvor du for Danmark kan se, hvilke skærmstørrelser de mest brugte telefoner eller tablets har, og du kan herefter udvælge enheder med de relevante skærmstørrelser.

Når du har information om skærmstørrelserne, så skal du finde ud af, hvilke operativsystemer man skal teste på. Først skal du beslutte, om du overhovedet vil teste på en bestemt platform. Hvis I laver native apps (dvs. en app, der er skrevet specifikt til et operativsystem), så giver det lidt sig selv, men hvis I bruger frameworks, der kan køre på flere platforme, eller har en webløsning, så skal du tage et bevidst valg. Hos StatCounter kan man også se, hvad fordelingen af Android, IOS og Windows Phone-enheder er i fx Danmark, og ud fra det tal kan du så beslutte, hvilke platforme, der skal testes. Fx har Windows Phone kun ca. 2-3% af markedet i Danmark, så mange vælger ikke at teste på den.

For hvert operativsystem du vælger, skal du beslutte, hvilke versioner, der skal testes på. Det er igen noget du kan få fra jeres produktionssystemer, men alternativt er distributionstal for de forskellige platforme frit tilgængelige fra producenterne.

For IOS kan du se dem her
For Android kan du se dem her

Generelt er Apple ret aggressive i forhold til at opdatere folks enheder, så det er normalt nok at teste på de to senest versioner. Mange Android-enheder kan derimod ikke opdateres eller bliver det bare ikke, og derfor er det nødvendigt med 4-5 versioner for at få en passende dækning.

Nu skal du så definere dine platforme ved at kombinere skærmstørrelser og operativsystemversioner. Her kan du vælge at være grundig og teste alle skærmstørrelser på hver operativsystem, eller du kan nøjes med at teste nogle kombinationer. Det bestemmes ud fra den risiko testen forsøger at afdække, eller den tid, der er til rådighed.

Der kan som nævnt være andre egenskaber ved enheder, som du ønsker at teste, hvilket kan påvirke dine valg af enheder. Samtidig er det vigtigt at huske på, hvem ens brugere er, når du bruger statistikker. Fx er der langt flere IOS enheder i de større byer, så hvis dine brugere primært bor i byen, kan du måske ikke helt regne med statistikken, der kigger på hele landet.

Alt i alt får du dog et godt udgangspunkt ved ovenstående metode, og platformene kan herefter raffineres på baggrund af testerfaringer og udviklingen af nye enheder og operativsystemer.

Kender du de agile testkvadranter?

Et af de spørgsmål jeg hører mest omkring agil test er, hvordan man laver en teststrategi. Hvis man tidligere har arbejdet meget i projekter der følger en V-model e.lign., er det naturligt at man også gerne vil lave en for et agilt projekt, og det er bestemt også relevant. De agile testkvadranter er en del af svaret og en af de modeller jeg bruger mest i agile projekter. De er oprindeligt opfundet af Brian Marick og ser sådan her ud:

 Klik her for at hente "De Agile Testkvadranter"  (20mb) ned som PDF til print i op til A0+ 

Som navnet antyder er der fire kvadranter der hver indeholder nogle test typer. Testtyperne er fordelt efter, hvilken værdi de bidrager til projektet.


Kvadrant 1
Indeholder unittest og lign. test der ofte håndteres af team medlemmer der kan kode. Disse tests giver fokus på intern kvalitet og hjælper med at bygge kvalitet ind i produktet. De hjælper også teamet med at få lavet mere, ved hurtigt at kunne give feedback da det er testtyper der normalt automatiseres og dermed nemt og hurtigt kan bruges som regressionstest.


Kvadrant 2
Indeholder testtyper der tester en given funktionalitet i produktet. F.eks. de tests der tester en
storys acceptkriterier. Her styrker testen samarbejdet mellem forretningen og teamet. De giver
fokus på at bygge den funktionalitet forretningen ønsker og vil i vid udstrækning også kunne
automatiseres og dermed supportere teamet i form af regressionstest.


Kvadrant 3
Indeholder testtyper der ser på produktet som en helhed og ofte benytter testernes erfaring med enten domænet eller produktet som en aktiv del af testen. Det er f.eks. tests, hvor man afprøver realistiske brugsscenarier og forretningsgange. Dermed får man afprøvet om produktet rent faktisk kan bruges til det brugerne ønsker. Det betyder samtidig at disse tests er meget svære at automatisere, men i højere grad hjælper med at afgøre om teamet er på rette vej og leverer det rigtige produkt.


Kvadrant 4
Indeholder en hel gruppe af tests som vi ofte glemmer - de non-funktionelle. Dvs. tests der ikke så meget har fokus på hvad produktet kan, men mere på hvordan. Den mest kendte testtype er de forskellige typer af performance (svartid, load, stress osv.) men her testes også sikkerhed, brugervenlighed m.m. Ligesom testtyperne i kvadrant 1 er det tests der har fokus på produktets kvalitet, men nu mere den eksterne kvalitet. Gør produktet det det skal godt nok? Hvorvidt disse test kan automatiseres svinger meget fra produkt til produkt, men de kræver ofte en eller anden form for værktøj og ofte er specialister også involveret.


Konklusion
Når vi nu har været igennem alle de kvadranter, hvad kan de så bruges til og hvad har de med en teststrategi at gøre? Det man kan bruge dem til, er at man skal tænke over hver kvadrant når man har noget der skal testes. Dvs. teststrategien grundlæggende er: For alle elementer der skal testes, skal der være noget test fra hver kvadrant, eller man skal have taget en bevidst beslutning om, at det ikke er nødvendigt.

Jeg skriver “elementer” og ikke “stories", “features” eller “epics” fordi man netop kan bruge strategien på alle niveauer. Når man taler om, hvordan vi tester hele produktet skal vi tænke over hver kvadrant, og når vi tester en enkelt klasse skal vi tænke over hver kvadrant. På den måde skal strategien ikke hele tiden ændres for at følge med de mange ændringer der hele tiden sker i agile projekter. Det er samtidig også en strategi der hurtigt kan præsenteres og som hele teamet aktivt kan anvende. Print den ud i plakatstørrelse og hæng den centralt i projektlokalet.

 

 

Mobile Performace Testing

Performancetest er vigtigt for alle typer af software, men for mobile applikationer er det særligt vigtigt! 

De enkelte mobile enheder har ofte meget begrænsede ressourcer og vi bruger dem anderledes end vi bruger mere traditionel software som f.eks. det vi kører på en laptop. Faktisk siger 3 ud af 5 it-ledere i 2014 at deres primære fokus for mobiltest er performance (kilde: World Quality Report 2013-14).

Så hvad skal man tænke over, når man laver perfomancetest af mobile applikationer? Det varierer selvfølgelig fra applikation til applikation, men hvis man adresserer følgende tre punkter i sin test er man i hvert fald godt på vej og langt foran gennemsnittet.

  • Hvem bruger min app?

  • Hvilke typer forbindelser skal testes?

  • Performance på de enkelte enheder?

Hvem bruger min app?

Først er det vigtigt at identificere brugerprofilen for dine brugere og den belastning der skal simuleres under testen. 

  • Er det en native app eller en browserløsning?

  • Hvilke enheder har brugerne og hvilke versioner af operativsystemer er der på dem?

  • Hvis det er en browserløsning, hvilken browser bruges der så mest? - Safari, Chrome, Explorer etc.

  • Hvor er brugerne henne i verden og hvor mange er der hvert sted?

  • Hvor tit kommunikeres der mellem enhederne og serveren - og hvor store mængder data?

  • Er der nogle dele/forretningsprocesser der bruges mere end andre?

Hvilke typer af forbindelser skal testes?

At en bruger er mobil er langt fra det samme som at vedkommende er online hele tiden. Forbindelsen vil f.eks. variere når brugeren flytter sig eller vejret skifter og alt efter om brugeren benytter, 3g, 4g eller wifi vil der være betydelige forskelle i svartider og overførselshastigheder. En god tilgang til testen er først at etablere en baseline, hvor der kun testes med en enkelt bruger/enhed. Her måles både svartider fra serveren men også hvordan brugerinterfacet på enheden opfører sig. Herefter gennemføres en test hvor en realistisk belastning på systemet simuleres og der samtidig testes med fysiske enheder for at se konsekvenserne af den eventuelt reducerede performance. 

Der er således to aspekter der skal simuleres i testen.

  1. En realistisk belastning på serveren. Det er ofte lettest at gøre via cloud-løsninger, da det normalt vil kræve at man har servere placeret på de fysiske lokationer hvor belastningen kommer fra, men for interne applikationer kan virksomhedens eget datacenter nogle gange benyttes.

  2. Forskellige typer af forbindelser på de fysiske enheder. Dette gøres oftest lettere via en proxy der understøtter “throttling”. Dvs. begrænse forbindelsens hastighed. Evt. kan man også tage de fysiske enheder ud i de omgivelser hvor de skal bruges, men det kan her være svært at få konsistente tests.

Performance på de enkelte enheder 

At måle performance af en server når mange enheder forbinder til den er vigtigt, men det er lige så vigtigt at teste om appen (klienten) fungerer tilfredsstillende på de enkelte enheder. Hvis f.eks. batterilevetiden halveres når appen benyttes, vil brugerne hurtigt finde en anden løsning hvis de får muligheden. Det samme gælder for processorbrug, hukommelse, grafikhastighed o. lign.

Den nemmeste og bedste måde at måle dette på er normalt, at indbygge et framework i ens app der kan rapportere enhedens tilstand tilbage til en server med faste intervaller. Husk at benytte informationen fra tidligere om, hvilke enheder og operativsystemversioner brugerne har til at teste de meste relevante kombinationer.

Opsummering

Performancetest af mobile løsninger er ikke bare at teste at serveren kan holde til en masse belastning. Vi skal også huske at teste ude på de enkelte enheder og vi skal huske at simulere vores brugere præcist, både hvad angår lokation såvel som forbindelseskvalitet. Som det altid gælder for performanceproblemer, så kan de være rigtig dyre at rette, hvis man først finder dem lige omkring release. Begynd derfor så tidligt som overhovedet muligt. Hvis der er skrevet noget kode, kan vi også måle på, hvor hurtigt det kører og om det pludseligt bliver langsommere!

Info: Jeg arbejder for CapGemini Sogeti Danmark og denne artikel er også publiceret vores virksomhedsblog. Her kan du læse interessante indlæg om bl.a. test fra mine kolleger: www.capgeminisogeti.dk

Tolv hurtige, som ofte bliver glemt

Der er rigtig mange ting, som skal overvejes, når man tester mobile løsninger. Sikkerhed, funktionalitet og performance skal alt sammen virke efter hensigten på mange forskellige enheder og operativsystemer. Her er 12 test cases, som ofte bliver glemt under testen - også selvom man har en struktureret tilgang.

  • Indgående telefonopkald

  • Indgående SMS

  • GPS (bevægelse, tab af signal)

  • Bevægelse af telefonen (ryst, gang, løb)

  • Installering og afinstallation

  • Tab af internetforbindelse

  • Drejning af enheden

  • Tryk på fysiske knapper (volumen, tilbage, home)

  • Tilslutning og frakobling af oplader

  • Timeout for skærm / lås af skærmen

  • Voice Over

  • Navigation til anden app og tilbage igen

Har du prøvet dem alle på din app?