Cada error debe documentarse con al menos un archivo adjunto. Con tus archivos adjuntos, proporcionas evidencia de que el error ocurre en tu dispositivo, sistema operativo y/o navegador.
Nota: Los archivos adjuntos no reemplazan la información escrita en tu informe. Sirven como visualización del problema y como prueba.
¿Captura de pantalla o grabación de pantalla?
En general, los errores funcionales requieren una grabación de pantalla (screencast) para ilustrarse de manera correcta y efectiva. A menos que las instrucciones o el líder de equipo soliciten archivos específicos, usa esta regla práctica para decidir entre una captura de pantalla o un screencast para tu error:
Siempre que se requiera realizar una acción para desencadenar un error o cuando sea necesario ilustrar un proceso, sube una grabación de pantalla. Las capturas son imágenes estáticas y no pueden mostrar la causa raíz. Por esta razón, los errores funcionales siempre requieren un screencast.
Cuando la naturaleza del error es estática (por ejemplo, problemas de la interfaz gráfica estática), una captura de pantalla es suficiente y ofrece mejor visualización que un video. Para errores de contenido o visuales, es suficiente con una captura de pantalla.
Requisitos generales para los archivos adjuntos
Se deben crear archivos adjuntos nuevos para cada informe de error o reproducción.
Está prohibido copiar archivos adjuntos de otros informes o reproducciones.
Los archivos adjuntos deben mostrar toda la información relevante del error como prueba.
Toda la información relevante debe mostrarse en inglés (o en alemán si el idioma del informe es alemán), por ejemplo: fecha, hora, información del sistema, mensajes de error.
Debes seleccionar solo un dispositivo o navegador al reportar el error y subir un único archivo adjunto para ese entorno. Si puedes reproducir el error en otros dispositivos o navegadores, menciona esto en tu resultado actual (Actual result).
No muestres información de otros clientes de Test IO (por ejemplo, correos de invitación o nombres de pestañas del navegador). Está permitido mostrar aplicaciones instaladas de otros clientes.
No muestres información personal o inadecuada, como fotos, videos o sugerencias de autocorrección inapropiadas. Recuerda que tus archivos estarán disponibles para otros testers, el personal de Test IO y el cliente.
Para pruebas en sitios web, el campo de URL debe ser visible en los archivos adjuntos.
La resolución debe ser lo suficientemente alta como para que el texto y los elementos sean fácilmente identificables.
Siempre graba toda tu pantalla.
Un registro de crash (crash log) es obligatorio para informes de errores funcionales o reproducciones positivas de fallos en aplicaciones. El video que documenta el fallo debe corresponder con el registro adjunto (los tiempos deben coincidir).
Reglas específicas para fecha y hora:
La fecha y la hora actual deben ser visibles en los archivos adjuntos.
Al demostrar un error mediante captura de pantalla en un dispositivo móvil, debes subir una segunda captura que muestre la fecha y la hora (el nivel de batería y la hora deben coincidir con la primera captura).
La fecha puede estar en cualquier formato común (por ejemplo, DD/MM o MM/DD), en inglés (o en alemán si el informe es en ese idioma).
La hora debe mostrarse en reloj de 24 horas; si usas reloj de 12 horas, asegúrate de usar el formato AM/PM.
Mostrar la fecha actual en tu archivo adjunto demuestra que lo registraste en ese día. Lugares donde puedes mostrar la fecha:
Windows: la barra de tareas o el calendario emergente.
Mac: el ícono del calendario en el Dock o en la barra de menús.
iOS y Android: desliza hacia abajo el centro de notificaciones al inicio de la grabación.
Más información: TecRevue
¿Qué debe incluir una captura de pantalla?
Reglas específicas para capturas:
Deben estar en formato JPG o PNG.
Resalta claramente el error en la captura.
Recomendamos las herramientas de grabación y las mejores prácticas que se describen en el siguiente artículo: Capturas de pantalla
Los errores más comunes se pueden consultar en el siguiente artículo:
¿Qué debe incluir un screencast?
Los screencasts deben ser lo más breves posible, pero tan largos como sea necesario. Esto significa que debes omitir los pasos que no provocan el error. Por ejemplo, cuando el botón «Añadir al carrito» de la página de detalles de un producto de una tienda online no funciona correctamente, por lo general es irrelevante cómo has navegado por la tienda online para llegar a la página de detalles del producto. Lo que suele ser relevante es el último paso de navegación, el paso que provoca el error y el error en sí.
Ejemplo 1: Error en sitio web, probado en escritorio
Pasos para crear un screencast:
Ve a la página donde ocurre el error.
Inicia tu grabación.
Refresca la página.
Realiza la acción que desencadena el error.
Espera a que ocurra el error.
Detén la grabación.
Ejemplo 2: Error en aplicación móvil
Pasos para crear el screencast:
Ejecuta la app y ve a la pantalla donde falta solo un paso para alcanzar la que tiene el error.
Inicia la grabación.
Desliza hacia abajo el centro de notificaciones para mostrar la fecha actual por algunos segundos.
Completa el último paso de navegación.
Realiza la acción que desencadena el error.
Espera a que ocurra el error.
Detén la grabación.
Team leaders might send you an information request asking for an external or additional recording. This is done to gain a better understanding of the bug or when in doubt due to the bug being non-reproducible.
Reglas específicas para los screencasts
Deben estar en formato MP4.
El tamaño máximo del archivo es 25 MB.
La duración máxima para screencasts de informes de errores es de 60 segundos, salvo que el error requiera mostrar un proceso de carga o una entrada manual prolongada.
Para reproducciones y User Stories, la duración máxima es de 15 segundos, ya que solo se debe mostrar la última acción que desencadena el error.
Los clics, toques o pulsaciones y el cursor deben ser visibles (obligatorio en Android y grabaciones de escritorio).
Graba de una sola vez: no pauses ni cortes en medio. Si el screencast es demasiado largo, solo recorta el inicio o el final.
No acelerar la grabación. Si excede el tiempo, revisa si mostraste pasos innecesarios.
No grabes sonidos como bebés llorando, conversaciones, TV, música, mascotas, etc.
Recomendamos las herramientas de grabación y las mejores prácticas que se describen en el siguiente artículo: Capturas de pantalla
Los errores más comunes se pueden consultar en el siguiente artículo:
Reglas para grabaciones en dispositivos de streaming (TV)
Graba siempre toda la pantalla del televisor.
El screencast debe tener alta resolución y buena calidad.
La iluminación debe ser adecuada (no muy oscura).
El control remoto debe estar visible completa y claramente.
La fecha y hora actual deben mostrarse en la grabación, ya sea en el televisor o un dispositivo externo como PC, teléfono o tablet.
Para informes de errores, el tiempo máximo de screencast es de 60 segundos. Para reproducciones o User Stories, 15 segundos.
No grabes sonidos molestos o distracciones (bebés, conversaciones, música, etc.).
La grabación debe lucir profesional: no muestres tus piernas, un soporte de TV desordenado ni elementos similares.
¿Cómo grabar un screencast de errores del teclado?
A veces se producen errores al interactuar con sitios web utilizando las teclas del teclado del ordenador.
Cuando esto ocurre, y dado que debemos mostrar la acción que provoca el error en el screencast, es obligatorio mostrar la entrada del teclado.
Aquí hay un excelente ejemplo de cómo crear un screencast que muestre la entrada del teclado:
Dominar los archivos adjuntos de screencast para todos los dispositivos
Difuminar información privada en los archivos adjuntos
Para proteger su información privada, como marcadores, nombres de cuentas o correos electrónicos almacenados, y evitar que sean visibles en las pestañas del navegador, puede seguir esta sencilla técnica para difuminarlos. Sin embargo, para que el proceso de notificación de errores sea más eficaz, se recomienda utilizar una ventana del navegador dedicada a realizar pruebas, como se muestra en el ejemplo siguiente, en el que no hay pestañas innecesarias abiertas ni marcadores visibles.
Si necesita incluir información privada en sus archivos adjuntos pero no desea que sea visible, puede seguir este ejemplo para ocultarla de manera profesional; tenga en cuenta que los nombres de las pestañas del navegador que podrían mostrar direcciones de correo electrónico, nombres de usuario y marcadores están ocultos.
Es importante tener en cuenta que la URL debe seguir siendo visible y que los elementos del sitio web no deben quedar obstruidos.
Por motivos profesionales, es fundamental evitar los métodos dibujados a mano o esquemáticos al cubrir la información de los archivos adjuntos, como se muestra en el siguiente ejemplo:
