Kompatibilitetstest er en integreret del af mange kvalitetssikringsstrategier, der giver virksomheder mulighed for at se, om deres software fungerer korrekt på forskellige platforme. Selv for et program, der kun er beregnet til computere, er der flere store operativsystemer at tage højde for og hundredvis – hvis ikke tusindvis – af hardwareforskelle, der kan påvirke stabiliteten. Forståelse af kompatibilitetstestprocessen og dens sædvanlige fordele kan hjælpe med at garantere en effektiv produktlancering, der er i stand til at nå det størst mulige publikum af brugere.
Selvom kompatibilitetstest kan give en række fordele, er der også mange betydelige udfordringer, som et softwaretestteam skal overvinde for at maksimere denne tekniks potentiale. Der er også specifikke fremgangsmåder, som disse afdelinger bør anvende for at opnå de bedste resultater – og sikre en omfattende overordnet testdækning.
I denne artikel ser vi nærmere på kompatibilitetstest, herunder de vigtige trin, som teams skal følge, samt de mest nyttige testværktøjer, der findes i øjeblikket.
Hvad er kompatibilitetstest i
softwaretest og -udvikling?
Kompatibilitetstest undersøger software på tværs af forskellige enheder, hardware og firmware for at sikre, at den lever op til teamets forventninger. Hver bruger kan være i gang med deres program på en ny enhed, og det gør det vigtigt, at virksomheden kan garantere, at de alle får en lignende oplevelse. Kompatibilitetstest kan f.eks. involvere at tjekke hver funktion i en app for at sikre, at den fungerer på alle større operativsystemer.
Uden grundige kompatibilitetstest er det meget muligt, at en virksomhed udgiver en applikation, der ikke fungerer på visse populære enheder. Disse kontroller skal være meget omfattende, fordi et problem kan opstå på mange forskellige måder – for eksempel kan programmet ikke fungere med en helt bestemt type grafikkort. Når de kombineres med andre former for softwaretest, kan kvalitetssikringsteams sikre, at deres program er klar til udgivelse.
1. Hvornår og hvorfor skal man udføre kompatibilitetstest for mobilapplikationer, hjemmesider, systemer og cross-browser?
Virksomheder udfører kompatibilitetstest i deres softwaretestfase, især når de har en ‘stabil’ version af programmet, som nøjagtigt afspejler, hvordan det vil opføre sig for kunderne. Dette fortsætter efter alpha, accept og de andre former for test, der ofte ser på generel stabilitet og funktionsrelaterede problemer. Hvis en applikation støder på problemer under kompatibilitetstestfasen, skyldes det normalt specifikke kompatibilitetsrelaterede problemer. Hvis man indfører disse kontroller for tidligt, kan de blive overflødige, da mindre ændringer senere i programmets udviklingscyklus kan påvirke kompatibiliteten radikalt.
Kompatibilitetstest for browsere og software er vigtigt, fordi det hjælper virksomheder med at udgive en applikation, som de ved vil køre ordentligt på stort set alle mulige enheder. For eksempel hjælper test af kompatibilitet på tværs af browsere især med at sikre, at folk, der bruger Opera, får den samme oplevelse som dem, der bruger Firefox og andre større browsere. Teamet tester normalt så mange hardware/software-varianter, som deres tid og budget tillader. Det betyder, at de på intelligent vis skal prioritere systemer eller browsere, som deres kunder er mere tilbøjelige til at bruge, så de kan garantere en bred testdækning og et levedygtigt produkt.
2. Når du ikke behøver at teste softwarekompatibilitet
Virksomheder kan skabe en skræddersyet applikation til et bestemt operativsystem eller en bestemt model, hvilket begrænser antallet af nødvendige kontroller massivt. Test af kompatibilitet på tværs af browsere i softwaretest kan være overflødig, hvis dette program f.eks. ikke kræver en browser. Tid kan også være en alvorlig faktor i en virksomheds evne til at udføre disse tests, selvom testteams stadig bør arbejde på at garantere, at større systemer og browsere er kompatible med softwaren. Der er også visse projekter, der ikke kan drage fordel af grundlæggende kompatibilitetstest.
3. Hvem er involveret i kompatibilitetstest?
Her er de vigtigste personer, der udfører kompatibilitetstest i softwaretest:
1. Udviklere
Udviklingsteamet kontrollerer applikationens ydeevne på én platform under udviklingen, og det kan endda være den eneste enhed, som virksomheden har tænkt sig at udgive programmet på.
2. Testere
Kvalitetssikringsteams, enten internt i virksomheden eller eksternt ansat, kontrollerer mange mulige konfigurationer som en del af applikationens kompatibilitetstestfase, herunder alle større operativsystemer og browsere.
3. Kunder
Virksomhedens kunder kan have hardware eller konfigurationer, som teamet ikke kunne teste grundigt, hvilket potentielt gør deres brugeroplevelse til det første rigtige tjek af den specifikke opsætning.
Fordele ved kompatibilitetstest
De sædvanlige fordele ved softwarekompatibilitetstest omfatter:
1. Bredere publikum
Jo grundigere et team tester sin software, jo flere enheder kan det med sikkerhed frigive den til, hvilket sikrer, at et bredt publikum på tværs af mange platforme kan få glæde af applikationen. Det giver virksomhederne mulighed for at sælge flere produkter på programmet og kan også forbedre antallet af positive anmeldelser, som denne software modtager fra brugerne.
2. Forbedrer stabiliteten
Kompatibilitetstest i softwaretest er afgørende for at fremhæve stabilitets- og performanceproblemer, som ofte kan være mere udtalte på forskellige enheder – især hvis udviklerne kun har designet applikationen til én platform. En systemkompatibilitetstest viser virksomheden, hvad brugerne (på en bred vifte af enheder) kan forvente af softwarens overordnede ydeevne.
3. Raffinerer udviklingen
Disse tests har også betydelige langsigtede konsekvenser for et udviklingsteam. For eksempel kan test af mobilkompatibilitet give værdifulde oplysninger om appudvikling, som virksomheder kan tage højde for, når de opretter yderligere programmer. Det kan sænke udgifterne til kompatibilitetstest betydeligt for fremtidige projekter, så de kan genbruge erfaringerne fra denne proces.
4. Verificerer andre tests
De fleste former for test indtil nu er begrænsede i omfang og tester ikke alle mulige hardware- eller softwarekombinationer – disse test kan effektivt dobbelttjekke disse resultater. Test af kompatibilitet på tværs af browsere validerer f.eks. de eksisterende kvalitetssikringsfaser ved at vise, at resultaterne er de samme, når brugeren har en anden browser.
5. Reducerer omkostninger
Kompatibilitetstest kan også sænke omkostningerne for det aktuelle program ved at hjælpe teams med at identificere problemer, før en app udgives offentligt – på dette tidspunkt bliver det dyrere at rette fejl. Jo mere varierede et teams tests er (og jo højere deres testdækningsgrad er), jo billigere er det at fjerne eventuelle fejl, efterhånden som de dukker op.
Udfordringer ved kompatibilitetstest
Her er almindelige udfordringer, som virksomheder kan stå over for, når de implementerer kompatibilitetstest i softwaretest:
1. Begrænset tid
Selvom automatiseringsværktøjer og andre løsninger kan fremskynde kompatibilitetstests betydeligt ved at simulere en række enheder, skal denne proces stadig overholde virksomhedens udviklingsplan. Det betyder, at testteamet er nødt til at prioritere de mest almindelige enheder og browsere for at garantere, at de får det bredeste (og mest folkelige) publikum.
2. Mangel på rigtige enheder
Disse kontroller involverer ofte virtuelle maskiner, der simulerer komponenter og forhold i rigtige enheder; det er meget billigere (og hurtigere) end selv at anskaffe de relevante dele og platforme. Det kan dog påvirke nøjagtigheden af disse resultater, især fordi ydeevnen ofte afhænger af, hvordan brugerne betjener en rigtig enhed.
3. Vanskeligt at fremtidssikre
Kompatibilitetstests kan kun bruges på platforme, der allerede findes; det betyder, at de ikke kan garantere, at applikationen vil køre som forventet på fremtidige versioner af Windows og Google Chrome. Organisationer kan kun rette op på dette efter lanceringen, hvilket ofte er dyrere, og applikationen kan i sidste ende blive forældet som følge heraf.
4. Vedligeholdelse af infrastruktur
Hvis et team beslutter sig for at kontrollere en betydelig mængde platforme in-house, kan det resultere i høje infrastrukturgebyrer. Kompatibilitetstest af mobilapplikationer kan f.eks. involvere indkøb af en række rigtige mobilenheder. Det er mere præcist end simulerede hardwarekompatibilitetstest, men det er dyrt og kræver typisk regelmæssig vedligeholdelse.
5. Højt antal kombinationer
Kompatibilitetstest tager højde for mange krydsende faktorer, såsom operativsystem, browser, hardware, firmware og endda skærmopløsning. Selv hvis testteamet har masser af tid, vil det i praksis være umuligt at tage højde for hver eneste mulighed. Konfigurations- og kompatibilitetstest skal igen prioritere de mest sandsynlige enhedskombinationer.
Karakteristika ved kompatibilitetstest
De vigtigste karakteristika ved kompatibilitetstest omfatter:
1. Grundig
Disse kontroller skal være i stand til at isolere eventuelle kompatibilitetsproblemer, der opstår mellem enheder – ellers kan teamet ende med at udgive et defekt program. For eksempel skal disse kontroller sikre, at hver eneste funktion i applikationen gengives som forventet, uanset brugerens skærmopløsning.
2. Ekspansiv
Testene skal opretholde en balance mellem dybde og bredde og hjælpe teams med at undersøge en række problemer på tværs af mange enhedskonfigurationer. Cross-browser kompatibilitetstest ser på en lang række OS- og browserkombinationer og sikrer et højt dækningsniveau – nogle gange ved hjælp af en automatiseret løsning.
3. Tovejs
Denne proces involverer både bagudrettet og fremadrettet kompatibilitetstest; førstnævnte giver teamet mulighed for at se, hvordan deres app vil fungere på ældre hardware. Sidstnævnte giver teamet adgang til banebrydende platforme og hjælper dem med at garantere en vellykket langsigtet præstation, selv om deres fremtidssikrede muligheder er ret begrænsede.
4. Gentagelig
De problemer, som disse kontroller afdækker, skal være nemme at gentage for andre testere og afdelinger – for at vise, at de afspejler fejl, som brugerne sandsynligvis vil støde på. Hvis en kompatibilitetstest af et website viser, at bestemte funktioner ikke fungerer i en bestemt browser, kan gentagelser hjælpe udviklerne med at løse problemet.
Typer af kompatibilitetstest
De vigtigste typer af kompatibilitetstest er som følger:
1. Test af bagudkompatibilitet
Test af bagudkompatibilitet indebærer kontrol af appen med ældre versioner af nutidig hardware – det er vigtigt, fordi en begrænsning af disse kontroller til moderne enheder kan begrænse antallet af brugere betydeligt. Mange bruger stadig ældre operativsystemer, som for eksempel Windows 8.
2. Test af fremadrettet kompatibilitet
Fremadrettet kompatibilitetstest er lignende, men ser i stedet på moderne eller kommende teknologier for at se, om appen sandsynligvis vil fortsætte med at fungere i årevis på trods af fremskridt og opdateringer. Uden disse tests kan softwaren endda holde op med at fungere med den næste browseropdatering, for eksempel.
3. Test af browserkompatibilitet
Tests af websitets browserkompatibilitet sikrer, at en webapplikation eller et website kan fungere i forskellige browsere; det er vigtigt, da de bruger forskellige layoutmotorer. Kvalitetssikringsteams tester endda kompatibilitet på tværs af browsere – hvilket betyder, at de kontrollerer, at hver browser kan håndtere applikationen på tværs af forskellige operativsystemer.
4. Test af mobilkompatibilitet
Test af mobilapps er en lignende proces som test af desktop- og webapplikationer, især fordi telefonens operativsystem er en anden vigtig faktor. Android- og iOS-apps kommer for eksempel i helt forskellige formater og kræver en helt separat udviklings- og testproces for at imødekomme begge.
5. Test af hardwarekompatibilitet
Disse kontroller ser på de specifikke komponenter, der udgør maskinen, og hvordan de kan påvirke et program; dette er kritisk for stort set alle typer enheder. For eksempel kan en computer have et grafikkort, der ikke kan gengive en webapplikations brugerflade.
6. Test af enhedskompatibilitet
Nogle applikationer forbindes med eksterne enheder via Bluetooth, bredbånd eller en kabelforbindelse. En app kan f.eks. have brug for at oprette forbindelse til en printer. Disse tests har til formål at sikre, at programmet fungerer med platformens egne forbindelser og alle enheder, som det kan få adgang til.
7. Test af netværkskompatibilitet
Hvis en applikation kræver netværksfunktionalitet for at køre – f.eks. ved at oprette forbindelse til en onlinedatabase via virksomhedens server – kræver det adskillige kompatibilitetstjek. Dette sikrer, at programmet kan køre med en passende hastighed med en Wi-Fi-, 4G- eller 3G-netværksforbindelse.
Hvad tester vi i kompatibilitetstests?
Kompatibilitetstestere kontrollerer normalt følgende:
1. Ydeevne
Et af hovedformålene med kompatibilitetstest er at sikre stabilitet, da nogle aspekter af applikationen kan være helt inkompatible med almindelige platforme. Ved at se på programmets generelle reaktionsevne sikrer testteamet, at der ikke er alvorlige nedbrud på visse enheder.
2. Funktionalitet
Kompatibilitetstest kontrollerer også de generelle egenskaber og funktioner i en applikation for at sikre, at softwaren er i stand til at levere de korrekte resultater. For eksempel kan et system til styring af kunderelationer måske ikke tilbyde salgsdata eller generelle analyser til brugere med et forældet operativsystem.
3. Grafik
Nogle browsere eller enheder kan have svært ved at gengive visse grafiske elementer af forskellige årsager – og kompatibilitetstjek kan hjælpe med dette. Et program kan måske kun fungere i bestemte skærmopløsninger, medmindre udviklerne ændrer på, hvordan programmet viser sit indhold.
4. Tilslutningsmuligheder
Kompatibilitetstests ser også på, hvordan programmet specifikt integreres med både brugerens enhed og dets egen database, så det kan registrere enheder som printere. Disse kontroller kan f.eks. afsløre, at appen ikke er i stand til at oprette forbindelse til sin egen database på 3G-netværk.
5. Alsidighed
Disse kontroller sikrer, at virksomhedens applikation er alsidig nok til at fungere på gamle og nye versioner af det samme operativsystem via bagud- og fremadkompatibilitetstest. Det sikrer, at brugerne ikke bliver udelukket fra programmet, hvis deres software er et par år forældet.
Typer af output fra kompatibilitetstests
De tre vigtigste resultater af kompatibilitetstest er:
1. Testresultater
Det mest almindelige output for disse kontroller er selve resultaterne, som kan tage mange former. For eksempel kan test af browserkompatibilitet afsløre, at en webapp resulterer i en hukommelseslækage på Microsoft Edge, mens den samme app ikke har nogen negative effekter på Chrome-baserede browsere. Alternativt kan applikationen fungere præcis, som teamet forventer, på de relevante platforme.
2. Testprotokoller
Testresultaterne manifesterer sig også i form af applikationens egne logfiler, som fremhæver eventuelle opdagede softwareproblemer gennem fejlmeddelelser. Disse logfiler kan endda identificere den specifikke del af et program, der forårsager denne fejl. Især når det gælder kompatibilitetstest, skal testerne være fortrolige med, hvordan disse logfiler manifesterer og præsenterer disse problemer på tværs af forskellige platforme.
3. Testcases
Kompatibilitetstestcases beskriver, hvilke tests teamet skal udføre, og giver dem mulighed for at registrere resultaterne i et enkelt format. Testerne skal bruge deres viden om softwaren sammen med resultaterne og logfilerne til at identificere årsagen til et problem. Jo flere oplysninger de giver, jo hurtigere kan udviklerne begynde at rette fejl.
Typer af opdagede defekter
gennem kompatibilitetstest
Her er de mest almindelige fejl, som kompatibilitetstests kan identificere:
1. Skalering af layout
En test af hjemmesidens kompatibilitet kan vise, om de elementer, der udgør en webapp eller endda websider, skaleres, så de passer til brugerens enhed, især opløsningen og størrelsen på deres skærm. Som følge heraf kan nogle grafikker være svære at se i bestemte browsere.
2. Software går ned
Kompatibilitetstest gør det lettere at se, om en applikation overhovedet kan køre på nogle platforme. For eksempel kan en spiludvikler finde ud af, hvad minimumskravene til deres produkts system er, ved at tjekke, hvilke enheder der går ned på grund af utilstrækkelig RAM og processorhastighed, når testerne starter det.
3. HTML/CSS-valideringsproblemer
Forskellige browsere og enheder læser kode på forskellige måder – nogle korrigerer automatisk simple kodefejl, som f.eks. ikke at lukke et HTML-tag korrekt. Browserkompatibilitetstest kan identificere forekomster af ugyldig CSS, som forhindrer appen i at generere sit indhold og endda grundlæggende funktioner.
4. Fejl i videoafspilning
Mange moderne videoafspillere bruger HTML5 til at streame videoer online, og det kan potentielt være en vigtig del af en virksomheds webapp. Men teams, der tjekker kompatibiliteten med webbrowsere, kan opdage, at deres apps videofunktioner ikke er kompatible med forældede browsere.
5. Sikkerhed for filer
Kompatibilitetstest i softwareudvikling kan også finde problemer med filsikkerhed, og hvordan dette varierer mellem enheder. For eksempel har nyere versioner af Windows en mere robust input/output-sikkerhed. Det kan føre til, at programmet (f.eks. antivirussoftware) har svært ved at få adgang til enhedens filer.
Proces til test af kompatibilitet
De sædvanlige trin i en kompatibilitetstest er:
1. Udarbejd en testplan
En omfattende testplan er afgørende for kompatibilitetstest; kvalitetssikringsteamet kan henvise til denne efter behov under deres kontroller. Det beskriver for eksempel de enheder, de vil teste, og kriterierne for at bestå eller fejle; de skal også fastslå, om de vil bruge robotprocesautomatisering.
2. Konfigurer testcases
Testcases er ligeledes vigtige, da de uddyber de specifikke kompatibilitetstjek, som holdene udfører, og de specifikke enheder, de arbejder med. Det indeholder også de nøjagtige trin, testerne skal tage, og rigelig plads til, at de kan registrere resultatet og alle oplysninger, der kan hjælpe udviklerne med at håndhæve kompatibiliteten.
3. Etablering af testmiljøet
Et isoleret og uafhængigt testmiljø uden påvirkninger udefra er nødvendigt for at sikre nøjagtige tests, og det giver også kvalitetssikringsteamet mulighed for at identificere, hvor de problemer, de opdager, kommer fra. Derudover kan testerne udføre deres tjek på applikationen uden at kompromittere den ‘rigtige’ version på nogen måde.
4. Udfør testene
Når testcases og miljø er fuldt forberedt, kan teamet begynde kompatibilitetstestene – selv med en automatiseret løsning har de kun en begrænset mængde tid. Testerne bliver nødt til at prioritere de mest almindelige operativsystemer og enhedskonfigurationer for at tage højde for dette og sikre en bred testdækning på trods af disse begrænsninger.
5. Prøv igen
Når testene er færdige, og udviklerne modtager testcases, vil de ændre applikationen på måder, der forbedrer dens kompatibilitet, selvom det måske ikke er muligt for alle enheder. Testerne tjekker derefter appen igen og kontrollerer, at de problemer, de tidligere har opdaget, ikke længere er til stede, og at der ikke er nye større fejl.
Almindelige målinger af kompatibilitetstest
Her er nogle almindelige målinger, der bruges til kompatibilitetstest:
1. Båndbredde
Netværkskompatibilitetstest måler, hvordan applikationen fungerer med forskellige netværk, herunder bredbånds- og mobildatanetværk. Den minimumsbåndbredde, der er nødvendig for, at programmet kan udføre sine sædvanlige opgaver og oprette forbindelse til virksomhedens database, kan f.eks. være for høj til den gennemsnitlige 3G-forbindelse.
2. CPU-forbrug
En måde, hvorpå problemer med ydeevnen viser sig, er gennem uforholdsmæssigt højt CPU-brug – det kan betyde, at enheden simpelthen ikke opfylder programmets minimumskrav. CPU-problemer kan også påvirke applikationens responstid, begrænse dens funktionalitet og forårsage så meget forsinkelse, at brugerne mister interessen.
3. Skala for systemets anvendelighed
System Usability Scale er en almindelig måde at måle subjektive detaljer i et program på og består af ti grundlæggende spørgsmål om en apps brugervenlighed. Den resulterende SUS-score er ud af 100 og kan variere fra en platform til den næste på grund af grafiske fejl.
4. Samlet antal defekter
Denne metrik er konstant på tværs af de fleste testtyper og lader testerne forstå programmets aktuelle tilstand. Det er også muligt for teamet at sammenligne antallet af defekter mellem forskellige platforme. Ved at gøre dette kan testerne fremhæve de fejl, der skyldes inkompatibilitet.
5. SUPRQ-score
I lighed med en applikations SUS-score er Standardized User Experience Percentile Rank Questionnaire en måde for testere at bedømme en applikation på flere nøglefaktorer, herunder brugervenlighed og udseende. Det hjælper dem med at identificere, hvordan kunderne kan have svært ved at bruge applikationen på bestemte enheder.
7 fejl og faldgruber ved implementering af kompatibilitetstest
Her er syv vigtige fejl, du skal undgå, når du udfører kompatibilitetstest:
1. Mangel på rigtige enheder
Selvom det ville være umuligt at teste på alle mulige kombinationer af enheder, kan et testteam stadig drage fordel af at bruge så mange rigtige enheder, som de kan skaffe. Forskellige platforme tilbyder ‘rigtige’ enheder via cloud-løsninger for at gøre det lettere at teste kompatibilitet på tværs af browsere på måder, der kan afspejle native performance.
2. Undgå ældre enheder
Mange brugere har stadig adgang til deres applikationer på ældre versioner af Windows eller iOS; hvis man udelukkende fokuserer på nye udgaver af populære enheder og operativsystemer, kan det begrænse et produkts rækkevidde. Hvis teamet ikke udvider deres tests til ‘forældede’ enheder, kan en betydelig del af deres publikum have svært ved at bruge programmet.
3. Dårlig tidsstyring
Der er ofte en stor mængde enheder og konfigurationer, der kræver en kompatibilitetstest, hvilket betyder, at teamet skal styre deres tid for at kontrollere så mange af disse som muligt. Det er vigtigt, da testene typisk stadig er i gang i slutningen af udviklingsforløbet; dårlig styring kan begrænse antallet af kontroller massivt.
4. Ukorrekt planlægning
Det er ligeledes altafgørende, at teams sørger for at udføre disse tests på et rimeligt tidspunkt i programmets udvikling, helst efter alpha-test og de fleste former for funktionel test. Det gør det lettere at se, om et problem er en generel defekt eller specifikt for de enheder, som teamet kigger på.
5. Tager ikke højde for skærmopløsning
Skærmopløsning kan være en langt større faktor for kompatibilitet, end mange testteams anerkender – især fordi den kan tilpasses og påvirker, hvordan en enhed viser grafiske elementer. Selv med en nært forestående deadline for kompatibilitetstest er det vigtigt, at testteams stadig arbejder på at tage højde for dette i deres strategi.
Mangel på ekspertise
Testere skal være meget dygtige til at tjekke hjemmeside-, browser- og softwarekompatibilitet blandt de mange andre former, som disse tests kan tage. Hvis en testleder sætter et af sine teammedlemmer til at udføre kompatibilitetstjek, og vedkommende ikke har tilstrækkelig erfaring, kan det forsinke testene og begrænse deres nøjagtighed.
6. Ingen forudgående diskussion
Da kompatibilitetstests ofte er tidskrævende (og potentielt kræver en bred vifte af enheder), skal teams fastlægge omfanget af deres kontroller tidligt i kvalitetssikringsfasen. For eksempel skal de have en klar idé om, hvilke specifikke enheder eller konfigurationer de har tænkt sig at teste, før deres kontrol overhovedet begynder.
Bedste praksis for test af kompatibilitet
De bedste måder at sikre kompatibilitetstest af høj kvalitet inkluderer:
1. Test under hele udviklingen
Da software ændrer sig markant fra den ene uge til den anden, kan det påvirke, hvor kompatibelt programmet er med de enheder, det er beregnet til. Teams skal gentagne gange teste software- og cross-browser-kompatibilitet for at sikre, at applikationen stadig kører godt på disse platforme efter udviklingsændringer.
2. Brug rigtige enheder
Nogle værktøjer til kompatibilitetstest giver adgang til “rigtige” simulerede enheder, som er i stand til at ligne brugerens oplevelse af den pågældende platform. På den måde kan du sikre kompatibilitet på tværs af flere enheder og samtidig opretholde en høj grad af nøjagtighed, som ikke findes i visse automatiserede løsninger.
3. Prioritér testene
Med en begrænset mængde tid til at udføre disse kontroller, kan kompatibilitetstestere være nødt til at prioritere de mest almindelige enheder, browsere og operativsystemer. På samme måde bør testteamet inspicere de mest kritiske funktioner i softwaren først for at garantere grundlæggende funktionalitet på disse enheder.
4. Integrer agile teknikker
Nogle virksomheder vælger at anvende en sprintbaseret tilgang til deres kompatibilitetstest, så de nemt kan nå testmilepæle – såsom at tjekke et bestemt antal enheder. Agile fremmer kommunikation på tværs af afdelingerne og giver samtidig en fast teststruktur, der kan garantere konsekvent og hurtig forbedring.
5. Begræns testens omfang
Kvalitetssikringsteams skal vide, hvornår de skal afslutte deres tests og endda acceptere et tilfælde af inkompatibilitet. I dette tilfælde vil udvikleren måske ikke ændre softwaren, men i stedet ændre minimumskravene, hvis det er for svært at omgå gennem fejlrettelser.
Eksempler på kompatibilitets-testcases og -scenarier
Kompatibilitetstestcases fastlægger testteamets input, teststrategi og forventede resultater; sidstnævnte sammenligner de med de faktiske resultater. Da kontrollerne omfatter mange enheder og konfigurationer, er det ofte en omfattende proces.
Disse tilfælde omfatter normalt:
– Test, at webapplikationens HTML vises korrekt.
– Tjek, at softwarens JavaScript-kode er brugbar.
– Se, om programmet fungerer i forskellige opløsninger.
– Test, at programmet kan få adgang til filmappen.
– Sørg for, at appen opretter forbindelse til alle brugbare netværk.
Her er specifikke eksempler på kompatibilitetstest i softwaretest for forskellige programmer:
1. App til sociale netværk
Sociale netværk tager ofte form af webapps i browsere og mobilapps til tilsvarende enheder; begge typer kræver lige grundig testning. For eksempel skal denne mobilapp som minimum være fuldt funktionsdygtig på iOS- og Android-enheder – og teamet skal tjekke gamle og nye enheder under hvert operativsystem. Hvis en bestemt iPhone-model f.eks. ikke kan gengive animerede GIF-filer, skal teamet identificere årsagen til dette for at sikre en ensartet brugeroplevelse.
2. Videospil
Videospil tilbyder generelt tilpassede grafiske indstillinger, som brugerne kan ændre, så de passer til deres maskine; dette inkluderer kontrol af skærmens opløsning og sikring af, at brugergrænsefladen skaleres korrekt. Visse problemer kan opstå afhængigt af spillerens specifikke hardware – med antialiasing-fejl, der fører til grynet grafik. Det kan skyldes et almindeligt grafikkort, som er inkompatibelt med virksomhedens teksturgengivelse. Afhængigt af det præcise problem kan det endda vise sig som et systemnedbrud, når visse enheder starter spillet.
3. CRM-system i skyen
Customer Relationship Management-løsninger gør stor brug af databaser til at hente oplysninger om deres transaktioner, leverandører og andre vigtige aspekter af forretningen, primært ved hjælp af cloud-lagring. Testerne skal sørge for, at databasen og dens cloud-tjenester fungerer på forskellige netværk, herunder 3G og 4G, hvis en bruger har brug for at tilgå den uden internetforbindelse. Teamet skal også inspicere en bred vifte af operativsystemer, da visse fejl måske kun vises på Linux-enheder, for eksempel.
Manuelle eller automatiserede kompatibilitetstests?
Automatisering kan være en stor hjælp til kompatibilitetstest, så teams kan tjekke et stort antal enheder langt hurtigere end ved en manuel tilgang. Manuel test kan dog være mere hensigtsmæssig, når der skal udføres kontrol på et begrænset antal browsere og enheder – for eksempel et videospil, der kun er tilgængeligt på to platforme. Softwarens brugervenlighed er ofte en kernefaktor i kompatibilitetstests og kræver normalt et menneskeligt perspektiv, som bedre kan identificere grafiske gengivelsesproblemer. Robotic process automation kan hjælpe med dette ved at implementere softwarerobotter, der lettere kan efterligne en menneskelig brugers tilgang til kompatibilitetstests.
For programmer, der er designet til en bred vifte af enheder, såsom mobil- og webapps, giver automatisering teamet mulighed for at sikre en bredere testdækning. De kunne endda bruge hyperautomatisering til intelligent at outsource disse kontroller på en måde, der stadig sikrer, at menneskelige testere inspicerer disse platforme for brugerspecifik funktionalitet. Kompatibilitetstest i manuel test er stadig obligatorisk for nogle opgaver – såsom at kontrollere, at brugergrænsefladen vises korrekt på alle enheder. Det betyder, at den bedste tilgang kan være en blandet strategi, som kan teste flere enheder samlet set gennem automatisering, øge tempoet og stadig tage højde for betydningen af brugervenlighed.
Hvad skal du bruge for at komme i gang med kompatibilitetstest?
De vigtigste forudsætninger for kompatibilitetstest omfatter typisk:
1. Kvalificeret testpersonale
Kompatibilitetstestere har generelt højere kvalifikationskrav end andre former for kvalitetssikring, fordi de kontrollerer et bredere udvalg af enheder og ofte støder på flere fejl. Det kan omfatte problemløsning, kommunikation og opmærksomhed på detaljer. Teamledere bør udpege testere, der har erfaring med at undersøge den samme applikation på mange platforme.
2. Stærk emulering af enheder
Det kan være svært at source og teste alle fysiske enheder inden for teamets område, hvilket gør emulering afgørende for at se, hvordan forskellige platforme reagerer på det samme program. Denne proces er sjældent perfekt, og testere må se på de mange emulatorer og automatiserede testværktøjer, der findes, for at se, hvilket der giver den største nøjagtighed.
3. Klart testomfang
Teamet bør have en forståelse af deres arbejdsområde, før kontrollerne begynder – især fordi det kan være afgørende for det tempo, de arbejder i. Selvom programmet måske sigter mod at dække mange platforme, bør testerne identificere en passende afgrænsning. For eksempel kan test af styresystemer, der er udgivet før Windows 7, føre til faldende afkast.
4. Tidshåndtering
Kompatibilitetstest kan finde sted på et hvilket som helst tidspunkt i kvalitetssikringsfasen, men gemmes ofte til slutningen af udviklingen – når programmet er stabilt og funktionsmæssigt komplet. Testere bør dog overveje kompatibilitet længe før dette, da det ofte er tidskrævende. Robust planlægning på forhånd hjælper teamet med at sikre, at de har tilstrækkelig tid til hvert tjek.
Kompatibilitetstest
tjekliste, tips og tricks
Her er yderligere tips, som kvalitetssikringsteams skal huske på, når de udfører kompatibilitetstest:
1. Gå ikke efter absolut dækning
Selvom alle teststrategier sigter mod at maksimere testdækningen, stopper de typisk, før de når 100%, fordi afkastet bliver mindre, og der kun sker mindre forbedringer for meget få brugere. I forbindelse med kompatibilitet bør teams forstå, hvornår for få af deres kunder vil bruge en enhed til, at disse kontroller er umagen værd.
2. Prioriter kombinationer på tværs af browsere
Test af kompatibilitet på tværs af browsere indebærer, at hver browser kontrolleres mod forskellige operativsystemer. Testerne skal bruge omfattende analyser af deres publikum for at finde ud af, hvad der er mest populært af begge dele, og bruge det som rettesnor for deres tilgang. De kan endda udvikle en browserkompatibilitetsmatrix, som fastlægger omfanget af disse kontroller og deres forskellige konfigurationer.
3. Bekræft layout
At sikre en ensartet oplevelse er kernen i kompatibilitetstest, og disse kontroller skal gå dybere end at identificere, om programmets funktioner fungerer på forskellige enheder. Teams bør også verificere softwarens overordnede layout, herunder justeringen af formularer eller tabeller, samt integriteten af programmets CSS og HTML.
4. Tjek API’er
Application programming interfaces er en kernekomponent i, hvordan browsere læser apps, hvilket gør dem afgørende for et teams test af kompatibilitet på tværs af browsere. Forskellige webbrowsere har deres egne API-kald, og deres opdateringer over tid kan påvirke kompatibiliteten. Testerne skal tjekke disse regelmæssigt, også selvom virksomheden bruger en lignende API til hvert program.
5. Undersøg SSL-certifikatet
SSL-certifikater øger en browsers sikkerhed – krypterer webtrafik og giver brugerne mulighed for at drage fordel af HTTPS-protokoller. Et website eller en webapp kan have et certifikat, der er inkompatibelt med visse browsere. Det betyder, at testere bør validere certifikatet på alle større platforme for at sikre, at brugerne føler sig trygge på deres hjemmeside.
6. Valider videoafspillere
Programmer, der viser video, såsom streamingtjenester eller freemium-mobilspil, der understøttes af reklamer, bør testes for at sikre, at disse videoer vises på alle tiltænkte enheder. For mange af appsene vil disse kontroller omfatte både stationære og mobile enheder og kunne se på videoens kvalitet, hastighed og billedfrekvens.
De 5 bedste værktøjer og software til kompatibilitetstest
De mest effektive gratis og betalte værktøjer til at teste kompatibilitet inkluderer:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST tilbyder fremragende funktionalitet i både Free- og Enterprise-udgaverne (betalingsudgaver) og hjælper virksomheder af enhver størrelse (eller budget) med deres kompatibilitetstjek. Virksomheder, der vælger ZAPTESTs Enterprise-version, kan endda få et afkast på op til 10 gange deres oprindelige investering. Løsningens 1SCRIPT-funktion er specifikt tilpasset kompatibilitetstesteres behov, så de kan køre nøjagtig de samme tests på flere platforme uden at ændre koden for at matche. Tilføj topmoderne RPA-funktionalitet uden ekstra omkostninger, og du har en one-stop-løsning til automatisering af alle opgaver.
2. LambdaTest
LambdaTest bruger en cloud-baseret tilgang til at levere 3.000 automatiserede enheder – dog med et betydeligt fokus på webbrowsere, hvilket kan begrænse denne løsnings effektivitet for visse programmer. Platformen er specialiseret i kontinuerlig testning og integrerer kvalitetssikringsprocessen tættere med udviklingen. Tjekkene i denne applikation giver også brugerne mulighed for at indstille deres opløsning, hvilket gør det meget lettere at teste kompatibilitet på tværs af browsere. Denne løsning tilbyder en freemium-model, men den omfatter begrænsede tests uden opgradering og ingen rigtige enheder.
3. BrowserStack
Ligesom LambdaTest giver BrowserStack adgang til 3.000 rigtige enheder; deres katalog indeholder også ældre og beta-muligheder for browsere. Selvom folk er mere tilbøjelige til at opgradere deres browser end deres operativsystem, kan der stadig være mange, der bruger ældre versioner – BrowserStack tager højde for dette. Brugere kan også udføre geolokaliseringstest for at se, hvordan hjemmesider og webapps ser ud i forskellige lande. Der er dog ingen gratis eller freemium-muligheder, og test af rigtige enheder kan være langsom.
4. TestGrid
TestGrid giver mulighed for parallel test, så teams kan tjekke flere kombinationer på samme tid for at fremskynde processen. Denne løsning integreres også godt med test- og udviklingsworkflowet – hvilket muligvis letter en agil tilgang ved at udgøre en vigtig del af afdelingens sprints. TestGrid har dog nogle gange problemer med at oprette forbindelse til cloud-enheder og browsere. Derudover er programmet ret begrænset, når det gælder belastningstest, dokumentation og tilføjelse af nye enheder til virksomhedens setup.
5. Browsera
Browsera fokuserer primært på at teste hjemmesider for at sikre, at de vises korrekt på forskellige enheder, browsere og operativsystemer. Som en cloud-baseret tilgang behøver kvalitetssikringsteams ikke at installere dette virtuelle testlaboratorium på deres enheder. Browsera kan også sammenligne output for på intelligent vis at spotte layoutproblemer og JavaScript-fejl, som selv en menneskelig tester kan overse. Browsera har dog ingen understøttelse af flere almindelige browsere, herunder Opera, og tilbyder kun grundlæggende testfunktionalitet gratis.
Konklusion
Kompatibilitetstest er afgørende for en vellykket kvalitetssikringsstrategi, så teams kan validere deres apps på en bred vifte af enheder. Uden denne teknik kan virksomheder være uvidende om, at deres software ikke vil fungere for en stor del af deres målgruppe før efter lanceringen. Det koster en masse tid og penge sammenlignet med pre-release test, og applikationer som ZAPTEST kan strømline denne proces yderligere. Med 1SCRIPT og mange andre gratis funktioner, som f.eks. parallel test, kan valget af ZAPTEST som testværktøj ændre ethvert projekt og give teams fuld tillid til deres applikation.
