Quan aturar la prova (Criteris de sortida a la prova de programari)

when stop testing

Criteris de sortida a les proves:

'Ben començat està mig fet': s'aplica a tot arreu, fins i tot a les proves de programari.

Sovint veiem provadors de programari molt entusiastes al principi del projecte. Creem documents de proves com ara Estratègia de prova, pla de proves o casos de prova amb ganes i entusiasme.

Després, provem el programari amb un BANG. Això només es veu amplificat pels interessants defectes que trobem al començament del projecte. Resoldre’ls només afegirà al nostre èxit.

A mesura que trobem molts defectes i completem la primera tirada, passem a la següent fase. Quan arribem a la segona tirada ens relaxem i, com és la tendència humana general avorrir-se de provar el mateix a la segona tirada.

quin és el millor bloquejador d'elements emergents per a Chrome

Molts provadors consideren que es converteix en això treball monòton en versions posteriors i comenceu a perdre l’interès per provar una vegada i una altra el mateix programari. Quan arribem a, potser la tercera prova, una pregunta comença a inquietar-nos i és 'Quan deixar de provar el programari?'

Aposto a que us heu sentit de la mateixa manera i heu preguntat 'Quan deixar de provar?', Almenys una vegada. Jo diria que la pregunta és 'Quan, on i com aturar les proves?' :)

Conceptualment hem llegit i molts provadors creuen que no pot haver-hi una condició o equació específica per decidir 'Quan deixar de provar?' Hi ha diversos factors a tenir en compte abans de concloure sobre aquesta qüestió.

A l’article d’avui, m’agradaria compartir les meves opinions sobre com concloure activitats de prova quan arribem a un punt del nostre cicle de proves on podem dir que aquestes proves són suficients. Ho farem amb l'ajut d'alguns exemples de la vida real en un cicle de proves típic.

Què aprendreu:

• Quan és suficient la prova?
• Parar quan es detecten tots els defectes: és possible?
• Decisió d’aturar les proves: criteris de sortida
• Què són els criteris de finalització o de sortida?
• Què hauria d'estar present als criteris de sortida?
• Les proves es poden aturar quan:
• Conclusió:
• Lectura recomanada

Quan són suficients proves?

Quan podem dir que n'hi ha prou amb aquestes proves? Es poden acabar mai les proves?

Per respondre a aquestes preguntes, haurem d’analitzar les activitats de proves de principi a fi. Tingueu en compte que - vaig a definir aquestes activitats en termes d’un home laic - No d’una manera tècnica fantàstica.

Considerem que comenceu a provar un projecte nou.

Activitats inicials:

• L’equip de proves rep els requisits.
• Comença l’equip de proves planificació i disseny.
• Els documents de prova inicials estan llestos i revisats.

Prova d'execució núm. 1)

• L’equip de proves inicia l'execució de la prova un cop rebin el producte desenvolupat.
• Durant la fase de proves, executen diversos escenaris per trencar el programari i trobar molts defectes. (A més, la taxa de defectes aquí és més elevada perquè l'aplicació és nova i s'està avaluant per primera vegada).
• Els desenvolupadors solucionen els defectes i tornen a l'equip de prova per tornar-los a provar.
• L'equip de proves realitza una nova prova dels defectes i executa la regressió.
• Una vegada que es resolguin la majoria dels defectes d’alta gravetat i el programari sembli estable, l’equip de desenvolupament llança la següent versió.

Prova d'execució núm. 2)

• L’equip de proves inicia la segona prova i es realitzen activitats similars com la primera.
• En aquest procés durant la segona prova, es detecten pocs defectes més.
• Els desenvolupadors solucionen els defectes i tornen a l'equip de prova per tornar-los a provar.
• L’equip de proves torna a provar els defectes i el seu rendiment regressió .

Això pot continuar per sempre. Executeu 3, executeu 4 en endavant fins que es detectin tots els defectes del programari i el programari quedi lliure d'errors.

Si volem dibuixar un diagrama de flux per a aquestes activitats, semblarà aproximadament el següent:

A partir del diagrama de flux anterior, podem concloure clarament que les proves poden continuar fins que es detectin tots els defectes del programari.

Però la pregunta és: és possible trobar tots els defectes del programari? Intentem trobar la resposta a aquesta pregunta d'un milió de dòlars :).

Parar quan es detecten tots els defectes: és possible?

La majoria de programari és complex i té un enorme abast de proves. No és impossible trobar tots els defectes del programari, però trigarà per sempre.

Fins i tot després de trobar molts errors al programari, ara ningú no pot garantir que el programari estigui lliure de defectes ara. No hi pot haver una situació en què puguem afirmar amb seguretat que hem completat les proves, que hem detectat tots els defectes del programari i que no té més errors.

A més, el propòsit de les proves no és trobar tots i cadascun dels defectes del programari. La intenció de les proves de programari és demostrar que el programari funciona tal com es pretén trencant-lo o trobant desviacions entre el seu comportament actual i el comportament esperat.

