Kompatibilitetstesting er en integrert komponent i mange kvalitetssikringsstrategier, som lar bedrifter se om programvaren deres fungerer riktig på tvers av forskjellige plattformer. Selv for et skrivebordseksklusivt program er det flere store operativsystemer å ta hensyn til og hundrevis – om ikke tusenvis – av maskinvareforskjeller som kan påvirke stabiliteten. Å forstå kompatibilitetstestprosessen og dens vanlige fordeler kan bidra til å garantere en effektiv produktlansering som er i stand til å nå et størst mulig publikum av brukere.
Selv om kompatibilitetstesting kan tilby en rekke fordeler, er det også mange betydelige utfordringer som et programvaretestteam må overvinne for å maksimere denne teknikkens potensial. Det er også spesifikke fremgangsmåter disse avdelingene bør bruke for å få de beste resultatene – og sikre en omfattende testdekning.
I denne artikkelen ser vi nøye på kompatibilitetstesting, inkludert de essensielle trinnene som teamene må følge, samt de mest nyttige testverktøyene som er tilgjengelige for øyeblikket.
Hva er kompatibilitetstesting i
programvaretesting og engineering?
Kompatibilitetstesting undersøker programvare på tvers av forskjellige enheter, maskinvare og fastvare for å sikre at den yter til et teams forventninger. Hver bruker kan engasjere seg i programmet sitt på en ny enhet, og dette gjør det viktig at selskapet kan garantere at de alle har en lignende opplevelse. Kompatibilitetstester, for eksempel, kan innebære å sjekke hver funksjon i en app for å sikre at den fungerer på alle større operativsystemer.
Uten grundig kompatibilitetstesting er det fullt mulig at et selskap kan gi ut en applikasjon som ikke fungerer for visse populære enheter. Disse kontrollene må være fullstendige fordi det kan oppstå et problem på en rekke måter – denne applikasjonen fungerer kanskje ikke med en veldig spesifikk type grafikkort, for eksempel. Når de kobles sammen med andre former for programvaretesting, kan kvalitetssikringsteam sørge for at programmet deres er klart for utgivelse.
1. Når og hvorfor må du utføre kompatibilitetstesting for mobilapplikasjoner, nettsteder, systemer og nettlesere?
Bedrifter utfører kompatibilitetstesting i programvaretestfasen , spesielt når de har en “stabil” versjon av programmet som nøyaktig gjenspeiler hvordan det vil oppføre seg for kundene. Dette fortsetter etter alfa , aksept og de andre formene for testing som ofte ser etter generell stabilitet og funksjonsrelaterte problemer. Hvis en applikasjon får problemer under kompatibilitetstestfasen, vil dette vanligvis skyldes spesifikke kompatibilitetsrelaterte problemer. Å vedta disse sjekkene for tidlig kan effektivt gjøre dem overflødige, ettersom mindre endringer senere i programmets utviklingssyklus kan påvirke kompatibiliteten radikalt.
Kompatibilitetstesting for nettlesere og programvare er viktig fordi det hjelper bedrifter med å gi ut en applikasjon som de vet vil kjøre tilstrekkelig på praktisk talt alle mulige enheter. For eksempel bidrar spesielt kompatibilitetstesting på tvers av nettlesere til å sikre at folk som bruker Opera har samme opplevelse som de som bruker Firefox og andre store nettlesere. Teamet tester vanligvis så mange maskinvare-/programvarevariasjoner som tiden deres og budsjettet tillater. Dette betyr at de intelligent må prioritere systemer eller nettlesere som kundene deres er mer sannsynlig å bruke, slik at de kan garantere bred testdekning og et levedyktig produkt.
2. Når du ikke trenger å gjøre programvarekompatibilitetstesting
Bedrifter kan lage en skreddersydd applikasjon for et spesifikt operativsystem eller modell, og begrense antallet nødvendige kontroller massivt. Testing av kompatibilitet på tvers av nettlesere i programvaretesting kan være overflødig hvis dette programmet for eksempel ikke krever en nettleser. Tid kan også være en alvorlig faktor i et selskaps evne til å utføre disse testene, selv om testteam fortsatt bør jobbe for å garantere at store systemer og nettlesere er kompatible med programvaren. Det er også visse prosjekter som ikke kan dra nytte av grunnleggende kompatibilitetstester.
3. Hvem er involvert i kompatibilitetstesting?
Her er hovedpersonene som utfører kompatibilitetstesting i programvaretesting :
1. Utviklere
Utviklingsteamet sjekker applikasjonens ytelse på én plattform under utvikling, og dette kan til og med være den eneste enheten som selskapet har til hensikt å gi ut programmet på.
2. Testere
Kvalitetssikringsteam , enten innen selskapet eller eksternt ansatt, sjekker mange mulige konfigurasjoner som en del av programmets kompatibilitetstesting, inkludert alle større operativsystemer og nettlesere.
3. Kunder
Selskapets kunder kan ha maskinvare eller konfigurasjoner som teamet ikke var i stand til å teste grundig, noe som potensielt gjør brukeropplevelsen deres til den første virkelige sjekk av det spesifikke oppsettet.
Fordeler med kompatibilitetstesting
De vanlige fordelene med testing av programvarekompatibilitet inkluderer:
1. Bredere publikum
Jo grundigere et team tester programvaren sin, jo flere enheter kan det trygt gi den ut for, noe som sikrer at et bredt publikum på tvers av mange plattformer kan nyte applikasjonen. Dette lar bedrifter få mer produktsalg på programmet og kan også forbedre antallet positive anmeldelser som denne programvaren mottar fra brukere.
2. Forbedrer stabiliteten
Kompatibilitetstesting i programvaretesting er avgjørende for å fremheve stabilitets- og ytelsesproblemer, som ofte kan være mer uttalt på forskjellige enheter – spesielt hvis utviklerne kun designet denne applikasjonen for én plattform. En systemkompatibilitetstest viser selskapet hva brukere (på et bredt spekter av enheter) kan forvente av programvarens generelle ytelse.
3. Foredler utviklingen
Disse testene har også betydelig langsiktig innvirkning på et utviklingsteam. For eksempel kan mobilkompatibilitetstesting gi verdifull informasjon om apputvikling som bedrifter kan ta hensyn til når de lager flere programmer. Dette kan redusere utgiftene til kompatibilitetstester for fremtidige prosjekter betydelig, slik at de kan gjenbruke leksjonene de lærer fra denne prosessen.
4. Verifiserer andre tester
De fleste former for testing frem til dette punktet er begrenset i omfang og tester ikke alle mulige kombinasjoner av maskinvare eller programvare – disse testene kan effektivt dobbeltsjekke disse resultatene. Testing av kompatibilitet på tvers av nettlesere, for eksempel, validerer de eksisterende kvalitetssikringsstadiene ved å vise at resultatene er de samme når brukeren har en annen nettleser.
5. Reduserer kostnader
Kompatibilitetstesting kan også redusere kostnadene for det nåværende programmet, og hjelpe teamene med å identifisere problemer før en app kommer inn i den offentlige utgivelsen – på dette tidspunktet blir det dyrere å fikse feil. Jo mer varierte et teams tester er (og jo høyere testdekningsgrad), jo billigere er det å fjerne eventuelle feil etter hvert som de dukker opp.
Utfordringer ved kompatibilitetstesting
Her er vanlige utfordringer som selskaper kan møte når de implementerer kompatibilitetstesting i programvaretesting:
1. Begrenset tid
Selv om automatiseringsverktøy og andre løsninger kan fremskynde kompatibilitetstester betraktelig ved å simulere en rekke enheter, må denne prosessen fortsatt følge selskapets utviklingsplan. Dette betyr at testteamet må prioritere de vanligste enhetene og nettleserne for å garantere at de mottar det bredeste (og mest folkerike) publikummet.
2. Mangel på ekte enheter
Disse kontrollene involverer vanligvis virtuelle maskiner som simulerer komponentene og forholdene til ekte enheter; dette er mye billigere (og raskere) enn å anskaffe de relevante delene og plattformene uavhengig. Dette kan imidlertid påvirke nøyaktigheten til disse resultatene; spesielt siden ytelsen ofte avhenger av hvordan brukere betjener en ekte enhet.
3. Vanskelig å fremtidssikre
Kompatibilitetstesting kan bare engasjere seg med plattformer som allerede eksisterer; Dette betyr at de ikke kan garantere at programmet vil kjøre som forventet på fremtidige versjoner av Windows og Google Chrome. Organisasjoner er bare i stand til å fikse denne post-lanseringen, som ofte er dyrere, og programmet kan til slutt bli foreldet som et resultat.
4. Vedlikehold av infrastruktur
Hvis et team bestemmer seg for å sjekke en betydelig mengde plattformer internt, kan dette resultere i høye infrastrukturavgifter. Kompatibilitetstesting for mobilapplikasjoner kan for eksempel innebære innkjøp av en rekke ekte mobile enheter. Selv om dette er mer nøyaktig enn simulert maskinvarekompatibilitetstesting, er det dyrt og innebærer vanligvis regelmessig vedlikehold.
5. Høyt antall kombinasjoner
Kompatibilitetstesting står for mange kryssende faktorer, som operativsystem, nettleser, maskinvare, fastvare og til og med skjermoppløsning. Selv om testteamet har mye tid, vil det i praksis være umulig å imøtekomme hver eneste mulighet. Konfigurasjons- og kompatibilitetstesting må igjen prioritere de mest sannsynlige enhetskombinasjonene.
Kjennetegn ved kompatibilitetstesting
Nøkkelegenskapene til kompatibilitetstester inkluderer:
1. Grundig
Disse sjekkene må være i stand til å isolere eventuelle kompatibilitetsproblemer som oppstår mellom enheter – ellers kan teamet ende opp med å gi ut et defekt program. Disse kontrollene må for eksempel sørge for at hver enkelt funksjon i applikasjonen gjengis som forventet, uansett brukerens skjermoppløsning.
2. Ekspansiv
Testene skal opprettholde en balanse mellom dybde og bredde, og hjelpe team med å undersøke en rekke problemer på tvers av mange enhetskonfigurasjoner. Testing av kompatibilitet på tvers av nettlesere ser på et omfattende utvalg OS- og nettleserkombinasjoner, og sikrer et høyt dekningsnivå – noen ganger ved hjelp av en automatisert løsning .
3. Toveis
Denne prosessen involverer både bakover- og fremoverkompatibilitetstesting; førstnevnte lar teamet se hvordan appen deres vil fungere på eldre maskinvare. Sistnevnte lar teamet få tilgang til banebrytende plattformer, og hjelper dem med å garantere vellykket langsiktig ytelse, selv om deres fremtidssikre evner er ganske begrensede.
4. Repeterbar
Problemene som disse sjekkene avdekker, må være enkle å gjenta for andre testere og avdelinger – noe som viser at de gjenspeiler feil som brukere sannsynligvis vil støte på. Hvis en nettstedskompatibilitetstest indikerer at spesifikke funksjoner ikke fungerer på en bestemt nettleser, hjelper repeterbarhet utviklere med å løse problemet.
Typer kompatibilitetstesting
Hovedtypene for kompatibilitetstesting er som følger:
1. Bakoverkompatibilitetstesting
Bakoverkompatibilitetstesting innebærer å sjekke appen ved å bruke eldre versjoner av dagens maskinvare – dette er viktig fordi å begrense disse sjekkene til moderne enheter kan begrense antallet brukere betydelig. Mange bruker fortsatt eldre operativsystemer, som for eksempel Windows 8.
2. Forward-kompatibilitetstesting
Forward-kompatibilitetstesting er lik, men ser i stedet på moderne eller kommende teknologier for å se om appen sannsynligvis vil fortsette å fungere i årevis til tross for fremskritt og oppdateringer. Uten disse testene kan programvaren til og med slutte å fungere med neste nettleseroppdatering, for eksempel.
3. Testing av nettleserkompatibilitet
Nettleserkompatibilitetstester sikrer at en nettapplikasjon eller et nettsted kan fungere på forskjellige nettlesere; dette er viktig siden de bruker forskjellige layoutmotorer. Kvalitetssikringsteam tester til og med kompatibilitet på tvers av nettlesere – noe som betyr at de sjekker at hver nettleser kan håndtere applikasjonen på tvers av separate operativsystemer.
4. Mobil kompatibilitetstesting
Å teste mobilapper er en lignende prosess som å sjekke skrivebords- og nettapplikasjoner, spesielt ettersom telefonens operativsystem er en annen viktig faktor. Android- og iOS-apper , for eksempel, kommer i helt forskjellige formater og krever en helt separat utviklings- og testprosess for å imøtekomme begge.
5. Testing av maskinvarekompatibilitet
Disse kontrollene ser på de spesifikke komponentene som utgjør maskinen og hvordan de kan påvirke et program; dette er avgjørende for praktisk talt alle typer enheter. En datamaskin kan for eksempel ha et grafikkort som ikke klarer å gjengi grensesnittet til en nettapplikasjon .
6. Testing av enhetskompatibilitet
Noen programmer kobles til eksterne enheter via Bluetooth, bredbånd eller en kablet tilkobling. En app må kanskje kobles til en skriver, for eksempel. Disse testene tar sikte på å sikre at programmet engasjerer seg med plattformens egne tilkoblinger og alle enheter den har tilgang til.
7. Testing av nettverkskompatibilitet
Hvis en applikasjon krever nettverksfunksjonalitet for å kjøre – for eksempel ved å koble til en online database gjennom selskapets server – krever dette en rekke kompatibilitetskontroller. Dette sikrer at programmet er i stand til å kjøre med en passende hastighet med en Wi-Fi-, 4G- eller 3G-nettverkstilkobling.
Hva tester vi i kompatibilitetstester?
Kompatibilitetstestere sjekker vanligvis følgende:
1. Ytelse
En av hovedformålene med kompatibilitetstesting er å sikre stabilitet, ettersom noen aspekter av applikasjonen kan være helt inkompatible med vanlige plattformer. Ved å se på den generelle responsen til dette programmet, sikrer testteamet at det ikke er noen alvorlige krasj på enkelte enheter.
2. Funksjonalitet
Kompatibilitetstesting sjekker også de generelle egenskapene og funksjonene til en applikasjon for å sikre at programvaren er i stand til å gi de riktige resultatene. For eksempel kan et kundeforholdsstyringssystem ikke være i stand til å tilby salgsdata eller generell analyse for brukere med et utdatert operativsystem.
3. Grafikk
Noen nettlesere eller enheter kan slite med å gjengi visse grafiske elementer på grunn av en rekke årsaker – og kompatibilitetssjekker kan hjelpe med dette. Et program kan kanskje bare fungere ved spesifikke skjermoppløsninger med mindre utviklerne endrer hvordan programmet viser innholdet.
4. Tilkobling
Kompatibilitetstester ser også på hvordan programmet spesifikt integreres med både brukerens enhet og sin egen database, slik at det kan oppdage enheter som skrivere. Disse sjekkene kan for eksempel avsløre at appen ikke klarer å koble til sin egen database på 3G-nettverk.
5. Allsidighet
Disse kontrollene sørger for at selskapets applikasjon er allsidig nok til å fungere på gamle og nye versjoner av samme operativsystem via bakover- og fremoverkompatibilitetstester. Dette sikrer at brukere ikke blir utestengt fra programmet hvis programvaren deres er noen år utdatert.
Typer utganger fra kompatibilitetstester
De tre hovedresultatene av kompatibilitetstester er:
1. Testresultater
Det vanligste resultatet for disse kontrollene er selve resultatene, som kan ha mange former. For eksempel kan nettleserkompatibilitetstesting avsløre at en nettapp resulterer i en minnelekkasje på Microsoft Edge, mens den samme appen ikke har noen negative effekter på Chrome-baserte nettlesere. Alternativt kan applikasjonen fungere nøyaktig slik teamet forventer på de relevante plattformene.
2. Testlogger
Testresultatene manifesterer seg også i form av applikasjonens egne logger, som fremhever eventuelle oppdagede programvareproblemer gjennom feilmeldinger. Disse loggene kan til og med identifisere den spesifikke delen av et program som forårsaker denne feilen. Spesielt for kompatibilitetstesting må testerne være kjent med hvordan disse loggene manifesterer seg og presenterer disse problemene på tvers av forskjellige plattformer.
3. Testtilfeller
Kompatibilitetstestsaker angir hvilke tester teamet skal kjøre, og tilbyr en plass for dem å registrere resultatene i et enkelt format. Testerne bør bruke sin kunnskap om programvaren, sammen med resultatene og loggene, for å identifisere årsaken til et problem. Jo mer informasjon de gir, jo raskere kan utviklerne starte feilrettinger.
Typer defekter som er oppdaget
gjennom kompatibilitetstesting
Her er de vanligste feilene som kompatibilitetstester kan identifisere:
1. Layoutskalering
En nettstedskompatibilitetstest kan vise om elementene som utgjør en nettapp , eller til og med nettsider, skaleres for å passe til brukerens enhet, spesielt oppløsningen og størrelsen på skjermen. Som et resultat kan noe grafikk være vanskelig å se på bestemte nettlesere.
2. Programvare krasjer
Kompatibilitetstester gjør det lettere å se om en applikasjon i det hele tatt er i stand til å kjøre på enkelte plattformer. For eksempel kan en spillutvikler oppdage produktets minimumssystemkrav ved å sjekke hvilke enheter som krasjer på grunn av utilstrekkelig RAM og prosessorhastighet når testere starter det.
3. HTML/CSS-valideringsproblemer
Ulike nettlesere og enheter leser kode på separate måter – med noen som automatisk korrigerer enkle kodefeil, for eksempel å ikke lukke en HTML-tag på riktig måte. Testing av nettleserkompatibilitet kan identifisere tilfeller av ugyldig CSS som hindrer appen i å generere innholdet og til og med grunnleggende funksjoner.
4. Videoavspillingsfeil
Mange moderne videospillere bruker HTML5 for å streame videoer på nettet, og dette kan potensielt være en sentral del av en bedrifts nettapp. Imidlertid kan team som sjekker nettlesers kompatibilitet oppdage at appens videofunksjoner ikke er kompatible med utdaterte nettlesere.
5. Filsikkerhet
Kompatibilitetstesting innen programvareteknikk kan også finne problemer med filsikkerhet og hvordan dette varierer mellom enheter. For eksempel har nyere versjoner av Windows mer robust inn-/utdatasikkerhet. Dette kan føre til at applikasjonen (som antivirusprogramvare) sliter med å få tilgang til enhetens filer.
Kompatibilitetstesting
De vanlige trinnene for kompatibilitetstesting er:
1. Sett sammen en testplan
En omfattende testplan er avgjørende for kompatibilitetstesting; kvalitetssikringsteamet kan henvise til dette ved behov under sine kontroller. For eksempel beskriver dette enhetene de vil teste og kriteriene for bestått eller ikke bestått; de må også fastslå om de vil bruke robotprosessautomatisering .
2. Konfigurer testtilfeller
Testtilfeller er like viktige ettersom de utdyper de spesifikke kompatibilitetskontrollene som teamene kjører og de spesifikke enhetene de jobber med. Dette inneholder også de nøyaktige trinnene testerne vil ta, og god plass for dem å registrere resultatet og all informasjon som vil hjelpe utviklerne å håndheve kompatibilitet.
3. Etabler testmiljøet
Et isolert og uavhengig testmiljø fritt for påvirkning utenfra er nødvendig for å sikre nøyaktige tester, og også la kvalitetssikringsteamet identifisere hvor problemene de avdekker kommer fra. På toppen av dette kan testerne utføre sine kontroller av applikasjonen uten å kompromittere den “ekte” versjonen på noen måte.
4. Utfør testene
Med testsakene og miljøet fullt forberedt, kan teamet begynne kompatibilitetstestene – selv med en automatisert løsning har de bare en begrenset tid. Testere må prioritere de vanligste operativsystemene og enhetskonfigurasjonene for å ta hensyn til dette, og sikre bred testdekning til tross for disse begrensningene.
5. Test på nytt
Når testene er fullført og utviklerne mottar testsakene, vil de endre applikasjonen på måter som forbedrer kompatibiliteten, selv om dette kanskje ikke er mulig for alle enheter. Testerne sjekker deretter appen på nytt og bekrefter at problemene de tidligere har avdekket ikke lenger er tilstede og at det ikke er noen nye store feil.
Vanlige beregninger for kompatibilitetstesting
Her er noen vanlige beregninger som brukes for kompatibilitetstester:
1. Båndbredde
Nettverkskompatibilitetstester måler hvordan applikasjonen interagerer med ulike nettverk, inkludert bredbånd og mobildatanettverk. Minimumsbåndbredden som er nødvendig for at programmet skal utføre sine vanlige plikter og koble til selskapets database, kan være for høy for den gjennomsnittlige 3G-tilkoblingen, for eksempel.
2. CPU-bruk
En måte ytelsesproblemer manifesterer seg på er gjennom uforholdsmessig høy CPU-bruk – dette kan bety at enheten rett og slett ikke oppfyller programmets minimumskrav. CPU-problemer kan også påvirke applikasjonens responstid, begrense funksjonaliteten og forårsake nok forsinkelse til å koble fra brukere.
3. System Usability Scale
System Usability Scale er en vanlig måte å måle subjektive detaljer om et program på, og består av ti grunnleggende spørsmål om en apps brukervennlighet. Den resulterende SUS-poengsummen er av 100 og kan variere fra en plattform til den neste på grunn av grafiske feil.
4. Totalt antall feil
Denne beregningen er en konstant på tvers av de fleste testtyper, og lar testerne forstå programmets nåværende helse. Det er også mulig for teamet å sammenligne defekttotaler mellom ulike plattformer. Ved å gjøre dette kan testerne fremheve feilene som skyldes inkompatibilitet.
5. SUPRQ Score
I likhet med en applikasjons SUS-poengsum, er Standardized User Experience Percentile Rank Questionnaire en måte for testere å vurdere en applikasjon på flere nøkkelfaktorer, inkludert brukervennlighet og utseende. Dette hjelper dem med å identifisere hvordan kunder kan slite med å bruke applikasjonen på bestemte enheter.
7 feil og fallgruver ved implementering av kompatibilitetstester
Her er syv viktige feil å unngå når du utfører kompatibilitetstesting:
1. Mangel på ekte enheter
Selv om det ville være umulig å teste på alle mulige enhetskombinasjoner, kan et testteam fortsatt dra nytte av å bruke så mange ekte enheter som de kan hente. Ulike plattformer tilbyr “ekte” enheter via skyløsninger for å lette kompatibilitetstesting på tvers av nettlesere på måter som kan gjenspeile den opprinnelige ytelsen.
2. Unngå eldre enheter
Mange brukere har fortsatt tilgang til applikasjonene sine på eldre versjoner av Windows eller iOS; å fokusere helt på nye utgaver av populære enheter og operativsystemer kan begrense et produkts rekkevidde. Hvis teamet ikke utvider testene til “utdaterte” enheter, kan en betydelig mengde av publikum slite med å bruke programmet.
3. Tidsvanskjøtsel
Det er ofte et høyt volum av enheter og konfigurasjoner som vil kreve en kompatibilitetstest, noe som betyr at teamet må administrere tiden sin for å sjekke så mange av disse som mulig. Dette er viktig siden testene vanligvis fortsatt pågår nær slutten av utviklingen; feilstyring kan begrense antallet kontroller massivt.
4. Feil planlegging
Det er på samme måte viktig at team sørger for at de gjennomfører disse testene på et rimelig stadium i programmets utvikling, helst etter alfa-testing og de fleste former for funksjonell testing . Dette gjør det lettere å se om et problem er en generell defekt eller spesifikt for enhetene som teamet ser på.
5. Tar ikke hensyn til skjermoppløsningen
Skjermoppløsning kan være en langt større faktor for kompatibilitet enn mange testteam anerkjenner – spesielt siden dette kan tilpasses; og påvirker hvordan en enhet viser grafiske elementer. Selv med en inngripende frist for kompatibilitetstester, er det viktig at testteam fortsatt jobber for å imøtekomme dette i strategien.
Mangel på kompetanse
Testere må være svært dyktige for å sjekke kompatibilitet med nettsider, nettlesere og programvare blant de mange andre formene som disse testene kan ta. Hvis en testleder tildeler et av teammedlemmene sine til å utføre kompatibilitetskontroller og de har utilstrekkelig erfaring, kan dette redusere testene og begrense nøyaktigheten.
6. Ingen forutgående diskusjon
Siden kompatibilitetstester ofte er tidkrevende (og potensielt krever et bredt spekter av enheter), må teamene fullt ut fastslå omfanget av sjekkene sine tidlig i kvalitetssikringsstadiet. For eksempel må de ha en klar ide om hvilke spesifikke enheter eller konfigurasjoner de har tenkt å teste før kontrollene i det hele tatt begynner.
Beste praksis for kompatibilitetstesting
De beste måtene å sikre kompatibilitetstester av høy kvalitet inkluderer:
1. Test gjennom hele utviklingen
Med programvare som endres betydelig fra en uke til den neste, kan dette påvirke hvor kompatibelt programmet er med de tiltenkte enhetene. Teamene må utføre programvare- og kompatibilitetstesting på tvers av nettlesere gjentatte ganger for å sikre at applikasjonen fortsatt kjører bra på disse plattformene etter utviklingsendringer.
2. Bruk ekte enheter
Noen kompatibilitetstestverktøy gir tilgang til “ekte” simulerte enheter som er i stand til å likne brukerens opplevelse for den plattformen. Dette lar deg sikre kompatibilitet på tvers av flere enheter samtidig som du opprettholder et høyt nivå av nøyaktighet som ikke finnes i visse automatiserte løsninger.
3. Prioriter testene
Med en begrenset tid til å utføre disse kontrollene, kan det hende at kompatibilitetstestere må prioritere de vanligste enhetene, nettleserne og operativsystemene. På samme måte bør testteamet inspisere de mest kritiske funksjonene til programvaren først for å garantere grunnleggende funksjonalitet på disse enhetene.
4. Integrer smidige teknikker
Noen selskaper velger å ta i bruk en sprintbasert tilnærming for kompatibilitetstestene, slik at de enkelt kan nå testmilepæler – for eksempel å sjekke et spesifikt antall enheter. Agile oppmuntrer til kommunikasjon på tvers av avdelinger, samtidig som det gir en fast teststruktur som kan garantere konsekvent, rask forbedring.
5. Begrens testomfanget
Kvalitetssikringsteam må vite når de skal avslutte testene og til og med godta et tilfelle av inkompatibilitet. I dette tilfellet kan det hende at utvikleren ikke endrer programvaren, og kan i stedet endre minimumskrav hvis dette blir for vanskelig å omgå gjennom feilrettinger.
Eksempler på kompatibilitetstesttilfeller og scenarier
Kompatibilitetstestsaker etablerer testteamets input, teststrategi og forventede resultater; sistnevnte sammenligner de med de faktiske resultatene. Ettersom kontrollene dekker mange enheter og konfigurasjoner, er dette ofte en omfattende prosess.
Disse tilfellene inkluderer vanligvis:
• Test webapplikasjonens HTML-visninger riktig.
• Sjekk at programvarens JavaScript-kode er brukbar.
• Se om applikasjonen fungerer i forskjellige oppløsninger.
• Test at programmet har tilgang til filkatalogen.
• Sørg for at appen kobles til alle levedyktige nettverk.
Her er spesifikke eksempler på kompatibilitetstesting i programvaretesting for forskjellige programmer:
1. App for sosiale nettverk
Sosiale nettverk har ofte form av nettapper på nettlesere og mobilapper for tilsvarende enheter; begge typer krever like grundig testing. For eksempel må denne mobilappen være fullt operativ på iOS- og Android-enheter som et minimum – med teamet som sjekker gamle og nye enheter under hvert operativsystem. Hvis en spesifikk iPhone-modell ikke kan gjengi animerte GIF-filer, for eksempel, må teamet identifisere hva som forårsaker dette for å sikre en konsistent brukeropplevelse.
2. Videospill
Videospill tilbyr generelt tilpassbare grafiske alternativer som brukere kan endre for å matche maskinen deres; dette inkluderer å kontrollere skjermens oppløsning og sikre at brukergrensesnittet skalerer riktig. Visse problemer kan dukke opp avhengig av spillerens spesifikke maskinvare – med antialiasingsfeil som fører til kornete grafikk. Dette kan skyldes et vanlig grafikkort som er uforenlig med selskapets teksturgjengivelse. Avhengig av det eksakte problemet, kan dette til og med manifestere seg som et systemkrasj når visse enheter starter spillet.
3. CRM skysystem
Kunderelasjonsadministrasjonsløsninger bruker mye databaser for å hente informasjon om deres transaksjoner, leverandører og andre viktige aspekter av virksomheten, hovedsakelig ved hjelp av skylagring. Testere bør sørge for at denne databasen og dens skytjenester fungerer på forskjellige nettverk, inkludert 3G og 4G hvis en bruker trenger å få tilgang til den uten internettforbindelse. Teamet må også inspisere et bredt spekter av operativsystemer, da visse feil kan forekomme bare på Linux-enheter , for eksempel.
Manuelle eller automatiserte kompatibilitetstester?
Automatisering kan være svært nyttig for kompatibilitetstester, slik at team kan sjekke et stort antall enheter langt raskere enn en manuell tilnærming . Manuell testing kan imidlertid være mer hensiktsmessig når du utfører kontroller på et begrenset antall nettlesere og enheter – for eksempel et videospill som bare er tilgjengelig på to plattformer. Programvarens brukervennlighet er ofte en kjernefaktor i kompatibilitetstester og krever vanligvis et menneskelig perspektiv som bedre kan identifisere problemer med grafisk gjengivelse. Robotprosessautomatisering kan hjelpe med dette ved å implementere programvareroboter som lettere kan etterligne en menneskelig brukers tilnærming til kompatibilitetstester.
For programmer designet for et bredt spekter av enheter, som mobil- og nettapper, lar automatisering teamet sikre bredere testdekning. De kan til og med bruke hyperautomatisering for å sette ut disse sjekkene på en intelligent måte på en måte som fortsatt sikrer at menneskelige testere inspiserer disse plattformene for brukerspesifikk funksjonalitet. Kompatibilitetstesting i manuell testing er fortsatt obligatorisk for enkelte oppgaver – for eksempel å sjekke at brukergrensesnittet vises riktig på hver enhet. Dette betyr at den beste tilnærmingen kan være en blandet strategi som kan teste flere enheter totalt gjennom automatisering, øke tempoet mens de fortsatt tar hensyn til betydningen av brukervennlighet.
Hva trenger du for å starte kompatibilitetstesting?
De viktigste forutsetningene for kompatibilitetstesting inkluderer vanligvis:
1. Kvalifisert testpersonell
Kompatibilitetstestere har generelt høyere ferdighetskrav enn andre former for kvalitetssikring på grunn av at de sjekker et bredere spekter av enheter, og ofte møter flere feil. Dette kan inkludere problemløsning, kommunikasjon og oppmerksomhet på detaljer. Teamledere bør tildele testere som har erfaring med å undersøke samme applikasjon på mange plattformer.
2. Sterk enhetsemulering
Det kan være vanskelig å hente og teste alle fysiske enheter innenfor teamets omfang, noe som gjør emulering avgjørende for å se hvordan ulike plattformer reagerer på det samme programmet. Denne prosessen er sjelden perfekt, og testere må se på de mange emulatorene og automatiserte testverktøyene som er tilgjengelige for å se hvilken som gir mest nøyaktighet.
3. Tydelig testomfang
Teamet bør ha en forståelse av omfanget før kontrollene begynner; spesielt ettersom dette kan bestemme tempoet de jobber med. Selv om programmet kan ta sikte på å dekke mange plattformer, bør testerne identifisere et passende grensepunkt. For eksempel kan testing av operativsystemer utgitt før Windows 7 føre til redusert avkastning.
4. Tidsstyring
Kompatibilitetstesting kan forekomme når som helst gjennom kvalitetssikringsstadiet, men lagres vanligvis til slutten av utviklingen – når programmet er stabilt og funksjonsfullt. Testere bør imidlertid vurdere kompatibilitet lenge før dette, da det ofte er tidkrevende. Robust planlegging på forhånd hjelper teamet med å sikre at de har nok tid til hver sjekk.
Kompatibilitetstesting
sjekkliste, tips og triks
Her er flere tips som kvalitetssikringsteam må huske på når de gjennomfører kompatibilitetstester:
1. Ikke målrett absolutt dekning
Mens hver teststrategi tar sikte på å maksimere testdekningen, stopper de vanligvis før de når 100 % på grunn av avtagende avkastning med kun små forbedringer for svært få brukere. I sammenheng med kompatibilitet bør teamene forstå når for få av kundene deres vil bruke en enhet til at disse sjekkene er verdt det.
2. Prioriter kombinasjoner på tvers av nettlesere
Testing av kompatibilitet på tvers av nettlesere innebærer å sjekke hver nettleser mot ulike operativsystemer. Testere må bruke omfattende analyser om publikummet deres for å finne den mest populære av begge og bruke dette til å veilede deres tilnærming. De kan til og med utvikle en nettleserkompatibilitetsmatrise, som fastslår omfanget av disse sjekkene og deres forskjellige konfigurasjoner.
3. Bekreft layout
Å sikre en konsistent opplevelse er kjernen i kompatibilitetstesting, og disse kontrollene må gå dypere enn å identifisere om programmets funksjoner fungerer på forskjellige enheter. Teamene bør også verifisere programvarens generelle layout, inkludert justeringen av eventuelle skjemaer eller tabeller, samt integriteten til programmets CSS og HTML.
4. Sjekk APIer
Applikasjonsprogrammeringsgrensesnitt er en kjernekomponent i hvordan nettlesere leser apper, noe som gjør dem avgjørende for et teams kompatibilitetstesting på tvers av nettlesere. Ulike nettlesere har sine egne API-kall, og oppdateringene deres over tid kan påvirke kompatibiliteten. Testere må sjekke disse regelmessig; selv om selskapet bruker en lignende API for hvert program.
5. Undersøk SSL-sertifikatet
SSL-sertifikater øker nettleserens sikkerhet – krypterer nettrafikk og lar brukere dra nytte av HTTPS-protokoller. Et nettsted eller nettapp kan ha et sertifikat som er inkompatibelt med visse nettlesere. Dette betyr at testere bør validere sertifikatet på alle større plattformer for å sikre at brukerne føler seg trygge på nettstedet deres.
6. Valider videospillere
Programmer som viser video, for eksempel strømmetjenester eller freemium-mobilspill som støttes av annonser, bør gjennomgå testing for å sikre at disse videoene vises for alle tiltenkte enheter. For mange av appene vil disse sjekkene omfatte både stasjonære og mobile enheter og kan se på videoens kvalitet, hastighet og bildefrekvens.
5 beste verktøy og programvare for kompatibilitetstesting
De mest effektive gratis og betalte verktøyene for å teste kompatibilitet inkluderer:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST tilbyr utmerket funksjonalitet i både sine gratis og Enterprise (betalte) utgaver, og hjelper selskaper av alle størrelser (eller budsjett) med deres kompatibilitetssjekker. Selskaper som velger ZAPTESTs Enterprise-versjon kan til og med nyte godt av en avkastning som er opptil 10 ganger de opprinnelige investeringene. Løsningens 1SCRIPT-funksjon er spesifikt tilpasset behovene til kompatibilitetstestere, slik at de kan kjøre nøyaktig samme tester på flere plattformer uten å endre koden for å matche. Legg til toppmoderne RPA-funksjonalitet uten ekstra kostnad, og du har en automatiseringsløsning for alle oppgavene.
2. LambdaTest
LambdaTest bruker en skybasert tilnærming for å levere 3000 automatiserte enheter – dog med et betydelig fokus på nettlesere, noe som kan begrense denne løsningens effektivitet for visse programmer. Plattformen spesialiserer seg på kontinuerlig testing, og integrerer kvalitetssikringsprosessen tettere med utvikling. Kontrollene på denne applikasjonen lar også brukere angi oppløsningen, noe som gjør testing av kompatibilitet på tvers av nettlesere mye enklere. Denne løsningen tilbyr en freemium-modell, selv om denne inkluderer begrensede tester uten oppgradering og ingen reelle enheter.
3. BrowserStack
I likhet med LambdaTest gir BrowserStack tilgang til 3000 ekte enheter; katalogen deres inkluderer også eldre og betaalternativer for nettlesere. Mens det er mer sannsynlig at folk oppgraderer nettleseren sin enn operativsystemet, kan det fortsatt være mange som bruker eldre versjoner – BrowserStack har plass til dette. Brukere kan også vedta geolokaliseringstesting for å se hvordan nettsteder og nettapper ser ut i forskjellige land. Det er imidlertid ingen gratis- eller freemium-alternativer, og ekte enhetstesting kan være treg.
4. TestGrid
TestGrid tillater parallell testing, og lar team sjekke flere kombinasjoner samtidig for å fremskynde prosessen. Denne løsningen integreres også godt med test- og utviklingsarbeidsflyten – muligens muliggjør en smidig tilnærming ved å utgjøre en sentral del av avdelingens sprints. Imidlertid sliter TestGrid noen ganger med å koble til skyenheter og nettlesere. På toppen av dette er programmet ganske begrenset når det gjelder belastningstesting , dokumentasjon og å legge til nye enheter i selskapets oppsett.
5. Nettlesera
Browsera fokuserer hovedsakelig på å teste nettsteder for å sikre at de vises riktig på ulike enheter, nettlesere og operativsystemer. Som en skybasert tilnærming trenger ikke kvalitetssikringsteam å installere dette virtuelle testlaboratoriet på enhetene sine. Browsera kan også sammenligne utdata for intelligent å oppdage layoutproblemer og JavaScript-feil som selv en menneskelig tester kan gå glipp av. Browsera har imidlertid ingen støtte for flere vanlige nettlesere, inkludert Opera, og tilbyr kun grunnleggende testfunksjonalitet gratis.
Konklusjon
Kompatibilitetstesting er avgjørende for en vellykket kvalitetssikringsstrategi, som lar team validere appene sine på et bredt spekter av enheter. Uten å omfavne denne teknikken, kan selskaper være uvitende om at programvaren deres ikke vil fungere for mye av målgruppen før etter lansering. Dette koster mye tid og penger sammenlignet med testing før utgivelsen og applikasjoner som ZAPTEST kan strømlinjeforme denne prosessen ytterligere. Med 1SCRIPT og mange andre funksjoner tilgjengelig gratis, for eksempel parallell testing, kan å velge ZAPTEST som testverktøyet forvandle ethvert prosjekt samtidig som teamene får full tillit til applikasjonen.
