L’última guia de proves basades en el risc: gestió del risc en proves de programari

ultimate guide risk based testing

La guia definitiva sobre proves basades en el risc, gestió de riscos i el seu enfocament amb exemples:

Què són les proves basades en el risc?

Les proves basades en el risc consisteixen en realitzar proves o dissenyar i executar els escenaris, de manera que els principals riscos empresarials que tindran un impacte negatiu en el negoci tal com els identifiqui el client es desenterrin al seu producte o característica al començament del cicle de vida i siguin mitigats mitjançant la implementació de mesures de mitigació.

=> Feu clic aquí per obtenir una sèrie completa de programes de proves

L'impacte negatiu pot incloure un impacte de costos, un client insatisfet, una mala experiència d'usuari i fins i tot en la mesura de perdre'ls.

En altres paraules, l'enfocament RBT és assegurar-se que les proves es fan de manera que fins i tot si es tracta d'un usuari troba un error a la producció, això no l’impedeix utilitzar el programari o no afecta el negoci de manera seriosa.

RBT està realitzant proves basades en els riscos del producte. RBT s’ha d’esbrinar amb molta antelació, ja que és el risc de fallar una característica o funcionalitat determinades en la producció i el seu impacte en el negoci en termes de costos i altres danys mitjançant l’ús d’una tècnica de priorització per als casos de prova.

Per tant, les proves basades en el risc utilitzen el principi de prioritzant les proves de les funcions, mòduls i funcionalitats d’un producte o programari. La priorització es basa en el risc de la probabilitat de fallada d’aquesta característica o funcionalitat en la producció i del seu impacte en els clients.

Què aprendreu:

• Proves basades en el risc i la seva rellevància per a Agile & DevOps
  • Enfocament de les proves basades en el risc
    • Quan fem servir l'enfocament RBT?
    • Exemple d'aproximació RBT
  • Maneres de dur a terme anàlisis de riscos
  • Procediment d’anàlisi de riscos
  • Metodologia d’anàlisi de riscos
    • Pas 1) Utilitzar una quadrícula 3X3
    • Pas 2) Probabilitat i impacte d'un fracàs
    • Pas 3) Prova de la quadrícula prioritària
    • Pas 4) Detalls de les proves
  • Com és rellevant RBT per a Agile i DevOps?
  • Beneficis de l'enfocament de proves basades en el risc
• Gestió de riscos durant la planificació de proves
  • Procés de gestió de riscos
    • # 1) Identificació de riscos
    • # 2) Avaluació de riscos / Anàlisi d’impacte de riscos
    • # 3) Mitigació del risc
  • Conclusió
• Gestió de riscos en la fase d'execució de la prova (amb exemple)
  • Gestió de riscos: amb un enfocament a l’aut
  • Com es fan les proves de bases de risc?
  • Conclusió
  • Lectura recomanada

Proves basades en el risc i la seva rellevància per a Agile & DevOps

Tres-centes hores dedicades al desenvolupament de programari es poden fer inútils en només 30 segons amb un sol defecte identificat a la producció.

Això, al seu torn, pot arruïnar el propòsit de tot el producte sense cap altra opció que retirar-lo del mercat. I aquesta és la importància i la necessitat de les 'proves de qualitat'.

Amb el ràpid creixement de la tecnologia, el programari s’allotja al núvol que admet múltiples sistemes operatius, múltiples plataformes, infraestructures de TI complexes, etc., els usuaris finals són cada vegada més exigents sobre les funcions, les opcions i mai no comprometen la satisfacció del client. .

Avui en dia, la 'qualitat' s'està convertint en un factor crucial en el lliurament de programari, on es produeixen millores contínues per millorar la qualitat per tal de mantenir feliços els clients.

Sovint ens adonem que és un problema habitual que gairebé tots els verificadors estiguin sotmesos a una enorme pressió perquè es comprimeixi la finestra de proves i normalment es lliura la versió per a la prova a l'últim moment. No hi ha prou temps i recursos perquè facin totes les proves que han dissenyat i la cobertura automatitzada no sempre és del 100% i té els seus propis reptes.

No es pot perdre el termini de lliurament i, al mateix temps, tampoc es pot comprometre la qualitat. Qualsevol que sigui el pla B, per afegir recursos de prova addicionals extret dels altres equips, no funciona, el pla C, deixar de fer totes les altres activitats i desviar l'esforç només a això, no és realment útil. Tot i que, al final, no hi ha molta addició de recursos de prova.

No hi ha cap altra opció que fer proves limitades i importants dins del temps i recursos disponibles.

Com decidim, doncs, quina prova és important en aquesta etapa? El que un tester consideri important pot no ser realment important per als clients. Des de quina perspectiva es decideix la importància de la característica o una funcionalitat? Qui decidirà quines són les proves importants? I segueixen sorgint moltes altres preguntes.

Per tal de respondre a totes aquestes preguntes i gestionar eficaçment la situació anterior, es va anomenar un enfocament de proves 'Proves basades en el risc' , en breu trucada 'RBT' , va començar a existir, on l’equip ha planificat i identificat clarament els escenaris de prova basant-se en els criteris de ‘Risc del projecte’.

Tot i que l’equip de control de qualitat té una imatge clara de les proves importants, RBT és un mètode provat per identificar les proves crucials i importants des de la perspectiva del client i del negoci a través d’una 'Anàlisi de riscos' procediment .

Així doncs, enfront de la forma tradicional d’identificar simplement els defectes del programari, l’enfocament i l’objectiu de la QA han canviat amb el temps degut al canvi de tecnologia, l’augment de la competència al mercat per llançar un programari de qualitat, la introducció de 'Automatitzeu-ho tot' i, en total, la introducció de la pràctica Agile i DevOps de lliurament del programari durant un període de poques hores.

Per tant, la tendència actual del «principi de prova» no és només «identificar els defectes», sinó també,

# 1) Centreu-vos en l'àrea del producte en què hi hagi un alt impacte en el negoci a causa d'un fracàs o d'una alta probabilitat de fracàs en la producció.

# 2) Centrant-nos en identificar els defectes primerenca i permetent a un equip solucionar-la el més aviat possible i, per tant, permetent que el programari / producte o funció ho facin 'Falla ràpidament'.

# 3) L’aspecte més important del servei de l’equip de control de qualitat ara és centrar-se en el client per aportar valor al client augmentant el focus en 'Experiència del client de punta a punta'.

Enfocament de les proves basades en el risc

Sempre és com preparar-se per a un examen, que no es pot dir que les proves siguin suficients i que no hi hagi més defectes en el programari, fins i tot si dissenyen i executen un nombre ampli de proves.

Hi ha un moment en què no es garantirà doblement l'estabilitat del programari augmentant el nombre de casos de prova sols. En aquest moment, no es tracta només de centrar-se en el nombre de proves, sinó en el que realment espera el client de la versió.

Per tant, és fonamental trobar un equilibri en l'optimització de les proves per tal d'obtenir el màxim benefici amb l'esforç raonable de les proves. I això és més important quan els terminis de les proves són molt ajustats i no es disposa de recursos suficients per dur a terme les proves suficients.

Així, en aquest cas, l’enfocament RBT juga un paper clau a l’hora d’optimitzar l’esforç de control de qualitat i maximitzar el benefici de les proves amb el mínim risc empresarial.

Per tant, si ens centrem en l’aspecte anterior, aleshores el treball d’un control de qualitat serà molt alleujat. No han de cremar els caps de setmana a l'oficina, provant contínuament el programari i preocupant-se per tots els defectes S4 (gravetat 4) i P4 (prioritat 4) que surten de les proves.

Bé, 4 es considera la prioritat i la gravetat més baixes dels defectes en les proves. Poden invertir millor el seu temps en altres aspectes útils del projecte.

Per resumir els motors clau de l'enfocament de 'proves basades en el risc':

• Per permetre provar 'el que volen els clients' des d'una perspectiva empresarial.
• Per complir l’horari amb la qualitat esperada.
• Per optimitzar l’esforç de control de qualitat.

Quan fem servir l'enfocament RBT?

S'utilitza en els escenaris següents:

• L'enfocament RBT es pot utilitzar sempre que hi hagi una limitació o limitació en el temps, el cost i els recursos d'un projecte i sempre que calgui optimitzar els recursos.
• L’enfocament RBT s’utilitza quan el programa és més complex i adapta la nova tecnologia i, per tant, comporta molts reptes.
• Quan el programa és un projecte d’R + D, és de primer tipus i hi ha una sèrie d’incògnites i riscos al projecte.

Exemple d'aproximació RBT

A la indústria de les TI s’utilitzen diversos enfocaments d’anàlisi basats en el risc per superar els riscos de la producció i el seu impacte.

A continuació es presenta un d’aquest enfocaments:

Aquest enfocament de la RBT inclou identificar les 'Funcionalitats vitals o característiques clau' del producte i avaluar els riscos als quals s'exposen cadascuna d'aquestes funcionalitats en la producció i implementar les mesures de mitigació adequades per reduir o mitigar el risc.

Per tant, l’enfocament RBT inclou provar les funcionalitats que tenen la probabilitat d’error i el major impacte en el negoci. Els tipus d’errors poden ser operatius o comercials, tècnics, externs, etc.

Maneres de dur a terme anàlisis de riscos

No hi ha cap procés o plantilla estàndard definit com a tal per dur a terme l’anàlisi de riscos en les proves de programari per a totes i cadascuna de les característiques d’un producte. Diverses organitzacions utilitzen el seu propi enfocament dels mètodes d’anàlisi de riscos.

L'anàlisi de riscos es pot dur a terme en diversos elements del projecte per identificar els riscos i implementar un enfocament RBT per a l'anàlisi. Aquests articles inclouen:

