Test Process Improvement (TPI) ved hjælp af PDCA Model

Hvad er forbedring af testprocesser?

Test procesforbedring er praksissen med at måle, hvordan en testproces præsterer, identificere dens svage punkter og anvende kontrollerede ændringer, så det næste projekt leverer højere kvalitet til en lavere pris og på kortere tid. Den behandler test som en proces, der kan måles og justeres, i stedet for en aktivitet, der gentages på samme måde i hver udgivelse.

Forestil dig Guru99 Bank-projektet er netop blevet afsluttet. Ledelsen sætter pris på dit arbejde, og kunden er tilfreds. Alligevel har din chef stadig spørgsmål til dig.

Ledere beskriver ofte software test som en besværlig og ukontrollerbar proces. Når man ser tilbage på Guru99 Bank-projekt, stødte du på nogen af ​​følgende problemer?

Disse er almindelige problemer i næsten ethvert testprojekt. Mange organisationer er klar over, at forbedring af testprocessen er den eneste holdbare måde at løse dem på, fordi det at lære af tidligere fejl er det, der forhindrer de samme fejl i at gentage sig i den næste udgivelsescyklus.

Hvorfor teste procesforbedring?

Følgende scenarie viser, hvorfor forbedring af testprocesser er vigtig. Guru99 Bank-projektet er færdigt, kvaliteten af ​​testningen var fremragende, og I har modtaget god feedback fra kunden.

Hvad er lektien fra dette scenarie? Det er simpelthen "forsøg altid at gøre det bedre"Selv når du mener, at du har gjort et godt stykke arbejde, er der altid andre, der gør det bedre, fordi de har fundet bedre ideer og bedre løsninger end dine.

Enhver virksomhed ønsker projektet færdiggjort med højeste kvalitet, ved laveste omkostninger, og i korteste leveringstid. Forbedring af testprocesser er det, der hjælper et testteam med at bevæge sig mod alle tre mål på samme tid.

Hvordan implementerer man forbedring af testprocesser?

At implementere forbedring af testprocesser på Guru99 Bank-projektet, kan testlederen følge PDCA model. PDCA (Plan-Do-Check-Act) er en firetrins ledelsesmetode, der bruges i virksomheder til at kontrollere og løbende forbedre en proces. Hver passage gennem løkken er en enkelt forbedringscyklus, og outputtet fra Act bliver input til den næste Plan.

Trin 1) Planlæg

Planfasen er der, hvor forbedringen designes. Den er opdelt i tre mindre trin.

Trin 1.1) Identificer problemet

Den første aktivitet i en testforbedringsproces er identificere de problemer, der opstod i det aktuelle projekt. Problemerne i dette projekt kan opstå igen i andre projekter. At løse problemer og finde ud af løsningerne for at undgå dem i fremtiden er det primære mål med Test Improvement.

Nu tilbage til projektet Guru99 Banks hjemmeside, finder du nogen problemer eller forbedringspunkter? Vælg nedenfor

Trin 1.2) Bestem målet

Forstå problemet og de problemer, der opstod i projektet. Sådan bestemmer du forbedringspunkterne og de testfaser, der fortjener først opmærksomhed.

Antag, at du har identificeret, at testudførelsesfasen også tog Det er meget tid og omkostninger at gennemføre. Kunne testningen gøres hurtigere og billigere? Det spørgsmål bliver målet for cyklussen. Et nyttigt mål angives som et tal og en deadline, for eksempel "reducer indsatsen for regressionsudførelse med 30 procent inden næste udgivelse".

Trin 1.3) Definer forbedringshandlingerne

Baseret på det aftalte mål fastlægges forbedringstiltagene. Disse tiltag bør være gradvise og introduceres lidt efter lidt, da det ikke er realistisk at ændre alt med det samme.

For eksempel, for at gøre testningen hurtigere og billigere, er følgende handlinger mulige.

I eksemplet ovenfor gør både mulighed A og B testning hurtigere og billigere. Mulighed C ville gøre testning hurtigere, men det koster mere, fordi en mere erfaren tester fortjener en højere løn. Det kompromis er netop grunden til, at enhver kandidathandling skal bedømmes i forhold til målet, ikke i forhold til intuition.

