how tester can think
Escena : En un restaurante, llegó una familia de 3: padres y un niño pequeño. Después de pedir la pizza favorita, la familia se relajó y el niño comenzó a jugar con los palillos colocados sobre la mesa. Le gustaron y decidió cenar solo con palillos.
Anunció su deseo y los padres, ocupados en hablar, estuvieron de acuerdo. Cuando se sirvió la pizza, el niño empezó a usar palillos chinos y varias veces no lograba meterse la pizza en la boca. De repente, los padres lo notaron y le ordenaron al niño que no usara palillos. El niño no convenció porque los padres ya habían acordado su deseo antes.Cuando los padres comenzaron a enseñar acerca de comer pizza solo con cuchillo y tenedor, el niño pequeño cuestionó la creencia, pero yo quiero comerla solo con palillos y ¿por qué está mal? Y mientras usaba palillos chinos cuando no podía comer su pizza favorita, se impacientó y finalmente tiró los palillos y decidió no comer pizza también. Los padres, frustrados también, no pudieron hacer nada y la hora de la cena familiar resultó ser la peor hora del día.
Ahora, reemplace algunas palabras en el párrafo anterior como sigue y vuelva a pensar en ello:
Padres: Equipo de gestión de proyectos que incluye analista de negocios, vendedor, gerente de desarrollo y equipo de arquitectura.
Niño pequeño: Cliente / usuario final
Pizza: producto / aplicación
Palillos: Error
La aplicación más favorita es la única favorita hasta que el usuario no se equivoca y no ve el peor comportamiento de la aplicación. Una vez experimentado, el usuario nunca vuelve a la aplicación. Y por lo tanto, como evaluador, es muy necesario comprender mentalidad del usuario , cómo se espera que se comporte, qué mal puede hacer con la aplicación, cuál podría ser el peor error cometido y mucho más.
La mayoría de las veces, me han preguntado en foros, así como por miembros del equipo interno, sobre cómo replicar la experiencia del usuario durante las pruebas. Mi respuesta siempre ha sido simple: Ser un usuario :)
Aunque es fácil decirlo que implementarlo, es el momento adecuado para que la industria de pruebas de software avance en la dirección de la revolución, donde la experiencia del usuario y los comentarios son más importantes que cualquier otra cosa.
¿Cómo puede pensar un tester como usuario final?
Presentando por la presente algunos ejemplos típicos de comportarse como un usuario final y encontrar sorpresas , He observado durante los últimos días:
#1) Al probar un campo de fecha, cuando un usuario seleccionó o ingresó manualmente el valor de fecha correcto, funcionó bien. Pero cuando el usuario terminó ingresando un valor totalmente incorrecto como 12/00 // y hizo clic en Aceptar, se le presentó un mensaje de error sobre un valor de fecha no válido.
Ahora el usuario no corrige la fecha, pero actualiza la página. ¿Qué debería pasar? Bueno, muchos de ustedes pueden adivinar lo que debería suceder, pero ¿pueden pensar en lo que sucedió con la aplicación? Después de actualizar la página, a un usuario se le presentó un siguiente y el mismo valor también se guardó en una base de datos.

Entonces… ..el probador ha replicado al usuario aquí, ¿de acuerdo?
#2) Al probar una aplicación, donde el flujo de trabajo es enviar varios formularios en una secuencia especial si se sigue el orden, funcionó bien. Pero, ¿qué pasa si el usuario intenta volver al formulario n. ° 3, desde el formulario n. ° 5?
Nuevamente, en lugar de pensar en lo que debería suceder, veamos qué sucedió ...

Tester estaba estupefacto pero se enorgullecía de presentarse como usuario… ¿De acuerdo?
#3) Después de iniciar sesión correctamente, el usuario hace clic en el botón Atrás del navegador. De nuevo, veamos qué pasó ...

Las credenciales deberían haberse limpiado, pero no fue así. Continuando, en esta página de inicio de sesión, un usuario hace clic en el enlace Olvidó su contraseña. Sea claro que el usuario ya había iniciado sesión y había estado en la página de inicio de sesión haciendo clic en el botón Atrás del navegador. El clic en Olvidó su contraseña llevó al usuario a la página de inicio de la aplicación.
El probador se volvió hacia el usuario ... ¿Está de acuerdo?
#4) Después de observar la URL de la página de búsqueda (http: //x.x.x.x: y / # / Search) de la aplicación, el evaluador modificó la URL como http: //x.x.x.x: y / # / Search / test? y puedes pensar que hubiera pasado
conversor de video gratuito para archivos grandes
Bueno, la aplicación falló y de nuevo el evaluador se dirigió al usuario ... Espero que no esté en desacuerdo.
Conclusión
Supongo que, a través de estos ejemplos, he transmitido bastante de lo que quería.
Realmente, probar no significa verificar el flujo de trabajo de la aplicación ni tampoco significa romper la aplicación, pero ciertamente significa comprobar la experiencia del usuario incluso cuando comete los errores.
Sobre el Autor: Esta publicación está escrita por el miembro del equipo de STH Bhumika Mehta. Es líder de proyecto y cuenta con más de 10 años de experiencia en pruebas de software. También aprecia las buenas ideas, las innovaciones y los riesgos. Y, por supuesto, odia el trabajo monótono, las personas y el medio ambiente.
Y sí, convirtamos el tester en nosotros mismos en el usuario final ... ¿Está de acuerdo? :)
Así que ... nos gustaría escuchar más ejemplos como estos de usted y también nos gustaría conocer sus opiniones.
Lectura recomendada
- Tutorial de prueba de GUI: una guía completa de prueba de interfaz de usuario (UI)
- Prueba de cookies de sitios web y casos de prueba para probar cookies de aplicaciones web
- Autenticación de usuario en MongoDB
- Prueba de validación de correo electrónico: cómo probar la funcionalidad de correo electrónico de una aplicación
- Ganar dinero, carrera de pruebas de software y secretos de un evaluador más rico
- 5 cosas que un desarrollador (y evaluador) principiante debe saber sobre las pruebas de software
- Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
- Pruebas ad-hoc: cómo encontrar defectos sin un proceso de prueba formal