Hi ha defectes il·limitats al programari i, per tant, no és pràctic provar-lo fins que no es detectin tots els defectes, ja que mai no podrem saber quin defecte és l’últim. La veritat és que no podem dependre de trobar tots els defectes del programari per concloure les nostres proves.

Sincerament parlant, les proves són interminables i els cicles de proves continuaran fins que es decideixi quan i on aturar-se. Ara es fa encara més complicat arribar a la decisió d’aturar les proves. Si 'aturar-se quan es troben tots els defectes' no és el criteri per deixar de provar, en quina base s'hauria de decidir?

Decisió de deixar de provar: Criteris de sortida

Intentem ara comprendre: quins són els factors més importants que cal tenir en compte en finalitzar les activitats de prova? Crec que depèn principalment de la decisió d’aturar les proves Temps, pressupost i extensió de les proves.

L'enfocament més comú és aturar-se quan s'esgota el temps o el pressupost o s'executen tots els escenaris de prova. Tanmateix, amb aquest enfocament, comprometrem la qualitat de les proves i això no donarà prou confiança sobre el programari; com?

Vegem amb unexemple.

Escenari de prova:

Suposem que esteu provant un mòdul de programari. Se us ha assignat un pressupost determinat per cobrir-lo. Els terminis del projecte són d’un mes. Els escenaris de prova totals són 200. Vostè és l'únic que prova aquest mòdul.

Escenari núm. 1)

Setmana 1: Trobeu el defecte showstopper / severity 1 el primer dia i tota la prova està bloquejada durant 3 dies. Per tant, no podreu executar cap dels escenaris fins que no es resolgui el defecte de la gravetat 1. Després de perdre 3 dies, es resol el bloqueig i continueu amb la vostra execució.

Al final de la setmana, completareu 20 escenaris amb pocs més importants defectes prioritaris .

Setmana 2: Comenceu a provar el programari posant més èmfasi en la cerca de defectes. Obriu alguns defectes més de la gravetat 1, la gravetat 2 i la gravetat 3 durant la segona setmana i, al final de la setmana, podreu cobrir 70 escenaris.

Setmana 3: Al començament del 3^rdla setmana que es resolen tots els defectes d'alta prioritat, de manera que, juntament amb l'execució d'escenaris pendents, haureu de tornar a provar tots els defectes que hagin aterrat al dipòsit de proves. Continuant amb el bon progrés, cobreix 120 escenaris amb defectes addicionals.

En aquest moment ja s'han trobat i comunicat tots els defectes d'alta prioritat. Per tant, ara només us quedaran defectes de gravetat 3 per trobar.

Setmana 4: A la setmana 4 haureu de tornar a provar la majoria dels defectes oberts i els 80 escenaris restants. Amb això, a finals de la setmana 4, podreu completar fins a 180 escenaris amb tots els defectes de prioritat alta i mitjana corregits i provats de nou.

Posar aquesta informació en forma tabular:

Us heu d’aturar aquí?

El motiu que heu esgotat Temps de prova complet i han informat i solucionat la majoria dels defectes d'alta prioritat. Aturar-vos en aquest punt us donarà confiança sobre el programari? En realitat no es deu a les següents raons:

• Els escenaris no s’executen completament.
• Pocs fluxos ni tan sols es posen a prova una vegada.
• Tots els escenaris que es cobreixen només s'executen una vegada.
• El programari encara té defectes.
• La regressió no està coberta.

Escenari núm. 2)

Setmana 1: Trobareu un defecte de gravetat 1 el primer dia i les proves completes estan bloquejades durant 3 dies. Per tant, no podreu executar cap dels escenaris fins que no es resolgui el defecte de gravetat 1. Després de perdre 3 dies, el bloqueig es resol i continueu amb la vostra execució.

Al final de la setmana, completareu 20 escenaris amb pocs defectes més. Aquesta setmana continua sent la mateixa que l’escenari 1.

Setmana 2: Obriu alguns defectes més de la gravetat 1, de la gravetat 2 i de la gravetat 3 durant la segona setmana, però el focus és cobrir més escenaris per cobrir el retard de la setmana 1. Al final de la setmana, podeu cobrir 120 escenaris.

Setmana 3: Al començament del 3^rdla setmana que se solucionin tots els defectes oberts, de manera que, juntament amb l'execució d'escenaris pendents, haureu de tornar a provar tots els defectes aterrats en un dipòsit de proves. Continuant amb un bon progrés al final, el nombre d'escenaris completats es converteix en 200 amb defectes addicionals.

Ara només podeu informar de defectes de gravetat 2 i gravetat 3.

Posar aquesta informació en forma tabular:

Us heu d’aturar aquí?

Tu tens ha cobert tots els escenaris de proves completament una vegada i han obert alguns defectes importants. Aturar-vos en aquest punt us donarà confiança sobre el programari?

En realitat no es deu a les següents raons:

• Tots els escenaris només s'executen una vegada.
• El programari encara té molts defectes importants.
• La regressió no està coberta.