• Característiques
• Funcionalitats
• Històries d'usuaris
• Requisits
• Casos d’ús
• Casos de prova

En aquest cas, centrem-nos només en casos de prova per entendre la implementació de l'enfocament de proves basades en el risc.

Procediment d’anàlisi de riscos

L’anàlisi de riscos inclou la participació dels grups d’interès rellevants del programa tant dels Equip tècnic i equip empresarial » , que inclou propietari del producte, gestors de productes, analistes de negocis, arquitectes, verificadors i representants de clients.

S’organitzarien sessions de pluja d’idees amb aquests grups d’interès per dur a terme la discussió per identificar la importància de cada característica d’un producte i prioritzar-les en funció del risc de fallada i del seu impacte en els usuaris finals de la producció.

Diversos «documents del projecte», com ara documents de requisits, documents d’especificacions tècniques, documents d’arquitectura i disseny, documents de processos empresarials, documents de casos d’ús, etc., esdevindran l’entrada de la sessió de pluja d’idees.

El coneixement de les parts interessades sobre el producte i el producte existent al mercat també serà un factor d’entrada per al debat.

Poques altres fonts d’entrada també poden incloure,

• Per recopilar entrades sobre la funcionalitat més utilitzada.
• Entrades de la consulta d’un expert en dominis.
• Dades de la versió anterior del producte o producte similar al mercat.

Durant el pluja d'idees sessió, s’identifiquen els riscos de cadascuna d’aquestes característiques. Els tipus de riscos poden ser operatius, tècnics o relacionats amb el negoci. Les proves i els escenaris relacionats amb elles es ponderen i els valors del risc s’avaluen en funció de la probabilitat d’aparició del risc i de l’impacte del risc.

La 'Probabilitat d'ocurrència de risc' es pot deure a:

• Poca comprensió de la característica per l’equip de desenvolupament de productes.
• Arquitectura i disseny inadequats.
• Temps insuficient per dissenyar.
• Incompetència de l’equip.
• Recursos inadequats: persones, eines i tecnologia.

L ''impacte del risc' és l'efecte d'un fracàs per als usuaris i les empreses si es produeix. L'impacte podria ser,

• Impacte de costos, que comporta una pèrdua.
• Impacte empresarial que comporta la pèrdua de negoci o la pèrdua de quota de mercat, procediments judicials, pèrdua de llicència.
• Impacte sobre la qualitat, cosa que provoca la versió del producte deficient o incompetent.
• Mala experiència d'usuari, que provoca la insatisfacció i la pèrdua d'un client.

L’àrea d’enfocament de l’avaluació del risc d’una característica o producte pot ser:

• Àrea de negoci Criticitat de la funcionalitat.
• Funcions més utilitzades i funcionalitats importants.
• Zones propenses a defectes
• Funcionalitat que comporta l'impacte de seguretat.
• Àrea de Disseny Complex i Arquitectura.
• Canvis realitzats a partir de versions anteriors.

Metodologia d’anàlisi de riscos

Ara entenem detalladament la 'metodologia de proves basades en el risc'.

L’enfocament de les proves basades en el risc utilitza RISC com a criteri en totes les fases de prova del cicle de proves, és a dir, planificació de proves , disseny de proves, implementació de proves, execució de la prova i informes de proves. L’ideal seria dissenyar un gran nombre de combinacions possibles d’escenaris de prova.

Per tant, l’enfocament RBT inclou un rànquing de les proves en funció de la gravetat dels riscos per conèixer l’àrea de fallida més defectuosa o arriscada, que provoca un alt impacte en el negoci.

L'objectiu principal de l'anàlisi de riscos és distingir entre els 'Alt valor' elements com a característiques del producte, funcionalitats, requisits, històries dels usuaris , i proves de casos, i ' Valor baix ” uns i, per tant, més tard, centrar-nos més en els casos de prova de 'valor elevat', centrant-nos menys en els casos de prova de 'valor baix'. Aquest és el pas inicial de l’anàlisi de riscos abans d’iniciar les proves basades en el risc.

La tasca principal de categorització o agrupació de casos de prova en valor alt i valor baix i assignació del valor de prioritat a cadascun d’aquests casos de prova inclou els passos següents:

Pas 1) Utilitzar una quadrícula 3X3

L’anàlisi de riscos es realitza mitjançant una quadrícula 3X3, en què un equip d’interessats avalua cada funcionalitat, no funcionalitat i els casos de prova relacionats.Probabilitatde fracàs ”i“ Impacte de fracàs ”.

Generalment, un grup d ''experts tècnics' accedeix a la probabilitat de fallada de cada funcionalitat de la producció i es classifica com a 'Probable que falli, bastant probable i poc probable' al llarg de l'eix vertical de la graella.

quin és el millor lloc de descàrrega de mp3 de forma gratuïta

