Test Process Improvement (TPI) med PDCA-modell

Vad är förbättring av testprocesser?

Testprocessförbättring är praxisen att mäta hur en testprocess presterar, identifiera dess svaga punkter och tillämpa kontrollerade förändringar så att nästa projekt levererar högre kvalitet till en lägre kostnad och på kortare tid. Den behandlar testning som en process som kan mätas och finjusteras, istället för en aktivitet som upprepas på samma sätt i varje release.

Resor som ger Guru99 Bank-projektet har just slutförts. Ledningen uppskattar ditt arbete och kunden är nöjd. Trots det har din chef fortfarande frågor till dig.

Chefer beskriver ofta mjukvarutestning som en besvärlig och okontrollerbar process. Om man ser tillbaka på Guru99 Bank-projektet, har du stött på något av följande problem?

Det här är vanliga problem i nästan alla testprojekt. Många organisationer inser att det enda hållbara sättet att lösa dem är att förbättra testprocessen, eftersom det är att lära sig av tidigare misstag som förhindrar att samma misstag upprepas i nästa releasecykel.

Varför testa processförbättring?

Följande scenario visar varför förbättring av testprocesser är viktigt. Guru99 Bank-projektet är slutfört, testkvaliteten var utmärkt och ni fick bra feedback från kunden.

Vad är lärdomen från detta scenario? Det är helt enkelt "försök alltid att göra bättre"Även när du tror att du har gjort ett bra jobb finns det alltid andra som gör det bättre, eftersom de har hittat bättre idéer och bättre lösningar än dina.

Varje företag vill att projektet ska vara klart med högsta kvalitet, vid lägst kostnad, och i kortast leveranstid. Förbättring av testprocessen är det som hjälper ett testteam att arbeta mot alla tre målen samtidigt.

Hur implementerar man förbättringar av testprocesser?

Att implementera förbättring av testprocesser på Guru99 Bank-projektet, testchefen kan följa PDCA modell. PDCA (Plan-Do-Check-Act) är en fyrstegsmetod som används inom affärsvärlden för att styra och kontinuerligt förbättra en process. Varje steg genom loopen är en enda förbättringscykel, och resultatet av Act blir indata för nästa Plan.

Steg 1) Planera

Planeringsfasen är där förbättringen utformas. Den är uppdelad i tre mindre steg.

Steg 1.1) Identifiera problemet

Den första aktiviteten i en testförbättringsprocess är identifiera de problem som uppstod i det aktuella projektet. Problemen i detta projekt kan hända igen i andra projekt. Att lösa problem och ta reda på lösningarna för att undvika dem i framtiden är det primära målet med Test Improvement.

Nu tillbaka till projektet Guru99 Banks webbplats, hittar du några problem eller förbättringspunkter? Välj nedan.

Steg 1.2) Bestäm målet

Förstå problemet och de problem som uppstod i projektet. Så här identifierar du förbättringspunkterna och de testfaser som förtjänar uppmärksamhet först.

Anta att du har identifierat att testkörningsfasen också tog mycket tid och kostnad att slutföra. Kan testningen göras snabbare och billigare? Den frågan blir målet för cykeln. Ett användbart mål anges som ett nummer och en deadline, till exempel "minska ansträngningen för regressionsexekvering med 30 procent före nästa release".

Steg 1.3) Definiera förbättringsåtgärderna

Baserat på det överenskomna målet fastställs förbättringsåtgärderna. Dessa åtgärder bör vara gradvisa och införas bit för bit, eftersom det inte är realistiskt att ändra allt omedelbart.

För att till exempel göra testningen snabbare och billigare är följande åtgärder möjliga.

I exemplet ovan gör både alternativ A och B testningen snabbare och billigare. Alternativ C skulle göra testningen snabbare, men det kostar mer eftersom en mer erfaren testare har en högre lön. Den avvägningen är just anledningen till att varje kandidats handling måste bedömas utifrån målet, inte utifrån intuition.

Steg 2) Gör

Du har redan definierat förbättringspunkterna. Det är nu dags att skapa en plan som implementerar dem. Denna plan måste besvara följande frågor.

