Menú

Què és la prova exploratòria en proves de programari (una guia completa)

  • Principal
  • Altres
  • Què és la prova exploratòria en proves de programari (una guia completa)

what is exploratory testing software testing

Proveu El Nostre Instrument Per Eliminar Problemes

Què són les proves exploratòries?

'Proves exploratòries', com el seu nom indica, és un procés d'aprenentatge simultani, disseny de proves i execució de proves. Podem dir que en aquesta prova, la planificació, l'anàlisi, el disseny i l'execució de la prova es fan tots junts i a l'instant.

Aquestes proves consisteixen en explorar el sistema i fomentar el pensament pràctic i en temps real d'un provador.

En aquesta sèrie hem tractat els següents tutorials:

Tutorial # 1: Què és la prova exploratòria en proves de programari (Aquest tutorial)
Tutorial # 2: Ús de tours per assegurar proves exploratòries completes
Tutorial # 3: Proves exploratòries vs proves amb guió
Tutorial # 4: Proves exploratòries amb HP Sprinter
Tutorial # 5: 17 eines de proves exploratòries principals

************************************
Proves exploratòries

Què aprendreu:

Visió general

En termes no normals, les proves exploratòries impliquen el disseny de casos de proves simultanis i l'execució de proves d'una aplicació o sistema sotmès a prova. El comprovador crearà o escriurà una idea de prova per donar-li una direcció i explorarà el sistema mentre prova per crear proves crítiques, pràctiques i útils per provar amb èxit una aplicació.

Això requereix una planificació mínima. Els verificadors prenen contínuament una decisió sobre el seu següent pas d'acció. Depèn completament del procés de pensament del verificador.

De vegades, aquesta prova pot ser més beneficiosa que l'enfocament de la prova formal trobant alguns defectes subtils que falten a les proves formals.

Conscientment o inconscientment, tots els provadors haurien fet proves exploratòries en algun moment de la seva carrera.

Com tots sabem, l’alumne aprendrà millor a través de l’experiència pràctica en lloc d’emmagatzemar la teoria.

De la mateixa manera, un provador només coneixerà l'aplicació millor mentre explora i aprèn totes les funcions que proporciona per si mateix. Sempre és bo tenir una perspectiva de client i de negoci mentre proveu per assegurar-vos que les aplicacions tenen èxit.

Per exemple, si obriu un lloc web de compres, teniu la idea general que aquest lloc web de compres us permetrà comprar seleccionant el producte que vulgueu i pagant el mateix.

Durant aquest procés, és possible que aprengueu que el lloc web us proporciona un aspecte humà virtual que us ajuda en el procés de selecció de productes. També heu comprovat que podeu demanar diversos productes per a proves a casa o que podeu fer el pagament mitjançant punts de recompensa d'alguns bancs, etc.

Com a provador, no només heu de verificar si un sistema funciona com s’esperava, sinó també comprovar si aquest sistema no es comporta d’una manera que no s’esperava.

Poques coses que cal recordar en realitzar aquesta prova:

  • La vostra missió hauria de ser clara.
  • Assegureu-vos de crear notes i informar sobre el que esteu fent i el comportament d’un sistema, que podria ser un error potencial.
  • Apreneu, observeu i, a continuació, creeu nous casos de prova.

Servei recomanat de proves exploratòries

# 1) Digivante Direct

Logotip de Digivante Direct

Digivante Direct realitza proves exploratòries mitjançant la seva xarxa global de verificadors professionals perquè pugueu cobrir les proves en tots els dispositius principals en un període de temps inabastable per qualsevol altre proveïdor de proves o equip intern.

Allibereu més ràpidament, més segur i permeteu a les vostres plataformes digitals oferir una major satisfacció del client i augmentar els ingressos en línia.

