Menu

8 klíčových indikátorů výkonu pro zprávy o kvalitě (recenze Panaya Test Dynamix)

8 key performance indicators

Vyzkoušejte Náš Nástroj Pro Odstranění Problémů

Tento článek vysvětluje 8 klíčových indikátorů výkonu pro zprávy o kvalitě pomocí komplexního testovacího řešení Panaya Test Dynamix:

Není žádným tajemstvím, že manažeři kvality softwaru čelí rostoucímu tlaku na poskytování vysoce kvalitního softwaru rekordní rychlostí.

Otázka, kterou si všichni často klademe, je - „jak měříme náš úspěch“, pokud jde o kvalitu softwaru?

Rychlost uvedení na trh je mnohem jednodušší výpočet, ale měření našeho výkonu při poskytování vysoce kvalitního softwaru závisí na mnoha faktorech, jako je metodika projektu (vodopád, hybrid, agilita), složitost softwaru, úroveň technické dluh, počet rozhraní a mnoho dalšího.

Stručně řečeno, počet proměnných, které hrají na přijatelnou úroveň vady vysoké závažnosti by neměl být podceňován. Proto, abychom přežili na tomto trhu, musíme se neustále vyvíjet, a to jak v našich názorech, tak v našich měřících tyčkách.

jak se vyhnout výjimce nulového ukazatele v Javě

To je důvod, proč jsem vytvořil tento seznam 8 nejlepších KPI, které byste měli přidat do své karty skóre kvality a začít sledovat, abyste zmírnili riziko vydání, zlepšili kvalitu a hned změřili svůj úspěch.

klíčové indikátory výkonu

Co se naučíte:

Klíčové ukazatele výkonu pro zprávy o kvalitě

# 1) Efektivita detekce defektů (DDE, AKA Procento detekce defektů)

Toto je míra vaší celkové regresní testování účinnost. Vypočítává se jako poměr vad zjištěných před a po vydání vašimi zákazníky.

Vady nalezené po uvolnění jsou obvykle známé jako „Incidenty“ a jsou přihlášeni do systému technické podpory, zatímco vady zjištěné během testovacích fází ( Např. , Unit, System, Regression nebo UAT) jsou identifikovány před vydáním a dokumentovány pomocí nástrojů jako Test Panaya Dynamix .

Chcete-li správně vypočítat tento KPI, měli byste před vydáním do produkčního prostředí vždy kategorizovat verzi softwaru, v níž byla identifikována každá vada.

Vzorec často používaný pro DDE:

Počet vad zjištěných ve verzi verze softwaru /

Počet defektů ve verzi softwaru + uniklé defekty identifikované koncovými uživateli (Např, Incidenty)

Zde je jednoduchá ilustrace:

Předpokládejme, že během vašeho regresního testovacího cyklu bylo u posledního měsíčního balíčku SAP Service Pack nalezeno 95 defektů a po vydání bylo zaznamenáno 25 defektů. DDE by se počítalo jako 95 děleno (95 + 25) = 79%.

Mějte na paměti, že DDE by mělo být monitorováno pomocí spojnicového grafu, který začíná na 100% den po vydání do výroby. A protože vaši interní koncoví uživatelé a zákazníci začnou pracovat například s vaší nejnovější aktualizací Service Pack pro SAP, nevyhnutelně zaznamená několik incidentů.

Mám zkušenost, že během prvního týdne 2 dny poté, co aktualizace Service Pack zasáhne produktivní prostředí, dojde k „krmení šílenství“. To je, když si všimnete rychlého poklesu ze 100% na přibližně 95%, protože jsou zaznamenány incidenty. Pokud vaše společnost používá měsíční kadenci vydání aktualizace Service Pack, změřte na každé aktualizaci Service Pack DDE po dobu 30 dnů.

Na druhou stranu, pokud vaše společnost provozuje pouze čtyři (4) hlavní cykly vydání ročně, změřte to po dobu 90 dnů, abyste zjistili, jak se v daném časovém období snižuje.

Co je považováno za „dobrý DDE“?

Podobá se to údajům o krevním tlaku, které se každá organizace a člověk v průběhu času vyvíjí.

Ačkoli lékařská komunita definuje „optimální“ hodnotu krevního tlaku na 120/80 - je přirozené, že s věkem roste systolický krevní tlak. Díky DDE je známo, že odborníci v oboru a vedoucí představitelé říkají, že 90% je chvályhodných ve většině průmyslových odvětví.

Viděl jsem však, jak organizace konzistentně dosahují> 95% DDE posunem doleva pomocí nástrojů pro simulaci dopadu změn, jako je Analýza dopadů společnosti Panaya .

# 2) Systémové vady (SWD)

Setkali jste se někdy s více vadami, které jsou spojeny se stejnými objekty? Určitě ano. Je to běžný jev, s nímž se setkává mnoho manažerů zkoušek.

Najednou uvidíte obrovský nárůst počtu chyb hlášených v cyklu UAT. Naštěstí se vsadím, že jste typu, který sleduje vady každých 15 minut a ručně „spojuje“ duplikáty dohromady nebo čte každý jednotlivý popis, aby sám rozpoznal hlavní příčinu, že? Pochybný.

