I en artikel som publicerades för några veckor sedan tog vi upp de mänskliga utmaningar som testare står inför.
Testarens arbete handlar inte bara om mänskliga aspekter, utan det finns också många utmaningar kopplade till de tekniska aspekterna av testning.
I den här artikeln presenterar vi några av de tekniska utmaningar som vi oftast stöter på.
Programvara är inte isolerad i sin miljö. Den kommunicerar med annan programvara via API:er. För att produkten ska fungera är det viktigt att säkerställa att den kan interagera med viss omgivande programvara. Dessa interaktioner mellan programvaror måste därför testas.
Dessa tester kan vara förvirrande för testare, eftersom API:er inte har några grafiska gränssnitt (programvaran behöver inte dem för att kommunicera med varandra) och kräver specifika verktyg.
Dessutom är det visserligen enkelt att lära sig hantera API:erna för vår egen programvara, men detsamma gäller inte nödvändigtvis för API:erna hos den programvara som vår produkt interagerar med.
Slutligen kan dessa starkt kodifierade interaktioner leda till arkitekturer som är mer eller mindre lätta att förstå.
Det finns flera skäl till varför du som testare inte bör vara rädd för API-testning och API:er i allmänhet, inte ens om du är en funktionell testare med få ”tekniska” färdigheter:
API-testning är ett bra första steg in i världen av ”teknisk” testning, eftersom det är tillräckligt enkelt att sätta sig in i när man väl har börjat praktiskt. På samma sätt blir det i ett agilt sammanhang allt viktigare för testare att kunna ingripa i olika aspekter av testningen, och API-testning är en kompetens som efterfrågas alltmer.
Det här är ingen ny utmaning! Jag har hört talas om testautomatisering ända sedan jag började arbeta 2011. Jag tvivlar faktiskt inte på att testare har hört talas om automatisering redan mycket längre än så.
Så vid första anblicken verkar det ganska förvånande att automatisering inte är helt utbredd. Faktum är att andelen automatiserade tester har tenderat att stabiliseras snarare än att öka under de senaste åren.
Anledningen till detta är ganska enkel: det är inte lätt att automatisera testkörningen. Verktygen är många, och behoven och sammanhangen är ännu fler!
Många automatiseringsprojekt misslyckas eftersom automatiseringsverktyget är olämpligt, de automatiserade testerna är för tidskrävande att underhålla, automatiseringsmålen och strategin inte är tydligt definierade eller anpassade, eller så är de automatiserade testerna inte tillräckligt tillförlitliga.
För att lyckas med automatiseringen måste du välja rätt verktyg, utbilda de personer som ska arbeta med automatiseringen, fastställa automatiseringens omfattning och anpassa omfattningen och testerna till sammanhanget.
Om du är funktionstestare kan testautomatisering snabbt bli svår att förstå. Faktum är att icke-tekniska testare behöver utveckla sina kunskaper i skriptspråk (för att förstå och skriva automatiserade tester) samt sin förmåga att konfigurera och övervaka automatiserade tester.
I det här fallet rekommenderar jag att man tar det steg för steg och börjar med ”enkel” automatisering. Detta kan göras genom API-testning eller genom att använda ett redan utvecklat KDT-ramverk (Keyword Driven Testing), som till exempel RobotFramework, eller genom att använda automatiseringsverktyg som är utformade för funktionstestare och som gör det möjligt för dem att bekanta sig med automatisering och dess begränsningar. Jag tänker här på verktyg som Agilitest.
Om du inte har några större svårigheter med den tekniska sidan av saken, behöver du ”bara” ta itu med utmaningen att sätta upp och köra systemet. Nyckeln är att:
Slutligen hör vi allt oftare talas om icke-funktionella tester. De vanligaste är penetrationstester (som blivit populära tack vare GDPR), prestandatester, anpassningsbarhetstester (särskilt för mobila enheter) och tillgänglighetstester (som blivit populära tack vare RGAA i Frankrike och WCAG i resten av världen).
Listan över icke-funktionella testtyper kommer att fortsätta växa, i takt med framtida användning och standarder såsom RGESN för ekodesign.
Som ni vet är det omöjligt att utföra alla dessa tester ingående, och en testare måste veta vilka icke-funktionella tester som ska utföras och i vilken utsträckning.
Mitt främsta råd här är att utgå från kraven och ”kräva” att det finns testbara icke-funktionella krav… eller helt enkelt kräva att det för de punkter som inte behandlas inte finns några krav och därför inget behov av testning!
Jag är medveten om att den första delen är utopisk i många sammanhang. Om förekomsten av sådana krav inte kan övervägas kan det vara värt att ta upp ämnet icke-funktionell testning direkt i företagets teststrategi, med metoder för att välja ut de icke-funktionella tester som ska genomföras. Denna strategi kan sedan omsättas i testplaner (strategi på projekt-/produktnivå). I avsaknad av kvantifierade krav måste man hämta inspiration från olika standarder (GDPR, RGAA…) eller från vad man observerar på marknaden eller i produktionen om produkten redan är i produktion.
Man kan hävda att testdesign inte är tekniskt. Det stämmer att man inte behöver kunna hantera eller läsa kod för att utforma bra tester. Att utforma högkvalitativa tester är dock en mycket teknisk del av en testares arbete.
Det finns ett antal metoder för testdesign (de mest kända bland testare är specifikationsbaserade) som, utifrån testvillkoren, identifierar vilka tester som ska köras och med vilka värden.
På samma sätt måste en testare veta hur man prioriterar och identifierar vilka element som ska testas, och i vilken utsträckning, utifrån riskerna och de tillgängliga resurserna.
Först och främst måste du känna till dina utformningstekniker, deras styrkor och svagheter samt hur du tillämpar dem.
Men teknisk kunskap räcker inte. Det är viktigt att förstå sammanhanget och den produkt som ska testas. Detta gör det möjligt för oss att anpassa oss till sammanhanget och föreslå en kombination av tekniker som resulterar i ett så effektivt testpaket som möjligt.
Det är också viktigt att arbeta ingående med testdata (vissa designtekniker ger tydliga riktlinjer för vilka värden som ska väljas i vissa fall), så att man väljer data som på bästa sätt identifierar produktens olika potentiella brister.
Detta är ett stort problem för många testare! Testmiljöerna är inte stabila, inte lättillgängliga eller inte tillräckligt nära produktionsmiljön.
Data är inte representativa, inte tillräckligt omfattande, inte tillgängliga eller inte anonymiserade…
Problemet här är att det, för att kunna testa en produkt korrekt, är avgörande att komma så nära produktionsanvändningen som möjligt, för att simulera användarbeteendet så troget som möjligt.
Tyvärr är det praktiskt taget omöjligt att ha en miljö som är lika omfattande som produktionsmiljön, både vad gäller volym och interaktion med samarbetspartners. På samma sätt är det inte någon lösning att helt förlita sig på produktionstestning med ”shift right”.
Problem som rör data och miljö är i allmänhet ganska komplexa.
Lyckligtvis finns det idag ett antal verktyg som kan hjälpa oss att hantera dessa frågor. Jag tänker särskilt på miljövirtualisering, som gör det möjligt för oss att skapa miljöer direkt, och därmed undvika problemen med miljöer som delas av flera team eller miljöer med data som ”redan använts”.
När det gäller data finns det verktyg (från leverantörer eller internt utvecklade) som gör det möjligt att anonymisera data och extrahera delmängder från produktionsmiljön för att få representativa urval.
När det gäller partnerna är en lösning som ibland är obligatorisk att sätta upp plugins, eftersom partnerna inte nödvändigtvis har delade testmiljöer med vår produkt, eller så är den sistnämnda alltför ofta ”nere”.
Kort sagt finns det ingen mirakellösning här, utan snarare en strävan efter pragmatiska lösningar (ofta verktygsbaserade) anpassade till varje sammanhang. Det viktigaste är att identifiera de mest problematiska punkterna och försöka lösa dem.
Slutligen händer det också att miljö- och dataproblem kan lösas genom mänskligt ingripande i sammanhang där testmiljöer och data inte står under kontroll av de team som använder miljöerna och data.