Tesztelje a folyamatjavítást (TPI) PDCA-modell segítségével

⚡ Okos összefoglaló

A tesztelési folyamatfejlesztés (Test Process Improvement) a PDCA ciklust alkalmazza a tesztelésre, így minden projekt mérhető tanulságokat hagy maga után. Ez az oldal ismerteti a négy PDCA lépést, a mögöttük álló érettségi modelleket és a fejlesztés tényleges megtörténtét bizonyító mérőszámokat.

🔁 PDCA hurok: A Tervezés, Cselekedj, Ellenőrzés és Cselekedj segítségével egy projekt hibáiból ismételhető normát csinálhatsz.
🎯 Kezdjük a problémákkal: Sorolja fel a valós hibákat, késéseket és költségtúllépéseket, mielőtt bármilyen fejlesztési intézkedést választana.
📊 Mérj meg mindent: Track termelékenység, hibaszivárgás és tesztesetenkénti költség minden változtatás előtt és után.
⚠️ Figyelj a mellékhatásokra: Az automatizálás itt növelte az áteresztőképességet, de a minőség romlott, amíg a szerszámválasztást nem korrigálták.
🪜 Fokozatosan javuljon: A kis, egymás után végrehajtott műveletek sokkal gyakrabban sikeresek, mint egy teljes folyamat átírása.
🏛️ Válasszon egy modellt: A TPI NEXT négy érettségi szintet használ; a TMMi és a CMMI egyaránt ötöt definiál.
📝 Standardizáld a győzelmet: Frissítsd a tesztelési szabályzatot és a sablonokat, hogy a következő projekt is örökölje a nyereséget.

További információk

Mi a tesztelési folyamatfejlesztés?

Tesztfolyamat javítása a tesztelési folyamat teljesítményének mérésének, gyenge pontjainak azonosításának és ellenőrzött változtatások alkalmazásának gyakorlata, hogy a következő projekt jobb minőséget nyújtson alacsonyabb költségek mellett és kevesebb idő alatt. A tesztelést egy mérhető és hangolható folyamatként kezeli, ahelyett, hogy egy minden kiadásnál ugyanúgy ismétlődő tevékenységként kezelné.

Képzelje el a GuruA 99 Bank projektje épp most fejeződött be. Az igazgatótanács nagyra értékeli a munkáját, és az ügyfél elégedett. Ennek ellenére a főnökének még mindig vannak kérdései Önhöz.

A vezetők gyakran leírják szoftver tesztelés mint egy nehézkes és kontrollálhatatlan folyamat. Visszatekintve a Guru99 Bank projekt, szembesült-e a következő problémák bármelyikével?

Ezek gyakori problémák szinte minden tesztelési projektben. Sok szervezet felismeri, hogy a tesztelési folyamat fejlesztése az egyetlen tartós módja a megoldásuknak, mivel a múltbeli hibákból való tanulás az, ami megakadályozza, hogy ugyanazok a hibák megismétlődjenek a következő kiadási ciklusban.

Miért érdemes a tesztelési folyamat javítását?

A következő forgatókönyv bemutatja, miért fontos a tesztelési folyamat fejlesztése. GuruA 99 Bank projekt befejeződött, a tesztelés minősége kiváló volt, és jó visszajelzéseket kaptál az ügyféltől.

Mi a tanulság ebből a forgatókönyvből? Egyszerűen csak annyit, hogy „mindig próbálj meg jobban teljesíteni”Még akkor is, ha úgy gondolod, hogy jól végezted a munkádat, mindig vannak mások, akik jobban csinálják, mert jobb ötleteket és jobb megoldásokat találtak, mint a tiéd.

Minden vállalkozás azt szeretné, ha a projekt a lehető legjobban be lenne fejezve. legnagyobb minőség, a legalacsonyabb költség, és a legrövidebb szállítási idő. A tesztelési folyamat fejlesztése segíti a tesztelőcsapatot mindhárom cél egyidejű elérésében.

Hogyan lehet megvalósítani a tesztelési folyamat fejlesztését?

