Mobil · Testautomation

Shopify gjorde mobiltesterna stabilare med bildtolkning

Shopify byggde ett striktare testgränssnitt som ser mobilappen som användaren gör och uppger att den interna teststabiliteten steg från 50 till 98 procent.

Motiv: Shopifys illustration av datorseende som identifierar text och tryckmål i ett mobilgränssnitt. Källa och kredit: Shopify Engineering, illustration © Shopify. Debrief-bearbetning: ingen.

Shopifys största mobilapp hade ett testproblem som såg ut som ett produktproblem. End-to-end-testerna blockerade fler korrekta kodändringar än felaktiga, och till slut plockades testsviten bort från de obligatoriska kontrollerna för nya kodförslag.

Lösningen blev inte fler väntetider eller ännu en städinsats. Shopify byggde ett striktare gränssnitt ovanpå Appium, lät testerna tolka skärmen visuellt och krävde ett bevis efter varje handling. Några veckor efter att den nya lösningen återinförts i blockerande CI uppgav bolaget en teststabilitet på 98 procent, jämfört med 50 procent med det gamla gränssnittet.

Flexibiliteten skapade fel sorts frihet

Sedan 2023 hade Shopifys mobiltester kört Appium via WebdriverIO och hittat element med React Native-test-id:n. Det gav utvecklarna låg nivå-kontroll, men gjorde det också lätt att skriva tester som tryckte vidare innan nästa skärm hunnit visas.

En fast paus kunde få testet att fungera lokalt, men föll när en skärm tog lite längre tid i CI. Ett annat problem var mer principiellt: testen kunde verifiera att en nod fanns i komponentträdet utan att kontrollera att en handlare faktiskt kunde se eller använda den.

Shopifys exempel visar hur appens nederkant skymmer den sista cellen, trots att det gamla testgränssnittet kunde hitta och trycka på den via komponentträdet.
Shopify-appens nederkant täcker delvis den sista raden i gränssnittet.

Shopifys exempel visar en cell som är skymd av appens nederkant. Det gamla testgränssnittet kunde ändå hitta cellen via dess id, trycka på den och markera flödet som godkänt. Implementationen såg rätt ut för testverktyget men inte för användaren.

Varje handling måste bevisa sin effekt

Det nya gränssnittet använder fortfarande Appium för att styra enheten, men utvecklarna möter en betydligt mindre uppsättning kommandon. Shopify beskriver den som en builder-baserad API där varje steg måste innehålla både en handling och ett påstående om vad skärmen ska visa efteråt.

Ett test får alltså inte bara trycka, skriva eller vänta. Det måste ange vilket tillstånd som ska uppstå. Shopify kontrollerar dessutom att påståendet var falskt före handlingen och sant efter den. När flödet avviker stannar testet där felet uppstod, i stället för flera steg senare.

Undantag finns, men de märks med prefixet UNSAFE_. Det gör exempelvis specialanpassade tidsgränser och direkt användning av test-id:n synliga i kodgranskningen. Poängen är att det stabila arbetssättet ska vara standardvägen, medan riskabla genvägar kräver ett medvetet val.

Datorseende testar det som syns

Den större förändringen ligger i hur ett test hittar sitt mål. Varje steg tar en skärmbild. PaddleOCR läser text och OpenCV matchar ikoner mot SVG-filer i Shopifys designsystem Polaris. Ett kommando kan därför leta efter texten ”Save” eller en synlig plusikon i stället för en dold identifierare i komponentträdet.

Test-id:n finns kvar som reserv när genererat innehåll gör den visuella matchningen osäker, men de är uttryckligen opt-in. Varje körning producerar också en annoterad video som visar vad systemet letade efter, vad det hittade och var det tryckte. Det kortar vägen från ett misslyckat test till en möjlig förklaring.

Det begränsade kommandospråket har ytterligare en effekt. Enligt Shopify blir det enklare för AI-agenter att skriva tester eftersom grammatiken motsvarar det som syns på skärmen och inte kräver kunskap om appens interna komponentstruktur. Det är en bolagsuppgift, men konstruktionen visar en konkret princip: agentvänlighet kan komma från färre och tydligare val, inte från större frihet.

98 procent kräver rätt fotnot

Shopify definierar teststabilitet som antalet lyckade enskilda tester dividerat med det totala antalet körningar. Bolaget uppger 98 procent några veckor efter att det nya gränssnittet infördes i blockerande CI, upp från 50 procent med det gamla.

Originalartikeln redovisar däremot inte antalet tester eller körningar och isolerar inte effekten av varje förändring. Resultatet är därför ett internt före- och efterutfall, inte ett bevis på att appen är 98 procent felfri eller att samma metod ger samma lyft i andra team.

Shopify lägger också nya tester i en separat stabilitetskontroll där de körs flera gånger innan de får ansluta till den blockerande sviten. Det är kanske den mest överförbara lärdomen: tillförlitlighet är ett inträdeskrav för testet självt, inte bara något teamet hoppas få efter hand.

Debrief
Vad hände?

Shopify byggde om ramverket för mobil end-to-end-testning med ett strikt API, visuell skärmtolkning och obligatorisk kontroll efter varje handling. Bolaget uppger att den interna teststabiliteten steg från 50 till 98 procent.

Varför spelar det roll?

Instabila tester förlorar snabbt sitt värde när team slutar lita på dem. Shopifys metod flyttar kontrollen närmare den faktiska användarupplevelsen och gör det svårare att skriva tester som råkar passera.

Vår analys

Det intressanta är inte datorseendet ensamt. Stabiliteten kommer från en kombination av begränsad API-yta, bevis efter varje steg, synliga undantag och en separat spärr för nya tester. Team som vill använda AI för testskrivning bör börja med att göra det korrekta beteendet lätt att uttrycka och genvägarna svåra att gömma.

Källkoll
Så vet vi det här
How we raised mobile end-to-end test stability to 98%Primärkälla
Nästa artikel · Tools
Magnitude kopplar lokala AI-modeller till dina befintliga kodagenter

Relaterat