8 key performance indicators
En aquest article s’expliquen 8 indicadors clau de rendiment per a versions de qualitat amb l’ajut de la solució de prova de punta a punta de Panaya Test Dynamix:
No és cap secret que els gestors de qualitat del programari s’enfronten a una pressió creixent per oferir programari d’alta qualitat a una velocitat de rècord.
La pregunta que sovint ens fem tots és: 'com mesurem el nostre èxit' en termes de qualitat del programari?
La velocitat de comercialització és un càlcul molt més senzill, però mesurar el nostre rendiment en el lliurament de programari d’alta qualitat depèn de multitud de factors com la metodologia del projecte (cascada, híbrid, àgil), la complexitat del programari, el nivell tècnic el deute implicat, el nombre d’interfícies i molt més.
En poques paraules, el nombre de variables que juguen a un nivell acceptable de defectes d’alta gravetat no s’ha de menystenir. Per tant, per sobreviure en aquest mercat, hem d’evolucionar contínuament, tant en les nostres opinions com en els nostres pals de mesura.
Aquesta és la raó per la qual he elaborat aquesta llista dels 8 primers indicadors clau de qualitat que heu d’afegir al vostre Quadre de Qualitat i començar el seguiment per mitigar el risc de llançament, millorar la qualitat i mesurar el vostre èxit immediatament.
com convertir-se en revisor de videojocs
Què aprendreu:
- Indicadors clau de rendiment per a les versions de qualitat
- # 1) Eficàcia de la detecció de defectes (DDE, percentatge de detecció de defectes AKA)
- # 2) Defectes de tot el sistema (SWD)
- # 3) Compliment dels requisits
- # 4) Finalització del desenvolupament
- # 5) Cobertura del pla de proves
- # 6) Anàlisi de riscos de canvi
- # 7) Risc d’execució de la prova
- # 8) Execució de defectes
- Què més heu de saber sobre aquesta solució
- Conclusió
- Lectura recomanada
Indicadors clau de rendiment per a les versions de qualitat
# 1) Eficàcia de la detecció de defectes (DDE, percentatge de detecció de defectes AKA)
Aquesta és una mesura del vostre proves de regressió general eficàcia. Es calcula com una proporció de defectes detectats abans i després de la publicació pels vostres clients.
Els defectes que es troben després de la publicació es coneixen normalment com 'Incidents' i es registren en un sistema d’assistència mentre que els defectes trobats durant les fases de proves ( Per exemple. , Unitat, Sistema, Regressió o UAT) s’identifiquen abans del llançament i es documenten amb les eines com Panaya Test Dynamix .
Per calcular correctament aquest KPI, sempre heu de classificar la versió del programari en què es va identificar cada defecte, abans de llançar-la al vostre entorn de producció.
La fórmula que s’utilitza sovint per a DDE:
Nombre de defectes identificats a la versió del programari Release /
Nombre de defectes de la versió del programari + defectes escapats identificats pels usuaris finals (Per exemple., Incidents)
Aquí teniu una il·lustració senzilla:
Suposem que es van trobar 95 defectes durant el cicle de proves de regressió en aquest darrer paquet de serveis mensual de SAP i que es van registrar 25 defectes després de la versió. El DDE es calcularà com a 95 dividit per (95 + 25) = 79%.
Tingueu en compte que el DDE s'ha de controlar amb un gràfic de línies que comença al 100% l'endemà de sortir a la producció. I a mesura que els vostres usuaris finals interns i clients comencen a treballar amb el vostre darrer paquet de serveis SAP com a exemple, inevitablement registraran algunes incidències.
La meva experiència ha estat que es produeix un 'frenesí alimentari' durant la primera setmana dos dies després que un Service Pack arribi a l'entorn productiu. És llavors quan notareu una ràpida caiguda del 100% al 95% aproximadament a mesura que es registren els incidents. Si la vostra empresa té una cadència de llançament mensual del Service Pack, mesureu DDE durant un període de 30 dies a cada Service Pack.
D'altra banda, si la vostra empresa només executa quatre (4) cicles de llançament importants a l'any, mesureu-la durant 90 dies per veure com disminueix durant aquest període de temps.
Què es considera un 'bon DDE'?
S’assembla molt a les lectures de pressió arterial que cada organització i persona evoluciona al llarg del temps.
Tot i que la comunitat mèdica defineix que la lectura de la pressió arterial 'òptima' és de 120/80, és natural que augmenti la pressió arterial sistòlica a mesura que envellim. Amb DDE, se sap que els professionals de la indústria i els líders de pensament diuen que el 90% és encomiable a la majoria de les indústries.
Tanmateix, he vist com les organitzacions aconsegueixen> 95% de DDE de manera coherent canviant cap a l'esquerra amb eines de simulació d'impacte de canvi, com ara Anàlisi d’impacte de Panaya .
# 2) Defectes de tot el sistema (SWD)
Us heu trobat mai amb diversos defectes associats als mateixos objectes? Segur que ho tindríeu. És un fenomen habitual que es troben molts gestors de proves.
De sobte, veieu un augment positiu enorme en el nombre d'errors reportats en un cicle UAT. Afortunadament, aposto a que sou del tipus que controla els defectes cada 15 minuts i que 'enllaça' manualment els duplicats o llegeix totes les descripcions per discernir la causa principal, no? Dubtós.
Llavors, quines opcions teniu per gestionar el drama inevitable de la 'inflació defectuosa?'
El drama que es produeix en aquella trucada de resum nocturn amb la direcció de la seu central sobre 'Per què un repunt tan deficient avui en dia?' (Pausa ... Respiració profunda abans de respondre) ... 'Estic en procés de treballar amb els nostres clients potencials funcionals per realitzar una anàlisi manual de la causa arrel.
Però creiem que molts dels problemes es relacionen amb un tema comú, però que encara no s’ha identificat ”, us sembla familiar?
què és com obrir un fitxer json
El meu suggeriment és que comenceu a fer el seguiment de les trucades de Panaya 'Defectes de tot el sistema' . Fer un seguiment manualment dura per sempre; creieu-me, ho he provat moltes vegades. També és dolorós fer-ho mentre utilitzeu eines ALM heretades, on només us queda la possibilitat d’enllaçar els defectes i afegir un comentari.
Vaja, això realment va ajudar! (intueix el sarcasme?). Però si ara no teniu opcions d’eines, haureu de reservar el temps per fer un seguiment adequat dels defectes de tot el sistema per “explicar-los” clarament? per què la línia de tendència d'errors es mou cap amunt cap al final d'un cicle de proves en lloc de cap avall.
Si teniu ocasió, consulteu Panaya Test Dynamix, ja que té SWD integrat al propi motor que calcula automàticament SWD sobre la marxa.
La teranyina - Residint a la 'Cockpit de risc' d'aquesta plataforma, es tracta d'una representació potent però senzilla dels 6 indicadors de rendiment addicionals que completen els KPI més importants que haurien de fer el seguiment de tots els gestors de qualitat, proves i versions.
# 3) Compliment dels requisits
Els gestors de control de qualitat comprenen el risc a un nivell més profund que només es pot realitzar amb un codi o una visibilitat a nivell de transport acumulada a cada requisit. Això requereix el conjunt d’eines adequades.
L'eina Panaya donarà resposta a les necessitats de les organitzacions dirigides per SAP que cerquin suggeriments intel·ligents per a les proves unitàries i l'anàlisi de riscos basat en l'activitat de transport.
Aquest nivell de seguiment està disponible dins Panaya Release Dynamix (RDx) .
# 4) Finalització del desenvolupament
Vivim en una època en què els clients són el rei i això condueix l’estratègia de transformació digital de totes les organitzacions. En aquests temps, no ens podem permetre el luxe de deixar-nos embadalir en el nostre pensament o en el nostre enfocament organitzatiu per a la garantia i la distribució de la qualitat del programari.
Els nostres models tradicionals d’ALM d’abans no estaven dissenyats per al model de lliurament continu d’avui en dia. Per combatre aquesta vella forma de pensar, els gestors de control de qualitat i de proves s’han d’incorporar a l’acció de desenvolupament d’aplicacions, el que significa tenir un impuls en el lliurament de les històries dels usuaris.
No n’hi ha prou amb “seure i esperar” perquè la història d’un usuari arribi a l’estat de fet. Més aviat, hem de seguir l’evolució d’una història d’usuari, assistir a reunions diàries de Scrum i parlar obertament sobre els riscos que es desenvolupen amb canvis importants que s’estan fent a l’aplicació sotmesa a prova.
# 5) Cobertura del pla de proves
Aquest és un dels meus KPI preferits per fer un seguiment perquè no estic relegat al seguiment del sistema, integració, regressió i cobertura UAT només.
Amb l’autèntic esperit de desplaçament cap a l’esquerra, he començat a assessorar sobre la importància del seguiment de la cobertura de les proves d’unitats. Sembla boig, oi? No ho és, sobretot si teniu les eines adequades per facilitar l'execució de les proves unitàries, però facilita fins i tot la captura dels resultats reals (proves).
Amb la capacitat integrada de gravació i reproducció de proves de Panaya Test Dynamix, la vostra participació a les proves d’unitats es dispararà. No només podreu mostrar amb orgull una matriu de traçabilitat dels requisits que mostra una cobertura de punta a punta, sinó que també mostrarà fàcilment els resultats reals al vostre departament d’auditoria des de la unitat fins a les proves de regressió.
# 6) Anàlisi de riscos de canvi
Un risc és inherent a qualsevol canvi que fem a una aplicació en prova, però no sempre sabem si estem provant les coses adequades.
Moltes organitzacions tenen la seva pròpia definició del que significa 'risc de canvi' per a elles. Dins del ‘Cockpit de risc’ de la versió Dynamix (RDx) de Panaya, podeu eliminar les conjectures del seguiment dels canvis amb una anàlisi d’impacte per al vostre projecte o la propera versió.
RDx calcula sistemàticament el risc de cada requisit i us manté al corrent de com canvia a mesura que avança al cicle de vida del lliurament.
# 7) Risc d’execució de la prova
És massa habitual que totes les organitzacions realitzin un seguiment dels KPIs, com ara proves autoritzades, proves superades, proves automatitzades i proves executades, però, què passa amb el seguiment dels passos reals realitzats dins de cadascuna de les proves?
Alguna vegada us heu adonat que molts dels popular ALM platforms no proporcioneu funcions d'informes pròpies per fer un seguiment del progrés de l'execució del 'pas' de la prova? Quan teniu moltes 'transferències' diferents a través d'un Cicle UAT , té sentit fer un seguiment del risc i l'estat d'execució de la prova, no només a nivell de prova, sinó també a nivell de procés empresarial.
Panaya Test Dynamix només ho fa, de manera ràpida.
# 8) Execució de defectes
Els defectes de seguiment també tenen intrínsecament una connotació negativa.
la millor eina de revisió de codi per a git
A més de fer un seguiment de defectes actius, defectes corregits per dia i defectes rebutjats i defectes greus, també suggerim supervisar la resolució de defectes en relació amb els requisits inclosos.
Moltes organitzacions no tenen una visió de resolució de defectes basada en els requisits.
Per què aquesta solució per a proves?
Amb una traçabilitat de punta a punta integrada tant a Release Dynamix com a Panaya Test Dynamix, la vostra organització pot fer un seguiment del flux de treball de resolució de defectes de principi a fi al nivell de requisits.
Això és especialment útil per als gestors de llançament, qualitat i proves que busquen una visió d’ocell d’un projecte o cicle de llançament.
Panaya accelera el procés de proves per a usuaris tècnics de TI i empreses, reduint així l'esforç global de proves en un 30-50%:
- Gestors: Alertes en temps real de proves i defectes i prevenció de colls d'ampolla.
- Usuaris empresarials: Documentació automatitzada de proves i defectes de proves.
- Analistes funcionals: Automatització d'activitats de proves repetitives.
- Provadors professionals: Millora perfectament la captura de coneixement empresarial.
- Solucionadors de defectes: Redueix l’anada i la tornada amb els provadors.
Què més heu de saber sobre aquesta solució
# 1) Panaya Test Dynamix és una solució SaaS el que significa que obtindreu una integració perfecta, actualitzacions freqüents i indolores, així com un seguiment de les eines d’automatització locals.
# 2) Eines de col·laboració integrades Agilitzeu els cicles de proves amb notificacions i eines de comunicació incorporades.
El lliurament automàtic de passos de prova al següent usuari elimina el temps d'inactivitat, alleuja els colls d'ampolla de la càrrega de treball i garanteix fluxos de treball òptims.
# 3) Gestió intel·ligent de defectes permet als usuaris controlar de manera centralitzada els defectes, la seva resolució i els processos empresarials que els afecten.
Quan es troba un defecte, identifica automàticament totes les altres proves afectades i bloqueja o envia notificacions als verificadors fins que es resolgui el defecte principal. El defecte resolt es tanca automàticament eliminant el retard de defectes.
# 4) Amb un enfocament centrat en els processos empresarials a UAT i SIT, experts en temes transversals i geogràficament dispersos validen els cicles UAT en funció dels processos empresarials reals (aplicacions empaquetades).
# 5) Prova de connectors d'automatització proporcionar una integració completa de Panaya Test Dynamix amb les eines d’automatització existents per a cicles de regressió efectius en un temps i esforç mínims amb funcions de seguiment i monitorització holístiques.
# 6) Automatització de proves de proves automatitza les proves manuals gestionades tradicionalment a Excel i Word.
Estalvia temps documentant sense esforç totes les execucions de la prova, incloses les proves de prova i un registre de passos per a la reproducció de la prova, alhora que redueix l’anada i tornada entre desenvolupadors i verificadors. La documentació és preparat per a auditories , garanteix el compliment de tots els estàndards de qualitat interns i externs.
# 7) Proves autònomesSM for SAP permet la creació i el manteniment de casos de prova de zero-touch, de manera que ja no haureu de fer front als dolors associats a la captura de coneixement empresarial i al procés de creació i manteniment de seqüències d'ordres dissenyades manualment.
Els scripts es poden personalitzar mentre l'aprenentatge automàtic ofereix validació i suggeriments basats en l'anàlisi de multitud.
# 8) Captura automatitzada de coneixement empresarial: Omega crea automàticament casos de prova de la vida real basats en activitats d’usuaris empresarials que es capturen perfectament a la producció mitjançant algoritmes d’aprenentatge automàtic (SAP).
Conclusió
Els administradors de qualitat del programari i tots els grups d'interès rellevants poden complir els seus indicadors clau de prova per impulsar més innovació, tot reduint els esforços entre un 30 i un 50%, sense comprometre l'abast ni la qualitat mitjançant Panaya.
Estandarditza el procés de proves i mesura l'èxit ja que tots els grups d'interès adopten la mateixa metodologia de prova per obtenir visibilitat en temps real en tots els cicles de prova, inclosa la UAT a gran escala.
Per obtenir més informació, podeu explorar Panaya Test Dynamix .
Feu-nos saber les vostres opinions o consultes als comentaris que hi ha a continuació.
Lectura recomanada
- Quins són els atributs de qualitat?
- Rendiment de MongoDB: rendiment de bloqueig, errors de pàgina i perfils de bases de dades
- Diferència entre garantia de qualitat i control de qualitat (QA vs QC)
- Fals Déu de la qualitat enfront dels veritables humans: qui és responsable de la qualitat del programari?
- Georgia Tech normalitza les proves de rendiment a RadView WebLOAD
- HTTP contra HTTPS: una comparació completa de funcions i rendiment
- Diferència entre el pla de prova de rendiment i l'estratègia de prova de rendiment
- Com es realitzen proves de rendiment manuals?