Introducción
Test IO se compromete a apoyar el crecimiento de los probadores. Para asegurarnos de que tu carrera de pruebas sea próspera, hemos decidido compartir contigo los errores más comunes que cometen nuestros probadores durante los primeros días de su carrera como probadores. Incluso los probadores experimentados a veces cometen errores y aprenden de ellos.
Es muy tentador probarlo todo cuando estás realizando pruebas, incluso algunos pasos inusuales que un usuario normal nunca haría. Cuando sientas esta urgencia, detente antes de enviar un informe de error. Piensa si tus pasos son un comportamiento normal de un usuario o si el error que encontraste será interesante para nuestros clientes. Siempre piensa si tu error afectará el flujo normal del usuario.
Veamos algunos ejemplos de los errores más comunes que hemos recopilado para ti.
Probar la Suscripción por Correo Electrónico usando un correo al que no tienes acceso
A menudo, nuestros probadores desean comprobar si la suscripción por correo electrónico o el flujo de registro acepta correos electrónicos inválidos. Comprobar si el servidor acepta correos electrónicos inválidos está perfectamente bien y es una de las acciones útiles para nuestros clientes, pero antes de proceder con tal práctica, asegúrate de entender la diferencia entre correos electrónicos inválidos y no existentes. Algunos podrían decir que es lo mismo, pero no lo es. Lee este artículo para comprender qué son los correos electrónicos inválidos.
Por otro lado, los correos electrónicos que no existen representan aquellos que no fueron creados por ti (ni por nadie más) y, por lo tanto, no existen en el sistema. Un intento de validar un correo electrónico que no existe probablemente no provocará ninguna reacción por parte del servidor, ya que se considerará válido si sigue el patrón correct de un correo electrónico. Este comportamiento es esperado y no se considera un error.
La solución:
Si estás probando con correos electrónicos comerciales, DEBES usar una bandeja de entrada existente. De esta manera, no enviaremos solicitudes inválidas a Gmail, Outlook u otros proveedores de correo electrónico.
Si deseas probar la validación, debes usar correos electrónicos del equipo de calidad (qa.team). Dado que todos los nombres de usuario válidos del equipo de calidad existen, los probadores nunca enviarán una solicitud a una bandeja de entrada inexistente, por lo que solo probarán la validación en sí.
Para entornos de preparación (staging), siempre se debe utilizar correos electrónicos en qa.team para el registro regular (a menos que el cliente indique lo contrario).
Para validaciones de correos electrónicos inválidos, utiliza los ejemplos compartidos en este artículo o crea tu propia combinación que siga el mismo patrón.
Informar errores relacionados con la validación del navegador
La validación del navegador representa la validación de entrada HTML realizada por el navegador en función de atributos dentro del elemento de entrada.
Aquí tienes un ejemplo de la validación del navegador HTML 5 de la entrada de correo electrónico:
<input type="email" id="email" pattern=".+@test\.io" size="30" required>
Si ves algo similar, significa que hay una validación del navegador implementada y que esa validación no se realiza mediante JavaScript.
Uno de los ejemplos más comunes de validación del navegador es mostrar una línea roja ondulada debajo de la palabra mal escrita que ingresaste en el campo del formulario.
Informar este tipo de errores no está dentro del alcance del ciclo de pruebas ejecutado por Test IO, y estos errores serán rechazados.
La solución:
Cuando te preguntes qué tipo de validación de entrada está implementada por el cliente para el entorno particular que estas probando (sitio web), haz clic con el botón derecho en la página y luego haz clic en "Ver código fuente de la página". Si observas el código
<input type="email"...>, significa que el campo de correo electrónico está validado por el navegador y que no debes informar este error en la prueba.
Realizar pruebas sin habilitar el proxy cuando se requiere en las instrucciones de la prueba
A veces, nuestros probadores no leen detenidamente las instrucciones de la prueba, lo que provoca que sus errores sean rechazados o, en el peor de los casos, una advertencia de nuestro Equipo de Cumplimiento. Uno de los errores más comunes es cuando los probadores no utilizan un proxy cuando es necesario. Hicimos una pequeña investigación y aquí está cuál fue el problema para los probadores.
En las pruebas recurrentes, los probadores leen las instrucciones de la prueba una vez, y cuando llega la siguiente prueba del mismo cliente, para el mismo producto, los probadores piensan que la estrategia de prueba debe ser la misma y que leer las instrucciones sería una pérdida de su valioso tiempo. Ahí es cuando cometen el error. El mismo título de la prueba no significa que el acceso al entorno sea el mismo camino.
Muchas veces, nuestros clientes quieren separar el tráfico que causan nuestros probadores del tráfico que realizan los usuarios reales. En tales casos, utilizamos un proxy. Otro caso es obtener acceso al entorno de preparación que está bloqueado para cualquiera que no tenga un pase adecuado: proxy habilitado. Si el probador no habilita el proxy, el entorno de preparación mostrará errores 403 o 1020. Informar tales errores provocará rechazos por no seguir las instrucciones de la prueba.
La solución:
Cuando aceptas participar en un ciclo de prueba en el que se requiere el uso de un proxy para acceder al entorno a ser probado, debes seguir las instrucciones de la prueba de manera precisa, o los errores que encuentres no se considerarán legítimos.
Actualizar errores de contenido y visuales a errores funcionales para que estén dentro del alcance de la prueba
A veces, nuestros probadores, sin ninguna intención, actualizan todos los errores de contenido y visuales a errores funcionales porque no tienen la experiencia para determinar qué tipo de errores exactamente deben actualizarse a funcionales. Como resultado, reciben rechazos. Muchas veces, esos rechazos son por motivos de "fuera de alcance", lo que significa que la calidad y el rango del probador sufrirán enormemente.
La solución:
Concéntrate en aprender la diferencia entre errores de contenido, visuales y funcionales. Entiende que si los errores de contenido y visuales no impiden la funcionalidad del producto, o si existe una solución intuitiva, no debes informarlos como errores funcionales.
No actualizar el sistema operativo del dispositivo antes de aceptar un ciclo de prueba Beta
Esta práctica está bien documentada, no solo por nuestros novatos, sino también por nuestros probadores experimentados. En su mayoría, no es intencional. Nuestros probadores participan en muchas pruebas a lo largo de una semana y a veces olvidan registrarse para probar versiones Beta del sistema operativo.
La solución:
Es humano cometer errores, pero asegúrate de leer siempre las instrucciones de la prueba, ya que contienen información importante sobre el dispositivo solicitado y el sistema operativo Beta.
En los casos en que se requiera la versión Beta del sistema operativo, no debes probar el producto con la versión oficial, sino con la versión Beta.
Seleccionar el dispositivo incorrecto en el informe de error
En ocasiones, los probadores quieren ser los más rápidos en informar errores. Cuando hacen esto, a veces eligen el dispositivo incorrecto por error. Si no cambian al entorno correcto antes de que el líder del equipo revise su informe de error, buenos errores podrían ser rechazados.
La solución:
Antes de hacer clic en "Enviar error", asegúrate de seleccionar los detalles correctos del error, como el tipo de error, la gravedad, el dispositivo y el navegador. Si eliges accidentalmente el dispositivo o navegador incorrectos, puedes corregirlo siempre y cuando nadie más lo haya informado correctamente, y antes de que el líder del equipo revise tu informe de error.
Enviar un mensaje en el chat del ciclo de prueba para notificar al líder del equipo que has realizado cambios solicitados en el informe de error
En la fase inicial de las pruebas, nuestros probadores reciben múltiples solicitudes de información para mejorar sus informes de errores. Durante ese tiempo, los probadores pueden sentirse impacientes por ver cuál será el resultado de la presentación. Es entonces cuando los probadores, en su mayoría, caen en la trampa de enviar varios comentarios en el informe de error o incluso mensajes en el chat del ciclo de prueba para informar al líder del equipo sobre los cambios realizados. ¿Te suena familiar, verdad? Todos hemos estado allí y hemos aprendido de nuestros errores. Pero queremos que seas más inteligente que eso y aprendas de nuestros errores.
La solución:
Cuando respondas a la solicitud de información con toda la información necesaria que tu líder de equipo solicitó, por favor, abstente de enviar múltiples comentarios en el informe de error y mensajes en el chat del ciclo de prueba. Los líderes de equipo reciben notificaciones sobre las solicitudes de información completadas, y no es necesario ponerse nervioso o ansioso. Todos los errores se revisarán a tiempo porque nuestro sistema no permite cerrar ninguna prueba con informes de errores en estado no revisado.
Usar Google Translate para traducir el entorno de prueba mientras grabas el error
Una de las ventajas de la tecnología actual es que no necesitas hablar todos los idiomas del mundo para probar el producto en un idioma extranjero. El uso de una herramienta de traducción de terceros, como Google Translate, está permitido durante las pruebas, pero asegúrate de que el error que encontraste no sea causado por el uso de Google Translate. A veces, Google Translate interrumpe el entorno y nuestros probadores terminan informando errores que no existen. En otros casos, nuestros probadores informan un error que existe y que no es causado por Google Translate, pero se olvidan de desactivar Google Translate cuando graban el error. Cuando eso sucede, el líder del equipo rechazará el error porque no cumple con nuestros estándares.
La solución:
Cada vez que estés probando un entorno en un idioma que no hablas, utiliza la herramienta de traducción de terceros para facilitar la comprensión del producto, pero desactívala justo antes de comenzar a grabar la pantalla de tu dispositivo.
Reproducir un error "PASS" en la prueba
Este comportamiento se observa en pruebas en las que se pide a nuestros probadores que envíen un error funcional titulado "PASS" para demostrar que el flujo descrito en las instrucciones de la prueba es exitoso. No se permite enviar reproducciones en tales errores, y tales envíos serán rechazados.
La solución:
Cuando veas "PASS" en el título del informe de error, por favor, no envíes una reproducción.
Suponer erróneamente que filtrar y ordenar son funcionalidades similares
Por lo general, la filtración y la ordenación se presentan juntas porque ayudan a los usuarios a manejar conjuntos grandes de elementos (productos, películas, boletos); sin embargo, su implementación difiere considerablemente. Una funcionalidad de filtro reduce una colección de elementos según criterios específicos como tamaño, color, marca y similares. Una funcionalidad de ordenación organiza un conjunto de datos según diferentes criterios, como de bajo a alto o más nuevo a más antiguo.
La filtración y la ordenación en dispositivos móviles y de escritorio
Comprender estas diferencias es crucial, ya que los errores encontrados en estas funcionalidades pertenecen a diferentes tipos. Por ejemplo, mientras que los problemas con la funcionalidad de ordenación son errores funcionales, la mayoría de los problemas de filtrado son errores de contenido.
La solución:
La forma más sencilla de diferenciar estas dos funcionalidades es observando el tipo y el número de opciones disponibles para la funcionalidad. La funcionalidad se filtrará cuando ofrezca numerosas opciones que describan las características físicas de los elementos. La funcionalidad se ordenará cuando las opciones dadas sean solo unas pocas y estén destinadas a ver los elementos mostrados de una manera particular.
La lista de errores más comunes no se limita a los casos mencionados. Para conocer más errores comunes y recibir excelentes consejos al momento de realizar pruebas, te sugerimos escuchar el siguiente episodio de nuestro podcast: