Menu

8 kľúčových ukazovateľov výkonu pre uvoľňovanie kvality (recenzia Panaya Test Dynamix)

8 key performance indicators

Vyskúšajte Náš Nástroj Na Odstránenie Problémov

Tento článok vysvetľuje 8 kľúčových ukazovateľov výkonu pre správy o kvalite pomocou komplexného testovacieho riešenia Panaya Test Dynamix:

Nie je žiadnym tajomstvom, že manažéri kvality softvéru čelia čoraz väčšiemu tlaku na dodávanie vysokokvalitného softvéru rekordnou rýchlosťou.

Otázka, ktorú si každý z nás často kladie, je - „ako meriame náš úspech“ z hľadiska kvality softvéru?

Rýchlosť uvedenia na trh je oveľa jednoduchší výpočet, ale meranie nášho výkonu pri dodávaní vysoko kvalitného softvéru závisí od mnohých faktorov, ako je metodika projektu (vodopád, hybrid, agilný), zložitosť softvéru, úroveň technickej zapojený dlh, počet rozhraní a oveľa viac.

Stručne povedané, počet premenných, ktoré hrajú na prijateľnú úroveň chyby vysokej závažnosti netreba podceňovať. Preto, aby sme prežili na tomto trhu, musíme sa neustále vyvíjať, a to tak v našich názoroch, ako aj v našich meračkách.

To je dôvod, prečo som vytvoril tento zoznam 8 najlepších KPI, ktoré by ste mali pridať do svojho skóre kvality a začať sledovať, aby ste znížili riziko vydania, zlepšili kvalitu a ihneď zmerali svoj úspech.

ako pripojiť bin súbor -

Kľúčové ukazovatele výkonnosti

Čo sa dozviete:

Kľúčové ukazovatele výkonu pre správy o kvalite

# 1) Účinnosť detekcie defektov (DDE, AKA percento detekcie defektov)

Toto je vaša miera celkové regresné testovanie efektívnosť. Vypočíta sa ako pomer chýb zistených pred a po prepustení zákazníkom.

Poruchy zistené po prepustení sú zvyčajne známe ako „Incidenty“ a sú prihlásení v systéme technickej podpory, zatiaľ čo chyby zistené počas testovacích fáz ( Napr. , Unit, System, Regression alebo UAT) sú identifikované pred vydaním a zdokumentované pomocou podobných nástrojov Test Panaya Dynamix .

Aby ste mohli správne vypočítať tento KPI, mali by ste pred uvedením do produkčného prostredia vždy kategorizovať verziu softvéru, v ktorej bola identifikovaná každá chyba.

Vzorec často používaný pre DDE:

Počet zistených chýb vo verzii verzie softvéru /

Počet chýb v softvérovom vydaní + uniknuté chyby identifikované koncovými používateľmi (Napr, Incidenty)

Tu je jednoduchá ilustrácia:

Predpokladajme, že počas vášho cyklu regresného testovania bolo pri poslednom cykle SAP Service Pack nájdených 95 chýb a po vydaní bolo zaznamenaných 25 chýb. DDE by sa počítalo ako 95 vydelené (95 + 25) = 79%.

Majte na pamäti, že DDE by malo byť monitorované čiarovým grafom, ktorý začína na 100% deň po uvoľnení do výroby. Keď vaši interní koncoví používatelia a zákazníci začnú pracovať napríklad s najnovšou aktualizáciou Service Pack pre systém SAP, nevyhnutne zaznamenajú niekoľko udalostí.

Mám skúsenosti s tým, že k „kŕmeniu pri kŕmení“ dôjde počas prvého týždňa 2 dni po tom, ako balík Service Pack zasiahne produktívne prostredie. Vtedy zaznamenáte rýchly pokles zo 100% na približne 95%, keď sa udalosti zaznamenajú. Ak má vaša spoločnosť mesačnú frekvenciu vydávania balíkov Service Pack, potom na každom balíku Service Pack zmerajte DDE po dobu 30 dní.

Na druhej strane, ak vaša spoločnosť prevádzkuje iba štyri (4) hlavné cykly vydania ročne, potom ju merajte 90 dní, aby ste zistili, ako sa v danom časovom období znižuje.