Jaké jsou tedy vaše možnosti, jak zvládnout nevyhnutelné drama „defektní inflace“?

Drama, které následuje po nočním rekapitulačním hovoru s vedením v ústředí o „Proč dnes tak náhlý nárůst defektů?“ (Pauza .... Hluboký dech, než odpovíte) ... „Jsem v procesu práce s našimi funkčními kabely, abych provedl manuální analýzu hlavních příčin.

Ale myslíme si, že mnoho problémů souvisí s běžným problémem, ale to ještě nebylo identifikováno “, Zní to povědomě?

Navrhuji, abyste začali sledovat, co Panaya volá „Systémové vady“ . Sledovat to ručně trvá věčnost - věřte mi, už jsem to mnohokrát zkoušel. Je také bolestivé dělat při používání starších nástrojů ALM, kde vám zbývá jen možnost vzájemně propojit vady a přidat komentář.

Páni, to opravdu pomohlo! (Cítíte sarkasmus?). Pokud ale nyní nemáte na výběr v nástrojích, budete si muset vyhradit čas na správné sledování systémových defektů, abyste je jasně „vysvětlili“? proč se trendová linie chyb pohybuje směrem nahoru ke konci testovacího cyklu, spíše než dolů.

Pokud máte šanci, podívejte se na Panaya Test Dynamix, který má v samotném motoru zabudovaný SWD, který za vás automaticky vypočítá SWD za běhu.

Závada celého systému

Pavučina - Toto řešení, umístěné v „kokpitu rizik“ této platformy, je výkonným a zároveň jednoduchým znázorněním 6 dalších klíčových ukazatelů výkonu, které doplňují nejdůležitější KPI, které by měl sledovat každý manažer kvality, testování a vydání.

# 3) Dokončení požadavků

Manažeři QA chápou riziko na hlubší úrovni, kterou lze realizovat pouze s viditelností kódu nebo dopravy na úrovni každého požadavku. To vyžaduje správnou sadu nástrojů.

Nástroj Panaya odpoví na potřeby organizací provozovaných společností SAP, které hledají inteligentní návrhy pro testy jednotek a analýzu rizik založenou na přepravní aktivitě.

Tato úroveň sledování je k dispozici v rámci Panaya Release Dynamix (RDx) .

Dokončení požadavků

# 4) Dokončení vývoje

Žijeme v éře, ve které jsou zákazníci králem, a to řídí strategii digitální transformace každé organizace. V dnešní době si nemůžeme dovolit nechat se uklidnit svým myšlením nebo naším organizačním přístupem k zajišťování a poskytování kvality softwaru.

Naše tradiční modely ALM z dávných dob nebyly navrženy pro dnešní model nepřetržitého doručování. Aby bylo možné bojovat proti tomuto starému způsobu myšlení, musí se QA a testovací manažeři zapojit do akce vývoje aplikací, což znamená mít impuls k doručování uživatelských příběhů.

Nestačí „sedět a čekat“, až uživatelský příběh dosáhne hotového stavu. Spíše musíme sledovat vývoj uživatelského příběhu, účastnit se denních schůzek Scrumu a otevřeně mluvit o rozvíjejících se rizicích s důležitými změnami prováděnými v testované aplikaci.

# 5) Pokrytí testovacího plánu

Toto je jeden z mých oblíbených KPI ke sledování, protože nejsem zařazen pouze ke sledování systému, integrace, regrese a pokrytí UAT.

Ve skutečném duchu řazení doleva jsem začal radit o důležitosti sledování pokrytí testovací jednotkou. Zní to šíleně, že? Není tomu tak, zvláště pokud máte správné nástroje, které vám usnadní provádění samotných testů jednotek, ale usnadníte i zachycení skutečných výsledků (důkazů).

Se zapnutou funkcí záznamu a přehrávání testů Panaya Test Dynamix bude vaše účast na testování jednotek raketově stoupat. Budete nejen moci hrdě zobrazit Matici sledovatelnosti požadavků zobrazující end-to-end pokrytí, ale také snadno představíte skutečné výsledky svému auditnímu oddělení od jednotky až po regresní testování.

Sledovatelnost požadavků

# 6) Změňte analýzu rizik

Každá změna, kterou provedeme v testované aplikaci, je spojena s rizikem, ale ne vždy víme, zda testujeme správné věci.

Mnoho organizací má vlastní definici toho, co pro ně znamená „riziko změny“. V rámci „Rizikového kokpitu“ Panaya's Release Dynamix (RDx) můžete odhady ze sledování změn vyloučit pomocí Analýzy dopadů pro váš projekt nebo příští vydání.

RDx systematicky vypočítává riziko pro každý požadavek a udržuje vás krok s tím, jak se mění, jak se pohybujete dále do životního cyklu dodávky.

Změňte analýzu rizik

# 7) Riziko provedení testu