• Vilka förbättringspunkter behöver implementeras, och i vilken ordning?
• När måste planen vara klar?
• Vilka steg måste genomföras för att uppnå planen?
• Vem äger varje steg, och hur bekräftas slutförandet?

Utför förbättringsåtgärder

När planen är fastställd måste den implementeras. Förbättringsaktiviteter kan störa testarbetet som redan är igång, så en testchef måste betala uppmärksamhet till dem för att undvika oönskade konsekvenser.

Tänk dig följande scenario. På Guru99 Bank-projektet, för att göra testning snabbare och billigare, bestämde du dig för att använda automatiseringstestning istället för ett stort antal manuella regressionstester. Efter att åtgärden hade tillämpats ökade produktiviteten avsevärt.

Steg 3) Kontrollera

I kontrollsteget gör du tre saker.

• Utvärdera effektivitet av testförbättringsåtgärderna
• Mät hur effektiv lösningen var
• Analysera om det kan vara förbättras ytterligare

Målet med denna fas är att bekräfta att förbättringsåtgärderna har genomförts framgångsrikt och att utvärdera om målet som sattes i planen faktiskt har uppnåtts.

Det bästa sättet att utföra den utvärderingen är med metrikMätvärden är avgörande för framgångsrik organisationsledning. Testledaren samlar in data och använder den för att mäta parametrar som produktivitet, kvalitet och kostnad.

Till exempel, innan automatisering tillämpades på projektet, testades produktiviteten 10 testfall per arbetstimmeEfter att automatisering hade tillämpats mättes produktiviteten till 20 testfall per arbetstimme.

Men ett oönskat problem dök upp vid sidan av den vinsten.

I det här fallet tillämpas automatisering ökat testningens produktivitet, men testningens kvalitet minskadeEn förbättringsåtgärd kan därför orsaka allvarliga Konsekvenserna någon annanstans. I ett sådant scenario måste testverktyget väljas mycket mer noggrant, och den automatiserade sviten måste granskas med samma noggrannhet som produktionskoden. En strukturerad utvärdering av kandidatverktyg, såsom den som beskrivs i Selenium handledning, förhindrar att ett verktyg antas enbart för att det är populärt.

Tänk dig samma scenario igen. Guru99 projektkostnader hade överskridande eftersom gruppmedlemmarna tog för mycket mycket tid att utföra testfallen. Genom att använda det automatiserade testverktyget sparade du 30 procent av projektkostnaden. Det är en bra förbättring, men din chef förväntar sig mer.

Därför måste man alltid leta efter nyare lösningar som ytterligare förbättrar testprocessen. I det här scenariot kan andra alternativ spara ytterligare projektkostnader.

• Hantera dina mänskliga resurser effektivt, så att skickliga testare används där de tillför mest värde
• Förhandla fram bättre kommersiella villkor med era verktygs- och bemanningsleverantörer
• Ta bort dubbletter eller testfall med lågt värde istället för att automatisera dem

Steg 4) Agera

När förbättringsåtgärderna har implementerats framgångsrikt och målet har uppnåtts, bör testledaren slutföra loopen med följande aktiviteter.

• Review förbättringsaktiviteterna och agera utifrån de lärdomar som dragits
• Standardisera förbättringspunkten inom testhanteringsprocessen
• Uppdatering policydokumenten, testplanmallarna och standardprocessdokumenten
• Bestämma när och var dessa ändringar kommer att tillämpas på nästa projekt

Om målet inte uppnåddes, stannar inte cykeln. Det ouppnådda målet tas med in i en ny planfas tillsammans med allt som kontrollfasen avslöjade om varför åtgärden underpresterade.

TPI NEXT, TMMi och CMMI jämförda

PDCA är motorn för förbättring, men en referensmodell visar hur "bättre" ser ut. Tre modeller används ofta, och de förväxlas ofta med varandra.

