Control de calidad que realmente funcione

Un producto de software es como un avión: debe someterse a una revisión técnica

antes del lanzamiento.

El control de calidad es un paso necesario para lanzar 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 tantos tipos de pruebas de software: automatizadas y manuales, exploratorias y funcionales, compatibilidad, UI/UX, regresión, unidades, API y pruebas de rendimiento. ¡Buena suerte envolviendo tu cabeza alrededor de todos ellos!

Sin embargo, lo que es común para todos estos tipos es que cada uno requiere que usted escriba una documentación exhaustiva de prueba 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 hacerte la 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.

Hacer un plan de prueba y un informe de progreso de

la prueba

El plan de prueba es un documento guía 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é características necesitan ser probadas?”. No se apresure a probar cada parte de su software. Debe decidir qué metodologías, tecnologías y herramientas utilizará.

El plan de prueba le ayudará a entender lo siguiente:

• ¿Cuáles son los criterios de aceptación?
• Qué recursos necesitas? ¿Qué sistemas operativos, cuántas copias y con qué licencia? ¿Necesitas algún asesor técnico?
• ¿Están bien designados sus roles y responsabilidades?
• ¿Qué 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 hay.

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.

1. ID es un número único asignado a su caso de prueba.
2. En la sección Caso de prueba , indica los requisitos que probará y proporciona un enlace a ellos en el documento de especificaciones.
3. En la sección Pasos de prueba , enumera todas las acciones necesarias para completar un caso de prueba.
4. En la sección Resultado esperado , resume el resultado de una prueba en particular si tiene éxito.
5. En la sección Estado , indica si un paso en particular pasó o falló la prueba.
6. En la sección Resultado real , explica el resultado de una prueba fallida.
7. La sección Comentarios no es obligatoria, pero puede 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 guía hacia la obtención de una solución de software libre de errores.

Suena simple, ¿verdad? Sí, pero solo hasta que empieces a documentarte. Aquí puede ver un ejemplo de un informe de defecto típico:

El informe de defectos consta de las siguientes

secciones:

Identificador, resumen, descripción, pasos para reproducir, reproducibilidad, gravedad, prioridad, entorno y archivos adjuntos.

1. 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, probadores y PM.
2. En la sección de resumen , proporciona una respuesta concisa a tres preguntas simples: qué sucedió, dónde y en qué circunstancias.
3. 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.
4. Luego, escribe sobre los pasos para reproducir (STR) . Esto muestra a los desarrolladores exactamente cómo reproducir el problema. No se pierda un paso o su informe puede volver a usted.
5. En la sección de reproducibilidad , aclaras si el error aparece cada vez que sigues el STR. Debe usar números para mostrar posibilidades aproximadas, por ejemplo, 7 veces de 10.
6. En la sección de gravedad , explica cuánto daño puede causar el error al proyecto. En otras palabras, muestra el grado tecnológico de influencia del defecto en todo el sistema. Incluso un pequeño problema puede afectar gravemente a toda la aplicación.
7. La prioridad muestra la importancia de un informe de defecto en particular. La prioridad se puede denotar con la ayuda de letras: “A” para el más urgente y “Z” para el menos urgente, números: “1” para el más urgente y “9” para el menos urgente, o simplemente palabras como “alta”. ”, “medio” o “bajo”.
8. En la sección de entorno , debe definir qué sistemas operativos o versiones de navegador se vieron afectados.
9. 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

1. Escribir un resumen suficiente y adecuado. No importa si es largo o corto. Lo que importa es que debe quedar claro.
2. Echa un vistazo al resumen y la descripción. ¿Se ven más o menos iguales? Debe haber olvidado delinear los resultados esperados y reales en la descripción y agregar el enlace a los requisitos.
3. Capture el problema con la ayuda de una captura de pantalla. Puede ahorrarle mucho tiempo a usted y al equipo de desarrollo. A veces, un vistazo a la imagen es suficiente para comprender la situación.
4. Antes de informar el problema, intente reproducirlo al menos 3 veces para asegurarse de que existe.
5. Informe el problema lo antes posible y notifique a su gerente de proyecto o propietario del producto si el problema es importante.
6. Verifique si hay errores gramaticales en su documentación de control de calidad para que la policía gramatical no lo elimine.
7. Por cómico que parezca, asegúrese de que el problema no sea una característica: ¡revise la documentación nuevamente!
8. No se pierda ninguna información importante en sus Pasos para reproducir.

Enviar 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 gerente de proyecto o un líder técnico decide si asignarlo a un desarrollador o rechazarlo por insuficiencia o inadecuación.

Después de que el desarrollador asignado haya solucionado el error, usted, como control de calidad, debe volver a 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 soluciona, vuelve a abrir el informe de defectos y lo envía de vuelta al desarrollador asignado. El proceso de corrección de errores puede ser largo, pero debe mantenerse fuerte hasta que finalmente se cierren todos los informes de defectos.

Para concluir

El control de calidad es un proceso que simplemente no puede evitar. Cada avión antes de la salida se somete a una revisión técnica. Si hay algún problema, la aeronave está en tierra hasta que se resuelva el problema.

De manera similar, cada producto de software debe verificarse 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.

Fuente de: freeCodeCamp