De la mateixa manera, l’impacte de l’error d’aquestes característiques i funcionalitats en la producció l’experimenta el client final, si un grup de ' Especialistes en empreses 'i es classifiquen en categories' Menors, visibles i d'interrupció 'al llarg de l'eix horitzontal de la quadrícula.

Pas 2) Probabilitat i impacte d'un fracàs

Tots els casos de prova es col·loquen en els quadrants de la quadrícula 3 X 3 basant-se en els valors identificats de probabilitat de fallada i impacte de fallada que es mostren com a punts a la imatge següent.

Highbviament, l’elevada probabilitat de fallada i l’alt impacte de la fallada (interrupció) s’agrupen a l’extrem superior dret de la quadrícula, cosa que és d’alta importància i, per tant, s’identifica que les proves de “valor alt” i proves de “valor baix” s’agrupen a la cantonada inferior esquerra, que té menys o cap importància per al client, on es pot posar un focus menor en aquestes funcions o casos de prova.

Pas 3) Prova de la quadrícula prioritària

Basant-se en el posicionament anterior dels casos de prova a la graella, les proves es prioritzen i s’etiqueten amb les prioritats 1,2,3,4 i 5 i es marquen amb cadascun d’ells. Les proves més importants es posicionen en un 1^cles quadrícules assignades amb prioritat 1 i, de manera similar, amb menys importància es classifiquen en 2, 3, 4 i 5.

Finalment, tots els casos de prova s’ordenen en funció dels seus números de prioritat i es recullen per a la seva execució en l’ordre de prioritat. Els de màxima prioritat es recullen per a la seva execució primer i els de baixa prioritat s’executen més tard o no s’abasten.

Pas 4) Detalls de les proves

El següent pas és decidir el nivell de detalls de les proves per a l'abast definit de les proves. La profunditat de l'abast de les proves es pot decidir en funció de la classificació anterior segons la graella següent.

Les proves d'alta prioritat amb el rànquing 1 es posen a prova 'Més a fons' i, en conseqüència, es desplegen experts per provar aquestes funcions d'alta criticitat i els seus casos de prova relacionats. De manera similar, es poden provar casos amb prioritat 2, 3 i 4. Es pot prendre una decisió de deixar de banda les funcions i proves de la prioritat 5 en funció del temps i recursos disponibles.

Per tant, l’enfocament del nivell de detall de les proves de prioritzar les funcions i els casos de prova no només ajuda els verificadors a identificar les “proves d’alt valor”, sinó que també els guia a decidir el seu “nivell de detall de les proves” en funció d’aquests rànquings prioritaris i els ajuda a realitzar millors proves i redueix el cost de les proves mitjançant el procés d’optimització.

Com és rellevant RBT per a Agile i DevOps?

Ara, després d’entendre l’enfocament de les proves basades en el risc de dur a terme les proves basades en la priorització de les proves en funció del “risc de fracàs” d’una característica concreta i del seu “impacte per al client” en directe, òbviament es plantejaria la qüestió de la rellevància de l'enfocament de les proves basades en el risc a les pràctiques Agile i DevOps.

'Automatitza-ho tot', 'Prova tot', 'Prova contínuament', 'Prova repetidament' són els conceptes clau d'aquestes pràctiques.

Cada vegada que es produeix un canvi de codi o hi ha una versió, totes les proves dissenyades s’executen mitjançant l’automatitzat Integració contínua (CI) / Lliurament continu (CD) ràpidament i repetidament, independentment de la seva priorització.

Llavors, quina relació hi ha entre RBT i DevOps? On encaixaria RBT i seria rellevant a Agile i DevOps ???

# 1) Sí, com he dit anteriorment, no és que totes les indústries i tots els productes tinguin una cobertura 100% automatitzada per a les seves execucions de proves. Per tant, si l’equip ha de triar la priorització per a l’execució de la prova entre la tria de casos de prova manuals i vol estalviar l’energia i l’esforç dels recursos de prova cap a altres activitats, llavors la RBT és la millor opció.

L’enfocament basat en el risc també és una millor aposta per executar proves automatitzades amb proves d’alta prioritat i provar-les com a mínim.

# 2) L’equip de control de qualitat pot adoptar l’enfocament RBT de manera més eficaç durant l’anàlisi de requisits analitzant els requisits i proporcionant un informe previ dels riscos probables dels productes i les característiques perquè l’equip del programa pugui prendre les accions adequades de manera proactiva per mitigar-lo.

# 3) L'enfocament RBT es pot utilitzar eficaçment en el disseny de casos i escenaris de prova basats en el risc alt, de manera que es pugui centrar més les característiques i funcionalitats d'alt risc.

# 4) La identificació de les àrees “d’alt risc” permet a l’equip de control de qualitat centrar el seu esforç de proves en aquelles àrees per provar-les “amb més deteniment” mitjançant “Probadors d’alta capacitat”.

