Meny

8 viktiga resultatindikatorer för kvalitetsreleaser (Panaya Test Dynamix Review)

8 key performance indicators

Prova Vårt Instrument För Att Eliminera Problem

Den här artikeln förklarar 8 viktiga prestandaindikatorer för kvalitetsreleaser med hjälp av Panaya Test Dynamix end-to-end testlösning:

Det är ingen hemlighet att programvarukvalitetshanterarna står inför ett ökande tryck för att leverera högkvalitativ programvara med rekordhastighet.

Frågan som vi ofta ställer är - 'hur mäter vi vår framgång' när det gäller mjukvarukvalitet?

Speed-to-market är en mycket enklare beräkning, men att mäta våra resultat när det gäller att leverera högkvalitativ programvara beror på en mängd faktorer som projektmetodiken (vattenfall, hybrid, smidig), mjukvarans komplexitet, nivån på teknisk involverade skulder, antalet gränssnitt och mycket mer.

I ett nötskal, antalet variabler som spelar in i en acceptabel nivå av höga svårighetsgrader bör inte underskattas. För att överleva på denna marknad måste vi därför utvecklas kontinuerligt, både i våra åsikter och våra mätpinnar.

Det är anledningen till att jag har utvecklat den här listan över de 8 bästa KPI: erna som du ska lägga till i ditt kvalitetsmål och börja spåra för att mildra frigöringsrisken, förbättra kvaliteten och mäta din framgång direkt.

Viktiga prestandaindikatorer

Vad du kommer att lära dig:

Viktiga resultatindikatorer för kvalitetsreleaser

# 1) Effektivitet för upptäckt av defekter (DDE, AKA-detekteringsprocent)

Detta är ett mått på din övergripande regressionstestning effektivitet. Det beräknas som ett förhållande mellan defekter som har hittats före och efter släpp av dina kunder.

Fel som hittats efter att du släppt är vanligtvis kända som 'Incidenter' och är inloggade i ett helpdesk-system medan de fel som upptäcktes under testfaserna ( T.ex. , Enhet, system, regression eller UAT) identifieras innan de släpps och dokumenteras med verktygen som Panaya Test Dynamix .

För att beräkna denna KPI korrekt bör du alltid kategorisera programvaruversionen som varje defekt identifierades i innan du släpptes i din produktionsmiljö.

Formeln som ofta används för DDE:

Antal defekter som identifierats i programversionen /

Antal defekter i programutgåva + undkommna defekter identifierade av slutanvändare (T.ex., Incidents)

Här är en enkel illustration:

Antag att 95 defekter hittades under din regressionstestcykel på det senaste månatliga SAP Service Pack och 25 defekter loggades efter lanseringen. DDE skulle beräknas som 95 dividerat med (95 + 25) = 79%.

Tänk på att DDE bör övervakas med ett linjediagram som börjar 100% dagen efter att ha släppts till produktion. Och när dina interna slutanvändare och kunder börjar arbeta med ditt senaste SAP-servicepack som ett exempel, kommer de oundvikligen att logga några incidenter.

Det har varit min upplevelse att en 'utfodringsrost' inträffar under den första veckan två dagar efter att ett Service Pack träffar den produktiva miljön. Det är då du kommer att märka en snabb nedgång från 100% till cirka 95% när incidenter loggas. Om ditt företag har en månatlig Service Pack-frigöringsfrekvens, mät DDE under en 30-dagarsperiod på varje Service Pack.

vad är säkerhetsnyckeln för nätverket?

Å andra sidan, om ditt företag bara kör fyra (4) stora utgivningscykler per år, mät det sedan i 90 dagar för att se hur det minskar under den tiden.

Vad betraktas som en “bra DDE”?

Det är ungefär som blodtrycksavläsningarna som varje organisation och person utvecklas över tiden.

Även om det medicinska samfundet definierar den 'optimala' blodtrycksavläsningen till 120/80 - är det naturligt att se en ökning av det systoliska blodtrycket när vi åldras. Med DDE har branschutövare och tankeledare varit kända för att säga att 90% är lovvärt i de flesta branscher.

Jag har dock sett att organisationer uppnår> 95% DDE på en konsekvent basis genom att flytta åt vänster med simuleringsverktyg för förändringseffekter som t.ex. Panayas konsekvensanalys .

# 2) System-Wide Defects (SWD)

Har du någonsin stött på flera fel som är associerade med samma objekt? Visst skulle du ha. Det är ett vanligt fenomen som många testchefer stöter på.

Plötsligt ser du en enorm uppgång i antalet buggar som rapporterats i en UAT-cykel. Lyckligtvis slår jag vad om att du är av den typen som övervakar defekter var 15: e minut och manuellt 'länkar' dubbletterna tillsammans eller läser igenom varje enskild beskrivning för att urskilja orsaken själv, eller hur? Tveksam.

