Meny

Feltesting for mobilapplikasjoner (viktighet og nødvendighet)

  • Hoved
  • Annen
  • Feltesting for mobilapplikasjoner (viktighet og nødvendighet)

field testing mobile applications importance

Prøv Instrumentet Vårt For Å Eliminere Problemer

Feltprøving - mobilapplikasjoner:

Ofte når vi tester mobilapplikasjonen vår, kommer det et spørsmål til oss ‘Om automatiseringstesting, regresjon, belastning, nettjenestetesting er nok for appen vår, eller skal vi teste noe mer? '

I denne opplæringen vil jeg gi en dyp innsikt i feltprøving, dens betydning, strategi og forklare når skal det også gjøres.

Vel, det kan være nok, eller det kan ikke være fordi alle disse testene som automatisering, webservice, belastning osv., Faller under testkategorien ‘Internt’. Men hvis du vil implisere sluttbrukerrollen, er det enda en type test som må gjøres, og det er ingenting annet enn ‘Feltesting’ .

Feltprøving

Som navnet antyder, innebærer det å gå ut av den sterke Wifi-sonen din og bruke 2G-, 3G- eller 4G-nettverket for å sjekke bruken av applikasjonen din. Du kan prøve å bruke appen mens du kjører bilen eller når du går en tur eller sitter hjemme i henhold til din komfort.

For grunnleggende informasjon om testing av mobilapplikasjoner, kan du se følgende veiledninger.

Hva du vil lære:

Klassifisering av mobilapplikasjonstesting

Hvis du tester en webapplikasjon på en mobil, forblir testtypene de samme som du gjør for bærbare datamaskiner som datamaskiner som funksjonell, brukergrensesnitt, grense, belastning osv. Men for å teste en mobilapplikasjon, enten hybrid eller innfødt, testing er klassifisert i to kategorier på det aller første nivået.

De er:

  1. Interntesting
  2. Feltprøving

Grunnlaget for forskjellen mellom disse to kategoriene er rollen du utgir deg for, dvs. Tester du som en kvalitetssikring for å verifisere appen mot kravet, eller bruker du appen som sluttbruker for å oppfylle ditt behov?

Nedenfor er det få forskjeller mellom begge:

Interntesting

Feltprøving

Denne testingen er gjort helt fra den innledende til utgivelsesfasen for å verifisere at applikasjonen oppfyller de oppgitte kravene når det gjelder funksjonalitet, skalerbarhet, brukervennlighet osv. Dette gjøres mot brukerhistoriene eller prosjektkravsdokumentene gitt av kunden.

Denne testingen er gjort i den siste fasen når regresjonen er gjort for applikasjonen og applikasjonen kalles stabil av ‘Teamet’ før utgivelsen. Det kan eller ikke stilles krav til dette fra kunden.

Testtypen inkluderer funksjonell, regresjon, brukergrensesnitt, ytelse, automatisering.

Testtypen inkluderer hovedsakelig funksjonens og brukervennligheten til applikasjonen.

Denne testingen er gjort på både WiFi og mobile nettverk.

Dette gjøres strengt på mobilnettverk.

Testlaboratorier opprettes i et rom eller på en QAs pult.

QAs behov for å gå ut og teste mens du går rundt eller hjemme eller kjører.

Testing kan gjøres på emulator eller simulator.

Testing utføres bare på ekte enheter.

Klassifisering av mobilapptesting

Viktigheten av iOS og Android feltprøving

Som forklart ovenfor gjøres feltprøving for å verifisere oppførselen eller brukbarheten til applikasjonen din som sluttbruker. Dette gjøres i utgangspunktet på telefonens mobilnettverk ved å gå rundt på gatene eller et marked, ved å kjøre bil eller bare være hjemme.

Eksempel på mobil testing

( bildekilde )

I dagens verden bruker vi mobilappene våre overalt, når som helst, er hjemme og handler / bestiller billetter / sjekker e-post osv., Eller står i et marked og leter etter steder / restauranter / kjøpesentre i nærheten eller det å kjøre til et sted ved å søke på kart.