# 5) 'Fail Fast', com tots sabem, és el concepte de 'Agile' i 'DevOps', per al qual l'enfocament RBT ajuda a identificar les àrees 'd'alt risc' del programari, identificar els defectes primerencament i permetre que fallin ràpidament i fallin primer i deixar que l'equip ho solucioni.

# 6) L’objectiu final d’Agile / DevOps és el “focus del client” i, per tant, l’enfocament RBT permet al QA centrar-se en l’experiència del client que només trobar defectes.

Beneficis de l'enfocament de proves basades en el risc

Ja enteníem el propòsit i l’ús de l’enfocament RBT per analitzar els requisits, dissenyar i executar els escenaris de proves. Hi ha diversos avantatges de la RBT.

Podem consolidar i enumerar els avantatges de les proves basades en el risc com:

• Ajuda a un ús més eficient i optimitzat dels recursos de prova.
• Ajuda a facilitar les activitats de treball de qualitat, proves, disseny i desenvolupament de proves i preparació de proves mitjançant la priorització.
• Ajuda a gestionar millor els recursos de control de qualitat assignant els recursos claus a àrees d’enfocament alt.
• Ajuda a la utilització efectiva dels recursos i desvia el seu temps i energia cap a coses millors del projecte.
• Ajuda a l'equip de control de qualitat a planificar els esforços de proves basats en l'avaluació del risc i la identificació de zones volàtils i d'alt risc.
• Ajuda l’equip a optimitzar les proves que es realitzaran en funció de la importància i, per tant, deixar d’abast les proves de baix valor, d’acord amb les parts interessades.
• En general, ajuda a la reducció de costos mitjançant activitats de proves optimitzades i reduïdes.
• L’enfocament RBT permet a l’equip de control de qualitat provar primer les àrees d’alt risc i permet que el producte ‘Falla ràpidament’ i solucioni ràpidament.
• L’enfocament RBT ajuda a aportar claredat a Cobertura de la prova » i el 'Test Scope' per a tot el grup de grups d'interès.
• L’equip pot centrar-se en les àrees d’alt risc i concentrar-se menys en l’àrea de baix risc.
• RBT permet a l'equip decidir amb antelació sobre la implementació de la forma més eficaç de mitigació dels riscos del producte.
• RBT ajuda a evitar l’efecte d’una implementació inadequada de mitigacions.
• Les proves basades en el risc permeten a l’equip prendre les mesures adequades per mitigar o planificar la contingència o situar qualsevol solució alternativa per superar el fracàs o reduir-ne l’impacte si el risc es produeix a Live.
• RBT ajuda a minimitzar el risc residual de l'alliberament.
• Ajuda a aconseguir la 'Qualitat millorada' mitjançant defectes de producció menys costosos.
• En última instància, ajuda a 'Millorar l'experiència del client' i 'Client satisfet'.

A continuació, aprendrem a gestionar els riscos a les fases de planificació i execució de proves del cicle de vida de les proves de programari.

Gestió de riscos durant la planificació de proves

Com gestionar els riscos durant la fase de planificació de les proves:

La vida està plena de riscos, així com un projecte de programari. Qualsevol cosa pot sortir malament en qualsevol moment. Sempre estem a punt per fer les coses bé, però, què passa amb assegurar-nos que res no surt malament i que quan ho sabem exactament què hem de fer? Introduïu la gestió de riscos: es tracta d’una part d’un projecte de proves de programari que ens prepara per prevenir, comprendre, trobar i superar els riscos.

Un risc és simplement un problema que és probable que es produeixi i, quan es produeixi, causarà una pèrdua.

La pèrdua pot ser qualsevol cosa: diners, temps, esforç o un compromís de qualitat. La pèrdua mai no és bona. Per molt que li donem un gir, no és positiu ni ho serà mai. Per tant Gestió de riscos és una part integral dels projectes de programari per assegurar-nos que gestionem els riscos i prevenim / reduïm les pèrdues.

Proves basades en el risc : Com que som una comunitat de control de qualitat, deixem-nos ser específics dels riscos i del procés relacionat amb ella exclusivament en el nostre món del control de qualitat. Els riscos s’avaluen i es gestionen aproximadament en dues fases de la nostra Cicle de vida de la prova de programari . STLC es pot classificar en 3 fases: planificació de proves, disseny de proves i execució de proves.

El procés de gestió de riscos es produeix dues vegades durant:

1. Planificació de proves
2. Disseny de casos de prova (final) o de vegades en fase d'execució de proves

És obligatori en el cas 1, però en el cas 2 és més aviat una situació de 'necessitat'.

Sèrie d'articles en dues parts:

Tot i que el procés subjacent és el mateix, el tipus de riscos tractats en aquestes dues àrees són completament diferents. Per fer-los justícia individualment, els tractarem de manera diferent com una sèrie de dues parts.

Aquesta secció tractarà sobre 'Gestió de riscos durant la planificació de proves'.

