Pruebas ágiles: técnicas
Las técnicas de prueba de las pruebas tradicionales también se pueden utilizar en las pruebas ágiles. Además de estos, en los proyectos Agile se utilizan técnicas y terminologías de prueba específicas de Agile.
Base de prueba
En proyectos ágiles, la cartera de productos reemplaza los documentos de especificación de requisitos. El contenido de la acumulación de productos suele ser historias de usuarios. Los requisitos no funcionales también se tienen en cuenta en las historias de usuario. Por lo tanto, la base de prueba en los proyectos ágiles es la historia del usuario.
Para garantizar las pruebas de calidad, lo siguiente también se puede considerar adicionalmente como base de prueba:
- Experiencia de iteraciones anteriores del mismo proyecto o proyectos anteriores.
- Funciones existentes, arquitectura, diseño, código y características de calidad del sistema.
- Datos de defectos de los proyectos actuales y pasados.
- Comentarios de los clientes.
- Documentación del usuario.
Definición de Terminado
La Definición de Terminado (DoD) es el criterio que se utiliza en los proyectos ágiles para garantizar la finalización de una actividad en el backlog de Sprint. El DoD puede variar de un equipo Scrum a otro, pero debe ser consistente dentro de un equipo.
DoD es una lista de verificación de actividades necesarias que garantizan la implementación de funciones y características en una historia de usuario junto con los requisitos no funcionales que forman parte de la historia de usuario. Una historia de usuario llega a la etapa Listo después de que se completan todos los elementos de la lista de verificación del Departamento de Defensa. Un DoD se comparte en todo el equipo.
Un DoD típico para una historia de usuario puede contener:
- Criterios de aceptación comprobables detallados
- Criterios para garantizar la coherencia de la historia de usuario con las demás en la iteración
- Criterios específicos relacionados con el producto
- Aspectos de comportamiento funcional
- Características no funcionales
- Interfaces
- Requisitos de datos de prueba
- Cobertura de prueba
- Refactoring
- Requisitos de revisión y aprobación
Además del DoD para historias de usuarios, también se requiere DoD:
- en cada nivel de prueba
- para cada característica
- para cada iteración
- para liberación
Información de prueba
Un probador debe tener la siguiente información de prueba:
- Historias de usuarios que deben probarse
- Criterios de aceptación asociados
- Interfaces del sistema
- Entorno donde se espera que funcione el sistema
- Disponibilidad de herramientas
- Cobertura de prueba
- DoD
En los proyectos ágiles, dado que las pruebas no son una actividad secuencial y se supone que los probadores deben trabajar en modo colaborativo, es responsabilidad del probador:
- Obtenga la información de prueba necesaria de forma continua.
- Identifique las lagunas de información que afectan las pruebas.
- Resuelva las brechas en colaboración con otros miembros del equipo.
- Decide cuándo se alcanza un nivel de prueba.
- Asegúrese de que se ejecuten las pruebas adecuadas en los momentos pertinentes.
Diseño de prueba funcional y no funcional
En proyectos ágiles, se pueden utilizar las técnicas de prueba tradicionales, pero la atención se centra en las pruebas tempranas. Los casos de prueba deben estar en su lugar antes de que comience la implementación.
Para el diseño de prueba funcional, los probadores y desarrolladores pueden utilizar las técnicas tradicionales de diseño de prueba Black Box, como:
- Partición de equivalencia
- Análisis de valor límite
- Tablas de decisiones
- Transición de estado
- Árbol de clases
Para el diseño de prueba no funcional, dado que los requisitos no funcionales también son parte de cada historia de usuario, las técnicas de diseño de prueba de caja negra solo se pueden utilizar para diseñar los casos de prueba relevantes.
Prueba exploratoria
En proyectos ágiles, el tiempo es a menudo el factor de limitación para el análisis de pruebas y el diseño de pruebas. En tales casos, las técnicas de prueba exploratoria se pueden combinar con las técnicas de prueba tradicionales.
Las pruebas exploratorias (ET) se definen como aprendizaje simultáneo, diseño de pruebas y ejecución de pruebas. En las pruebas exploratorias, el evaluador controla activamente el diseño de las pruebas a medida que se realizan y utiliza la información obtenida durante las pruebas para diseñar nuevas y mejores pruebas.
Las pruebas exploratorias son útiles para adaptarse a los cambios en los proyectos ágiles.
Pruebas basadas en riesgos
Las pruebas basadas en riesgos son pruebas basadas en el riesgo de falla y mitigan los riesgos utilizando técnicas de diseño de pruebas.
Un riesgo de calidad del producto se puede definir como un problema potencial con la calidad del producto. Los riesgos de calidad del producto incluyen:
- Riesgos funcionales
- Riesgos de desempeño no funcionales
- Riesgos de usabilidad no funcionales
Se debe realizar un análisis de riesgo para evaluar la probabilidad (probabilidad) y el impacto de cada riesgo. Luego, se priorizan los riesgos:
- Los riesgos elevados requieren pruebas exhaustivas
- Los riesgos bajos solo requieren pruebas de curso
Las pruebas se diseñan utilizando las técnicas de prueba adecuadas en función del nivel de riesgo y la característica de riesgo de cada riesgo. Luego se ejecutan pruebas para mitigar los riesgos.
Pruebas de ajuste
Las pruebas de ajuste son pruebas de aceptación automatizadas. Las herramientas Fit y FitNesse se pueden utilizar para automatizar las pruebas de aceptación.
FIT usa JUnit, pero extiende la funcionalidad de prueba. Las tablas HTML se utilizan para mostrar los casos de prueba. Fixture es una clase Java detrás de la tabla HTML. El dispositivo toma el contenido de la tabla HTML y ejecuta los casos de prueba en el proyecto que se está probando.