Característiques:

  • 24 dies laborables de proves en només 24 hores o 90 dies laborables en 72 hores i un nivell complet i incomparable de proves inassolibles per qualsevol altre mitjà.
  • Baix cost , paquets de preus fàcils d'entendre sense extres ocults.
  • Autoservei portal en línia que no requereix cap compromís continu.
  • Persones reals provant en dispositius reals - Cobertura del dispositiu i del navegador molt més gran que la que podeu aconseguir a casa i tot en un temps de resposta més ràpid.
  • Cobertura completa de proves exploratòries - Reduir el risc i millorar la satisfacció i els percentatges de conversió de l'usuari final, augmentant així els ingressos alhora que redueixen els costos
=> Visiteu el lloc web Digivante Direct

Exemples de proves exploratòries

Exemple 1:

Lloc web del proveïdor de serveis d’atenció domiciliària amb els components següents:

  • iniciar Sessió
  • Serveis
  • Carretó
  • Pagament
  • historial de comandes
  • Assignació de tècnics

Una idea general per començar exploratori la prova serà per iniciar sessió o reservar un servei.

Com cobrir casos de prova?

Casos de proves de proves exploratòries

preguntes i respostes d’entrevistes d’analistes de qualitat pdf

A l’anterior Exemple, la idea és començar amb una funcionalitat basada en els vostres coneixements. A mesura que apreneu i observeu més sobre l’aplicació, podeu governar el vostre següent conjunt de casos de prova.

Exemple 2:

Una vegada em van incloure en un petit projecte que consistia a afegir un nou fons d'inversió a la sol·licitud. La meva tasca consistia a provar l'aplicació per assegurar-me que el nou fons d'inversió estigui disponible per a la compra dels usuaris i comprovar si la valoració associada és correcta. Només tenia 2 dies per completar la prova.

En rebre el termini limitat i la severitat de les proves, vaig utilitzar l'enfocament exploratori de les proves. El meu objectiu era provar noves funcions i trobar infraccions dels requisits de compatibilitat.

L'objectiu esmentat es va convertir en el meu estatut per a aquesta sessió de proves.

Durant aquesta prova es van desenvolupar els casos de prova següents:

  • Proves per assegurar-se que el nou fons d'inversió s'ha afegit a l'aplicació.
  • El nou MF es compra amb èxit.
  • La valoració del nou MF és correcta.
  • Vaig intentar comprar un nou MF per a una cartera existent.
  • Es pot afegir un nou MF a totes les carteres?
  • Impacte del nou MF en una valoració de l'existent.
  • Així, en altres proves es van evolucionar casos.

Vaig preparar notes i informes durant les proves per discutir la meva observació amb el BA i el client implicat.

L’estratègia fonamental de les proves exploratòries és tenir un pla d’atac. Comenceu a provar amb la vostra idea i improviseu nous casos de prova basats en el vostre coneixement i observació.

Exemple 3:

Proves exploratòries del lloc web IRCTC

=> Feu clic aquí per descarregar els exemples de casos de proves de proves exploratòries del lloc web IRCTC.

Enfocament de proves

  • Feu servir heurístiques per guiar les proves.
  • L'execució de casos de prova i la creació de casos de prova van de la mà.
  • Els casos de prova continuen evolucionant en funció de l’observació i l’aprenentatge dels provadors.
  • Diferents tècniques de proves com Anàlisi del valor límit , es poden aplicar proves d'equivalència, etc. a ET.
  • L’ET basat en sessions es pot utilitzar per fer-lo més estructurat i enfocat.
  • Els provadors poden derivar idees però mai s’allunyen de la vostra missió.
  • Les proves ET no utilitzen scripts, sinó que depenen de la intuïció, l'habilitat i l'experiència del provador.

Beneficis

Els avantatges d’aquesta prova inclouen:

  • Promoure el pensament en temps real i ajuda a descobrir més defectes.
  • Promoure casos d’ús i proves basades en escenaris.
  • Documentació mínima, proves màximes.
  • Es posa més èmfasi en aprendre i ampliar l’horitzó d’un provador.
  • Eviteu el treball duplicat.
  • Útil quan voleu auditar el treball d'altres provadors.

Demèrits

