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.

Testing Methodology vs Testing Type vs Test Strategy

The note above hints at a genuine ambiguity in the industry. Three terms are used interchangeably in conversation but mean different things on a project document, and confusing them produces test plans that answer the wrong question.

Termin	Fråga den svarar	Beslutad av	Exempel
Testmetodik	When and how does testing fit into the development cycle?	The development model in use	Waterfall, iterative, agile, extreme programming
Testing type	What aspect of the product is being verified?	Risk and requirement coverage	Unit, integration, system, performance, security
Testing level	At what depth is the software examined?	Position in the build hierarchy	Component, integration, system, acceptance
Testa strategi	What is our organisational approach to quality?	QA leadership, applies across projects	Risk based, automation first, shift left
Testplan	What exactly will this project test, when, and by whom?	Test manager, project specific	Scope, schedule, resources, entry and exit criteria

A useful rule of thumb: the methodology sets the rhythm, the type sets the target, and the testplan records the commitment. The sections below examine the methodologies.

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?

In this model, a big project is divided into small parts, and each part is subjected to multiple iterations of the waterfall model. At the end of an iteration, a new module is developed or an existing module is enhanced. This module is integrated into the software architecture and the entire system is tested all together.

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 to the test suite to verify the new functionality which is yet to be developed
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
Customers having a vague software design in mind could use extreme programming	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-Model and Spiral Model

Two further models appear on most projects and complete the picture, because each answers a weakness of the waterfall approach in a different way.

V-Model. Often called verification and validation, the V-Model pairs every development phase with a corresponding test phase, drawn as the two arms of a V. Requirements pair with acceptance testing, high level design with system testing, low level design with integration testing, and coding with unit testing. The value is that test design starts alongside each development phase rather than after coding, so ambiguous requirements are found by the person writing the acceptance tests months before a defect could be built. Its weakness is inherited from waterfall: the model still assumes requirements are stable.

Spiral Model. The spiral wraps iteration around explicit risk analysis. Each loop contains four activities: determine objectives, identify and resolve risks, develop and test, then plan the next iteration. Testing therefore concentrates where risk is highest rather than spreading evenly. It suits large, expensive, long running programmes such as aerospace or banking core systems, where the cost of a late discovery is severe. For a small web project the overhead of formal risk analysis on every loop is rarely justified.

Both models sit between waterfall discipline and agile responsiveness. Where release frequency matters more than either, a DevOps pipeline pushes testing into continuous integration so every commit is verified automatically.

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