A tesztelési folyamatfejlesztés megvalósítása a következőn: Guru99 Bank projekt, a Tesztmenedzser követheti a PDCA modell. A PDCA (Plan-Do-Check-Act, Tervezés-Megvalósítás-Ellenőrzés-Cselekvés) egy négylépéses menedzsmentmódszer, amelyet az üzleti életben használnak egy folyamat irányítására és folyamatos fejlesztésére. Minden egyes cikluson való áthaladás egyetlen fejlesztési ciklus, és a Cselekvés kimenete a következő terv bemenetévé válik.

💡 Tipp: Futtassa a PDCA ciklust egyszerre egy szűk problémán. Egy olyan ciklus, amely egyetlen mérhető fájdalompontot, például a regresszió végrehajtási idejét célozza meg, elég gyorsan befejeződik ahhoz, hogy az eredmény egyetlen kiadáson belül megjelenjen.

1. lépés) Tervezze meg

A Tervezési fázisban tervezik meg a fejlesztést. Ez három kisebb lépésre oszlik.

1.1. lépés) Határozza meg a problémát

A tesztfejlesztési folyamat első tevékenysége az azonosító a jelenlegi projektben előforduló problémákat. A projektben előforduló problémák más projektekben is megismétlődhetnek. A Tesztfejlesztés elsődleges célja a problémák megoldása és a megoldások megtalálása a jövőbeni elkerülés érdekében.

Most vissza a projekthez Guru99 Bank weboldal, talált-e bármilyen problémát vagy fejlesztendő pontot? Válasszon az alábbiak közül!

Sr No	Probléma	Leírás
1	Minőség	Az ügyfél még talált néhányat Disszidál szabadulás után
2	Kézbesítés	A projekt késett
3	Csapat	Néhány alkalmazott nem működött együtt a csapat többi tagjával
4	szakértelem	A csapattag nem rendelkezett a kívánt készségekkel a feladatok elvégzéséhez
5	Menedzsment	A tesztmenedzser nem figyelte jól az előrehaladást, ami miatt néhány projekt késett
6	Kommunikáció	Nincs állandó kapcsolat az ügyféllel; félreérti az ügyfél követelményeit
7	Költség	A projekt költsége túllépte a tervezett költségvetést

Problémád van vele Minőség Kézbesítés Csapat ,Készségek , Menedzsment , Kommunikáció ,Költség

1.2. lépés) Határozza meg a célt

Értsd meg a problémát és a projekt során felmerült nehézségeket. Így határozhatod meg a fejlesztési pontokat és a tesztelési fázisokat, amelyekre elsősorban figyelmet kell fordítani.

Tegyük fel, hogy azonosította, hogy a tesztvégrehajtási szakasz is eltartott sok az elvégzéshez szükséges idő és költség. Lehetne-e gyorsabbá és olcsóbbá tenni a tesztelést? Ez a kérdés lesz a ciklus célja. Egy hasznos célt számként és határidőként adnak meg, például: „csökkentse a regresszió végrehajtására fordított erőfeszítést 30 százalékkal a következő kiadás előtt”.

1.3. lépés) Határozza meg a fejlesztési intézkedéseket

A megállapodott cél alapján meghatározzák a fejlesztési intézkedéseket. Ezeket az intézkedéseket fokozatosan, apránként kell bevezetni, mert nem reális mindent azonnal megváltoztatni.

Például a tesztelés gyorsabbá és olcsóbbá tétele érdekében a következő intézkedések lehetségesek.

A fenti példában az A és a B lehetőség is gyorsabbá és olcsóbbá teszi a tesztelést. A C lehetőség gyorsabbá tenné a tesztelést, de többe kerülne, mivel egy tapasztaltabb tesztelő magasabb fizetést kap. Pontosan ez a kompromisszum az oka annak, hogy minden jelölt cselekedetét a célponthoz, nem pedig az intuícióhoz viszonyítva kell megítélni.

2. lépés) Tedd meg

Már meghatároztad a fejlesztési pontokat. Most itt az ideje, hogy kidolgozz egy tervet, amely megvalósítja őket. Ennek a tervnek a következő kérdésekre kell választ adnia.