A continuació es detallen els desavantatges:

  • Les proves depenen de l'experiència, l'habilitat i el coneixement del provador.
  • Necessiteu temps per aprendre l'aplicació. És més probable que es perdi el provador si en sap menys sobre l’aplicació.
  • No és adequat per a projectes amb un temps d'execució llarg.

Proves exploratòries basades en sessions

Tot i que realitzen proves exploratòries, és molt difícil que els verificadors expliquin quant ha provat i sobre quina base.

Bàsicament, és difícil quantificar la feina i el temps dedicat. No obstant això, en tots els projectes, hem de proporcionar mètriques, estimacions i informe de progrés als responsables d’equip i als gestors. Com diu la dita: 'si no el podeu quantificar, no el podeu gestionar'.

Les proves basades en sessions són un enfocament basat en el temps per realitzar aquestes proves que ajuden a la gestió i el seguiment. Inclou una sessió de proves dedicada amb temps, sense interrupcions de correu electrònic, telèfon, missatges, etc.

Enfocament:

Les tasques de proves es divideixen en sessions.

A continuació es mostren els components de les proves basades en la sessió (SBT):

  • Missió: La missió crida el propòsit de la sessió i, en certa manera, proporciona el focus al comprovador. També inclourà una durada del temps de la sessió.
  • Carta: Inclou l'abast de les proves. Bàsicament, una agenda que detalli els objectius que cal completar durant la sessió.

Exemple de carta de proves per a la funcionalitat d'inici de sessió del lloc web del servei d'atenció a casa:

Exemple de Carta de proves per a la funcionalitat d

  • Sessió: Sessió de proves predefinida sense cap interrupció. Cada sessió pot tenir la durada següent:
    • 'Curt' (60 minuts)
    • 'Normal' (90min)
    • 'Llarg' (120 min)
  • Informe de sessió: Incloeu notes i informes lleugers per proporcionar mètriques als líders i als administradors. Ofereix detalls sobre la sessió de charter restant o feta, el temps de configuració de la sessió, l'escenari provat, sobre el procés de prova, una llista d'errors i problemes trobats i altra informació per a les mètriques.
  • Session de-brief: Una breu reunió o stand-up entre el comprovador i el responsable / responsable de proves per revisar els resultats de la sessió de prova.

Els administradors poden obtenir les mètriques següents basades en l'informe de sessió:

  • El nombre de sessions completades i restants.
  • El nombre d'errors reportats.
  • Temps dedicat a la configuració de la sessió.
  • Temps dedicat a les proves.
  • Temps dedicat a analitzar problemes o problemes.
  • Funcions cobertes.

Per resumir l'anterior:

SBT permet la rendició de comptes, és una prova exploratòria i ofereix una millor gestió del temps dedicat a les proves. També augmenta la productivitat i proporciona una millor comprensió de la detecció d’errors. És una manera fantàstica de proporcionar mètriques als líders d’equip i als administradors per comprovar el progrés del projecte.

Proves exploratòries basades en parelles

La prova de parells és un enfocament en què dues persones posen a prova la mateixa cosa / funció de l'aplicació alhora compartint un PC. Comparteixen contínuament els seus pensaments i idees. Durant aquesta prova, una persona s’encarrega del teclat mentre que l’altra suggereix casos de proves i en pren nota.

Sempre és útil tenir una bona comunicació entre els socis perquè tots dos siguin conscients del que es fa i del perquè. Un parell en què la força dels verificadors complementa mútuament la seva debilitat es considera un grup fort.

Aquest emparellament beneficia tant les parts com cadascú pot aprendre alguna cosa de la seva parella. També és una bona manera d’entrenar nous recursos combinant-los amb recursos experimentats.

Avantatges de les proves de parells

  • Ajuda un provador a centrar-se en la tasca que es fa.
  • Fomenteu la confiança i el respecte mutu entre els socis.
  • La pluja d’idees entre provadors aparellats sol conduir a idees més constructives.
  • Eviteu la visió del túnel.
  • Hi ha menys possibilitats que altres els interrompin.

Tècniques d’assaig exploratori

