Testing av apper i ekte verden

Dette innlegget ble opprinnelig publisert i 10 Things Blogg i september 2011.

Det fine med internettaktiverte applikasjoner er at det er enkelt å tilføre verdi med rike medier, overvåking i sanntid og andre funksjoner. Men med denne fleksibiliteten kommer nye ansvar for å teste applikasjonenes "godhet" i sanntids situasjoner. Hvis for eksempel ansatte bruker mobile enheter drevet av Internett, kan apputviklere ikke lenger anta et stabilt miljø på kontoret der applikasjonene deres vil bli brukt. I stedet kan det hende de må vurdere om en app vil bli brukt i en bil i bevegelse, eller i temperaturer under frysepunktet. Dette er i konflikt med dagens metodikk for testing av IT-applikasjoner, som vanligvis ikke går langt nok til å teste for miljøvennlighet og brukervennlighet. Som et resultat kan IT savne båten i sin teststrategi og finne seg i å gjøre mye mer arbeid med vedlikehold av apper.

Her er ti ting du bør tenke på hvis du utvikler apper som må fungere med "ting" utenfor - miljøer og utfordringer med brukervennlighet som du ikke lett kan forutse i testlaboratoriet ditt.

1: Tenk på hvordan folk vil bruke applikasjonen

En applikasjon som leveres pakket på en bærbar eller bærbar datamaskin med en forbrukerklasse for en polititeambil, tåler ikke strenge krav til høye hastigheter og konstante smell og slag. En del av applikasjonsteststrategien, hvis du utvikler for situasjoner som denne, bør omfatte testing av robustheten til selve enheten under ugunstige driftsforhold. Hvis du ikke klarer å inkludere enheten i testplanen din, kan appen være flott - men den kan også krasje i et kritisk øyeblikk hvis sluttenheten mislykkes.

2: Tenk på miljøforhold

Det gjør ikke noen noe bra hvis en sluttbruker prøver å plassere en enhet av forbrukerklasse i en fryser for å overvåke temperaturene. Robuste håndholdte enheter er spesielt designet for arbeid under ekstreme kalde forhold. Dette er et tilfelle der det er viktig å kjenne miljøene som brukerne skal bruke sine mobile enheter i - noe som igjen gjør det viktig å inkludere enheten så vel som appen i testplanen din.

3: Utvikle en omfattende testplan med en sjekkliste for brukervennlighet samt appfunksjoner og funksjoner

Åtti prosent av aksept av sluttbrukere av en app kommer ned til brukervennlighet (over funksjoner og funksjoner). Likevel interessant er en IT-testplan vanligvis det motsatte (80 prosent funksjoner / funksjoner og 20 prosent brukbarhet). En gang redesignet jeg en app som hadde sittet på sokkelen hos et selskap i mer enn to år fordi den hadde et uvennlig brukergrensesnitt. Når vi parerte bort to tredjedeler av grensesnittet (og redusert funksjonsfunksjonene som er satt for å gjøre appen mindre kompleks), var brukeropptaket nesten øyeblikkelig.

4: Engasjere brukere aktivt i testing

Å engasjere brukere i testing (spesielt for brukervennlighet og miljøtilpassning) sikrer at det ikke blir noen overraskelser fra brukersiden når appen går i produksjon. Det sikrer også avmelding og innkjøp av apper for appen og et kontinuerlig samarbeidsforhold til sluttvirksomheten når du forbedrer appen over tid.

5: Engasjer brukere foran i appdesign

Mange IT-applikasjonsutviklere får nå brukere involvert helt i begynnelsen av applikasjonsdesign, spesielt når det gjelder utforming av applikasjonsgrensesnittet. Det er en god praksis, fordi den gir en fungerende blåkopi av brukergrensesnittkrav som testplanen din kan kobles til. Det setter også brukerne (og ikke IT) ansvaret for å designe "looken" til appen.

6: Prototype

Så snart utviklere har en fungerende modell av en app, bør de sette seg ned med sluttbrukere og demonstrere både brukergrensesnittet og hvordan data flyter inn og ut av grensesnittet. Disse demo-øktene skal være korte og iterative (ettersom flere deler av appen er fullført), og de bør ofte forekomme. Å gjøre dette vil sikre at appen fortsetter å spore oppfylt brukerkrav. Disse vanlige prototypevisningene vil redusere QA og de endelige testtidene betydelig.

7: Bygg skalerbarhet i appen din - og test for den

Spesielt for Internett og mobile enheter, bør apptillegg som rich media forventes å vokse. Designplanen din bør forutse dette (f.eks. Skalerbarhet for lagring, CPU, båndbredde) - og testplanen din skal teste for den. Ved å dimensjonere for fremtidig utvidelse, kan du unngå kostbar redesign av appene.

8: Inkluder sikkerhet og låsing

Datakryptering, samsvar med sikkerhetsstandarder og lokaliserings- og låsemuligheter når enheter går tapt, er alle viktige testpunkter for mobile enheter. Det blir vanligvis de to første, men lokaliseringen og låsningen blir ofte savnet. Det skulle det ikke være. Tretti milliarder dollar verdt av mobile enheter gikk tapt i fjor.

9: Bruk standard API-er for appgrensesnitt

Et av de verste marerittene for applikasjonsintegrering (og nesten alle apper er integrert med forskjellige datalagringsplasser, andre apper osv.) Er utviklingen av tilpassede grensesnitt som må endres over tid - og som igjen skaper vedlikeholdsarbeid på alle annen app de berører. Du kan spare mye tid i regresjonstesting ved å holde deg med standard API-er.

10: Gjør testing av alles virksomhet

Vi har allerede snakket om å få sluttbrukere engasjert i den endelige kassen og i mellomkassene. Men det er også bra å ta med innspill (og utsjekking) fra helpdesk, som forstår så vel som alle i IT hva de konstante brukerens smertepoeng er. Det er også en god ide å dele QA-teamet ditt i to leirer: den ene siden som tester appen for teknisk "godhet" og en andre side som tester for brukervennlighet og samlet "fit" for virksomheten og sluttbrukerens arbeidsmiljø.

Topp 10 nyhetsbrev

Vend deg til disse må-lesne primerne for å få den magre på de hotteste teknologiske emner, strategier og analyser. Leveres fredager

Registrer deg i dag

© Copyright 2021 | pepebotifarra.com