Hoy propongo repasar el capítulo 5 del ISTQB CTAL-TA y las revisiones de la base de prueba. En estas páginas podemos conocer las técnicas recomendadas para una detección temprana de errores que ahorran mucho trabajo y coste económico a los proyectos. En esta documentación el ISTQB se centra en las listas de comprobación para realizar un trabajo más ordenado, tanto en técnicas ágiles, como en técnicas tradicionales. Como analista de pruebas, tendrás una fantástica herramienta para revisar la documentación del proyecto. ¿Quieres saber que tienes que tener en cuenta?
Índice de contenidos
Como he comentado anteriormente, es necesario que el proceso de revisión siga una planificación, participación y seguimiento. El analista de pruebas aportará su punto de vista para enriquecer el proceso. En este sentido, el ISTQB propone la téncia de la lista de comprobación.
Listas de comprobación en las revisiones
Esta técnica es una de las utilizadas por el Analista de pruebas. En ella se propone revisar un conjunto de puntos de forma sistemática con el objetivo de evitar olvidos y de despersonalizar la revisión. Es frecuente trabajar con varios tipos de listas, una más genérica, otra más especifica, orientada a un tipo de proyectos (con unas características similares) u otras.
También, es frecuente emplear distintos tipos de listas en función del formato de los requisitos. No es lo mismo que estén en formato narrativo o especificado en diagramas. Para las listas específicas, podemos indicar, por ejemplo, las listas para cumplir medidas de seguridad (serán más específicas), ya que implican un riesgo o las recomendadas por un Equipo de QA que deben cumplir criterios de calidad (quizás no especificados en la propia documentación).
Revisión de Requisitos para metodologías no ágiles
En este párrafo, vamos a hablar de como aplicar la lista de comprobaciones a un listado de requisitos. En un principio, debes tener en cuenta que un requisito tiene que tener la capacidad de ser probado. ¿Cómo se interpreta esto? Es necesario que un Analista de Prueba pueda saber como probarlo. Sin embargo, si no fiera así, diríamos que ese requisito tiene un defecto.
¿Qué podríamos incluir en la lista de verificación del requisito? En primer lugar, la persona o departamento que lo ha creado, la capacidad de ser probado o su criterio de aceptación. Además, debe tener una estructura de caso de uso (si aplica), un identificador único, la versión, la trazabilidad frente a otros requisitos o caso de uso y un glosario de la terminología utilizada. Para más información, puedes consultar el post: 6 consejos para definir los requisitos de información del sistema.
Hay que tener especialmente cuidado con los requisitos generales tipo «el software debe ser usable», porque este requisito desencadenará muchos de casos de prueba para probar la usabilidad y deberemos apoyarnos en alguna normativa vigente. En caso de haber un cambio en la normativa, será necesario aplicar cambios en todos los casos de prueba relacionados con ese requisito global.
Revisiones de historias de usuarios
El ISTQB CTAL-TA y las revisiones de historia de usuario tiene un enfoque similar al de los requisitos no ágiles. En este caso, al analizar una historia, nos encontramos un texto que narra la funcionalidad que se desea desarrollar en un tiempo limitado.
En este sentido, la lista de comprobación debe estar enfocada a preguntar: si es adecuada o no para el objetivo de esta iteración o si está escrita desde el punto de vista de la persona que desarrolla el cambio. Además, se verificará si tienen capacidad de ser probados y si tienen criterios de aceptación. A continuación, es necesario saber si esta historía está definida y diferenciada del resto, si es independiente y priorizada, etc. para evitar conflictos con otras historias relacionadas.
En este sentido, es importante seguir la lista de comprobación para hacer una refinación óptima de historias de usuario que nos permite cumplir el sprint y entregar un desarrollo de calidad.
Adaptación de lista de comprobación
Siempre puedes realizar adaptaciones en tus listas de comprobación. Hoy en día, no podemos pensar que lo que hacemos está construido en piedra y perdurará a lo largo de los siglos. Toda buena lista de verificación, tendrá deficiencias, que nos permitirá iniciar debates que mejoren esa lista. Tras cada iteración tendremos una fórmula más sólida que nos permita asegurar la alta calidad de nuestro producto. En consecuencia, el Analista de Prueba puede ser más eficaz en sus revisiones.
¿Cómo puede ser adaptada la lista? Se debe tener en cuenta la organización. Cada entidad tiene sus propias normas, convenciones, políticas de empresa o limitaciones jurídicas que pueda tener cada empresa del sector. También, depende del proyecto y el esfuerzo de desarrollo, nivel de riesgo del proyecto que se está revisando y las técnicas de prueba que se están aplicando.
Conclusión: El ISTQB CTAL-TA y las revisiones nos ayudan a ahorrar
Es vital tener unas técnicas de revisión de documentación procedimentadas que nos ayuden a encontrar defectos de forma temprana, a ser más eficientes y a ahorrar costes al proyecto. En ese sentido, el ISTQB CTAL-TA y las revisiones se enfocan en utilizar listas de verificación tanto para metodologías ágiles, como no ágiles. Además, trabajando en una depuración continua de esas listas que nos ayuden a ser más eficientes en nuestras comprobaciones de requisitos.
¿Empleas la listas de comprobación en tus verificaciones de documentación? ¿Son listo estándar o tenéis procesos de actualización consensuados por los equipos? Dejame tu comentario o suscríbete al blog y estarás al tanto de todas las novedades.
Quizás te puede interesar