Tours: És una tècnica senzilla que permet a un provador utilitzar la seva imaginació i pensar-se com un turista que explora la ciutat que visita. Aquí una aplicació per provar és la ciutat i els provadors són els turistes. És molt difícil explorar tota la ciutat tret que tingueu molt de temps i diners a la mà, de manera que un turista ha de tenir un pla amb un objectiu determinat.

Un turista pot fer les següents excursions:

  • Visita guiada - Prova de la característica destacada de l'aplicació. Utilitzeu escenaris basats en l'usuari.
  • Explorant la història de la ciutat - Proveu les funcions antigues d'una aplicació.
  • Gira de diners, el que significa assegurar-se que totes les funcions crítiques en referència al client o client es comproven i funcionen correctament.
  • Recorregut per la criminalitat - Introduïu dades no vàlides i proveu escenaris negatius.
  • Recorregut pel carreró - Proveu les funcions menys utilitzades de l'aplicació.
  • Avorrit recorregut - Dediqueu un temps mínim a cada pantalla de l’aplicació, empleneu els camps mínims i agafeu el camí més curt. Això us ajudarà amb el valor per defecte i les proves de validació.

Mentre feu un recorregut, sempre teniu l’opció de fer qualsevol ruta. Podeu navegar pel programari i trobar un camí únic per provar la funció.

A continuació es mostren alguns consells / trucs que podeu utilitzar a ET:

  • Divideix l'aplicació en mòduls i bifurca mòduls en diferents pàgines. Inicieu el vostre ET des de les pàgines. Això donarà la cobertura adequada.
  • Feu una llista de comprovació de totes les funcions i marqueu una marca quan estigui coberta.
  • Comenceu amb un escenari bàsic i, a continuació, milloreu-lo gradualment per afegir més funcions per provar-lo.
  • Proveu tots els camps d'entrada.
  • Proveu el missatge d'error
  • Proveu tots els escenaris negatius.
  • Comproveu la GUI amb els estàndards.
  • Comproveu la integració de l'aplicació amb altres aplicacions externes.
  • Comproveu si hi ha una lògica empresarial complexa.
  • Intenteu fer el pirateig ètic de l'aplicació.

Els factors que afecten l’ET són els següents:

  • L'objectiu del projecte
  • Estratègia de proves
  • L'objectiu de les proves d'una fase concreta
  • Eines i instal·lacions disponibles
  • Paper i habilitats dels provadors
  • Temps disponible
  • Suport a la gestió
  • Suport entre iguals
  • Recursos disponibles (materials d’estudi, condicions de proves, etc.)
  • Interès dels clients
  • Comprensió del producte.
  • La IU de l'aplicació
  • La funcionalitat de l'aplicació
  • Resultats de proves anteriors
  • Riscos associats a l'aplicació
  • Defectes anteriors
  • Canvis recents
  • Tipus de dades que s’utilitzaran per fer proves
  • Tipus d’usuari que l’utilitzarà

En lloc de preguntar als provadors què han de presentar-se, deixem el criteri del provador per decidir què volen provar i com volen provar-ho.

Diferència entre les proves exploratòries i les proves ad-hoc

No confongueu ET amb Prova ad-hoc .

  • Les proves ad-hoc es refereixen a un procés de cerca de defectes sense guions, no planificats i improvisats, mentre que les proves exploratòries són una metodologia reflexiva per a les proves ad-hoc.
  • La prova ad hoc és un mètode de prova i èxit per trobar un error mentre que ET no ho és. En l'enfocament ET, un provador coneix el sistema mentre explora i, finalment, evoluciona les proves utilitzant els coneixements adquirits.
  • Les proves ad-hoc són una activitat no estructurada, mentre que l'ET és una activitat estructurada.

Proves automatitzades exploratòries (EAT)

Les proves automatitzades exploratòries són un mètode que ajuda un provador a racionalitzar la reproducció i la notificació d’errors, la recopilació d’instantànies i la preparació d’un futur procés de regressió. És un procés que combina proves d'automatització amb proves exploratòries.