Procés de gestió de riscos

El procés genèric per a la gestió de riscos inclou tres etapes importants:

1. Identificació de riscos
2. Anàlisi d’impacte de risc
3. Mitigació de riscos

Riscos de proves i exemples de mitigació:

# 1) Identificació de riscos

Com es diu, el primer pas per resoldre un problema és identificar-lo. Aquesta etapa consisteix a fer una llista de tot allò que pot sorgir i alterar el flux normal dels esdeveniments.

El principal resultat d’aquest pas és una llista de riscos.

Aquest pas de proves basades en el risc és dirigit normalment pel responsable / gerent / representant de control de qualitat. Tanmateix, el líder no podrà arribar a la llista completa, ja que les aportacions de tot l’equip de control de qualitat tenen un gran impacte. Podem dir que es tracta d’una activitat col·lectiva liderada pel líder de control de qualitat.

A més, els riscos que s’identifiquen durant la fase de planificació de les proves tenen una orientació més “gerencial”, és a dir, analitzarem qualsevol cosa que pugui afectar el calendari, l’esforç, el pressupost, els canvis d’infraestructura, etc. del projecte de control de qualitat, etc. no l'AUT, sinó la manera com continuarà la fase QA.

Riscos durant la planificació de proves: exemples de proves basades en el risc

A continuació es mostra una llista de mostres de riscos que es poden enumerar durant la fase de planificació de proves. Tingueu en compte que l'autenticació i la seva funcionalitat no són el focus aquí.

1. El calendari de proves és ajustat. Si l’inici de la prova es retarda a causa de tasques de disseny, la prova no es pot ampliar més enllà de la data d’inici programada de la UAT.
2. No hi ha prou recursos, recursos incorporats massa tard (el procés triga uns 15 dies).
3. Els defectes es troben en una etapa tardana del cicle o en un cicle tardà; és probable que els defectes descoberts tardans es deguin a especificacions poc clares i que es necessitin molt de temps per resoldre’ls.
4. Abast no definit completament definit
5. Desastres naturals
6. No disponibilitat d’Independent Entorn de prova i accessibilitat
7. Proves endarrerides per problemes nous

En aquest moment, podeu escollir ser tan exhaustiu com vulgueu, en funció de la quantitat de temps disponible.

Un cop es mostren tots els riscos, passem a l’avaluació de riscos / anàlisi d’impacte de riscos.

# 2) Avaluació de riscos / Anàlisi d’impacte de riscos

L’anàlisi de riscos és alguna cosa així? :)

Anàlisi de riscos en proves de programari : Tots els riscos es quantifiquen i es prioritzen en aquest pas. Es determina sistemàticament la probabilitat i l’impacte de cada risc (possibilitat d’aparició) (quantitat de pèrdues que causaria quan es materialitzi aquest risc).

Alt - mitjà-baix , s’assignen valors tant a la probabilitat com a l’impacte de cada risc. Primer es tenen en compte els riscos amb una probabilitat 'alta' i un impacte 'alt' i després es segueix l'ordre.

Taula d'anàlisi d'impacte de risc:

Després d’aquests passos, la taula d’anàlisi d’impacte de risc per als riscos anteriors enumerats tindria un aspecte semblant a aquest (tots els valors són hipotètics i només a efectes de comprensió):

# 3) Mitigació del risc

El darrer pas d’aquest procés de proves basades en el risc (RBT) és trobar solucions per planificar com gestionar cadascuna d’aquestes situacions. Aquests plans poden diferir d’empresa a empresa, de projecte a projecte i fins i tot de persona a persona.

Tècniques de mitigació de riscos:

A continuació, es mostra un exemple de què es transforma la taula de riscos quan es completa aquesta fase:

Alguns punts a tenir en compte:

1. Com més aviat comenci la gestió del risc en una fase de planificació de projectes de qualitat, millor.
2. Dels 3 passos, La identificació de riscos és la més important . Si alguna cosa no apareix a la llista i es contempla per a altres passos, el risc no es gestiona.
3. Intenteu trobar un període de temps ideal per a aquesta activitat. Recordeu que una planificació excessiva deixa massa poc temps per fer-ho.
4. A més, després del procés de gestió de riscos, si apareix una nova situació, el pla de gestió de riscos es pot modificar o actualitzar per reflectir l’estat més actual.
5. Dades històriques pot ser molt útil per a l'èxit d'aquest procés.

Conclusió

Això ens porta a un final de la gestió del risc en la fase de planificació de les proves. Tot i que els passos i principis subjacents són similars, el procés de gestió de riscos es concentra més cap a l’AUT quan passa a la fase de disseny / execució de la prova.

A la nostra següent secció, tractarem - Gestió de riscos en fase d'execució de proves.

Gestió de riscos en la fase d'execució de la prova (amb exemple)

