Testmetoder för programvara: QA-modeller

Vad är metod för mjukvarutestning?

Software Testing Methodology definieras som strategier och testtyper som används för att intyga att applikationen som testas uppfyller kundens förväntningar. Testmetoder inkluderar funktionella och icke-funktionella tester för att validera AUT. Exempel på testmetoder är Enhetstestning, Integrationstestning, Kravhantering, Prestandatester etc. Varje testmetod har ett definierat testmål, teststrategi och resultat.

Anmärkningar: Eftersom mjukvarutestning är en integrerad del av alla utvecklingsmetoder, använder många företag termen utvecklingsmetoder och testmetoder i vardagsspråk. Därför kan testmetoder också hänvisa till Waterfall, Agile och andra QA-modeller i motsats till ovanstående definition av testmetoder. Diskussion om olika testtyper ger inget mervärde för läsarna. Därför kommer vi att diskutera de olika utvecklingsmodellerna.

Testmetodik kontra testtyp kontra teststrategi

Ovanstående antyder en genuin tvetydighet i branschen. Tre termer används synonymt i samtal men betyder olika saker i ett projektdokument, och att blanda ihop dem leder till testplaner som besvarar fel fråga.

Termin	Fråga den svarar	Beslutad av	Exempel
Testmetodik	När och hur passar testning in i utvecklingscykeln?	Utvecklingsmodellen som används	Vattenfall, iterativ, agil, extrem programmering
Testtyp	Vilken aspekt av produkten verifieras?	Risk- och kravtäckning	Enhet, integration, system, prestanda, säkerhet
Testnivå	På vilket djup granskas programvaran?	Position i bygghierarkin	Komponent, integration, system, acceptans
Testa strategi	Hur ser vår organisations syn på kvalitet ut?	Ledarskap inom kvalitetssäkring, gäller i alla projekt	Riskbaserad, automatisering först, skift vänster
Testplan	Vad exakt kommer det här projektet att testa, när och av vem?	Testansvarig, projektspecifik	Omfattning, tidsplan, resurser, inträdes- och utträdeskriterier

En användbar tumregel: metodiken sätter rytmen, typen sätter målet och testplan registrerar åtagandet. Avsnitten nedan granskar metoderna.

Vattenfallsmodell

Vad är det?

I vattenfallsmodell, mjukvaruutveckling framsteg genom olika faser som kravanalys, design etc – sekventiellt.

I denna modell börjar nästa fas först när den tidigare fasen är klar.

Vad är testmetoden?

Den första fasen i vattenfallsmodellen är kravfasen där alla projektkrav är helt definierade innan testningen påbörjas. Under denna fas brainstormar testteamet omfattningen av testning, teststrategi och utarbetar en detaljerad testplan.

Först när designen av mjukvara är klar kommer teamet att gå vidare till exekvering av testfallen för att säkerställa att den utvecklade mjukvaran beter sig som den förväntade sig.

I denna metodik fortsätter testteamet till nästa fas först när den föregående fasen är klar.

Fördelar	Nackdelar
Denna mjukvaruteknikmodell är mycket enkel att planera och hantera. Därför kan projekt, där kraven är tydligt definierade och angivna i förväg, enkelt testas med hjälp av en vattenfallsmodell.	I vattenfallsmodellen kan du börja med nästa fas först när den föregående fasen är klar. Därför kan denna modell inte hantera oplanerade händelser och osäkerhet.
	Denna metod är inte lämplig för projekt där kraven ändras ofta.

Iterativ utveckling

Vad är det?

I den här modellen delas ett stort projekt upp i mindre delar, och varje del genomgår flera iterationer av vattenfallsmodellen. I slutet av en iteration utvecklas en ny modul eller så förbättras en befintlig modul. Denna modul integreras i programvaruarkitekturen och hela systemet testas tillsammans.

Vad är testmetoden?

Så snart iterationen är klar, testas hela systemet. Feedback från testning är omedelbart tillgänglig och införlivas i nästa cykel. Testtiden som krävs vid successiva iterationer kan reduceras baserat på erfarenheterna från tidigare iterationer.

Fördelar	Nackdelar
Den största fördelen med iterativ utveckling är att testfeedbacken är omedelbart tillgänglig i slutet av varje cykel.	Denna modell ökar kommunikationskostnaderna avsevärt eftersom, i slutet av varje cykel, återkoppling om leveranser, ansträngning etc måste ges.

Smidig metod

Vad är det?

Traditionella metoder för mjukvaruutveckling arbetar på premissen att mjukvarukraven förblir konstanta under hela projektet. Men med en ökad komplexitet genomgår kraven många förändringar och utvecklas kontinuerligt. Ibland är kunden själv inte säker på vad han vill ha. Även om den iterativa modellen tar itu med detta problem, är den fortfarande baserad på vattenfallsmodellen.

I Agil metodik utvecklas mjukvara i inkrementella, snabba cykler. Interaktioner mellan kunder, utvecklare och klienter betonas snarare än processer och verktyg. Den agila metodiken fokuserar på att reagera på förändringar snarare än omfattande planering.

Vad är testmetoden?

