Hoy voy a tratar un tema muy interesante, la documentación recomendada en testing para asegurar la calidad de nuestro software.
Tanto si trabajamos en entornos ágiles, como si estamos trabajamos con metodologías más clásicas debemos entender qué necesitamos un mínimo de documentación para saber dos cosas: La primera, ¿qué vamos a desarrollar? Y la segunda, ¿qué vamos a probar? Si estás trabajando desarrollando software o probando un proyecto y no conoces las respuestas a las preguntas anteriores, difícilmente podrás verificar y validar el producto de forma adecuada.
Índice de contenidos
Base de la que partimos
En primer lugar, vamos a repasar la documentación recomendada en Testing que será la base de la cual partamos para conocer qué se va a desarrollar. Como adelantamos al comienzo del post, en función del tipo de metodología sobre la que desarrollemos deberemos contar un material u otro.
Historias de usuario, si trabajas con Ágile
Se deben disponer de las historias de usuarios cumplimentadas y trabajadas en la aclaración de dudas, para que no haya la menor incertidumbre a la hora de desarrollar. Es recomendable que disponga de una serie de campos a rellenar, partiendo quizás de una plantilla que nos permita estandarizar la recogida de la información. Por ejemplo: número de la historia, título de la historia, validación, valor, prioridad, estimación, etc. Lo importante es contar con esa documentación, no omitirla.
Sin esta información no se podrá realizar un correcto desarrollo, ni realizar un plan de pruebas adecuado que asegure la calidad de lo que pide nuestro cliente.
Documentación recomendada en Testing: Requisitos del sistema
Por otro lado, si trabajamos con metodologías más clásicas es necesario disponer de los requerimientos necesarios para realizar el desarrollo. En ese sentido, debes tener en cuenta que hay una clasificación de los requisitos. En primer lugar, existen los requerimientos de usuarios y los de sistemas. Los requisitos de sistemas se dividen entre requerimientos funcionales y no funcionales. En este sentido, se debe poner foco en los requisitos funcionales: de producto, organizacionales y externos. Sin olvidar, las restricciones técnicas y de integración.
Un requisito deben cumplir las características de ser: correcto, no ambiguo, completo, consistente, rastreable, modificable, calificada de acuerdo a la importancia y/o estabilidad, y verificable.
Toda esta clasificación de requisitos se debe completar con distintos formatos o documentos disponibles: Tablas para listado de requisitos, casos de uso, diagramas de flujos, bocetos de diseño, modelos de negocio, restricciones o excepciones. Si además todo esto se puede gestionar desde una herramienta online, mucho mejor.
Actas de las reuniones realizadas
En este párrafo voy a hablar la importancia de las actas. Se deben registrar las reuniones llevadas a cabo con el cliente para dejar constancia de los acuerdos que se han concluido. Esta es una documentación recomendada en Testing, porque no se deja en el tintero los puntos tratados, sino que cada una de las partes confirman los acuerdos llevados a cabo. De esta forma, evitamos olvidos o malentendidos a posteriori. Además, se puede consultar esa documentación y evitamos perdidas de tiempo innecesarias.
Documentación que generamos para un correcto aseguramiento de la calidad
Plan de pruebas
Se debe definir un plan de pruebas que abarque los niveles de pruebas necesarios, teniendo en cuenta todos los puntos importantes: necesidad de datos, equipo humano que va a diseñar y ejecutar el plan de pruebas, fechas planificadas, criterios de aceptación, entornos de ejecución, etc.
Siempre es relevante, que esta información esté registrada correctamente y que esté a disposición del equipo y del cliente, si es necesario. La transparencia y la revisión continua del plan es vital.
Casos de prueba del plan de pruebas
En quinto lugar, es importante elaborar los casos de prueba ricos en contenido. En otras palabras, deben estar descritos formalmente y de forma exhaustiva para su correcta ejecución. Para más detalles, puedes consultar el post: Consejos de testing: Diseña un caso de prueba de 10. Siempre se han definido en un excel, aunque esta ya no es una opción muy recomendada. Lo ideal es que estos diseños puedan ser importados a una herramienta para una gestión más ágil, y manejable de la ejecución.
Con respecto a la ejecución. Hay veces, que se opta por realizar las ejecuciones más informalmente, sin registros ni evidencias. Sin embargo, esta no es una opción muy recomendada para efectuar una correcta gestión de la calidad. Se debe almacenar evidencias de lo probado y almacenarlos correctamente para una posible consulta y seguimiento de las ejecuciones.
Matriz de trazabilidad
En último lugar, vamos a repasar las matrices de trazabilidad. Todo el que ha trabajado un tiempo en una empresa de desarrollo de software saber que la información (requisitos) puede ser modificada con más o menos frecuencia. Estos cambios suelen tener impacto en diversos puntos del proyecto: cambios en código, casos de uso, casos de prueba, etc.
La matriz de trazabilidad es una documentación recomendada en Testing porque nos ayuda a rastrear fácilmente estos impactos. Al tener relacionados bidireccionalmente los requisitos, con los casos de uso, o los requisitos con los casos de prueba, cuando un requisito sufre una modificación se identifica rápidamente en qué impacta. En otras palabras, podremos realizar las modificaciones necesarias en esos casos de prueba o en esos casos de uso, identificados en el menor tiempo posible a qué afecta. Después de eso, minimizaremos el riesgo de olvidar defectos en nuestra documentación, código o configuración.
Conclusión: Si dispones de la documentación recomendada en Testing, lo estás haciendo bien
Aunque nos movamos en entornos ágiles, tenemos que ser conscientes de que necesitamos almacenar la información en tiempo y forma para poder desempeñar nuestras tareas de la mejor forma posible. Disponer de la documentación recomendada en Testing, además, es vital para conocer, poder verificar y validad el software que estamos probando. Como consejo, te digo que no te dejes llevar por la urgencia y céntrate en lo importante para obtener los mejores resultados.
¿Para ti falta alguna documentación imprescindible para el equipo de Testing? Déjame un comentario o suscríbete al blog y estarás al tanto de todas las novedades del mínimo viable.
La Bitácora de Pruebas es importante en este proceso, ya que se tiene que dejar constancia de la ejecución de prueba, se tiene que dejar evidencia de que los procesos están funcionamiento correctamente o en caso contrario tienen errores o fallas.
De igual manera es importante la Notificación de Defectos, para nosotros como testers es prioridad encontrar y notificar los defectos en caso de que se encuentren. Entonces se arma el documento de Notificación de Defectos, el cuál es entregado al área correspondiente para su revisión y posterior corrección en caso de que corresponda.
Se hace seguimiento a los defectos encontrados y reportados, ya que con esto, nosotros debemos realizar la respectiva prueba de regresión y certificar que todo esté funcionando correctamente.
Debemos recordar que nuestro último reporte de pruebas, cuando ya se finalizó todo el proceso; debe de tener todos los casos de pruebas ejecutados y certificados.