Čo sa považuje za „dobrý DDE“?

Je to podobné ako s údajmi o krvnom tlaku, ktoré si každá organizácia a človek časom vyvíja.

Aj keď lekárska komunita definuje „optimálnu“ hodnotu krvného tlaku na 120/80, je prirodzené, že s pribúdajúcim vekom je vidieť zvýšenie systolického tlaku. Vďaka DDE je známe, že odborníci v odbore a vedúci pracovníci tvrdia, že 90% je chvályhodných vo väčšine priemyselných odvetví.

Videl som však organizácie, ktoré konzistentne dosahujú> 95% DDE posunom doľava pomocou nástrojov na simuláciu dopadu zmien, ako sú napr. Analýza vplyvu spoločnosti Panaya .

# 2) Systémové chyby (SWD)

Stretli ste sa už s viacerými poruchami, ktoré súvisia s rovnakými objektmi? Určite by ste mali. Je to bežný jav, s ktorým sa stretávajú mnohí manažéri testov.

Zrazu uvidíte obrovský nárast počtu chýb hlásených v cykle UAT. Našťastie sa stavím, že ste typu, ktorý sleduje chyby každých 15 minút a manuálne „spája“ duplikáty dohromady alebo číta každý jeden popis, aby rozpoznal hlavnú príčinu, však? Pochybné.

Aké sú vaše možnosti, ako zvládnuť nevyhnutnú drámu „defektnej inflácie?“

Dráma, ktorá nasleduje po tejto nočnej rekapitulačnej výzve s vedením v ústredí o „Prečo dnes taký náhly nárast defektov?“ (Pozastavte .... Pred reakciou sa zhlboka nadýchnite) ... „Momentálne pracujem s našimi funkčnými elektródami na vykonaní manuálnej analýzy základných príčin.

Ale myslíme si, že veľa problémov súvisí so spoločným problémom, ale ten zatiaľ nebol identifikovaný ”, Znie to povedome?

Navrhujem, aby ste začali sledovať, čo volá Panaya „Systémové chyby“ . Sledovanie tohto manuálu trvá večne - verte mi, vyskúšal som to už mnohokrát. Je tiež bolestivé robiť pri používaní starších nástrojov ALM, kde vám zostáva iba možnosť vzájomne prepojiť chyby a pridať komentár.

Páni, to skutočne pomohlo! (tušiť sarkazmus?). Ak však teraz nemáte na výber v nástrojoch, budete si musieť vyhradiť čas na správne sledovanie systémových defektov, aby ste ich jasne „vysvetlili“? prečo sa trendová čiara chyby posúva nahor ku koncu testovacieho cyklu, a nie nadol.

Ak máte šancu, pozrite sa na test Panaya Test Dynamix, ktorý má v samotnom motore zabudovaný SWD, ktorý za vás automaticky počíta SWD za chodu.

Porucha celého systému

Pavučina - Nachádza sa v „rizikovom kokpite“ tejto platformy a predstavuje výkonné, ale jednoduché zastúpenie ďalších 6 kľúčových ukazovateľov výkonu, ktoré dopĺňajú najdôležitejšie KPI, ktoré by mal sledovať každý manažér kvality, testovania a vydávania.

# 3) Dokončenie požiadaviek

Manažéri QA chápu riziko na hlbšej úrovni, ktorú je možné realizovať iba pomocou viditeľnosti kódu alebo transportu na úrovni každej požiadavky. Vyžaduje si to správnu sadu nástrojov.

Nástroj Panaya odpovie na potreby organizácií riadených spoločnosťou SAP, ktoré hľadajú inteligentné návrhy na testovanie jednotiek a analýzu rizík na základe dopravnej činnosti.

Táto úroveň sledovania je k dispozícii v rámci domény Panaya Release Dynamix (RDx) .

Dokončenie požiadaviek

# 4) Dokončenie vývoja

Žijeme v ére, v ktorej sú zákazníci kráľom, a to vedie k stratégii digitálnej transformácie každej organizácie. V dnešnej dobe si nemôžeme dovoliť nechať sa utíšiť svojím myslením alebo organizačným prístupom k zabezpečeniu a dodávaniu kvality softvéru.