Så, vad är dina alternativ för att hantera det oundvikliga drama av 'defekt inflation?'

Dramat som följer på den här nattliga sammanfattningen samtal med ledningen på högkvarteret om 'Varför en sådan plötslig uppgång i defekter idag?' (Paus…. Andas djupt innan du svarar) ... “Jag håller på att arbeta med våra funktionella ledningar för att utföra en manuell analys av orsakerna.

Men vi tror att många av frågorna relaterar till en gemensam fråga, men det har inte identifierats ännu ”, låter det bekant?

Mitt förslag är att du börjar spåra vad Panaya kallar “System-wide defects” . Att spåra detta manuellt tar evigt - tro mig, jag har provat det många gånger. Det är också smärtsamt att göra när du använder äldre ALM-verktyg där allt du har kvar är möjligheten att länka defekterna till varandra och lägga till en kommentar.

Wow, det hjälpte verkligen! (känner sarkasmen?). Men om du inte har något val i verktyg nu, måste du avsätta tiden för att spåra systemomfattande fel för att tydligt 'förklara bort'? varför bugtrendelinjen rör sig uppåt mot slutet av en testcykel snarare än ner.

Om du får en chans, kolla in Panaya Test Dynamix, den har SWD inbyggd i själva motorn som automatiskt beräknar SWD för dig direkt.

Systemövergripande defekt

Spindelnätet - Med denna riskcockpit på denna plattform är detta en kraftfull men ändå enkel framställning av de ytterligare 6 nyckelprestationsindikatorerna som avrundar de viktigaste KPI: erna som varje kvalitets-, test- och släpphanterare ska spåra.

# 3) Slutförande av krav

QA-chefer förstår risken på en djupare nivå som endast kan realiseras med en kod eller transportnivå synlighet rullas upp till varje krav. Detta kräver rätt uppsättning verktyg.

Panaya-verktyget kommer att svara på behoven hos SAP-drivna organisationer som söker intelligenta förslag för enhetstester och riskanalys baserat på transportaktivitet.

Denna spårningsnivå finns inom Panaya Release Dynamix (RDx) .

Krav slutförd

# 4) Slutförande av utveckling

Vi lever i en era där kunderna är kungen och detta driver varje organisations digitala transformationsstrategi. I dag och tid har vi inte råd att bli tysta i vårt tänkande eller vårt organisatoriska tillvägagångssätt för kvalitetssäkring och leverans av programvara.

Våra traditionella ALM-modeller från förr var inte designade för dagens leveransmodell. För att bekämpa detta gamla sätt att tänka måste QA och testchefer bädda in sig själva i applikationsutvecklingens handlande, vilket innebär att ha en puls på leveransen av användarberättelser.

Det räcker inte att 'sitta och vänta' på att en användarberättelse ska nå den färdiga statusen. Vi måste snarare följa utvecklingen av en användarberättelse, delta i dagliga Scrum-möten och prata öppet om de risker som utvecklas med viktiga förändringar i applikationen som testas.

# 5) Testplanens täckning

Detta är en av mina favorit-KPI att spåra eftersom jag inte förvisas att spåra systemet, integrering, regression och UAT-täckning ensam.

I den riktiga andan av att flytta åt vänster har jag börjat ge råd om vikten av att spåra enhetstestning. Låter galet, eller hur? Det är inte, speciellt om du har rätt verktyg för att göra utförandet av enhetstester ensam, men gör det även enklare att fånga faktiska resultat (bevis).

Med Panaya Test Dynamix inbyggda testinspelnings-och-spel-kapacitet på kommer ditt deltagande i enhetstestning att skjuta i höjden. Du kommer inte bara att kunna stolt visa en kravspårbarhetsmatris som visar en end-to-end-täckning utan kommer också enkelt att visa de faktiska resultaten för din revisionsavdelning från enhet till regressionstestning.

Krav spårbarhet

# 6) Ändra riskanalys

En risk är inneboende i alla ändringar som vi gör i en applikation som testas men vi vet inte alltid om vi testar rätt saker.

Många organisationer har sin egen definition av vad ”förändringsrisk” betyder för dem. Inom ”Risk Cockpit” i Panayas Release Dynamix (RDx) kan du ta gissningar från att spåra ändringarna med en konsekvensanalys för ditt projekt eller nästa release.

RDx beräknar systematiskt risken för varje krav och håller dig uppdaterad om hur det förändras när du går längre in i leveransens livscykel.

Ändra riskanalys

# 7) Testkörningsrisk

Det är för vanligt att alla organisationer spårar KPI: er som författade tester, godkända tester, automatiserade tester och utförda tester, men hur är det med att spåra de faktiska stegen som utförs inom vart och ett av testerna?