Hi ha dos tipus d’enfocament EAT:

  • MENJA passiva
  • Menjar actiu

MENJA passiva

L’EAT passiu també el pot realitzar un sol provador o en parell. En aquesta metodologia, normalment, una eina que captura i registra totes les activitats realitzades per un recurs de prova i que s’instal·la al PC del recurs.

L’EAT passiu és similar a l’ET que es realitza manualment, ja que no hi ha cap canvi en la manera en què s’executen les proves a part d’elaborar el resultat de la prova en funció de la sessió capturada. Aquests resultats de les proves es poden utilitzar per informar i recrear accions registrades més endavant.

L'eina de vídeo instal·lada ajuda un provador a enregistrar casos de proves i informar de defectes.

També té pocs avantatges com:

  • Proporciona passos clars per reproduir els errors.
  • La reproducció de defectes és més fàcil fins i tot quan l’informador de defectes no està disponible.
  • Elimineu els conflictes entre l'equip de proves i desenvolupament quan s'informi d'un error intermitent.
  • Ajuda a fer proves de rendiment obtenint el temps de resposta del sistema en el moment concret.

A continuació, es mostren alguns altres punts que cal tenir en compte abans del Passive EAT:

  • Es recomana realitzar una prova pilot abans d’adaptar completament l’eina per a EAT automatitzat. Per assegurar-se que el temps necessari per redissenyar els registres de prova creats durant la sessió de prova no sigui més que l'execució de la prova. Si és així, l’equip ha de prendre una decisió mútua sobre el següent:
    • Si en absolut es necessita automatitzar les proves per al projecte concret.
    • Si cal canviar l’eina que s’utilitza.
    • Si es pot optimitzar el rendiment de l’eina que s’utilitza.
  • L’eina que s’utilitza per realitzar EAT automatitzada s’ha d’instal·lar a tots els recursos de prova implicats en les proves. També és una bona idea involucrar els desenvolupadors, cosa que es pot aconseguir donant als desenvolupadors VPN o accés remot a màquines de prova o instal·lant l'eina a l'entorn de desenvolupament.
  • Sempre és una bona idea tenir l’objecte GUI de l’aplicació organitzat a l’eina de prova de manera que, quan arribi el moment d’analitzar l’error o un problema, l’objecte es pugui reconèixer a causa d’un nom significatiu.
  • És una pràctica fantàstica donar un nom significatiu a l’objecte GUI utilitzat a AUT i mantenir-los organitzats per a un ús posterior.

Ara, passem al segon enfocament.

Menjar actiu

Es recomana realitzar Active EAT amb proves de parells. En aquest enfocament, les proves basades en paraules clau s’utilitzen de forma sincronitzada amb les proves de sessió. Un provador crea l'script de prova automatitzat i el segon executa els scripts de prova creats pel primer provador.

La creació d’escriptures de proves d’automatització en aquest enfocament adopta un camí diferent al de les proves convencionals. Els scripts de prova automatitzats es fan durant les proves i el que s’ha descobert en les proves anteriors determina el seu disseny.

S'executa una fase de tancament al final de la sessió de proves. I hauria de tenir les tasques següents:

  • Els verificadors implicats haurien d'intercanviar rols de manera que el recurs de prova que ha creat l'script de prova tingui l'oportunitat de tornar a executar-los per confirmar la fiabilitat i la robustesa del conjunt creat.
  • Cal proporcionar una breu descripció juntament amb poques característiques identificatives per a cada script de prova automatitzat.
  • Cal definir un criteri per identificar quins scripts de prova automatitzats es poden utilitzar per a la prova de regressió.

Avantatges de menjar

  • Al començament de cada sessió, s'executen scripts de prova automatitzats ja creats, millorant així la cobertura de la prova cada cop.
  • Millor notificació d’errors i documentació per a la reproducció de defectes.
  • EAT proporciona proves i documentació suficients perquè els grups d'interès puguin veure el progrés.

Tipus de proves exploratòries