Milyen fejlesztési pontokat kell megvalósítani, és milyen sorrendben?
Mikorra kell elkészülnie a tervnek?
Milyen lépéseket kell végrehajtani a terv megvalósításához?
Ki a felelős az egyes lépésekért, és hogyan fogják megerősíteni a befejezést?

Végezzen javító intézkedéseket

Miután a terv elkészült, azt végre kell hajtani. A fejlesztési tevékenységek megzavarhatják a már folyamatban lévő tesztelési munkát, ezért a tesztmenedzsernek fizetnie kell figyelem nekik azért, hogy elkerülni a nem kívánt következményekkel jár.

Vegyük figyelembe a következő forgatókönyvet. A Guru99 Bank projekt, a tesztelés gyorsabbá és olcsóbbá tétele érdekében úgy döntött, hogy a következőt használja: automatizálási tesztelés egy nagyszámú manuális regressziós teszt helyett. A művelet alkalmazása után a termelékenység jelentősen megnőtt.

3. lépés) Ellenőrizze

Az Ellenőrzés lépésben három dolgot kell tennie.

Értékelje a hatékonyság a tesztfejlesztési intézkedések közül
Mérje meg hogyan hatékony a megoldás az volt
Elemezd, hogy lehetséges-e javított további

Ennek a fázisnak a célja annak megerősítése, hogy a fejlesztési intézkedéseket sikeresen végrehajtották, és annak értékelése, hogy a tervben kitűzött célt valóban elérték-e.

Az értékelés elvégzésének legjobb módja a mutatókA metrikák elengedhetetlenek a sikeres szervezetirányításhoz. A tesztmenedzser adatokat gyűjt, és azokat olyan paraméterek mérésére használja fel, mint a termelékenység, a minőség és a költségek.

Például, mielőtt az automatizálást alkalmazták volna a projektben, a tesztelés termelékenysége 10 teszteset munkaóránkéntAz automatizálás alkalmazása után a termelékenységet a következő helyen mérték: 20 teszteset munkaóránként.

De ezzel a nyereséggel együtt egy nemkívánatos probléma is felmerült.

Ebben az esetben az automatizálás alkalmazása <p></p> a tesztelés termelékenysége, de a tesztelés minősége csökkentEgy fejlesztési intézkedés ezért súlyos károkat okozhat. következményei máshol. Ilyen esetben a tesztelőeszközt sokkal körültekintőbben kell kiválasztani, és az automatizált csomagot ugyanolyan szigorúsággal kell felülvizsgálni, mint az éles kódot. A jelölteszközök strukturált értékelése, mint amilyen a ... részben leírt. Selenium oktatóimegakadályozza, hogy egy eszközt pusztán azért alkalmazzanak, mert népszerű.

⚠️ Figyelmeztetés: Soha ne egyetlen mérőszám alapján ítélj meg egy fejlesztési intézkedést. Egy olyan változás, amely megduplázza a végrehajtási áteresztőképességet, miközben csökkenti a hibaészlelést, egyszerre gyorsabbá és rontottabbá tette a folyamatot. Mindig párosíts egy sebességmérőszámot egy minőségmérőszámmal.

Vegyük fel újra ugyanazt a forgatókönyvet. Guru99 projekt költsége volt túlfutás mert a csapattagok is sok idő a tesztesetek végrehajtásához. Az automatizált teszteszköz használatával Ön mentett 30 százalék a projekt költségeinek egy részét. Ez jó előrelépés, de a főnököd többet vár el.

Ezért mindig újabb megoldásokat kell keresni, amelyek tovább javítják a tesztelési folyamatot. Ebben az esetben más lehetőségek további projektköltségeket takaríthatnak meg.

Hatékonyan kezelje emberi erőforrásait, hogy a képzett tesztelőket ott alkalmazza, ahol a legtöbb értéket képviselik
Tárgyaljon jobb kereskedelmi feltételeket a szerszám- és munkaerő-kölcsönző beszállítóival
Duplikált vagy alacsony értékű tesztesetek kivonása automatizálás helyett

4. lépés) Act

Amikor a fejlesztési intézkedéseket sikeresen megvalósították és a cél teljesült, a tesztmenedzsernek a következő tevékenységekkel kell befejeznie a ciklust.