Podem veure que la qualitat es veu compromesa per sobre de tots dos escenaris. El millor enfocament serà trobar un punt on es cobreixin tots els factors de l’escenari 1 i 2 i la qualitat no es vegi compromesa. Per aconseguir-ho haurem de definir determinats criteris al començament de les proves.

Aquests criteris es denominen criteris de finalització o de sortida. És la resposta a la nostra pregunta: 'Quan deixar de provar?'.

Què són els criteris de finalització o de sortida?

Els criteris de sortida s’avaluen al final del cicle de proves i es defineixen al pla de proves. És el conjunt de condicions o activitats que s’han de complir per concloure les proves.

Els criteris de sortida defineixen la quantitat suficient de proves i quan es poden declarar completades les activitats de prova. Cobertura i els criteris de finalització es combinen per definir els criteris de sortida de les proves.

Què hauria d’estar present als criteris de sortida?

Idealment, Criteris de sortida o aturada es defineixen combinant diversos factors i, per tant, és únic en tots els projectes. Depèn del requisit del projecte i, per tant, s'ha de definir durant la planificació de proves; al començament del projecte. Els paràmetres que s’hi defineixen s’han de quantificar tant com sigui possible.

A continuació, es mostren alguns indicadors a tenir en compte en definir els criteris de sortida en cas de proves funcionals o de sistema. Podeu combinar pocs o tots els factors següents a l'hora de decidir on deixar de provar segons les necessitats del vostre projecte.

Les proves es poden aturar quan:

Requisits:

• S'aconsegueix la cobertura del 100% de requisits.

Defectes:

• S'arriba al recompte de defectes definit / desitjat.
• Tots els defectes o bloquejadors de Show Stop estan corregits i no hi ha cap defecte crític / gravetat 1 conegut en estat obert.
• S'identifiquen i solucionen tots els defectes d'alta prioritat.
• La taxa de defectes cau per sota de la taxa acceptable definida.
• Molt pocs defectes de prioritat mitjana estan oberts i tenen una solució alternativa.
• Molt pocs defectes oberts de baixa prioritat que no afecten l’ús del programari.
• Tots els defectes d'alta prioritat es tornen a provar i es tanquen i els escenaris de regressió corresponents s'executen amb èxit.

Cobertura de la prova:

• La cobertura de la prova s’ha d’aconseguir en un 95%.
• La taxa d’aprovació del cas de prova ha de ser del 95%. Això es pot calcular mitjançant la fórmula
  • (Nombre total de TC aprovats / Nombre total de TC) * 100.
• Es passen tots els casos crítics de prova.
• Es poden fallar els casos de prova del 5%, però els casos de prova fallits tenen poca prioritat.
• S'aconsegueix una cobertura funcional completa.
• Tots els principals fluxos funcionals / empresarials s’executen amb èxit amb diverses entrades i funcionen bé.

Terminis:

• S'ha arribat a la data límit del projecte o finalització de la prova.

Documents de prova:

• Tots els documents de prova / lliuraments (exemple: Informe de resum de la prova ) es preparen, es revisen i es publiquen a tot arreu.

Pressupost:

• S'ha esgotat el pressupost de proves complet.

Reunions 'Go / No Go':

• ' Vés / No vés ' reunió s’ha dut a terme amb els grups d’interès i es decideix si el projecte s’ha de produir o no.

Conclusió:

Fem-ho molt senzill al final.

Respon a les preguntes amb un simple Sí o No.

què s’ha d’utilitzar per obrir fitxers jar

Si obteniu la majoria de respostes com a Sí, significa que podeu deixar de provar en aquest moment. Si la majoria de les respostes són No, significa que heu de comprovar el que falta a les proves i això us pot ajudar a trobar un defecte de producció que s'escapi :)

• S’executen tots els casos de prova almenys una vegada?
• La taxa d’aprovació de casos de prova es defineix?
• S'ha aconseguit una cobertura completa de les proves?
• S’executen tots els fluxos funcionals / empresarials almenys una vegada?
• S'arriba al recompte de defectes decidit?
• Tots els defectes majors d’alta prioritat estan fixats i tancats?
• S'han tornat a provar i tancar tots els defectes?
• S'ha realitzat la regressió per a tots els defectes oberts?
• Heu esgotat el pressupost de les proves?
• Ha arribat el temps de finalització de les proves?
• Es revisen i es publiquen tots els lliuraments de proves?

Sobre l'autor: Aquest és un article convidat de Renuka K. Té més de 11 anys d'experiència en proves de programari.

Espero que aquest article us sigui d’utilitat. També m’agradaria escoltar els vostres pensaments / comentaris sobre el tema.

Bones proves!

Lectura recomanada

• Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
• Prova de programari Treball d'assistent de control de qualitat
• Programa de cursos de proves de programari: pla de formació detallat del curs en línia
• Curs de proves de programari: a quin institut de proves de programari m'he d'afegir?
• Selecció de proves de programari com a carrera professional
• Prova de programari Treball freelance d'escriptor de contingut tècnic
• Algunes preguntes d’entrevistes de proves de programari interessants
• Opinions i ressenyes sobre cursos de proves de programari