En el nostre viatge cap a la comprensió del procés de gestió de riscos, hem parlat de com va exclusivament a Fase de planificació de proves de proves basades en el risc . També vam entendre el procés genèric que implica: identificació de riscos, avaluació de riscos i pla de mitigació de riscos.

Administrador d'informàtica preguntes i respostes de l'entrevista

Com es gestiona el risc durant el disseny de proves o la fase d'execució de la prova:

Hi ha una altra forma de Gestió de riscos (també de vegades anomenat, Proves basades en el risc ) que es produeix durant la fase de disseny o execució de la prova en funció de la situació. Ara, de quina situació parlem? Intentem comprendre-ho primer.

Tots sabem que el nostre treball de proves és reactiu. Sense requisits (ni abast definit), no podem realitzar una anàlisi de viabilitat ni escriure escenaris de proves ni planificar activitats de prova.

De la mateixa manera, quan el codi no està preparat, no tenim res a provar, independentment de la quantitat de treballs preparatius que haguéssim estat preparats en termes de casos de prova, dades de proves, etc. A més, la prova és l'únic pas que queda abans que el producte surti viure.

Gestió de riscos: amb un enfocament a l’aut

Entenguem-ho millor amb un exemple:

Si les proves començarien en aquesta data, l’1 de gener^ci havia de continuar fins al 14 de gener^th- quan es realitzen les proves, la data de publicació del producte se sol fixar immediatament. Diguem: 15 de gener^thper la senzillesa. Ara, en un món perfecte, les coses anirien exactament com estava previst. Però tots coneixem la realitat.

En aquest cas, suposem que, per alguna raó, les proves no van començar fins al 7 de gener^th, el que significa que hem perdut la meitat del temps de proves. Però necessitem 14 dies per provar a fons el producte. Podríem moure la data de publicació més lluny 7 dies, però; això no sol ser una opció. Com que es promet que el producte sortirà al mercat en una data determinada i els retards no són bons per a l’empresa.

Per tant, normalment, els equips de proves hem d’absorbir els retards, compensar d’alguna manera, treballar amb el temps disponible i assegurar-nos que el producte es prova bé. Feina dura, oi?

Aquí és on es torna a emprar el procés de gestió de riscos.

• Ara, si s’espera un retard anticipat fins i tot abans que comencin les proves: el procés té lloc a la fase de disseny de la prova.
• Si els retards es produeixen durant un Fase d’execució de la prova que es va iniciar normalment, es segueix el procés durant la fase d'execució de la prova.
• Els passos i el mètode són els mateixos, independentment de l’etapa en què passi.

Quin és el procés?

La gestió del risc té lloc per determinar quines àrees de l’AUT (Application Under Test) necessiten un focus màxim. Normalment són les àrees funcionals (mòduls o components) que són crítics per a l’èxit del producte final i que són més propenses a fallar.

Llegiu també=> L’anàlisi d’efectes i mode de fallida (FMEA) és una tècnica de gestió de riscos

Qui la realitza?

Atès que es tracta d’AUT, el seu coneixement no és només de la QA, sinó de tots els altres equips (Dev, BA, Client, equips de gestió de projectes, etc.). Per tant, és un esforç col·lectiu, impulsat per l’equip de proves.

Com es fan les proves de bases de risc?

Pas 1) Identificació de riscos

Identifiqueu totes les àrees funcionals de l’AUT. Això inclourà simplement fer una llista.

Pas 2) Avaluació de Riscos

Tots els riscos es quantifiquen i es prioritzen en aquest pas. Quantificar és simplement assignar un número a cada risc de la llista que indiqui la prioritat amb què s’ha d’abordar.

Es decideix la probabilitat i l’impacte de cada risc (possibilitat d’aparició) (quantitat de pèrdues que causaria quan es materialitzi aquest risc).

El mètode típic és assignar les qualificacions. Per exemple, La probabilitat pot prendre els valors de l'1 al 5. L'1 és la probabilitat d'ocurrència de ser baixa (és probable que no passi gens) i el de ser alta 5 (segurament passarà).

De la mateixa manera, a Impact també se li pot assignar una qualificació d'1-5. 1 és d'impacte baix (fins i tot si es materialitza aquest risc, la pèrdua és mínima) i 5 d'impacte elevat (pèrdues enormes quan passa).

Pas 3)

Feu un format de taula i circuleu a tots els representants de l'equip: Dev, BA, Client, PM, QA i qualsevol altra persona rellevant.

Pas 4)

Indiqueu a cada equip que empleni els valors segons la seva qualificació de probabilitat i impacte.

Com que els valors de probabilitat i impacte són numèrics, facilitarà el càlcul del valor del 'factor de risc'.

Factor de risc = Probabilitat X Impacte. Com més alt sigui el factor de risc, més greu és el problema.

Un exemple:

Tingueu en compte que, en aquest moment, aquest és simplement el resultat de la classificació d’un equip. Per a un projecte on hi participin 5 equips diferents, l'equip de control de qualitat acabaria amb 5 taules diferents.

