Menú

Proves ad-hoc: com trobar defectes sense un procés de prova formal

ad hoc testing how find defects without formal testing process

Proveu El Nostre Instrument Per Eliminar Problemes

El mateix terme ad-hoc implica la manca d’estructura o alguna cosa que no sigui metòdica. Quan parles de proves ad-hoc , vol dir que és una forma de caixa negra o proves de comportament realitzades sense cap procés formal establert.

El procés formal aquí significa tenir documentació com ara documents de requisits, plans de proves, casos de proves i una planificació adequada de les proves pel que fa a la seva programació i ordre de proves realitzades. A més, les accions realitzades durant la prova no solen estar documentades.

Proves ad-hoc

Això es fa principalment amb l'objectiu d'intentar descobrir defectes o defectes que no es poden capturar mitjançant processos tradicionals o formals seguits durant el cicle de proves.

Com ja s'ha entès, l'essència d'aquestes proves resideix en no tenir una forma formal o estructurada de proves. Quan es realitza aquest tipus de tècniques de proves aleatòries, és evident que els provadors ho fan sense tenir en compte cap cas d'ús particular amb l'objectiu de trencar el sistema.

Per tant, és encara més evident que requereix una metodologia de proves tan intuïtiva o creativa el provador sigui extremadament hàbil, capaç i tingui un coneixement profund del sistema. Les proves ad-hoc garanteixen que les proves realitzades siguin completes i sigui particularment molt útil per determinar l’eficàcia del dipòsit de proves.

Lectura recomanada=> Proves exploratòries: com pensar més enllà dels límits de les proves tradicionals?

Què aprendreu:

Comencem amb un exemple de proves ad-hoc

Aquí teniu un exemple de com podem realitzar aquestes proves quan es tracta de l’assistent d’interfície d’usuari.

Posem per cas que heu de crear un pla o una plantilla per realitzar algun tipus de tasca mitjançant aquest assistent d’interfície d’usuari. L’assistent és una sèrie de plafons que contenen dades d’usuari com el nom, la descripció, etc.

A mesura que l’assistent avança: digueu que en un dels panells, s’han d’introduir dades d’usuari, cosa que implica que l’assistent de la IU llança un quadre emergent de context que afegeix les dades associades per completar l’assistent i desplegar / activar l’assistent.

Per provar aquest provador, fa proves regulars com:

com obrir un fitxer XML en Chrome
  • Completeu l'assistent correctament amb totes les dades vàlides i creeu el pla.
  • Cancel·leu l'assistent a mig camí.
  • Editeu un pla creat mitjançant l'assistent.
  • Suprimiu el pla creat i comproveu que no en queda cap.
  • Introduïu un valor negatiu a l'assistent i veureu que es mostren els missatges d'error adequats.

