Utforska shift-left-testning
Testning i programlivscykelhantering är viktigt för att maximera kodkvaliteten och minimera driftrisken i samband med distribution och uppdatering av programvara. Termen skift-vänster- i detta sammanhang förmedlar idén om att flytta testaktiviteter så tidigt som möjligt i utvecklingsfasen. Organisationen i vårt exempelscenario bör överväga att införliva den här metoden i sin DevOps-strategi för att minimera de aktuella säkerhets- och stabilitetsproblemen. I den här lektionen granskar du olika typer av tester som kan implementeras på det här sättet och undersöker sedan deras implementeringsmetoder.
Vilka tester ska ingå i shift-left-testning?
Programvaruutveckling omfattar ett brett utbud av testtyper, men de som är av särskilt intresse för oss inkluderar:
Enhetstester: Dessa tester fokuserar på de minsta testbara delarna i en programkod, till exempel enskilda funktioner eller metoder. Målet är att fastställa om varje kodenhet kan utföra sin avsedda åtgärd isolerat från resten av kodbasen och externa beroenden. Sådana tester bör vara helt automatiserade, snabba (slutförda inom 30 sekunder) och ge fullständig kodtäckning (vilket i princip innebär att alla enhetstester gemensamt bör testa hela kodbasen). Enhetstestning är lämplig för shift-left-metoden. Vi rekommenderar att du tillämpar den på all kod så tidigt i utvecklingscykeln som möjligt, helst i början av programmeringsfasen.
Röktester: Dessa tester är avsedda att utvärdera kärnfunktionerna i ett program i en testmiljö. Medan de testar det faktiska programmet (snarare än dess enskilda, isolerade komponenter, som enhetstester gör), är deras syfte att avgöra om programversionen eller distributionen är tillräckligt stabil för att motivera mer djupgående testning. De verifierar dock inte samverkan mellan appar. Precis som med enhetstester bör de vara helt automatiserade och relativt snabba (användarinteraktion kan simuleras med hjälp av verktyg för webbläsarautomatisering och ramverk för automatisering av användargränssnitt). Termen röktest är avsedd att förmedla idén om rök som indikerar ett stort problem (brand) som bör åtgärdas så snart som möjligt. Röktestning bör också implementeras tidigt i utvecklingscykeln, helst så snart en version av programvaran som tillhandahåller dess kärnfunktioner är tillgänglig. Detta gäller både programversions- och distributionsfaserna.
integrationstester: Dessa tester validerar interaktionen mellan olika programkomponenter. Till skillnad från enhetstester kan det ta lång tid att slutföra dem. Den utökade varaktigheten för dessa tester används ofta som argument för att köra dem tidigt i livscykeln för programvaruutveckling. I allmänhet bör du överväga integreringstester i scenarier där enhets- eller röktester inte är lämpliga. Rekommendationen är dock att schemalägga att de ska köras med jämna mellanrum. Den här metoden ger en rimlig kompromiss mellan en potentiell fördröjning i identifieringen av integrationsproblem och en extra väntetid som krävs för att slutföra dem.
Acceptanstester: Dessa tester avgör om en programvaruprodukt uppfyller affärskraven och är redo för leverans till sina konsumenter. Acceptanstestning är inte lämpligt för skift-vänster-strategin, men det kan vara möjligt att införliva några av dess element tidigt i programvaruutvecklingens livscykel. Till exempel bör acceptanskriterier och användarberättelser, som är viktiga komponenter i godkännandetestning, införas tidigt i utvecklingsprocessen. Detta underlättar samarbete mellan utvecklingsteam, produktägare och projektintressenter. Dessutom bör programvarukonsumenter och projektintressenter delta i de tidigare testfaserna för att kunna dela med sig av sin feedback. Det kan handla om att använda metoder som alfa- eller betatestning, användbarhetstestning eller tidiga versioner inför det formella godkännandetestet.