Naše tradičné modely ALM z dávnych čias neboli navrhnuté pre dnešný kontinuálny model dodávok. Aby bolo možné bojovať proti tomuto starému spôsobu myslenia, musia sa QA a testovací manažéri zapojiť do vývoja aplikácií, čo znamená impulz v poskytovaní užívateľských príbehov.

Nestačí „sedieť a čakať“, kým sa príbeh používateľa dostane do hotového stavu. Skôr musíme sledovať vývoj užívateľského príbehu, zúčastňovať sa denných stretnutí Scrumu a otvorene hovoriť o rizikách, ktoré sa budú odvíjať od dôležitých zmien uskutočňovaných v testovanej aplikácii.

# 5) Pokrytie testovacieho plánu

Toto je jeden z mojich obľúbených KPI, ktorý sledujem, pretože nie som zaradený do sledovania samotného systému, integrácie, regresie a pokrytia UAT.

V skutočnom duchu radenia doľava som začal radiť o dôležitosti pokrytia testovacej jednotky sledovacej jednotky. Znie to šialene, však? Nie je to tak, najmä ak máte správne nástroje, ktoré uľahčujú samotné vykonávanie jednotkových testov, ale uľahčujú dokonca aj zaznamenávanie skutočných výsledkov (dôkazov).

Vďaka zapnutej možnosti záznamu a prehrávania testov integrovanej v Panaya Test Dynamix bude vaša účasť na testovaní jednotiek prudko stúpať. Budete nielen schopní hrdo zobraziť Maticu sledovateľnosti požiadaviek zobrazujúcu komplexné pokrytie, ale budete tiež môcť ľahko prezentovať skutočné výsledky svojmu audítorskému oddeleniu od oddelenia až po regresné testovanie.

Vysledovateľnosť požiadaviek

# 6) Zmena analýzy rizika

S každou zmenou, ktorú vykonáme v testovanej aplikácii, je spojené riziko. Nie vždy však vieme, či testujeme správne veci.

Mnoho organizácií má vlastnú definíciu toho, čo pre nich znamená „riziko zmeny“. V rámci „Rizikového kokpitu“ programu Panaya’s Release Dynamix (RDx) môžete vyňať dohady zo sledovania zmien pomocou Analýzy dopadov pre váš projekt alebo nasledujúce vydanie.

RDx systematicky počíta riziko pre každú požiadavku a drží vás krok s tým, ako sa mení, keď sa dostanete ďalej do životného cyklu dodávky.

Zmena analýzy rizík

ako používať príkaz find v unixe -

# 7) Riziko vykonania testu

Pre všetky organizácie je príliš bežné sledovať KPI, ako sú autorské testy, zložené testy, automatizované testy a vykonané testy, ale čo sledovanie skutočných krokov vykonaných v rámci každého z testov?

Všimli ste si niekedy, že veľa z populárne platformy ALM neposkytujete možnosti okamžitého nahlasovania na sledovanie priebehu vykonávania testu? Keď sa vyskytne veľa rôznych „rozdaní“ naprieč a Cyklus UAT , má zmysel sledovať riziko a stav vykonania testu, a to nielen na úrovni testu, ale aj na úrovni obchodného procesu.

Panaya Test Dynamix to robí práve po vybalení z krabice.

riziko vykonania testu

# 8) Vykonanie vady

Sledovanie defektov má vo svojej podstate negatívnu konotáciu.

Okrem sledovania aktívnych defektov, defektov opravených za deň, odmietnutých defektov a závažných defektov, navrhujeme tiež monitorovať riešenie porúch, ktoré súvisia s rozsahom požiadaviek.

Mnoho organizácií nezohľadňuje riešenie problémov podľa požiadaviek.

Prečo toto riešenie pre Testovanie?

Vďaka komplexnej vysledovateľnosti zabudovanej do Release Dynamix aj Panaya Test Dynamix môže vaša organizácia sledovať pracovný postup riešenia defektov od začiatku do konca na úrovni požiadaviek.

To je obzvlášť užitočné pre manažérov vydávania, kvality a testovania, ktorí hľadajú projekt alebo cyklus vydávania z vtáčej perspektívy.