Ara, per l’exemple anterior aquí teniu alguns casos de prova per a proves ad-hoc que es podria realitzar per descobrir tants defectes com sigui possible:

  • Mentre intenteu afegir dades negatives, afegiu certs caràcters especials que no estan restringits per veure si es gestionen correctament. Per exemple, de vegades els mags no restringeixen {o (claudàtors), però en determinades situacions, això pot entrar en conflicte amb el codi basat en l'idioma en què està escrit i provocar un comportament molt poc fiable.
  • Una altra prova és específicament pel que fa a les finestres emergents. Un usuari pot provocar el llançament de la finestra emergent i després provar de prémer el botó de retrocés del teclat. Moltes vegades he observat que, en fer-ho, fa que l’assistent de fons desaparegui completament i que es perdin totes les dades d’usuari que s’han introduït fins al punt de llançament de la finestra emergent.

Característiques de les proves ad-hoc:

Si observeu els escenaris anteriors, veureu característiques molt diferents d’aquest tipus de proves.

Ells són:

  • Sempre estan en línia amb l’objectiu de la prova. Tot i això, són certes proves dràstiques realitzades amb la intenció de trencar el sistema.
  • El comprovador ha de tenir coneixement i coneixement complet sobre el sistema que s’està provant. El resultat d’aquestes proves detecta errors que intenten ressaltar les escletxes del procés de prova.
  • Si mirem també les dues proves anteriors, la reacció natural a això seria que aquest tipus de prova es pugui realitzar només una vegada, ja que no és factible fer una nova prova a menys que hi hagi un defecte associat.

Quan fem proves ad-hoc?

Una pregunta milionària!

La majoria dels equips de proves del temps sempre estan carregats amb massa funcions per provar-les en terminis limitats. En aquest període de temps limitat, hi ha moltes activitats de prova derivades del procés formal que també s'han de completar. En aquestes situacions, les proves ad-hoc troben poca prova.

Tanmateix, per la meva experiència, una ronda de proves ad-hoc pot fer meravelles sobre la qualitat del producte i plantejar moltes preguntes de disseny.

Atès que les proves ad-hoc són més que una tècnica de proves “wild-child” que no s’ha d’estructurar, la recomanació general és que s’ha de realitzar després de fer l’execució del dipòsit de proves actual. Un altre punt de vista és que això es podria fer quan no es poden realitzar proves detallades a causa de menys temps.

Al meu entendre, diria això es poden fer proves ad-hoc gairebé en qualsevol moment: al principi, cap al mig i cap al final. Simplement troba el seu lloc en cada moment. No obstant això, quan s’ha de fer proves ad-hoc per treure el màxim valor, és millor que ho jutgi un provador experimentat que tingui coneixements profunds sobre el sistema que s’està provant.

Quan no executar?

Si la pregunta anterior valia un milió de dòlars, hauria de valer-ne un milió.

Tot i que hem establert l’eficàcia i la fructificació de les proves ad-hoc, com a provador expert i capaç també hem de desxifrar quan no invertir en aquest tipus de proves. Tot i que és a criteri del provador, aquí els teniu algunes recomanacions / exemples quan potser no sigui necessari.

  • Eviteu aquesta prova quan hi hagi un cas de prova per al qual existeixi un defecte. En aquesta situació, cal documentar el punt de fallada del cas de prova i després verificar / tornar a provar el defecte quan es solucioni. Per tant, no serà aplicable aquí.
  • També pot haver-hi certs escenaris on es pugui convidar clients o clients proveu la versió beta del programari . En aquests casos, no s’haurien de realitzar aquestes proves.
  • Un altre escenari és quan hi ha una pantalla d’interfície d’usuari molt senzilla que s’afegeix. Les proves tradicionals positives i negatives haurien de ser suficients aquí per treure el màxim de defectes.

Tipus de proves ad-hoc

Les proves ad-hoc es poden classificar en tres categories a continuació:

# 1) Proves de companys

En aquesta forma de prova, hi haurà un membre de la prova i un membre de desenvolupament que s’escollirà per treballar al mateix mòdul. Just després del el desenvolupador completa la prova d’unitat , el el provador i el desenvolupador seuen junts i treballar al mòdul. Aquest tipus de proves permet veure la funció en un abast més ampli per a ambdues parts.

El desenvolupador obtindrà una perspectiva de totes les proves que realitza el comprovador i el comprovador obtindrà una perspectiva de com és el disseny inherent que l’ajudarà a no dissenyar escenaris no vàlids, evitant així defectes no vàlids. Ajudarà a un a pensar com a l’altre.

# 2) Proves de parells

En aquesta prova, dos provadors treballen junts en un mòdul amb la mateixa configuració de prova compartida entre ells. La idea que hi ha darrere d’aquesta forma de provar és que els dos provadors facin una pluja d’idees sobre idees i mètodes per tenir diversos defectes. Tots dos poden compartir el treball de proves i fer la documentació necessària de totes les observacions realitzades.

# 3) Prova de mico

Aquesta prova es realitza principalment a nivell de proves unitàries. El comprovador analitza dades o proves de forma completament aleatòria per assegurar-se que el sistema sigui capaç de suportar qualsevol bloqueig. Aquestes proves es poden classificar en dues categories:

com es divideix la cadena per caràcter python

Avantatges de proves ad-hoc

Aquesta prova garanteix al provador molta força per ser tan creatiu com sigui necessari.

Això augmenta la qualitat i l'eficiència de les proves de la manera següent:

  • El major avantatge que destaca és que un provador pot trobar el nombre de defectes que en les proves tradicionals a causa dels diversos mètodes innovadors que poden aplicar per provar el programari.
  • Aquesta forma de prova es pot aplicar a qualsevol lloc del SDLC; no només es limita a l’equip de proves. Els desenvolupadors també poden dur a terme aquesta prova, cosa que els ajudaria a codificar millor i també a predir quins problemes es poden produir.
  • Es pot combinar amb una altra prova per obtenir els millors resultats, que de vegades poden reduir el temps necessari per a les proves habituals. Això permetria generar casos de prova de millor qualitat i una millor qualitat del producte en general.
  • No exigeix ​​que es faci cap documentació que impedeixi la càrrega addicional per al comprovador. Un provador es pot concentrar a entendre realment l’arquitectura subjacent.
  • En els casos en què no hi ha molt de temps disponible per provar, això pot resultar molt valuós en termes de cobertura i qualitat de les proves.

Inconvenients de la prova ad-hoc

Les proves ad-hoc també tenen alguns inconvenients. Vegem alguns dels inconvenients que es manifesten:

Com que no està molt organitzat i no hi ha cap documentació obligatòria, el problema més evident és que el comprovador ha de recordar i recordar tots els detalls dels escenaris ad-hoc a la memòria. Això pot ser encara més difícil, especialment en escenaris on hi ha molta interacció entre diferents components.

  • Seguit des del primer punt, això també resultaria en no poder recrear defectes en els intents posteriors si se sol·licita informació.
  • Una altra qüestió molt important que es posa de manifest és la rendició de comptes. Com que això no està planificat / estructurat, no hi ha manera de explicar el temps i l'esforç invertit en aquest tipus de proves.
  • Les proves ad-hoc només han de ser realitzades per un provador molt coneixedor i expert de l’equip, ja que exigeix ​​ser proactiu i intuïtiu en termes de preveure possibles defectes a les zones muntades.

Bones pràctiques per fer aquesta prova més eficaç

Hem analitzat exhaustivament els punts forts i els punts febles associats a aquesta prova.

Idealment, les proves ad-hoc haurien de trobar el seu lloc al SDLC, tot i que, si no s’apropen de la manera adequada, pot resultar costós i perdre un temps valuós de proves. A continuació, es detallen algunes indicacions per fer efectives les proves ad-hoc:

# 1) Identifiqueu les zones propenses a defectes:

Quan tingueu una bona espera per provar un determinat programari, estareu d'acord que hi haurà certes funcions que són més propenses a errors que les altres. Si sou nou al sistema, continueu i comproveu els defectes v / s de les funcions oberts contra ells.

El nombre de defectes d’una determinada característica us mostrarà que és sensible i que heu de triar exactament aquella zona per fer proves ad-hoc. Es demostra que és una manera d’exposar alguns defectes greus amb molt de temps.

# 2) Experiència en construcció:

Sens dubte, un provador que té més experiència és més intuïtiu i pot endevinar on podrien trobar-se els errors en comparació amb algú que no té molta experiència. Diria, amb experiència o no, que depèn de l’individu fer el pas i construir experiència en el sistema que s’està provant.

Sí, els avaluadors experimentats tenen avantatges, ja que les seves habilitats acumulades al llarg dels anys són útils, però els nous avaluadors haurien d’utilitzar-ho com a plataforma per obtenir el màxim coneixement possible per dissenyar millors escenaris ad hoc.

# 3) Creeu categories de proves:

Un cop hàgiu conegut la llista de funcions a provar, reserveu uns minuts per decidir com classificaríeu aquestes funcions i proveu-les. Per exemple, hauríeu de decidir provar les funcions més visibles i les que més s’utilitzen per part de l’usuari abans que qualsevol altra cosa, ja que semblarien fonamentals per a l’èxit del programari.

A continuació, podeu classificar-los segons la funcionalitat / prioritat i provar-los segment per segment.

Un altre exemple en què això és particularment molt important és si hi ha integració entre components o mòduls. En aquests casos, es poden produir moltes anomalies. L’ús de la classificació ajudaria a tocar aquest tipus de proves almenys una o dues vegades.

# 4) Teniu un pla aproximat:

Sí, sí, aquest punt us pot confondre una mica, ja que hem descrit les proves ad-hoc com a proves que no haurien de tenir planificació ni documentació. La idea aquí és mantenir-vos en l’essència de les proves ad-hoc, però, tot i així, teniu algunes indicacions aproximades sobre la forma en què voleu provar.

Un exemple molt bàsic és que de vegades és possible que no recordeu totes les proves que voleu realitzar. Per tant, anotar-los no us perdrà res.

# 5) Eines:

Prenguem un exemple que tots afrontem molt sovint. Moltes vegades, si observeu, la prova de la funcionalitat en si mateixa té èxit, sense que hi hagi discrepàncies en el seu comportament. Tanmateix, els registres darrere de les escenes podrien informar d'algunes excepcions vistes que els verificadors podrien perdre, ja que no obstaculitza l'objectiu de la prova de cap manera.

Aquests podrien ser fins i tot de gran gravetat. Per tant, és molt important per a nosaltres aprendre i eines que ajudaran a identificar-ho immediatament.

# 6) Document per obtenir més defectes:

Una vegada més, entenc que això pot tornar a aixecar les celles. La documentació no ha de ser detallada, sinó només una petita nota per a la vostra pròpia referència de tots els diferents escenaris coberts, la desviació en els passos implicats i registrar aquests defectes per a la categoria de funcions de prova concreta.

Això us ajudarà a millorar el dipòsit de proves general, de manera que podreu decidir com improvisar casos de prova existents o afegir-ne més si cal.

Conclusió

Hem debatut detalladament sobre les tècniques de proves ad-hoc: els seus punts forts, els seus punts febles, les situacions en què seria i no seria beneficiós.

Aquesta és una tècnica de prova que garanteix atendre i satisfer al màxim la creativitat del verificador. En la meva totalitat prova de carrera , Obtinc la màxima satisfacció de les proves ad-hoc, ja que no hi ha límit per innovar i només s’acaba sent més coneixedor.

Dit això, el més important per recuperar tota la informació anterior seria fer-ho determinar com aprofitar els punts forts de les proves ad hoc i fer-ne un valor afegit al procés global de la prova i a la qualitat del producte.

Sobre l'autor: Aquest és un article de Sneha Nadig. Treballa com a responsable de proves amb més de 7 anys d’experiència en projectes de proves manuals i d’automatització.

Realitzeu proves ad-hoc al vostre projecte? Quins suggeriments teniu per aconseguir que les proves ad-hoc tinguin èxit?

Lectura recomanada

^