A continuació es detallen alguns tipus d’ET:

1) Estil lliure I:

Exploració d'aplicacions en estil ad-hoc.

En aquest tipus d’ET, no hi ha regles, no hi ha cap compte de cobertura, etc. No obstant això, aquest tipus de proves és bo quan necessiteu familiaritzar-vos amb l’aplicació ràpidament, quan vulgueu verificar el treball dels altres provadors i quan voleu investigar un defecte o fer una prova ràpida de fum.

2) ET basat en escenaris:

Com el seu propi nom indica, les proves realitzades es basen en escenaris. Comença amb escenaris d’usuaris reals, escenaris d’extrem a extrem o escenaris de prova. Després de les proves inicials, els provadors poden injectar variacions segons el seu aprenentatge i observació.

Els escenaris són com una guia genèrica sobre què fer durant ET. Es recomana als provadors que exploren diversos camins possibles mentre executen un escenari per garantir tot el camí possible per al treball de funcions. Els verificadors també s’han d’assegurar de reunir tants escenaris com sigui possible de diferents categories.

3) Estratègiabasat en ET:

Tècniques de proves conegudes, com ara l’anàlisi del valor límit, la tècnica d’equivalència i la tècnica basada en el risc, que es combinen amb proves exploratòries. Per a aquest tipus de proves es designa un provador experimentat o un provador familiaritzat amb l’aplicació.

Proves exploratòries àgils

Fins i tot si no heu treballat en un entorn àgil, estic segur que n'haureu llegit o sentit parlar a causa de la seva creixent popularitat. La metodologia àgil té uns sprints curts i uns terminis ajustats, cosa que dóna un parell de setmanes a l’equip per acabar de planificar, estimar, desenvolupar, codificar, provar i publicar.

Les proves exploratòries es fan útils en uns terminis tan ajustats, ja que en aquest enfocament de proves es posa èmfasi en el resultat ràpid i útil. Un cop hàgiu entès el requisit, podeu començar a provar en funció de la vostra experiència i coneixement.

Un cop us familiaritzeu amb les funcions i el comportament de l'aplicació, podeu dissenyar més casos de prova per validar la funcionalitat de l'aplicació i detectar errors no planificats. Com que es tracta d’un enfocament de proves d’estil lliure, cal documentar-ho tot. Tot i això, heu de mantenir notes i un breu informe sobre el que heu provat, els errors i els problemes trobats, etc.

Mèrits d’exploració a l’àgil

  • Proporcionar comentaris als desenvolupadors tan aviat com sigui possible.
  • Es descobreixen una varietat més àmplia de defectes.
  • Un grup divers d'un recurs, com ara desenvolupadors, provadors, BA, dissenyadors, pot realitzar ET ja que no hi ha casos de prova amb guió i cadascun aporta una perspectiva diferent.
  • L’escoltisme fet a ET ajuda a explorar nous territoris i a exposar errors crítics.
  • En cas de codificació iterativa d’una aplicació, ET es pot centrar en provar noves funcions mentre que l’automatització fa proves de regressió i compatibilitat amb versions anteriors.
  • En cas de requisit inestable, ET pot ajudar a provar nous requisits en un termini limitat.

Punts per recordar:

1. Requereix diferents habilitats: Els provadors que realitzen ET necessiten tenir bones habilitats d’escolta, lectura, pensament i informes. Cal tenir experiència en el domini, ja que no hi ha scripts ni casos de prova.

2. De vegades és difícil notificar un error: Mentre estem en un flux ET, és possible que ens trobem amb un defecte, però és possible que no el puguem reproduir. Això es deu al fet que no seguim els passos de les proves i és possible que oblidem els passos exactes per reproduir aquest problema.

3. Es pot fer com a activitat recreativa: Personalment faig ET quan vull un descans del meu cicle d’execució de proves regulars. Però molts equips tenen ET com una fase separada del seu cicle de proves.

4. Es pot fer per a totes les fases de proves: Podem implementar ET abans de començar qualsevol fase de proves. Podeu realitzar ET fins i tot abans de la fase de proves funcionals.