Áttekintés a fejlesztési tevékenységeket és a tanulságok alapján cselekedjünk
Szabványosítás a tesztmenedzsment folyamaton belüli fejlesztési pont
Frissítések a szabályzatdokumentumok, a tesztterv-sablonok és a szabványos folyamatdokumentumok
Határozzuk meg mikor és hol lesznek ezek a változtatások érvényben a következő projektben

Ha a cél nem teljesült, a ciklus nem áll meg. A nem teljesített cél egy új Tervezési fázisba kerül, mindazzal együtt, amit az Ellenőrzési fázis feltárt arról, hogy miért nem teljesített a művelet.

TPI NEXT, TMMi és CMMI összehasonlítás

A PDCA a fejlődés motorja, de egy referenciamodell megmondja, hogy mit jelent a „jobb”. Három modellt használnak általában, és gyakran összekeverik őket egymással.

TPI NEXT egy, a Sogeti által közzétett tesztspecifikus referenciamodell. 16 kulcsfontosságú területet értékel, három csoportba rendezve, négy érettségi szint alapján: Kezdeti, Ellenőrzött, Hatékony és Optimalizáló. Mivel az értékelés kulcsfontosságú területről kulcsfontosságú területre történik, egy csapat lehet hatékony az egyik területen, miközben egy másikon továbbra is Ellenőrzött.

TMMi, amelyet a TMMi tart fenn Foundation, egy szakaszos tesztelési érettségi modell, öt szinttel: Kezdeti, Kezelt, Meghatározott, Mért és Optimalizálás. Egy szervezet csak akkor ér el egy szintet, ha kielégíti az adott szint folyamatterületeit.

CMMI egyáltalán nem tesztelési modell. Lefedi a teljes fejlesztői szervezetet, és szakaszos reprezentációjának öt érettségi szintje van: Kezdeti, Menedzselt, Meghatározott, Mennyiségileg menedzselt és Optimalizáló. A TMMi-t a CMMI kiegészítésére, nem pedig annak helyettesítésére tervezték.

Modell	Kör	Szerkezet	Érettségi szintek
TPI NEXT	Csak tesztelési folyamat	16 kulcsfontosságú terület 3 csoportban, ellenőrzőpontokkal és klaszterekkel	4 — Kezdeti, Ellenőrzött, Hatékony, Optimalizáló
TMMi	Csak tesztelési folyamat	Szakaszos, minden szinthez hozzárendelt folyamatterületekkel	5 — Kezdeti, Kezelt, Meghatározott, Mért, Optimalizálás
CMMI	Teljes fejlesztési szervezet	Színpadi vagy folyamatos ábrázolás	5 (szakaszos) — Kezdeti, Kezelt, Meghatározott, Mennyiségileg kezelt, Optimalizáló

A tesztelési folyamat fejlesztését bizonyító mérőszámok

Az Ellenőrzési fázis számok nélkül összeomlik. Elegendő egy kis, stabil metrikakészlet, amelyet minden ciklus előtt és után gyűjtenek össze, és ugyanazokat a definíciókat kell használni az összehasonlítás mindkét oldalán.

Tesztvégrehajtás termelékenysége — munkaóránként végrehajtott tesztesetek
Hibaészlelési százalék (DDP) — a tesztelés során talált hibák aránya az összes talált hibához képest, beleértve a kiadás után jelentett hibákat is
Végrehajtott tesztesetenkénti költség — teljes tesztelési ráfordítási költség osztva a végrehajtott tesztesetekkel
Követelménylefedettség — legalább egy kapcsolódó követelmény próbaper
Hibajavítási határidő — a hibák átlagos életkora a hiba életciklusa

az Guru99 banki adat alapján, ahol 180 hibát találtak a tesztelés során, és 20-at az ügyfél jelentett a kiadás után, a számítás egyszerű.

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

A 90 százalékos DDP azt jelenti, hogy minden tizedik hiba továbbra is a vevőhöz került, tehát a minőségi cél nem teljesült teljes mértékben, annak ellenére, hogy a termelékenység megduplázódott, a költség pedig 30 százalékkal csökkent. Ez az egyetlen nézet az, ami megakadályozza a csapatot abban, hogy túl korán győzelmet hirdetsen.