Spoločnosť Panaya urýchľuje proces testovania technických IT a obchodných používateľov, čím znižuje celkové úsilie pri testovaní o 30 - 50%:

  • Manažéri: Varovania v reálnom čase týkajúce sa testovania a chýb a zabraňujúce vzniku zúžených miest.
  • Firemní používatelia: Automatizovaná dokumentácia dôkazov a defektov.
  • Funkční analytici: Automatizácia činností opakovaného testovania.
  • Profesionálni testeri: Hladko zlepšuje zachytávanie obchodných znalostí.
  • Riešitelia chýb: Redukcia pomocou testerov tam a späť.

Čo ďalšie by ste mali vedieť o tomto riešení

# 1) Panaya Test Dynamix je riešenie SaaS čo znamená, že získate bezproblémovú integráciu, časté a bezbolestné upgrady, ako aj monitorovanie on-premise automatizačných nástrojov.

# 2) Vstavané nástroje na spoluprácu zefektívniť testovacie cykly pomocou zabudovaných upozornení a komunikačných nástrojov.

Automatické odovzdanie testovacích krokov ďalšiemu používateľovi eliminuje čas nečinnosti, zmierňuje prekážky v pracovnej záťaži a zaisťuje optimálne pracovné toky.

# 3) Inteligentná správa defektov umožňuje používateľom centrálne monitorovať chyby, ich riešenie a nimi ovplyvnené obchodné procesy.

Keď sa zistí chyba, automaticky sa identifikujú všetky ostatné testy, na ktoré má vplyv, a blokuje alebo odosiela oznámenia testerom, kým sa hlavná chyba nevyrieši. Vyriešená chyba sa automaticky uzavrie odstránením nevybavených chýb.

# 4) S prístupom UAT a SIT zameraným na obchodné procesy, krížovo funkční a geograficky rozptýlení odborníci na tematické oblasti overujú cykly UAT na základe skutočných obchodných procesov (zabalené aplikácie).

# 5) Vyskúšajte automatizačné konektory poskytujú úplnú integráciu testu Panaya Test Dynamix s existujúcimi automatizačnými nástrojmi na efektívne regresné cykly za minimálny čas a úsilie s holistickými schopnosťami sledovania a monitorovania.

# 6) Testujte automatizáciu dôkazov automatizuje ručné testovanie tradične spravované v programoch Excel a Word.

Šetrí čas tým, že bez námahy zdokumentuje každé vykonanie testu - vrátane dôkazov o teste a záznamu krokov pre reprodukciu testu, a zároveň zníži počet medzi vývojármi a testermi. Dokumentácia je pripravený na audit , zaisťuje súlad so všetkými internými a externými štandardmi kvality.

# 7) Autonómne testovanieSM pre SAP umožňuje vytváranie a údržbu testovacích prípadov bez dotyku, takže už nemusíte riešiť bolesti spojené so zachytávaním obchodných znalostí a procesom vytvárania a údržby ručne pripravených skriptov.

Skripty sú prispôsobiteľné, zatiaľ čo strojové učenie ponúka overenie a návrhy založené na analýze davu.

# 8) Automatické získavanie obchodných znalostí - Omega automaticky vytvára testovacie prípady z reálneho života na základe aktivít podnikových používateľov bez problémov zachytených vo výrobe pomocou algoritmov strojového učenia (SAP).

Záver

Manažéri kvality softvéru a všetky príslušné zainteresované strany sa môžu stretnúť so svojimi testovacími KPI, aby podporili viac inovácií a zároveň znížili úsilie o 30 - 50% bez toho, aby využívali Panaya na úkor rozsahu alebo kvality.

Štandardizuje testovací proces a meria úspech, pretože všetky zúčastnené strany prijímajú rovnakú metodiku testovania na získanie viditeľnosti v reálnom čase vo všetkých testovacích cykloch vrátane rozsiahleho UAT.

Ďalšie informácie môžete preskúmať Test Panaya Dynamix .

Dajte nám vedieť svoje myšlienky / otázky v komentároch nižšie.

Odporúčané čítanie

^