Mobilapplikasjoner har nå blitt en del av vårt daglige liv.

Følgende er noen eksempler som forklarer behovet for å teste mobilappen din i stedet og ikke bare internt:

  • Det er ikke nødvendig at du hver gang har et sterkt Wifi eller hotspot rundt, spesielt i India. Derfor må du stole på telefonens mobilnettverk.
  • Det er steder vi har dekningsproblemer, og telefonområdet vil være middels eller lavt. Dette kan være på grunn av mindre mobile tårn eller tett dekket av trær. Hos meg møter jeg dette problemet mye i tegningen og spisestuen min, noe som er frustrerende hele tiden.
  • Det kan være mulig at du kjører bilen din, og du må få tilgang til e-postene dine eller få veibeskrivelse til et sted som er ukjent for deg.
  • Når vi drar på ferie, har vi ikke (hver eneste) informasjon om byen eller stedet. Når jeg reiser med familien på ferie, går vi alltid alene og bruker appene til å finne ut om byen, det være seg restauranter, steder å besøke osv.
  • I dag foretrekker vi online overføringer ved å bruke apper som PayTm, PayZApp etc., i stedet for å alltid bruke kontanter.
  • Bruker chat-apper, YouTube osv., Hvor som helst.

Dette er noen av sanntidseksemplene som definerer bruken av mobilapper. Derfor blir det viktig å teste appen din i felten. Det kan være mulig at målgruppene dine er i et godt utviklet land med hotspots eller Wifi tilgjengelig overalt.

Men likevel, du bør gjøre minst én feltprøving av appen din fordi:

1) Når du tester appen din mens du kjører bil eller går eller sitter på et sted med mindre rekkevidde, får du vite om appen din har krasjproblemer mens du sender eller henter data.

Vi hadde selve appinnloggingen krasj for den aller første utgivelsen av appen vår, vi testet på en telefon som hadde 3G. Innloggingen ble likevel tidsavbrutt og krasjet.

2) Brukere hater det når de ser et lastesymbol vises i mer enn 5 minutter. Det er veldig viktig å verifisere hva det er svartiden serveren din tar, nettjenesten og appen din for å laste informasjonen.

Laster skjerm

Dette er de to kritiske pekerne som blir bekreftet i en feltprøve, og dette hjelper deg også med å være trygg på at appen din er veldig stabil.

Hvordan påvirkes feltprøven?

Er feltprøven min påvirket av hybrid eller innfødt?

Før jeg svarer på dette spørsmålet, la meg først gi deg en grunnleggende forklaring på hybrid- og innfødte apper.

Hybrid-apper:

Dette er i utgangspunktet nettappene som er pakket inn i den opprinnelige innpakningen og som for det meste brukes til å utvikle plattformapplikasjoner (for å holde kodebasene like for Android og iOS). De ser ut som Native apps, men faktisk lastes informasjonen når brukeren navigerer gjennom sider.

Innfødte apper:

Disse er spesielt utviklet for et operativsystem som bruker funksjonene til operativsystemet på sitt beste. All informasjon lastes inn på en gang når appen startes.

Hybrid vs Native

( bildekilde )

Jeg har jobbet med både hybrid- og native-apptesting, og som en kvalitetssikring var det viktig å teste for begge deler for appen min. Det er en forskjell mellom Hybrid- og Native-appen. I motsetning til Native apps bruker Hybrid-apper ikke direkte telefonens funksjoner som GPS, Location etc. Hybridappene bruker telefonens eller OS-funksjonene via plugin-moduler.

eksempler på klientserverapplikasjon og nettbasert applikasjon

Jeg føler sterkt at for hver større utgivelse for en Native-app, bør feltprøve gjøres fordi den bruker telefonens og OS-funksjonene.