Gyakori hibák a tesztelési folyamatfejlesztésben

A legtöbb fejlesztési program inkább szervezési, mint technikai okokból vall kudarcot. A következő hibák teszik ki a félbehagyott kezdeményezések többségét.

Javulás alapvonal nélkül. Ha senki sem mérte fel a folyamatot a változás előtt, senki sem tudja bizonyítani, hogy a változás segített. A tervezés során rögzítse az alapállapotot, ne utána.
Egy érettségi szint hajszolása az üzleti hajtóerő helyett. Egy olyan tanúsítvány, amely nem csökkenti a költségeket, a hibákat vagy a szállítási időt, kiadás, nem pedig fejlesztés.
Túl sok változás egyszerre. Amikor öt művelet ugyanabban a kiadásban található, regresszió nem lehetséges. tracbármelyiküknek.
Hibás folyamat automatizálása. Az automatizálás megsokszorozza a problémákat, bármilyen folyamatra is alkalmazzák, beleértve a gyenge teszttervezést és a nem egyértelmű belépési kritériumokat.
Továbbping a Cselekvés fázisa. Egy olyan fejlesztés, amely soha nem szerepel a tesztelési szabályzatban és a szoftvertesztelés életciklusa A dokumentumok meghalnak a kitaláló projektcsapattal együtt.
A tesztelőket leszámítva. Azok az emberek, akikkel nem konzultáltak egy változásról, megbízhatóan találnak megoldást a megkerülésére.

Ezen ötletek továbbfejlesztéséhez tekintse át a következő fázisokat: szoftvertesztelés életciklusa, húzza meg a próbaper tervezés, formalizálás hibakezelési folyamat, értékelje, hol automatizálási tesztelés valódi megtérülést biztosít, és nézze meg, hogyan működik egy olyan eszköz, mint a HP ALM tárolhatja azokat a mérőszámokat, amelyektől az Ellenőrzés fázisod függ.

GYIK

Közvetlenül egy kiadás után, amikor a retrospektív adatok még frissek és senki sincs kézbesítési nyomás alatt. A sprint közbeni kezdés versenyez magával a kiadással, és hónapokkal későbbi kezdés azt jelenti, hogy az erőfeszítésre, a hibákra és a költségekre vonatkozó számok már nem megbízhatóak.

A tesztmenedzser felelős a ciklusért és a metrikákért, de minden művelethez szüksége van egy megnevezett tulajdonosra a munkát végző csapatból. A személy helyett egy csoporthoz rendelt fejlesztések azok, amelyek csendben elakadnak.

A retrospektív elemzések jól lefedik a helyi javításokat, de ritkán foglalkoznak a szervezet egészére kiterjedő gyengeségekkel, mint például a tesztadatok biztosítása vagy a környezet elérhetősége. Egy referenciamodell közös szókincset biztosít az agilis csapatoknak ezekre a csapatokon átívelő problémákra anélkül, hogy helyettesítené a retrospektív elemzést.

Az olyan végrehajtási mutatók, mint a termelékenység vagy a ciklusidő, általában egy kiadáson belül változnak. A minőségi mutatókhoz, mint például a hibák kiszivárgása, két vagy három kiadás szükséges, mivel a megkerült hibákat csak azután számolják, hogy az ügyfelek már használták a szoftvert éles környezetben.

Igen, mintázatészleléshez. A hibaelőzményeken, build naplókon és végrehajtási rekordokon betanított modellek felszínre hozhatják a hibás teszteket, a redundáns eseteket és az ismétlődő kilépési kóddal rendelkező modulokat. Annak eldöntése, hogy melyik megállapítás alapján érdemes cselekedni, továbbra is emberi megítélés kérdése az üzleti kockázattal kapcsolatban.

A mennyiséget összetéveszthetjük a lefedettséggel. A mesterséges intelligencia több ezer olyan esetet képes előállítani, amelyek megnövelik a végrehajtási számokat, miközben ugyanazokat az útvonalakat ismételten tesztelik. Track hibaészlelés az esetszámok mellett, és a generált esetek áttekintése, mielőtt azok bekerülnének a regressziós készletbe.