Menú

Com pot pensar un provador com a usuari final?

how tester can think

Proveu El Nostre Instrument Per Eliminar Problemes

fer front a situacions difícils a la feina

Escena : En un restaurant, va arribar una família de 3 persones: pares i un nen petit. Després de demanar la pizza més preferida, la família es va relaxar i el nen petit va començar a jugar amb els escuradents posats sobre la taula. Li van agradar i va decidir menjar el sopar només amb escuradents.

Va anunciar el seu desig i els pares, ocupats a parlar, van estar d’acord. Quan es va servir la pizza, el nen petit va començar a utilitzar escuradents i va fallar diverses vegades en aconseguir la pizza a la boca. De sobte, els pares es van adonar i van ordenar al nen petit que no fes servir escuradents. El nen petit no va convèncer, ja que els pares ja havien acordat el seu desig anteriorment.Quan els pares van començar a ensenyar sobre menjar pizza només amb ganivet i forquilla, el nen petit va qüestionar la creença, però vull menjar-la només amb escuradents i per què està malament? I mentre utilitzava escuradents quan no era capaç de menjar la seva pizza preferida, es va impacientar i, finalment, va llençar els escuradents i va decidir no menjar pizza també. Els pares, frustrats tampoc, no van poder fer res i el moment de sopar en família va resultar ser el pitjor moment del dia.

provador com a usuari final

Ara, substituïu algunes paraules del paràgraf anterior pel següent i torneu-ho a pensar:

Pares: Equip de gestió de projectes que inclou analista de negocis, venedor, cap de desenvolupament i equip d’arquitectura.
Nen petit: Client / usuari final
pizza: producte / aplicació
Escuradents: errada

L'aplicació més preferida només és la preferida fins que l'usuari no s'equivoca i no veu el pitjor comportament de l'aplicació. Un cop experimentat, l'usuari mai no torna a l'aplicació. I, per tant, com a provador, és molt necessari entendre-ho mentalitat de l’usuari , com s’espera que es comporti, quin mal pot fer amb l’aplicació, quin pot ser el pitjor error comès i molt més.

La majoria de les vegades, els fòrums i els membres de l’equip de casa m’han preguntat sobre com replicar l’experiència de l’usuari durant les proves. La meva resposta sempre ha estat senzilla: Sigues usuari :)

Tot i que és fàcil de dir que d’implementar, és un moment adequat perquè la indústria de les proves de programari passi cap a la direcció de la revolució, on l’experiència i els comentaris dels usuaris són més importants que qualsevol altra cosa.

Com pot pensar un provador com a usuari final?

Us presento alguns exemples típics de comportament com a usuari final i de trobar sorpreses , He observat durant els darrers dies:

# 1) En provar un camp de data, quan un usuari seleccionava o introduïa manualment el valor de data correcte, funcionava bé. Però quan l'usuari va acabar introduint un valor totalment incorrecte com el 12/00 // i va fer clic a D'acord, se li va presentar un missatge d'error sobre el valor de data no vàlid.

Ara l'usuari no corregeix la data, però actualitza la pàgina. Què hauria de passar? Bé, molts de vosaltres podeu endevinar què ha de passar, però se us ocorre què va passar amb l'aplicació? Després d'actualitzar la pàgina, es va presentar a un usuari un seguit i també es va desar el mateix valor en una base de dades.

proves d

Aleshores ... el verificador ha replicat l'usuari aquí, d'acord?

# 2) En provar una aplicació, on el flux de treball ha d'enviar diversos formularis en seqüència especial si es segueix l'ordre, va funcionar bé. Però, i si l’usuari intentés tornar al formulari # 3, des del formulari # 5?

De nou, en lloc de pensar què hauria de passar, anem a veure què va passar ...

proves de l

El provador estava desconcertat, però sentia orgull de presentar-se com a usuari ... Està d'acord?

# 3) Després d'iniciar la sessió correctament, l'usuari fa clic al botó Enrere del navegador. De nou, vegem què va passar ...

proves de l

Les credencials s’haurien d’haver netejat, però no. Per avançar, en aquesta pàgina d’inici de sessió, un usuari fa clic a l’enllaç He oblidat la contrasenya. Tingueu clar que l’usuari ja havia iniciat la sessió i havia estat a la pàgina d’inici de sessió fent clic al botó Enrere del navegador. Al fer clic a Heu oblidat la contrasenya, l’usuari va anar a la pàgina inicial de l’aplicació.

El provador es va adreçar a l'usuari ... ..Encord?

# 4) Després d'observar l'URL de la pàgina de cerca (http: //x.x.x.x: y / # / Cerca) de l'aplicació, el provador va modificar l'URL com a http: //x.x.x.x: y / # / Cerca / prova? i pots pensar què hauria passat?

passar una matriu a un mètode java

Bé, l'aplicació s'ha estavellat i el provador ha tornat a dirigir-se a l'usuari ... Espero que no hi estigueu d'acord.

Conclusió

Suposo que, mitjançant aquests exemples, he transmès prou del que volia.

Realment, fer proves no significa comprovar el flux de treball de l’aplicació ni tampoc vol dir trencar l’aplicació, però sens dubte vol dir-ho comproveu l’experiència de l’usuari fins i tot quan comet els errors.

Sobre l'autor: Aquesta publicació està escrita pel membre de l'equip de STH Bhumika Mehta. És cap de projecte, amb més de deu anys d’experiència en proves de programari. També valora les bones idees, les innovacions i els riscos. I, per descomptat, odia el treball monotònic, les persones i l’entorn.

I sí, anem a convertir el provador en nosaltres mateixos a l'usuari final ... Està d'acord? :)

Així que ... ... ens agradaria escoltar més exemples com aquests i també voldríem tenir les vostres opinions.

Lectura recomanada

^