TPI NÄSTA är en testspecifik referensmodell publicerad av Sogeti. Den utvärderar 16 nyckelområden, organiserade i tre grupper, mot fyra mognadsnivåer: Initial, Kontrollerad, Effektiv och Optimerande. Eftersom bedömning sker nyckelområde för nyckelområde kan ett team vara Effektivt inom ett område samtidigt som det fortfarande är Kontrollerat inom ett annat.

TMMi, underhålls av TMMi Foundation, är en stegvis testmognadsmodell med fem nivåer: Initial, Hanterad, Definierad, Mätt och Optimering. En organisation når en nivå först efter att ha uppfyllt processområdena för den nivån.

CMMI är inte alls en testmodell. Den täcker hela utvecklingsorganisationen, och dess etappvisa representation har också fem mognadsnivåer: Initial, Hanterad, Definierad, Kvantitativt Hanterad och Optimerande. TMMi utformades för att komplettera CMMI snarare än att ersätta det.

Mätvärden som bevisar förbättring av testprocesser

Kontrollfasen kollapsar utan siffror. En liten, stabil mätvärdesuppsättning som samlas in före och efter varje cykel räcker, och samma definitioner måste användas på båda sidor av jämförelsen.

• Produktivitet för testkörning — testfall utförda per arbetstimme
• Defektdetekteringsprocent (DDP) — fel som upptäckts vid testning som andel av alla upptäckta fel, inklusive de som rapporterats efter utgivning
• Kostnad per utfört testfall — total kostnad för testinsats dividerad med utförda testfall
• Kravtäckning — krav med minst en länkad testfall
• Handläggningstid för felåtgärder — genomsnittlig ålder för en defekt över hela defektens livscykel

Använda Guru99 Banksiffror, där 180 fel hittades vid testning och 20 rapporterades av kunden efter frigivning, är beräkningen enkel.

# Defect Detection Percentage and improvement deltas
def ddp(found_in_test, found_after_release):
    return found_in_test / (found_in_test + found_after_release) * 100

def delta(before, after):
    return (after - before) / before * 100

print("Defect Detection Percentage: %.1f%%" % ddp(180, 20))
print("Productivity gain: %.1f%%" % delta(10, 20))
print("Test cost change: %.1f%%" % delta(50000, 35000))

Produktion:

Defect Detection Percentage: 90.0%
Productivity gain: 100.0%
Test cost change: -30.0%

En DDP på ​​90 procent innebär att ett av tio fel ändå nådde kunden, så kvalitetsmålet uppnåddes inte helt trots att produktiviteten fördubblades och kostnaden minskade med 30 procent. Det är just den synen som hindrar ett team från att utropa seger för tidigt.

Vanliga misstag vid förbättring av testprocesser

De flesta förbättringsprogram misslyckas av organisatoriska skäl snarare än tekniska. Följande misstag står för majoriteten av övergivna initiativ.

• Förbättra utan en baslinje. Om ingen mätte processen före förändringen, kan ingen bevisa att förändringen hjälpte. Registrera baslinjen under planeringen, inte efteråt.
• Jagar en mognadsnivå istället för en affärsmässig drivkraft. Ett certifikat som inte minskar kostnader, defekter eller ledtider är en kostnad, inte en förbättring.
• Ändrar för mycket på en gång. När fem åtgärder landar i samma utgåva kan en regression inte utföras tractill någon av dem.
• Automatisera en trasig process. Automatisering mångfaldigar vilken process den tillämpas på, inklusive svag testdesign och otydliga inträdeskriterier.
• Hoppaping Aktfasen. En förbättring som aldrig skrivs in i testpolicyn och livscykel för mjukvarutestning dokument dör med projektgruppen som uppfann det.
• Exklusive testarna. Människor som inte konsulterats om en förändring hittar pålitligt sätt att kringgå den.

För att ta dessa idéer vidare, granska faserna i livscykel för mjukvarutestning, dra åt testfall designa, formalisera process för felhantering, utvärdera var automatiseringstestning ger en genuin avkastning, och se hur ett verktyg som t.ex. HP ALM kan innehålla de mätvärden som din kontrollfas är beroende av.

Vanliga frågor