Pas 5)

Agafeu una mitjana dels valors del factor de risc. Per exemple, si hi ha 5 equips, per a cada mòdul, afegiu tots els valors del factor de risc i dividiu-los per 5. Aquests són els valors finals que tractarem. Per exemple, aquests són els factors de risc promediats:

Com més factor de risc, més s’ha de provar aquest mòdul.

Per tant, els mòduls 5 i 2 són fonamentals per a l’èxit del negoci. Comparteix els resultats amb tots els equips.

Pas 6)

Pla de mitigació de riscos : Ara, aquest és el pas que canvia de Projecte a Projecte. Hem identificat que els mòduls 5 i 2 són els que més s’han de concentrar.

Exemplesdel pla podria ser:

1. Els mòduls 5 i 2 es provaran a fons assegurant-se que es provin tots els casos de prova relacionats amb ells. Els altres mòduls es provaran de manera exploratòria.
2. Primer es provaran els mòduls 5 i 2 i després, en funció del temps disponible, es atendran els altres.

Un cop fet un pla, tots els equips arriben a un acord i el segueixen per provar el producte tenint en compte el factor de risc.

Això és!

Alguns punts importants a tenir en compte:

• Ja que es tracta d’una activitat col·lectiva que requereix l’opinió de tothom en consideració ; les probabilitats que sigui exacta i efectiva són més altes.
• Això és no un mètode formal i no ha de formar part de tots els projectes de control de qualitat.
• De vegades, fins i tot si l'equip decideix no dibuixar taules i assignar valors sessió de pluja d’idees senzilla amb tots els presents, podeu donar una bona direcció a l’equip de control de qualitat sobre com procedir.
• El aportació de l’equip de desenvolupament és molt important perquè són els que creen el producte, de manera que sabran què pot funcionar i què pot necessitar una comprovació addicional. Assegureu-vos d’estar pendent d’això.
• Tot i que hi ha diversos passos en el procés, no triga una quantitat considerable de temps a realitzar-les . Especialment, si tots els equips poden seure junts i treballar simultàniament.
• Recordeu aquest procés i el seu resultat és només l’alternativa . Obtenir tot el temps previst per fer proves és la millor manera de realitzar l’activitat de control de qualitat.

Conclusió

L’enfocament de les proves basades en el risc indica clarament que l’objectiu del comprovador no és només continuar explorant els defectes, independentment de la gravetat i la prioritat. Ara les coses han canviat i els provadors han de funcionar de manera intel·ligent i han d’entendre la clara 'Necessitat del client i vol de l'usuari'.

Han d’estudiar a fons el producte i entendre quina és la característica més utilitzada a la producció, que és el camí més crític per a la generació d’ingressos i com protegir i protegir els clients dels problemes de producció i de les amenaces comercials.

Per tant, l’enfocament RBT educa clarament als 3 provadors que només provar-ho tot o fer proves extensives no vol dir que les proves siguin completes o que no hi hagi defectes al producte. Provar eficaçment en un temps estipulat i assegurar-se que s’anul·len els impactes empresarials crítics i importants i això és molt important per al verificador.

Per tant, les proves basades en el risc són l'eina més eficaç per a l'equip de control de qualitat per guiar els grups d'interès del projecte en funció dels riscos del projecte. L'enfocament RBT ajuda l'equip de control de qualitat en la identificació contínua del risc i la seva resolució que podria posar en perill l'assoliment dels objectius i objectius generals del projecte i ajuda a assolir l'objectiu final del grup QA.

P.S. Les paraules QA i Testing s’han utilitzat indistintament a tot el document.

Sobre l'autor: Aquest article està escrit per diversos membres de l'equip de STH: Gayathri Subrahmanyam i Swati S.

Gayathri és una pime de proves de programari amb més de dues dècades d’experiència en proves de programari i ha adoptat àmpliament l’enfocament de “proves basades en el risc” com a part de la industrialització de proves en diversos compromisos i s’ha adonat dels avantatges de l’optimització de recursos de prova i proves de qualitat.

Les proves basades en el risc van ser un repte per a vosaltres? Té alguna cosa interessant que afegir al nostre tutorial? No dubteu a expressar els vostres pensaments a la secció de comentaris de sota !!

=> Visiteu aquí per obtenir la sèrie completa de programes de proves

Lectura recomanada

• Procés d’integració contínua: Com millorar la qualitat del programari i reduir el risc
• Anàlisi d'efectes i mode de fallida (FMEA): com analitzar els riscos per obtenir una millor qualitat del programari i clients satisfets!
• L’última guia de proves basades en el risc: gestió del risc en proves de programari
• Principals eines i tècniques d’avaluació i gestió de riscos
• Tipus de riscos en projectes de programari
• Algunes preguntes d’entrevistes de proves de programari interessants
• Selecció de proves de programari com a carrera professional
• Opinions i ressenyes sobre cursos de proves de programari