Å utføre en feltprøve vil indikere ytelsen til appen din med hensyn til det samme. Det vil indikere om telefonen er en high-end eller low-end, hvordan er ytelsen, stabiliteten og brukervennligheten til applikasjonen din.

En annen grunn til å gjøre en feltprøve for hver større utgivelse er at innfødte apper må oppdateres med nye versjoner av operativsystemet. Derfor, i forhold til Hybrid-appene, er versjoner av Native flere, eller hvis en ny OS-versjon lanseres, er det nødvendig med en feltprøve, selv om det ikke er gjort noen endringer i appens funksjoner.

Strategi for feltprøven

Hva skal være min strategi for feltprøven?

For feltprøving er det viktigste og viktige trinnet å forstå, innvirkningen av nettverket eller dataene på de viktigste funksjonene i appen din. Derfor har en grundig diskusjon med utviklingsteamet om funksjonalitetene.

Følgende er tipsene for å bestemme strategien for feltprøving:

1) Det viktigste trinnet som en kvalitetssikring er å merke testtilfellene dine med ‘Field Test’ og lage en suite for det samme. Diskuter med BA- og QA-teamet om suiten og se om de har noe å legge til den.

2) Avhengig av formålet med appen din og brukerne, kan du lage noen separate testtilfeller for hvordan, når og hvor kan appen din brukes. Du trenger kanskje ikke å utføre disse for interne tester.

3) Gå kun til en feltprøve når appen består regresjonstesten og når det ikke er noen funksjonelle problemer åpne.

4) For den aller første utgivelsen oppretter du et dokument (diagram) med alle detaljene i testsaker, personen som utfører, et område der det ble testet og feilene rapportert. Når du er opprettet, kan du bruke dette til fremtidige utgivelser.

5) Bruk en High-end og en Low-end-enhet for feltprøving, og prøv å beholde det samme operativsystemet, dette vil bidra til å gjøre en analyse av feilene som er funnet. Noen ganger ser vi feil i feltprøven, men ikke i den interne testen.

6) Lag et team på 4-5 personer og la dem gjøre feltprøven i forskjellige områder, og prøv med sikkerhet å bruke appen mens du kjører og et sted med lavt dataområde. Du kan også ha lederen din, BA, involvert i feltprøven.

7) Merk feilene som er funnet med en tagg som ‘Field Test’, det vil være enkelt for deg å referere til fremtidige utgivelser.

8) Hvis appen din sender geografisk plassering, kan du teste funksjonaliteten grundig, og jeg vil foreslå at du utfører alle testsakene knyttet til den samme.

Det er ikke nødvendig at du finner feil eller mangler, og testen kan gå glatt. I henhold til min erfaring, hold fokus på ytelsen og tiden det tar å svare. Som nevnt tidligere vil en 'Laster' skjerm fraråde folk å bruke appen din.

Hvis appen din er en kommersiell app som Zomato, Jabong, BookMyShow osv., Så prøv å utføre en feltprøve med et team på 20-25 personer, fordi det vil indikere appens ytelse når 20-25 brukere vil treffe appen.

Når skal jeg gjøre en feltprøve for en app?

Det er ikke nødvendig at alle apper må testes i felten, men jeg anbefaler alltid personlig å gjøre en feltprøve, siden det viser appens ytelse i den virkelige verden. Du kan diskutere dette med BA, scrum master eller manager og produkteieren hvis de ikke er klar over eller ikke er interessert i å gjøre det. Som en kvalitetssikring, gi poengene dine om behovet for en feltprøve.

En felttest bør bare gjøres etter at regresjonstesting av appen er utført, funksjonalitetene for en utgivelse er implementert, feil er verifisert, løst og viktigst av alt er appen stabil.

