Testing Mobile Enterprise Apps for SAP

(Alexander Ilg) (11. nov. , 2020)

Testing er en viktig del av hvert programvareutviklingsprosjekt – enhetstester, integrasjonstester, brukeraksepttester og så videre. I denne bloggen vil jeg diskutere testing av mobile bedriftsapper, spesielt de for offline bruk.

Ingen programvare er perfekt. Raketter blir sendt til Mars, og de krasjer på grunn av feil. Noen fly stenger hvis de ikke blir «startet på nytt» minst hver 248 dager (og du spør meg hvorfor jeg er redd for å fly).

Redd for å fly? Ikke se på feilrapporter for flyprogramvare!

Listen fortsetter og fortsetter, det er til og med en Wikipedia-artikkel som viser eksempler på feil i det hele tatt områder – https://en.wikipedia.org/wiki/List\_of\_software\_bugs .

Å ha og fikse en feil på et sentralt sted som en SAP-systemet kan allerede være smertefullt (omstart av systemet, nedetid, ulykkelige brukere, tapte data osv.). Å fikse en feil i et program som er installert på mange datamaskiner (som for eksempel SAP GUI) er litt vanskeligere, men fremdeles håndterbart hvis alle maskiner er interne og koblet til bedriftsnettverket.

Det blir mye vanskeligere å sende en ny versjon av en mobil bedrift offline applikasjon som er installert på smarttelefoner og nettbrett utenfor firmaets kontor. Selv om du har en enhetsadministrasjonsløsning som Idaptive, SAP Mobile Secure, Mobile Iron eller Airwatch, er det fortsatt mye arbeid. Hvis brukerne har dårlig nettverkstilkobling, er det vanskelig å distribuere nye versjoner. Enda verre hvis det er avhengigheter mellom mobilapp og programvare på serversiden – i så fall må begge oppdateres samtidig, noe som kan være veldig vanskelig hvis brukerbasen er i flere tidssoner og distribuert over hele verden. På grunn av dette er det viktig å teste mobile bedriftsapper veldig nøye. Det spiller ingen rolle hvilken plattform du bruker – Agentry, SMP, SCP Mobile Services, MobiLink eller noe annet. Testing må utføres på alle lag, inkludert klient, mellomvare og backend. Følgende er en liste over tester som skal utføres for alle applikasjoner.

Funksjonstester

  • Test av all funksjonalitet i begge retninger – lag data i SAP og synkroniser dem til den mobile enheten. Opprett data på mobilenheten og send den til SAP. Oppdater poster på begge sider, slett data og kontroller at de også blir fjernet på motsatt system.
  • Testvalidering på mobilenheten – får brukeren riktig advarsel / feilmelding når han skriver inn feil data ?

Ytelsestester – synkronisering og på enhet

  • Synkroniser med det maksimale datavolumet du forventer. Ta også hensyn til at datavolumet kan øke over tid.
  • Test med maksimalt antall samtidige enheter for å se hvordan systemet kan takle belastningen.
  • Test enheten med maksimal datamengde – hvordan er ytelsen til lister og detaljdialoger? Hvor flytende er navigasjonen i appen? Hvor rask er oppstartstiden? Å teste på en simulator / emulator er aldri bra nok, du må teste den på den virkelige enheten som brukeren vil ha i hendene senere!

Test mot UI / UX-retningslinjene til mobiloperativsystem

  • Hvis du har en innfødt applikasjon, følger den UX-retningslinjene fra Apple, Google og Microsoft?
  • Hvis du har en hybrid / plattformuavhengig applikasjon , følger det vanlige retningslinjer (for eksempel SAP Fiori UX-guiden)?

Brukervennlighetstester

  • Gi applikasjonen til brukerne og la dem teste den. Er det intuitivt? Kan de finne ut hvordan de kan bruke den selv uten eller med bare litt dokumentasjon?
  • Test løsningen din med brukere som har erfaring med smarttelefoner / nettbrett og med de som ikke er vant til moderne teknologi.
  • Hvis du ruller ut internasjonalt, kan du teste med brukere fra forskjellige land for å se hvordan de reagerer på programvaren.
  • Test med forskjellige språk og plasseringsinnstillinger for å sikre at alt vises riktig
  • La oversettelsen bli gjennomgått og testet av en morsmål
  • Lytt til testbrukerne dine! Dette er uten tvil den beste tilbakemeldingen du kan få!

