I en artikel som publicerades för några veckor sedan pratade vi om de mänskliga utmaningarna som en testare står inför.
Men en testarens arbete handlar inte bara om mänskliga utmaningar, utan även om en rad tekniska utmaningar kopplade till testningsprocessen.
I denna artikel belyser vi några av de vanligaste tekniska utmaningarna vi stöter på.
API-testning
Utmaningen
Mjukvara är inte isolerad i sin miljö. Den kommunicerar med annan mjukvara via API:er. För att ha en funktionell produkt är det avgörande att säkerställa att den kan interagera med viss omgivande mjukvara. Dessa mjukvaruinteraktioner behöver därför testas.
Dessa tester kan vara förvirrande för testare, eftersom API:er inte erbjuder grafiska gränssnitt (mjukvara behöver inte dessa för att kommunicera med varandra) och kräver specifika verktyg.
Dessutom, medan det är lätt att bemästra API:erna för vår egen mjukvara, är det inte nödvändigtvis fallet för API:erna för den mjukvara som vår produkt interagerar med.
Slutligen kan dessa starkt kodifierade interaktioner skapa arkitekturer som är mer eller mindre lämpliga att förstå.
- Tips
Det finns flera anledningar till varför du inte bör vara rädd för API-testning och API:er i allmänhet när du är testare, även om du är en funktionell testare med få "tekniska" färdigheter:
- Det finns ett antal API-testverktyg, som Postman, som är tillgängliga och relativt enkla att lära sig.
- API-tester är generellt sett inte särskilt komplexa funktionellt, eftersom de är standardiserade meddelanden där variabler skickas. Personligen gillar jag att tänka på API-tester som formulärtester, där man kontrollerar de olika värden som fält kan ta.
- Det är enkelt att multiplicera API-tester snabbt. Faktum är att när du har ett meddelande kan du köra många tester (inklusive datadrivna tester) baserade på samma grundläggande meddelande.
API-testning är ett bra första steg in i världen av "teknisk" testning, eftersom det är tillräckligt enkelt att förstå när du väl har kommit igång. På samma sätt, i en agil kontext, blir det allt viktigare för testare att kunna ingripa i olika aspekter av testning, och API-testning är en färdighet som blir allt mer efterfrågad.
Testautomatisering
Utmaningen
Det här är ingen ny utmaning! Jag har hört talas om testautomation sedan jag började arbeta 2011. Faktum är att jag inte tvivlar på att testare har hört talas om automation mycket längre än så.
Vid första anblick kan det verka ganska överraskande att tänka att automation inte är helt utbrett. Faktum är att andelen automatiserade tester har tenderat att stabiliseras snarare än att växa de senaste åren.
Anledningen till detta är ganska enkel: det är inte lätt att automatisera testkörningar. Verktygen är många, behoven och sammanhangen ä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 är inte tydligt definierade eller anpassade, eller så är inte de automatiserade testerna tillräckligt pålitliga.
För att uppnå framgångsrik automation behöver du välja rätt verktyg, utbilda de personer som kommer att vara involverade i automationen, identifiera omfattningen av automationen och anpassa omfattningen och testerna till sammanhanget.
- Tips
Om du är en funktionell testare kan testautomation snabbt bli svårt att förstå. Faktum är att icke-tekniska testare behöver utveckla sina skriptfärdigheter (för att förstå och skriva automatiserade tester) samt sin förmåga att sätta upp och övervaka automatiserade tester.
I det här fallet rekommenderar jag att ta det steg för steg och börja med "enkel" automation. Detta kan göras med API-testning eller genom att använda ett redan utvecklat KDT (Keyword Driven Testing) ramverk, som det som syns med verktyg som RobotFramework, eller genom att använda automatiseringsverktyg designade för funktionella testare, vilket gör det möjligt för dem att bekanta sig med automation 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, så är det "bara" utmaningen att sätta upp och köra systemet som måste tas itu med. Nyckeln är att:
- Välja rätt testverktyg så att det kan hantera de olika testkraven.
- Föreslå tester som är lätta att underhålla genom att följa bra kodpraxis.
- Säkerställa så att de automatiserade testerna underhålls regelbundet.
- Säkerställa regelbundna uppföljningar av dessa tester och hålla testkampanjen vid liv.
Integration av rätt icke-funktionella tester
Utmaningen
Slutligen hör vi allt mer om icke-funktionella tester. De vanligaste är penetrationstester (populäriserade av GDPR), prestandatester, anpassningstester (speciellt för mobila enheter) och tillgänglighetstester (populäriserade av 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 som RGESN för ekodesign.
Som du vet är det omöjligt att utföra alla dessa tester på djupet, och en testare måste veta vilka icke-funktionella tester som ska utföras och i vilken omfattning.
- Tips
Mitt huvudsakliga råd här är att utgå från kraven och "kräva" att icke-funktionella krav ska vara testbara... eller helt enkelt kräva att de punkter som inte behandlas inte har några krav och därför inget behov av testning!
Jag är medveten om att den första delen kan verka utopisk i många sammanhang. Om sådana krav inte går att etablera, kan det vara värdefullt att ta upp frågan om icke-funktionell testning direkt i företagets teststrategi, med metoder för att välja de icke-funktionella tester som ska implementeras. Denna strategi kan sedan översättas till testplaner (strategi på projekt- eller produktnivå). Om kvantifierade krav saknas, behöver du istället hämta inspiration från olika standarder (GDPR, RGAA…) eller från vad du ser på marknaden eller i produktion om produkten redan är i drift.
Testdesign
Utmaningen
Man kan hävda att testdesign inte är teknisk, eftersom man inte behöver kunna manipulera eller läsa kod för att designa bra tester. Men i själva verket är testdesign en teknisk och viktig del av en testares arbete.
Det finns flera testdesignmetoder (de mest kända för testare är specifikationsbaserade) som hjälper till att identifiera vilka tester som ska köras och med vilka värden, baserat på testvillkor.
En testare måste också veta hur man prioriterar och väljer vilka delar som ska testas, och i vilken omfattning, utifrån risker och tillgängliga resurser.
- Tips
Först och främst är det viktigt att du känner till de designtekniker du använder, deras styrkor och svagheter, och hur du implementerar dem.
Men teknisk kunskap är inte tillräcklig. Det är avgörande att förstå sammanhanget och produkten som ska testas. Detta gör det möjligt att anpassa sig och välja en kombination av tekniker som ger det mest effektiva testpaketet.
Det är också viktigt att arbeta noggrant med testdata. Vissa designtekniker ger specifika riktlinjer för vilka värden som bör väljas i olika situationer, så att man kan välja data som bäst identifierar produktens potentiella brister.
Datastyrning och testmiljöer
Utmaningen
Detta är ett stort problem för många testare! Testmiljöer är ofta instabila, svåra att komma åt eller inte tillräckligt nära produktionen.
Data är antingen inte representativa, inte tillräckligt många, inte åtkomliga eller inte anonymiserade...
För att kunna testa en produkt på rätt sätt är det avgörande att komma så nära produktionsanvändning som möjligt för att kunna simulera användarbeteende på ett så korrekt sätt som möjligt. Tyvärr är det näst intill omöjligt att skapa en testmiljö som är lika stor som produktionsmiljön, både i termer av volym och interaktion med partners. Att enbart förlita sig på produktionstestning med en "shift right"-strategi är inte heller lösningen.
- Tips
Data- och miljöproblem är generellt sett ganska komplexa.
Lyckligtvis finns det flera verktyg tillgängliga som kan hjälpa oss att hantera dessa problem. Ett exempel är miljövirtualisering, som gör det möjligt att skapa miljöer på begäran och därmed undvika problem med delade miljöer mellan flera team eller miljöer med redan använda data.
För data finns det verktyg (både från externa leverantörer och interna lösningar) som gör det möjligt att anonymisera och ta fram delmängder av produktionsdata för att få representativa prover.
När det gäller partners är det ibland nödvändigt att sätta upp pluggar, eftersom partners inte alltid har delade testmiljöer med vår produkt, eller så är vår produkt ofta "nere".
Sammanfattningsvis finns det ingen mirakellösning, utan det är snarare en jakt på pragmatiska lösningar (ofta verktygsbaserade) som anpassas till varje specifik kontext. Det viktigaste är att identifiera de mest problematiska punkterna och försöka lösa dem.
Slutligen kan även mänsklig intervention vara en lösning på miljö- och dataproblem, särskilt i de fall där testmiljöer och data inte är under kontroll av de team som använder dem.
Marc Hage Chahine
Marc Hage Chahine arbetar med testning och driver den franska bloggen "La taverne du testeur". Han är föreläsare, bokförfattare och organisatör, samt talar vid olika evenemang inom programvarutestning. Marc är också en del av kommittén för JFTL (French Testing Day).