Viktige faktorer for felttest inkluderer:

  • Første utgivelse av appen: Det gir en stor fordel å gjøre en grundig feltprøve av appen for den første utgivelsen. Ettersom appen ennå ikke skal gå til Play Store, hjelper den deg og teamet ditt med å analysere ytelsen ved å bruke appen som en vanlig bruker.
  • En app er innfødt: Som nevnt tidligere, er feltprøven et must for hver utgivelse av en innfødt app, da de bruker funksjonene til telefonen og operativsystemet.
  • Når ny OS-versjon lanseres: Når en ny OS-versjon lanseres, må du kontrollere om appen er stabil, kompatibel og fungerer bra mot det nye operativsystemet.
  • Enhver større utgivelse for nye eller endrede funksjoner: Når nye funksjoner introduseres eller eksisterende funksjoner oppdateres, er det bra å gjøre en feltprøve for å sikre at ytelsen til appen ikke påvirkes.
  • Feltprøving som en del av rutineprøven: Feltesting for en mobilapp bør behandles akkurat som en rutinetest som regresjon, automatisering og skal aldri ignoreres. Selv om appen din er stabil, eller hvis du har jobbet med den i mer enn 1 eller 2 år, gjør du en feltprøve hver gang en større utgivelse skjer.

Felttest

Eksempler på tester som kan verifiseres i en feltprøve

La oss se på appen til Zomato som vi bruker til å søke etter restauranter rundt oss eller i et bestemt område.

Nedenfor er noen eksempler på testsaker som kan tas opp til feltprøve:

#1) Det grunnleggende og det aller første trinnet ville være å logge inn som jeg ville gjort som kunde.

Vær oppmerksom på at det først og fremst ikke skal ta mer enn et minutt å logge på med den Facebook- eller Google-kontoen jeg velger, for det andre, i det øyeblikket jeg er logget inn, bør den be meg om tillatelse til å slå på telefonens GPS (hvis det er av) ellers bør laste inn restaurantlisten for det oppdagede stedet mitt.

Ovennevnte er de to viktige verifiseringene som skal gjøres i den aller første testen.

#to) Bekreft at når du endrer sted, blir restaurantlisten oppdatert, prøv denne testen mens du går ut på veien. Listen skal oppdateres, og kortene til restaurantene skal vises med bilder uten feil.

# 3) Kontroller ovennevnte testtilfelle også når du kjører bil.

# 4) Bekreft (mens du går på veien) end-to-end-strømmen av appen, dvs. rett fra å logge inn, søke etter et sted og bestille mat fra en restaurant. Bestillingsinformasjonen din skal sendes til restauranten.

# 5) Utfør det samme testtilfellet ovenfor mens du kjører bil.

# 6) Bekreft på en 3G (ved å endre datamodusen til 3G) for en slutt-til-slutt-strøm for å bestille bord, dvs. endre plasseringen, velg en restaurant fra listen og bestill et bord.

# 7) Hvis du har en kupong, sjekk om du kan bruke den med hell mens du bestiller mat fra Zomato.

# 8) Bekreft om du kan skrive en tilbakemelding til restauranten (mens du går), og om tilbakemeldingen sendes til restauranten for gjennomgang, eller i det minste om den vises i restaurantens anmeldelser.

Dette er noen av eksemplene på testtilfeller mens du definerer den grunnleggende bruken av appen og bør testes i feltprøven. Her kan du også lage en matrise for telefonmodell (High end eller low end) mot typen nettverk (2G, 3G osv.) Og utføre testtilfellene for det samme.

Konklusjon

Enhver mobilapplikasjon kan kalles stabil og rask, ikke bare ved å bestå regresjonstest, bugverifisering, stress- eller belastningstest, men bare når den også består en feltprøve.

team foundation server tutorial for nybegynnere

Feltest bør utføres for hver utgivelse i mulig grad. For mobile applikasjoner er feltprøven en del av testsyklusen og bør aldri unngås eller tas lett på.

Feltprøving spiller en veldig viktig rolle i å definere appenes ytelse for den aller første utgivelsen. Hvis teamet ditt ikke er klar over dette, forklar dem om det og behovet for det.

I vår neste opplæring vil vi diskutere mer om “ Testing av den nyeste telefonen eller det nyeste operativsystemet '.

Anbefalt lesing

^