Un producto de software es como un avión: debe someterse a un control técnico antes de su lanzamiento.
La garantía de calidad es un paso necesario para el lanzamiento de un producto de software exitoso. Es solo una pequeña parte de todo el trabajo del proyecto, pero nadie dijo que sería simple.
Hay muchos tipos de pruebas de software: automatizadas y manuales, exploratorias y funcionales, compatibilidad, UI / UX, regresión, unidad, API y pruebas de rendimiento. ¡Buena suerte envolviendo tu cabeza con todos ellos!
Sin embargo, lo que es común para todos estos tipos es que cada uno requiere que escriba una documentación completa de pruebas de control de calidad. La calidad de los documentos de prueba define si su trabajo resultará útil o será en vano.
He escrito este artículo para hacer tu vida un poco más fácil. Así que aquí está, su guía definitiva sobre cómo escribir documentación de control de calidad de software que funcione.
Haga un plan de prueba y un informe de progreso de la prueba
El plan de prueba es un documento de orientación que describe el panorama general del proceso de control de calidad e incluye una lista de tareas pendientes, una estrategia, recursos y un cronograma.
Antes de crear un documento de plan de control de calidad, pregúntese "¿Cuál es el propósito de la solución de software?" y "¿Qué funciones deben probarse?". No se apresure a probar cada parte de su software. Debe decidir qué metodologías, tecnologías y herramientas utilizará.
El plan de prueba lo ayudará a comprender lo siguiente:
- ¿Cuáles son los criterios de aceptación?
- Qué recursos necesitas? ¿Qué sistemas operativos, cuántas copias y con qué licencia? ¿Necesita asesores técnicos?
- ¿Están bien designados sus roles y responsabilidades?
- ¿Cuáles son los plazos de prueba?
El informe de progreso de la prueba es otra parte de la documentación de control de calidad, que es similar al plan de prueba, pero con datos adicionales sobre el progreso actual. Este documento le permite a usted y a su equipo de desarrollo monitorear el progreso del proyecto e identificar problemas organizacionales, si los hubiera.
Crear casos de prueba
Una vez que haya aclarado el conjunto de funciones que deben probarse en su plan de prueba, debe crear un caso de prueba para cada parte de su software.
Los casos de prueba son bastante simples: esta documentación de control de calidad consta de 7 secciones: ID, caso de prueba, pasos de prueba, resultado esperado, estado, resultado real y comentarios.
- La identificación es un número único asignado a su caso de prueba.
- En la sección Caso de prueba , indica los requisitos que probará y proporciona un enlace a ellos en el documento de especificaciones.
- En la sección Pasos de prueba , enumera todas las acciones necesarias para completar un caso de prueba.
- En la sección Resultado esperado , resume el resultado de una prueba en particular si es exitosa.
- En la sección Estado , indica si un paso en particular pasó o no pasó la prueba.
- En la sección Resultado real , explica el resultado de una prueba fallida.
- La sección de Comentarios no es obligatoria, pero puedes agregarla para dejar algunas notas adicionales.
Escribir un informe de defectos
El informe de defectos es un elemento importante de la documentación de control de calidad. Registra cualquier problema no deseado con su programa. Es un elemento crucial de la documentación del proyecto, que lo orienta hacia la obtención de una solución de software libre de errores.
Suena simple, ¿verdad? Sí, pero solo hasta que empiece a documentar. Aquí puede ver un ejemplo de un informe de defectos típico:
El informe de defectos consta de las siguientes secciones: identificador, resumen, descripción, pasos para reproducir, reproducibilidad, gravedad, prioridad, entorno y anexos.
- A cada problema de software en particular se le asigna un número único: el identificador . Optimiza la navegación a través de documentos de control de calidad y facilita la comunicación entre desarrolladores, evaluadores y administradores de proyectos.
- En la sección de resumen , proporciona una respuesta concisa a tres preguntas simples: qué sucedió, dónde y bajo qué circunstancias.
- En la sección de descripción , describe el error en detalle. Debe informar sobre los resultados reales y los esperados. Es útil proporcionar un enlace a sus requisitos de software.
- Luego, escribe sobre los pasos para reproducir (STR) . Esto muestra a los desarrolladores exactamente cómo reproducir el problema. No se pierda ni un paso o su informe puede regresar.
- En la sección de reproducibilidad , aclaras si el error aparece cada vez que sigues el STR. Debes usar números para mostrar probabilidades aproximadas, por ejemplo, 7 de cada 10 veces.
- En la sección de gravedad , explica cuánto daño puede traer el error al proyecto. En otras palabras, muestra el grado de influencia tecnológica del defecto en todo el sistema. Incluso un pequeño problema puede afectar gravemente a toda la aplicación.
- La prioridad muestra la importancia de un informe de defectos en particular. La prioridad se puede denotar con la ayuda de letras: "A" para las más urgentes y "Z" para las menos urgentes, números "1" para las más urgentes y "9" para las menos urgentes, o simplemente palabras como "alta ”,“ Medio ”o“ bajo ”.
- En la sección de entorno , debe definir qué sistemas operativos o versiones del navegador se vieron afectados.
- Finalmente, los archivos adjuntos incluyen la lista de videos, capturas de pantalla o archivos de registros de la consola agregados al informe de defectos.
Tenga en cuenta estos consejos útiles para la redacción de informes de defectos
- Escribe un resumen suficiente y adecuado. No importa si es largo o corto. Lo que importa es que quede claro.
- Eche un vistazo al resumen y la descripción. ¿Se ven más o menos iguales? Debe haber olvidado describir los resultados esperados y reales en la descripción y agregar el enlace a los requisitos.
- Capture el problema con la ayuda de una captura de pantalla. Puede ahorrarle mucho tiempo a usted y al equipo de desarrollo. A veces, una mirada a la imagen es suficiente para comprender la situación.
- Antes de informar del problema, intente reproducirlo al menos 3 veces para asegurarse de que existe.
- Informe el problema lo antes posible y notifique a su gerente de proyecto o propietario del producto si el problema es importante.
- Verifique si hay errores gramaticales en su documentación de control de calidad para que la policía gramatical no lo detenga.
- Por muy cómico que parezca, asegúrese de que el problema no sea una característica: ¡revise la documentación nuevamente!
- No se pierda ninguna información importante en sus Pasos para reproducir.
Envíe un informe de defectos
Los informes de defectos pasan por un ciclo de vida: desde el momento en que informa un problema hasta el momento en que se cierra.
El primer paso es compilar y enviar el informe de defectos. En este punto, el director de proyecto o una ventaja de tecnología decide si se debe asignar a un desarrollador o para rechazar que por razones de insuficiencia o inadecuación.
Una vez que el desarrollador asignado ha corregido el error, usted, como QA, debe verificar y verificar que se haya solucionado. En caso afirmativo, puede cerrar el informe de defectos. La mejor práctica es cerrarlo en una semana o dos.
Si el error no se corrige, vuelve a abrir el informe de defectos y lo envías de vuelta al desarrollador asignado. El proceso de corrección de errores puede ser largo, pero debe mantenerse firme hasta que todos los informes de defectos estén finalmente cerrados.
Para concluir
La garantía de calidad es un proceso que simplemente no puede evitar. Cada avión antes de la salida se somete a un control técnico. Si hay algún problema, la aeronave se conecta a tierra hasta que se resuelva el problema.
Del mismo modo, cada producto de software debe comprobarse antes del lanzamiento. No puede darse el lujo de implementar software con errores porque los usuarios no le darán una segunda oportunidad a su aplicación.
¿Necesita mejorar la calidad de su software?
Mi empresa, KeenEthics, ofrece servicios sólidos de desarrollo y garantía de calidad. En caso de que necesite un presupuesto para un proyecto similar, no dude en ponerse en contacto .
Si le ha gustado el artículo, debe continuar con Qué es el prototipo y por qué lo necesitamos y Producto mínimo viable: entre una idea y el producto.
PD
El artículo original publicado en el blog de KeenEthics se puede encontrar aquí: ¿Cómo escribir documentación de control de calidad que funcione?