Har du någonsin märkt att många av de populära ALM-plattformar tillhandahåller inte out-of-the-box-rapporteringsfunktioner för att spåra test 'steg' -körningsförlopp? När du har många olika 'hand-offs' som förekommer över en UAT-cykel , är det vettigt att spåra risker och status för testutförande, inte bara på testnivå utan även på affärsprocessnivå.

Panaya Test Dynamix gör det bara, out-of-the-box.

testkörningsrisk

# 8) Felkörning

Spårningsfel har i sig en negativ konnotation.

Förutom att spåra aktiva defekter, defekter som åtgärdats per dag avvisade defekter och allvarliga defekter, föreslår vi också att man övervakar lösning av defekter i samband med inbyggda krav.

Många organisationer tar inte en kravdriven syn på defektlösning.

Varför den här lösningen för testning?

Med en end-to-end spårbarhet inbyggd i både Release Dynamix och Panaya Test Dynamix kan din organisation spåra arbetsflödet för defektupplösning från början till slut på kravnivån.

Detta är särskilt användbart för frisläppande, kvalitet och testchefer som söker fågelperspektiv på ett projekt eller släppcykel.

Panaya påskyndar testprocessen för tekniska IT- och affärsanvändare och minskar därmed den totala testinsatsen med 30-50%:

  • Chefer: Realtidsvarningar för testning och defekter och förebyggande av flaskhalsar.
  • Affärsanvändare: Automatiserad dokumentation av testbevis och defekter.
  • Funktionella analytiker: Automatisering av repetitiva testaktiviteter.
  • Professionella testare: Förbättrar sömlöst affärskunskap.
  • Defektlösare: Minskar fram och tillbaka med testarna.

Vad mer ska du veta om den här lösningen

# 1) Panaya Test Dynamix är en SaaS-lösning vilket innebär att du får sömlös integration, frekventa och smärtfria uppgraderingar samt övervakning av lokala automatiseringsverktyg.

vilka verktyg använder affärsanalytiker

# 2) Inbyggda samarbetsverktyg effektivisera testcykler med inbyggda meddelanden och kommunikationsverktyg.

Automatisk överlämning av teststeg till nästa användare eliminerar tomgångstid, lindrar arbetsflaskhalsar och säkerställer optimala arbetsflöden.

# 3) Smart defekthantering gör det möjligt för användare att centralt övervaka brister, deras lösning och de affärsprocesser som påverkas av dem.

När en defekt upptäcks identifieras automatiskt alla andra tester som påverkas av den och blockerar eller skickar aviseringar till testare tills huvudfelet är löst. Den lösta defekten stängs automatiskt genom att eliminera eftersläpningen.

# 4) Med en affärsprocesscentrerad inställning till UAT och SIT, tvärfunktionella och geografiskt spridda ämneexperter validerar UAT-cykler baserat på de faktiska affärsprocesserna (paketerade applikationer).

# 5) Testa automatiseringsanslutningar tillhandahålla en fullständig integration av Panaya Test Dynamix med befintliga automatiseringsverktyg för effektiva regressionscykler på minimal tid och ansträngning med helhetsspårnings- och övervakningsfunktioner.

# 6) Test Evidence Automation automatiserar manuell testning som traditionellt hanteras i Excel och Word.

Sparar tid genom att enkelt dokumentera varje testkörning - inklusive testbevis och en registrering av steg för testreproduktion samtidigt som det minskar fram och tillbaka mellan utvecklare och testare. Dokumentation är revisionsklar , säkerställer efterlevnad av alla interna och externa kvalitetsstandarder.

# 7) Autonom testningSM för SAP möjliggör zero touch-testfall skapande och underhåll så att du inte längre behöver hantera de smärtor som är förknippade med affärs kunskapssamling och processen att skapa och underhålla manuellt konstruerade skript.

Skript kan anpassas medan maskininlärning erbjuder validering och förslag baserat på publikanalys.

# 8) Automatiserad datafångst - Omega skapar automatiskt verkliga testfall baserat på affärsanvändaraktiviteter som fångas sömlöst i produktionen med maskininlärningsalgoritmer (SAP).

Slutsats

Programvarukvalitetshanterarna och alla relevanta intressenter kan möta sina testande KPI: er för att driva mer innovation samtidigt som de minskar insatserna med 30-50%, utan att kompromissa med omfattning eller kvalitet med Panaya.

Standardiserar testprocessen och mäter framgång då alla intressenter använder samma testmetodik för att få synlighet i realtid över alla testcykler, inklusive storskalig UAT.

För mer information kan du utforska Panaya Test Dynamix .

Låt oss veta dina tankar / frågor i kommentarerna nedan.

Rekommenderad läsning

^