Trin 2) Gør

Du har allerede defineret forbedringspunkterne. Det er nu tid til at udarbejde en plan, der implementerer dem. Denne plan skal besvare følgende spørgsmål.

• Hvilke forbedringspunkter skal implementeres, og i hvilken rækkefølge?
• Hvornår skal planen være færdig?
• Hvilke trin skal gennemføres for at opnå planen?
• Hvem ejer hvert trin, og hvordan bekræftes færdiggørelsen?

Udfør forbedringshandlinger

Når planen er etableret, skal den implementeres. Forbedringsaktiviteter kan forstyrre det testarbejde, der allerede er i gang, så en testmanager skal betale opmærksomhed til dem for at undgå uønsket konsekvenser.

Overvej følgende scenarie. På Guru99 Bank-projektet, for at gøre testning hurtigere og billigere, besluttede du at bruge automatiseringstest i stedet for en stor blok af manuelle regressionstests. Efter at handlingen var anvendt, steg produktiviteten betydeligt.

Trin 3) Tjek

I kontroltrinnet gør du tre ting.

• Evaluer effektivitet af testforbedringshandlingerne
• Mål hvordan effektiv løsningen var
• Analyser om det kunne være forbedret yderligere

Målet med denne fase er at bekræfte, at forbedringstiltagene blev implementeret med succes, og at evaluere, om det mål, der blev sat i planen, rent faktisk er blevet nået.

Den bedste måde at udføre denne evaluering på er med målingerMålinger er afgørende for succesfuld organisationsledelse. Testmanageren indsamler data og bruger dem til at måle parametre som produktivitet, kvalitet og omkostninger.

For eksempel, før automatisering blev anvendt på projektet, blev test af produktivitet 10 testsager pr. mandtimeEfter automatisering blev anvendt, blev produktiviteten målt til 20 testsager pr. mandtime.

Men et uønsket problem opstod ved siden af ​​denne gevinst.

I dette tilfælde anvendes automatisering øget produktiviteten af ​​testning, men kvaliteten af ​​testning er faldetEn forbedringsforanstaltning kan derfor forårsage alvorlige konsekvenser andre steder. I et sådant scenario skal testværktøjet vælges langt mere omhyggeligt, og den automatiserede suite skal gennemgås med samme grundighed som produktionskoden. En struktureret evaluering af kandidatværktøjer, som den der er beskrevet i Selenium tutorial, forhindrer et værktøj i at blive taget i brug udelukkende fordi det er populært.

Overvej det samme scenarie igen. Guru99 projektomkostninger havde overskridelse fordi teammedlemmerne tog også meget tid at udføre testcaserne. Ved at bruge det automatiserede testværktøj har du gemt 30 procent af projektomkostningerne. Det er en god forbedring, men din chef forventer mere.

Du skal derfor altid lede efter nyere løsninger, der forbedrer testprocessen yderligere. I dette scenarie kan andre muligheder spare yderligere projektomkostninger.

• Administrer dine menneskelige ressourcer effektivt, så dygtige testere anvendes der, hvor de tilfører mest værdi
• Forhandle bedre kommercielle vilkår med dine leverandører af værktøj og bemanding
• Tilbagekald dubletter eller testsager med lav værdi i stedet for at automatisere dem

Trin 4) Handl

Når forbedringstiltagene er implementeret med succes, og målet er nået, skal testmanageren fuldføre løkken med følgende aktiviteter.

• Anmeldelse forbedringsaktiviteterne og handle på de indhøstede erfaringer
• Standardisere forbedringspunktet i teststyringsprocessen
• Opdatering politikdokumenterne, testplanskabelonerne og standardprocesdokumenterne
• Bestem hvornår og hvor disse ændringer vil blive anvendt på det næste projekt

Hvis målet ikke blev nået, stopper cyklussen ikke. Det uopfyldte mål føres ind i en ny planfase sammen med alt, hvad kontrolfasen afslørede om, hvorfor handlingen ikke præsterede som forventet.