5. Comentaris ràpids: ET requereix informació ràpida sobre els problemes i les anomalies trobades.

6. Pensament crític i idees diverses: Aquesta prova requereix un pensament crític. Els avaluadors haurien de ser capaços de reproduir, revisar i expressar les seves idees d’una manera lògica. Un provador pot implementar la seva experiència en les diverses tecnologies i dominis en què van treballar.

Com pensar més enllà dels límits de proves tradicionals en proves exploratòries

'Aprecio molt la vostra preocupació pel producte i ens feu útils des d'una perspectiva comprensiva de l'usuari final. Serà molt útil. Gràcies per la bona feina i continueu així !!! ”

Aquest va ser l’últim correu electrònic d’una cadena de correu electrònic amb 21 correus electrònics del nostre client. Era mitjanit i el llançament del producte es va retardar a causa d’un error crític que vam trobar. Podríeu pensar, què hi ha de nou en això? Pot passar moltes vegades. Però, això va ser molt diferent, ja que l'error crític que vam informar no va ser el resultat d'un cas de prova documentat.

Després de completar proves de regressió per última vegada aquell vespre, només jugava amb el producte. Què vol dir això? Ets lliure de fer allò que no se suposa que hauries de fer. Basat en la meva experiència i coneixements del projecte, tenia algunes idees sobre com provar el producte a part del nostre dipòsit de proves típic, va trucar Proves exploratòries .

A les proves exploratòries realitzades es va trobar un error crític relacionat amb un problema de bloqueig del servidor mentre es feia quelcom inesperat.

Com que sóc fan de les proves exploratòries, m'encanta explorar el producte de diferents maneres. Per a mi, la definició de programari és:

'Ha de fer el que se suposa que ha de fer i no ha de fer el que no s'ha de fer'.

Procés de proves exploratòries

pl sql preguntes d’entrevistes amb respostes

Limitar els límits de les proves per comprovar si els productes que se suposa que funcionen funcionen com a provador incomplet. De fet, la vida d’un provador comença quan finalitzen les proves de regressió documentades i s’actualitzen els resultats. Mirar els productes des de diferents perspectives i comprendre els requisits dels usuaris finals en diferents escenaris fan una gran diferència. Per tant, avui entenem junts com es pot fer aquesta diferència:

Com mirar un producte des de diferents perspectives?

proves exploratòries

# 1. Comprendre el client / usuari final

Les proves de programari consisteixen a comprovar la qualitat del producte en termes de satisfacció del client. Com coneixes el punt de vista d'un client? La resposta és senzilla: heu de ser el client. D'acord, deixeu-me fer una correcció. Ser client no serà suficient. Heu d’entendre com vol gestionar el producte el client. No hi ha dos clients que hagin comprat les mateixes matèries primeres que prepararan la mateixa recepta. Sí, el producte que desenvolupem o lliurem és una matèria primera per a les empreses dels clients i tenen una mentalitat diferent mentre l’utilitzen.

Com a provador de programari, hem de comprovar la finalitat del producte i no l’objecte o l’aspecte del producte.

Deixeu-me donar-vos alguns exemples pràctics de la vida real:

  • Les tisores mai es limitaven només a tallar paper. El tall és el propòsit i no el paper (objecte).
  • Els telèfons mòbils mai no es limitaven només a trucar, sinó que “poder trucar” sempre ha estat el propòsit bàsic.
  • Les caixes d’emmagatzematge s’utilitzen per emmagatzemar, però la seguretat del material emmagatzemat és tan important com l’emmagatzematge.

La comprensió dels grups d'interès i una àmplia gamma de les seves expectatives hauria de ser la base de les proves exploratòries.

# 2. Una mentalitat

Mentre busqueu (diguem-ne) un anunci d’ocupació laboral, veieu aquest premi i entre les pàgines amb la lletra en negreta? La majoria de nosaltres no (creieu-me, és cert). Perquè hem indicat a la nostra ment que busqui allò que sigui útil o que es comprovi. Qualsevol altra cosa no serveix de res, de manera que la ment ens nega a reconèixer-ho.