Pro všechny organizace je příliš běžné sledovat KPI, jako jsou autorské testy, složené testy, automatizované testy a provedené testy, ale co sledování skutečných kroků provedených v rámci každého z testů?

Všimli jste si někdy, že mnoho z populární platformy ALM neposkytují možnosti okamžitého hlášení pro sledování postupu provádění „krokového“ testu? Pokud dochází k mnoha různým „rozdáváním“ napříč a Cyklus UAT , má smysl sledovat riziko a stav provádění testu, a to nejen na úrovni testu, ale také na úrovni obchodního procesu.

Panaya Test Dynamix to dělá hned po vybalení.

riziko provedení testu

# 8) Provedení vady

Sledování vad má ve své podstatě také negativní konotaci.

Kromě sledování aktivních defektů, defektů opravených za den odmítnutých defektů a závažných defektů také doporučujeme sledovat řešení defektů, které se vztahují k podrobným požadavkům.

Mnoho organizací nezohledňuje rozlišení defektů podle požadavků.

Proč toto řešení pro testování?

Díky sledovatelnosti typu end-to-end zabudované do Release Dynamix i Panaya Test Dynamix může vaše organizace sledovat pracovní postup řešení defektů od začátku do konce na úrovni požadavků.

To je obzvláště užitečné pro manažery vydání, kvality a testování, kteří hledají pohled na projekt nebo cyklus vydání z ptačí perspektivy.

Společnost Panaya zrychluje proces testování technických IT a podnikových uživatelů, čímž snižuje celkovou snahu o testování o 30-50%:

  • Manažeři: Upozornění na testování a závady v reálném čase a prevence úzkých míst.
  • Firemní uživatelé: Automatizovaná dokumentace důkazů o testech a závad.
  • Funkční analytici: Automatizace opakovaných testovacích činností.
  • Profesionální testeři: Hladce zlepšuje získávání obchodních znalostí.
  • Řešitelé vad: Snižuje se tam a zpět s testery.

Co dalšího byste měli o tomto řešení vědět

# 1) Test Panaya Dynamix je řešení SaaS což znamená, že získáte bezproblémovou integraci, časté a bezbolestné upgrady i monitorování on-premise automatizačních nástrojů.

# 2) Integrované nástroje pro spolupráci zefektivněte testovací cykly pomocí integrovaných upozornění a komunikačních nástrojů.

Automatické předání testovacích kroků dalšímu uživateli eliminuje dobu nečinnosti, zmírňuje úzká místa pracovní zátěže a zajišťuje optimální pracovní postupy.

# 3) Inteligentní správa defektů umožňuje uživatelům centrálně sledovat vady, jejich řešení a jimi ovlivněné obchodní procesy.

Když je nalezena závada, automaticky identifikuje všechny ostatní ovlivněné testy a blokuje nebo odesílá oznámení testerům, dokud nebude hlavní závada vyřešena. Vyřešená závada se automaticky uzavře odstraněním nevyřízených závad.

# 4) S přístupem UAT a SIT zaměřeným na obchodní procesy, cross-funkční a geograficky rozptýlení odborníci na předmět ověřují cykly UAT na základě skutečných obchodních procesů (zabalené aplikace).

# 5) Otestujte konektory automatizace poskytnout úplnou integraci Panaya Test Dynamix se stávajícími automatizačními nástroji pro efektivní regresní cykly v minimálním čase a úsilí s holistickými schopnostmi sledování a monitorování.

# 6) Testujte automatizaci důkazů automatizuje ruční testování tradičně spravované v Excelu a Wordu.

Šetří čas tím, že bez námahy zdokumentuje každé provedení testu - včetně důkazů o testu a záznamu kroků pro reprodukci testu při současném snížení počtu změn mezi vývojáři a testery. Dokumentace je připraveno na audit , zajišťuje soulad se všemi interními a externími standardy kvality.

# 7) Autonomní testováníSM pro SAP umožňuje vytváření a údržbu testovacích případů bez dotyku, takže již nemusíte řešit bolesti spojené se získáváním obchodních znalostí a procesem vytváření a údržby ručně vytvořených skriptů.

Skripty lze přizpůsobit, zatímco strojové učení nabízí ověřování a návrhy založené na analýze davu.

# 8) Automatizované získávání obchodních znalostí - Omega automaticky vytváří reálné testovací případy založené na aktivitách obchodních uživatelů, které jsou plynule zachyceny v produkci pomocí algoritmů strojového učení (SAP).

Závěr

Manažeři kvality softwaru a všechny příslušné zúčastněné strany se mohou setkat se svými testovacími KPI, aby podpořily více inovací a zároveň snížily úsilí o 30-50%, aniž by při používání Panaya slevily z rozsahu nebo kvality.

Standardizuje testovací proces a měří úspěch, protože všechny zúčastněné strany přijímají stejnou metodiku testování, aby získaly viditelnost v reálném čase ve všech testovacích cyklech, včetně rozsáhlého UAT.

Další informace můžete prozkoumat Test Panaya Dynamix .

Sdělte nám své myšlenky / dotazy v komentářích níže.

Doporučené čtení

^