Inkrementell testning används i agila utvecklingsmetoder och därför testas varje release av projektet grundligt. Detta säkerställer att eventuella buggar i systemet fixas innan nästa utgåva.

Fördelar	Nackdelar
Det är möjligt att göra ändringar i projektet när som helst för att uppfylla kraven.	Konstant kundinteraktion innebär ökad tidspress på alla intressenter inklusive kunden själv, mjukvaruutveckling och testteam.
Denna inkrementella testning minimerar riskerna.

Extrem programmering

Vad är det?

Extrem programmering är en typ av agil metodik som tror på korta utvecklingscykler. Ett projekt är uppdelat i enkla ingenjörsuppgifter. Programmerare kodar en enkel mjukvara och återkommer till kunden för feedback. Revsynpunkter från kunden införlivas och utvecklarna fortsätter med nästa uppgift.

I extrema programmeringsutvecklare arbetar vanligtvis i par.

Extrem programmering används på platser där kundernas krav ständigt förändras.

Vad är testmetoden?

Extrem programmering följer en testdriven utveckling som beskrivs enligt följande –

1. Lägg till Testfall till testsviten för att verifiera den nya funktionaliteten som ännu inte har utvecklats
2. Kör alla tester och uppenbarligen måste det nya testfallet misslyckas eftersom funktionaliteten inte är kodad ännu
3. Skriv lite kod för att implementera funktionen/funktionaliteten
4. Kör testsviten igen. Den här gången bör det nya testfallet passera eftersom det funktionellt har kodats

Fördelar	Nackdelar
Kunder som har en vag programvarudesign i åtanke kan använda extrem programmering	Möten mellan mjukvaruutvecklingsteamet och kunder ökar tidskraven.
Kontinuerlig testning och kontinuerlig integration av små releaser säkerställer att mjukvarukoden levereras är av hög kvalitet

V-modell och spiralmodell

Ytterligare två modeller förekommer i de flesta projekt och kompletterar bilden, eftersom var och en besvarar en svaghet i vattenfallsmetoden på ett annat sätt.

V-modell. V-modellen, som ofta kallas verifiering och validering, parar ihop varje utvecklingsfas med en motsvarande testfas, ritad som de två armarna i ett V. Krav paras ihop med acceptanstestning, högnivådesign med systemtestning, lågnivådesign med integrationstestning och kodning med enhetstestning. Värdet är att testdesignen börjar vid sidan av varje utvecklingsfas snarare än efter kodning, så tvetydiga krav hittas av den person som skriver acceptanstesterna månader innan en defekt kunde byggas. Dess svaghet ärvs från vattenfallsmodellen: modellen antar fortfarande att kraven är stabila.

Spiralmodell. Spiralen kretsar kring explicit riskanalys i iterationen. Varje loop innehåller fyra aktiviteter: fastställa mål, identifiera och lösa risker, utveckla och testa, och sedan planera nästa iteration. Testning koncentreras därför där risken är högst snarare än att fördelas jämnt. Det passar stora, dyra och långvariga program, såsom kärnsystem inom flyg- och rymdteknik eller banksektorn, där kostnaden för en sen upptäckt är hög. För ett litet webbprojekt är kostnaden för formell riskanalys på varje loop sällan motiverad.

Båda modellerna befinner sig mellan vattenfallsdisciplin och agil responsivitet. Där släppfrekvensen är viktigare än någon av dem, en DevOps Pipeline skickar testning till kontinuerlig integration så att varje commit verifieras automatiskt.

Vilken programvarumetod ska man välja?

Det finns massor av metoder tillgängliga för mjukvaruutveckling och dess motsvarande testning. Varje testteknik och metodik är designad för ett specifikt syfte och har sina relativa fördelar och nackdelar.

Valet av en viss metod beror på många faktorer som ett projekts natur, kundkrav, projektschema, etc.

Ur ett testperspektiv pressar vissa metoder på att testa input tidigt i utvecklingens livscykel, medan andra väntar tills en fungerande modell av systemet är klar.

Hur ställer man in metoder för mjukvarutestning?

Programvarutestmetoder bör inte ställas in bara för att testa programvarukod. Den stora bilden bör beaktas och projektets främsta mål bör vara tillfredsställt med testmetoden. Se den här listan över välrenommerade tjänsteleverantörer för mjukvarutestning som kan hjälpa dig att skapa effektiva teststrategier som är skräddarsydda för ditt projekts mål.

Schemaläggning

Realistisk schemaläggning är nyckeln till implementeringen av framgångsrik testmetod och schemat bör möta behoven hos varje medlem i teamet.

Definierade leveranser

För att hålla alla medlemmar i teamet på samma sida bör väldefinierade resultat tillhandahållas. Leveranserna bör innehålla direkt innehåll utan någon tvetydighet.

Testa tillvägagångssätt

När schemaläggningen är klar och definierade leveranser görs tillgängliga bör testteamet kunna formulera rätt testmetod. Definitionsdokument och utvecklarmöten bör ange teamet om den bästa testmetoden som kan användas för projektet.

Rapportering

Transparent rapportering är mycket svårt att uppnå, men detta steg avgör effektiviteten av testmetoden som används i projektet.

Vanliga frågor