Blog

📄 ¿Cómo crear un informe de pruebas de software eficaz?

Foto de Artem Podrez en Pexels

Crear reportes es tan importante como realizar pruebas. Si bien no podemos garantizar o asegurar la calidad de un producto, realizamos pruebas de software para obtener información acerca del mismo, de los riesgos, la calidad, los usuarios y las condiciones de su uso. Esta información ayuda a los clientes a tomar decisiones con base en la información sobre el producto, proyecto o negocio. 

Una vez que se planificó la estrategia de pruebas y se llevaron a cabo las pruebas de performance, exploratorias, manuales o automatizadas, etc., es donde entra en juego el reporte de pruebas. No sirve de nada la información obtenida si no se presenta claramente, de tal forma que permita tomar acciones concretas sobre esta.

Un buen reporte de pruebas, no tiene por qué ser necesariamente un proceso tedioso. El tiempo es un recurso esencial y se busca ser directos e ir al punto. Por ello, a continuación te mostramos cómo crear un reporte de testing efectivo y conciso, que tu equipo estará feliz de leer.

Es importante considerar que no siempre es necesario realizar un reporte. Por ejemplo, cuando se utilizan metodologías ágiles, generalmente no se requieren ni son útiles. En nuestro caso, al trabajar con equipos que aplican diferentes metodologías y en muchos casos, trabajan con equipos distribuidos, generalmente los efectuamos.

El propósito de nuestro trabajo no es la documentación, sino que es entregar software que funcione exactamente como esperan los usuarios. Como lo dice el manifiesto ágil, buscamos sacar el mayor provecho al tiempo del reporte.

Tips para crear un Reporte de Testing eficaz

La opción más segura para emplear a la hora de enviar un reporte de pruebas es mediante un documento de texto simple, ya que el mismo puede ser leído desde cualquier dispositivo: laptop, tablet y smartphones.

No es recomendable incluir archivos adjuntos, para que no se consuma demasiado ancho de banda. Incluir información generada automáticamente también agrega valor al informe. De manera general, tu reporte de testing debe ser conciso pero debe incluir:

1. Qué fue testeado

  • Qué áreas del producto (o productos).
  • Qué versión/es.
  • Qué ambiente/configuración.
  • Qué escenarios (incluyendo automatizaciones, si aplican).

2. Qué no fue testeado y por qué 

Es importante mostrar el proceso mental y las razones por las que se realizaron o no las pruebas. Se puede indicar que por ejemplo, debido a la falta de tiempo, ciertas pruebas se dejaron para futuras instancias. Dejar algo sin testear supone un riesgo y este se debe indicar, por lo que es necesario incluirlo en el reporte.

3. Resultados

  • Los escenarios que pasaron las pruebas.
  • Los escenarios que no pasaron las pruebas (si aplica, especificar el número de bugs).
  • Los escenarios pendientes por testear.

4. Conclusiones

En esta etapa hay que ser cuidadosos con el lenguaje utilizado. Se debe adoptar una forma de comunicar segura, pero sin asumir responsabilidades que no corresponden. Evitar utilizar expresiones como  “No hay bugs.” o “El producto está listo para salir”.

¿Alcanzó el producto, o la versión del mismo, los criterios aceptados? Si no fue así, es necesario indicar por qué no. Por ejemplo, “X número de bugs críticos deben ser arreglados” o “Se deben realizar más pruebas”. ¿Hay riesgos relacionados? Por ejemplo, “Las pruebas de seguridad no fueron ejecutadas debido a limitaciones en el tiempo y recursos”.

5. Investigación previa relevante

Si un proyecto o contrato se factura por hora, es recomendable anotar cualquier tipo de investigación efectuada (y si aplica, qué surgió de ella). 

Intercambio y feedback

Al final de cada reporte, se puede agregar una solicitud de feedback, por ejemplo: “Hazme saber si tienes alguna pregunta o inquietud o si necesitas más información, por favor” o “Cuéntame si la información brindada en este reporte fue suficiente para visualizar la calidad del proceso y el estado del mismo, o si quisieras ver otra información”. De esta forma se puede considerar la respuesta para futuras pruebas o reportes.

Menos es más

Se recomienda enviar en primera instancia, un esquema simple como lo mostrado anteriormente y esperar por el feedback del cliente. Luego, efectuar los ajustes necesarios y mantenerlos a futuro, en lugar de dejarlo completamente en sus manos, ya que es probable que el cliente acepte el formato simple una vez que lo vea.


Según tu experiencia, ¿cuáles son algunos de los puntos fundamentales a incluir en un informe de pruebas de software?

¡Síguenos en LinkedInTwitterFacebookInstagram y Youtube para ser parte de nuestra comunidad y enterarte de otras buenas prácticas a incorporar en tu plan de pruebas!


Otros contenidos relacionados

Tips para generar y gestionar reportes de testing

Cómo crear la estrategia de pruebas adecuada para tu proyecto

3 elementos esenciales para lanzar Software rápidamente, sin afectar la Calidad


107 / 208