TPI NEXT, TMMi og CMMI sammenlignet

PDCA er motoren for forbedring, men en referencemodel fortæller dig, hvordan "bedre" ser ud. Tre modeller bruges almindeligvis, og de forveksles ofte med hinanden.

TPI NÆSTE er en testspecifik referencemodel udgivet af Sogeti. Den vurderer 16 nøgleområder, organiseret i tre grupper, ud fra fire modenhedsniveauer: Initial, Kontrolleret, Effektiv og Optimerende. Fordi vurderingen sker nøgleområde for nøgleområde, kan et team være Effektivt på ét område, mens det stadig er Kontrolleret på et andet.

TMMi, vedligeholdt af TMMi Foundation, er en trindelt testmodenhedsmodel med fem niveauer: Initial, Administreret, Defineret, Målt og Optimering. En organisation når først et niveau efter at have opfyldt procesområderne for det pågældende niveau.

CMMI er slet ikke en testmodel. Den dækker hele udviklingsorganisationen, og dens trinvise repræsentation har også fem modenhedsniveauer: Initial, Administreret, Defineret, Kvantitativt Administreret og Optimerende. TMMi blev designet til at supplere CMMI snarere end at erstatte det.

Målinger, der beviser forbedring af testprocesser

Kontrolfasen kollapser uden tal. Et lille, stabilt metriksæt indsamlet før og efter hver cyklus er tilstrækkeligt, og de samme definitioner skal bruges på begge sider af sammenligningen.

• Produktivitet for testudførelse — udførte testsager pr. mandtime
• Fejldetekteringsprocent (DDP) — fejl fundet i test som andel af alle fundne fejl, inklusive dem, der er rapporteret efter frigivelse
• Omkostninger pr. udført testcase — samlede omkostninger til testindsats divideret med udførte testcases
• Kravdækning — krav med mindst én tilknyttet test sag
• Udbedring af fejl — gennemsnitsalderen for en defekt på tværs af defektens livscyklus

Brug af Guru99 Bank-tal, hvor 180 defekter blev fundet i test og 20 blev rapporteret af kunden efter frigivelse, er beregningen ligetil.

# 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))

Output:

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

En DDP på ​​90 procent betyder, at én ud af ti fejl stadig slipper ud til kunden, så kvalitetsmålet blev ikke fuldt ud opfyldt, selvom produktiviteten fordobles, og omkostningerne falder med 30 procent. Det er netop denne opfattelse, der forhindrer et team i at erklære sejr for tidligt.

Almindelige fejl i forbindelse med forbedring af testprocesser

De fleste forbedringsprogrammer mislykkes af organisatoriske årsager snarere end tekniske. Følgende fejl tegner sig for størstedelen af ​​​​opgivne initiativer.

• Forbedring uden en baseline. Hvis ingen målte processen før ændringen, kan ingen bevise, at ændringen hjalp. Registrer baseline under planlægningen, ikke bagefter.
• Jagter et modenhedsniveau i stedet for en forretningsdrivende ånd. Et certifikat, der ikke reducerer omkostninger, defekter eller leveringstid, er en udgift, ikke en forbedring.
• Ændrer for meget på én gang. Når fem handlinger lander i den samme udgivelse, kan en regression ikke udføres tractil nogen af ​​dem.
• Automatisering af en defekt proces. Automatisering mangedobler enhver proces, den anvendes på, herunder svagt testdesign og uklare adgangskriterier.
• Springping Act-fasen. En forbedring, der aldrig er skrevet ind i testpolitikken, og livscyklus for softwaretest dokumenter dør med projektteamet, der opfandt det.
• Undtagen testerne. Folk, der ikke er blevet hørt om en forandring, finder pålidelige måder at omgå den på.

For at tage disse idéer videre, gennemgå faserne af livscyklus for softwaretest, stram din test sag designe, formalisere proces til håndtering af fejl, vurder hvor automatiseringstest giver et reelt afkast, og se hvordan et værktøj som f.eks. HP ALM kan indeholde de metrikker, som din kontrolfase afhænger af.

Ofte Stillede Spørgsmål