Obriu la ment i no fixeu cap expectativa quan comenceu a explorar un producte . Recordeu sempre que no està bé si el producte està fent el que se suposa que ha de fer. També és important que no faci el que no se suposa que ha de fer.

Recordo un exemple clàssic:

A Linux, l’ordre ‘cat’ s’utilitza per comprovar el contingut d’un fitxer i l’ordre ‘ls’ per comprovar el contingut del directori. Treballant amb Linux i fent proves de programari durant cinc anys, mai no vaig pensar a fer gat perquè la meva ment estava decidida; si necessitava contingut de dir, haig d’utilitzar ‘ls’. Això va funcionar, però el revers de l’expectativa és que el producte no s’havia de comportar com no se suposava, estava equivocat. Un dels nostres clients, que no coneixia bé Linux, va fer un error per error i el sistema va fallar. Hem pagat per aquesta mentalitat.

Estigueu sempre a punt per equivocar-vos amb el programari, perquè això és el que farà l'usuari final. Per provar el programari, heu estat entrenat, però l'usuari final no estarà tan entrenat com vosaltres o no serà tan expert en tècniques com vosaltres. A més, farà qualsevol cosa amb el programari quan tingui problemes.

Penseu en aquests escenaris i proporcioneu comentaris sobre proves. La vida del programari i la vostra (com a provador) canviaran.

# 3. Conèixer els competidors

Mentre provava alguna aplicació de programari per al vostre client, heu intentat conèixer i comprendre altres programes amb el mateix propòsit? Alguna vegada heu suggerit algunes funcions útils que heu observat en el producte d'un competidor? No cau en la nostra descripció de feina, és la resposta típica. Però, coneixeu l’avantatge de fer-ho?

Aquí hi ha alguns exemples de la vida real per fer-vos entendre el punt:

  • No us agrada el dissenyador que no només us cusirà el vestit, sinó que també us proporcionarà més informació sobre els accessoris a joc?
  • No us agrada la marca de pizzes que no només fabrica pizzes fantàstiques, sinó que a casa els reparteix a temps?
  • No us agrada el fotògraf que no només fa bones fotografies, sinó que suggereix un altre tipus de marcs per a la sessió de fotos?

Tothom vol tenir alguna cosa extra pel que paga. La nostra anàlisi de programari competitiu pot funcionar de la mateixa manera. Al client sempre li agrada escoltar suggeriments valuosos, principalment suggeriments comparatius per fer el producte més útil o comercialitzable.

A més, aquest tipus de comparació i anàlisi de la mateixa gamma de productes fa que la nostra anàlisi sigui més potent i, finalment, creem un tresor al qual podem retrocedir en qualsevol moment i trobar alguna cosa útil.

Conclusió

Exploratory no té una manera convencional de provar, però és una manera molt potent de provar.

Treu el pensament fora de la caixa d'un provador i els anima a presentar casos pràctics i en temps real per trobar un defecte. La seva naturalesa lliure li proporciona un avantatge respecte als altres tipus de proves i es pot realitzar en qualsevol lloc, ja sigui un projecte amb Agile o cascada o qualsevol altre projecte que requereixi una documentació mínima.

L’èxit de les proves exploratòries depèn de nombrosos intangibles, com l’habilitat d’un provador, la capacitat de crear casos de proves efectius, la seva experiència i l’habilitat de seguir el seu sentiment intestinal.

És imprescindible recordar que l’ET és un procés adaptatiu més que predictiu i és fonamental mantenir un equilibri saludable entre les proves exploratòries i les proves guionitzades o periòdiques.

Sou un provador que té experiències típiques de proves exploratòries? Estem esperant per escoltar els vostres pensaments. No dubteu a compartir-los a la secció de comentaris següent.

Pròxim tutorial núm. 2: Com s'utilitzen els recorreguts per assegurar una prova exploratòria completa

Lectura recomanada

^