Test bak gardinen – ikke bare brukergrensesnittet, også mellomvare og backendintegrasjon

  • Testklient, mellomvare (hvis du har noen) og backend. Alt må fungere godt sammen.
  • Forsikre deg om at kommunikasjonen mellom de tre komponentene fungerer bra.

Test positive og negative tilfeller

  • Test løsningen din med data og test saker du forventer å fungere
  • Test løsningen din med data du forventer å mislykkes.Vi vet alle at brukere vil legge inn den mest uventede informasjonen, og du må sørge for at appen ikke krasjer i et slikt scenario.
  • Forsikre deg om at begge tilfellene blir dekket vellykket
  • Test applikasjonen når mellomvareserveren er nede. Oppfører den seg som forventet? Test det når SAP ikke er tilgjengelig også.
  • Hardt drep appen midt i en lagrings- eller synkroniseringsprosess. Fungerer det fortsatt? Mistet du data?
Høres kjent ut?

Test utenfor laboratoriet / med det virkelige nettverket

  • Test applikasjonen din med det virkelige nettverket brukerne vil bruke senere. Er ytelsen fortsatt god nok med GPRS eller Edge? Er ytelsen akseptabel på eksterne steder?
  • Test programvaren på den virkelige enheten, ikke bare en simulator. Vises alt slik det skal være? Er ytelsen som forventet?
  • Test programvaren med den virkelige enheten under reelle forhold. Kan du lese skjermen i sterkt sollys? Fungerer enheten utendørs i varme eller kulde?
  • Test løsningen med alle de andre appene som er installert – er det noen bivirkninger? Med sandkassefilosofien til Android og iOS skal den fungere, men du må teste den bedre.
  • Test den i situasjoner med lite minne – fungerer appen fremdeles? Hvordan er ytelsen i dette tilfellet? Hva skjer hvis appen fjernes fra minnet?
  • Test appen med eldre versjoner av operativsystemet. Test det også med betaversjoner som vil bli utgitt i fremtiden!
Kan du jobbe med akseptabel hastighet midt i blinken?

Skriv automatiserte testskripter

La utviklerne lage automatiske testsaker som kan kjøres før hver bygging. Å gjøre dette kan redusere testinnsatsen og allerede fange de første feilene før de virkelige testerne starter sine aktiviteter. Automatiserte enhetstester kan imidlertid aldri erstatte “ekte” tester, bare utfylle dem.

Test på forskjellige enheter

Hvis du har en BYOD-strategi (ta med din egen enhet), prøv å teste applikasjonen på forskjellige enheter. Fungerer appen på alle skjermoppløsninger? Hvis det fungerer uavhengig av plattform, fungerer det på alle plattformer?

Test installasjonen / oppdateringen

Test installasjonen og oppgraderingen av mobilappen din. Kan APK, IPA eller XAP lastes ned via telefonforbindelsen?

Test sikkerheten til appen

  • Bruk en nettverkssniffer for å se om krypteringen du slo på er aktiv.
  • Prøv å åpne enhetsdatabasen for å se om den virkelig er kryptert.
  • Test sikker lagring som for eksempel iOS-nøkkelring – er disse dataene bare lokale eller er de sende til skyen?

Test administrasjonsdelen av appen

  • Kan du opprette nye brukere, enheter etc. i mobillandskapet ditt?
  • Kan du avregistrere / slette enheter?
  • Er loggoppsettet riktig? Har de nok informasjon til å analysere problemer? Er det satt lavt nok til at loggen ikke reduserer ytelsen?

Uansett hvor lenge og godt du tester, vil det være feil som glir gjennom sprekkene. Jo mer kompleks appen er, desto mer sannsynlig vil det skje. På grunn av dette bør du alltid ha en tilbakefallsløsning – dette kan enten være et Excel-ark eller bare et stykke papir. Ideelt sett trenger du aldri å bruke den.

Testing er et populært tema – hvor mye testing er nok? Hvor mye er for mye? Du kan argumentere for at man aldri kan teste nok, men noen må betale for det. Som med alt, må du finne den rette balansen.

Lykke til med testingen! Og hvis du har spørsmål, eller trenger hjelp med testingen, kan du ta kontakt med meg på [email protected] .

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *