¿Qué son las pruebas ágiles?
AGILE TESTING es una práctica de prueba que sigue las reglas y principios del desarrollo ágil de software. A diferencia del método Waterfall, Agile Testing puede comenzar al inicio del proyecto con una integración continua entre el desarrollo y las pruebas. La metodología de prueba ágil no es secuencial (en el sentido de que se ejecuta solo después de la fase de codificación) sino continua.
En este artículo, discutiremos
- Plan de prueba ágil.
- Estrategias de prueba ágiles.
- El cuadrante de pruebas ágiles.
- Desafíos de control de calidad con desarrollo de software ágil.
- Riesgo de Automatización en Procesos Ágiles.
Plan de prueba ágil
El plan de prueba ágil incluye tipos de pruebas realizadas en esa iteración, como requisitos de datos de prueba, infraestructura, entornos de prueba y resultados de prueba. A diferencia del modelo en cascada, en un modelo ágil, se escribe y actualiza un plan de prueba para cada versión. Los planes de prueba típicos en ágil incluyen
- Alcance de prueba
- Nuevas funcionalidades que se están probando
- Nivel o tipos de pruebas según la complejidad de las características
- Pruebas de carga y rendimiento
- Consideración de infraestructura
- Plan de mitigación o riesgos
- Recursos
- Entregables e hitos
Estrategias de prueba ágiles
El ciclo de vida de las pruebas ágiles abarca cuatro etapas
(a) Iteración 0
Durante la primera etapa o iteración 0, realiza las tareas de configuración inicial. Incluye la identificación de personas para las pruebas, la instalación de herramientas de prueba, la programación de recursos (laboratorio de pruebas de usabilidad), etc. Los siguientes pasos están configurados para lograr en Iteración 0
a) Establecer un caso de negocio para el proyecto
b) Establecer las condiciones de contorno y el alcance del proyecto
c) Describa los requisitos clave y los casos de uso que impulsarán las compensaciones del diseño.
d) Esquema de una o más arquitecturas candidatas
e) Identificación del riesgo
f) Estimación de costos y elaboración de anteproyecto
(b) Iteraciones de construcción
La segunda fase de la metodología de prueba ágil son las iteraciones de construcción, la mayoría de las pruebas se producen durante esta fase. Esta fase se observa como un conjunto de iteraciones para construir un incremento de la solución. Para hacer eso, dentro de cada iteración, el equipo implementa un híbrido de prácticas de XP, Scrum, modelado ágil y datos ágiles, etc.
En la iteración de construcción, el equipo ágil sigue la práctica de requisitos priorizados: con cada iteración, toman los requisitos más esenciales que quedan de la pila de elementos de trabajo y los implementan.
La iteración de la construcción se clasifica en dos, pruebas de confirmación y pruebas de investigación. Las pruebas de confirmación se concentran en verificar que el sistema cumpla con la intención de las partes interesadas, tal como se describe al equipo hasta la fecha, y que es realizado por el equipo. Mientras que la prueba de investigación detecta el problema, el equipo de confirmación se ha saltado o ignorado. En las pruebas de investigación, el probador determina los problemas potenciales en forma de historias de defectos. Las pruebas de investigación tratan problemas comunes como las pruebas de integración, las pruebas de carga / estrés y las pruebas de seguridad.
Una vez más, para las pruebas de confirmación hay dos aspectos, las pruebas de desarrollador y las pruebas de aceptación ágil . Ambos están automatizados para permitir pruebas de regresión continuas a lo largo del ciclo de vida. Las pruebas de confirmación son el equivalente ágil de las pruebas de acuerdo con la especificación.
Las pruebas de aceptación ágiles son una combinación de pruebas funcionales tradicionales y pruebas de aceptación tradicionales, ya que el equipo de desarrollo y las partes interesadas lo hacen juntos. Mientras que las pruebas de desarrollador son una combinación de pruebas unitarias tradicionales y pruebas de integración de servicios tradicionales. Las pruebas de desarrollador verifican tanto el código de la aplicación como el esquema de la base de datos.
(c) Finalizar el juego o fase de transición
El objetivo de "Release, End Game" es implementar su sistema con éxito en producción. Las actividades que se incluyen en esta fase son la formación de usuarios finales, personal de apoyo y personal operativo. Además, incluye la comercialización del lanzamiento del producto, la copia de seguridad y la restauración, la finalización del sistema y la documentación del usuario.
La etapa final de prueba de metodología ágil incluye pruebas completas del sistema y pruebas de aceptación. De acuerdo con terminar su etapa de prueba final sin ningún obstáculo, debería tener que probar el producto de manera más rigurosa mientras se encuentra en iteraciones de construcción. Durante el juego final, los probadores trabajarán en sus historias de defectos.
(d) Producción
Después de la etapa de lanzamiento, el producto pasará a la etapa de producción.
Los cuadrantes de pruebas ágiles
Los cuadrantes de pruebas ágiles separan todo el proceso en cuatro cuadrantes y ayudan a comprender cómo se realizan las pruebas ágiles.
a) Cuadrante ágil I : la calidad del código interno es el enfoque principal en este cuadrante y consta de casos de prueba impulsados por la tecnología y que se implementan para respaldar al equipo.
1. Pruebas unitarias
2.Pruebas de componentes
b) Cuadrante ágil II : contiene casos de prueba impulsados por el negocio y que se implementan para respaldar al equipo. Este cuadrante se centra en los requisitos. El tipo de prueba que se realiza en esta fase es
1. Prueba de ejemplos de posibles escenarios y flujos de trabajo
2. Prueba de la experiencia del usuario, como prototipos
3. Prueba de pareja
c) Cuadrante ágil III : este cuadrante proporciona información sobre los cuadrantes uno y dos. Los casos de prueba se pueden utilizar como base para realizar pruebas de automatización. En este cuadrante, se llevan a cabo muchas rondas de revisiones de iteraciones que generan confianza en el producto. El tipo de prueba que se realiza en este cuadrante es
1. Pruebas de usabilidad
2. Pruebas exploratorias
3. Emparejar pruebas con clientes
4. Pruebas colaborativas
5. Prueba de aceptación del usuario
d) Cuadrante ágil IV : este cuadrante se concentra en los requisitos no funcionales como el rendimiento, la seguridad, la estabilidad, etc. Con la ayuda de este cuadrante, la aplicación se realiza para ofrecer las cualidades no funcionales y el valor esperado.
1. Pruebas no funcionales, como pruebas de estrés y rendimiento.
2. Pruebas de seguridad con respecto a la autenticación y la piratería
3. Pruebas de infraestructura
4. Prueba de migración de datos
5. Prueba de escalabilidad
6. Prueba de carga
Desafíos de control de calidad con desarrollo de software ágil
a) Las posibilidades de error son más ágiles, ya que se da menos prioridad a la documentación, lo que eventualmente ejerce más presión sobre el equipo de control de calidad
b) Las nuevas funciones se introducen rápidamente, lo que reduce el tiempo disponible para que los equipos de prueba identifiquen si las funciones más recientes se ajustan a los requisitos y si realmente se adaptan a las necesidades comerciales.
c) A menudo se requiere que los probadores jueguen un rol de
d) Los ciclos de ejecución de las pruebas están muy comprimidos
e) Menos tiempo para preparar el plan de prueba
f) Para las pruebas de regresión, tendrán un tiempo mínimo
g) Cambio en su rol de guardián de la calidad a socio de Calidad
h) Los cambios y actualizaciones de requisitos son inherentes a un método ágil, convirtiéndose en el mayor desafío para QA
Riesgo de automatización en procesos ágiles
- La interfaz de usuario automatizada proporciona un alto nivel de confianza, pero su ejecución es lenta, su mantenimiento es frágil y su construcción es costosa. Es posible que la automatización no mejore significativamente la productividad de la prueba a menos que los probadores sepan cómo realizar la prueba.
- Las pruebas no confiables son una preocupación importante en las pruebas automatizadas. Arreglar pruebas fallidas y resolver problemas relacionados con pruebas frágiles debe ser una prioridad para evitar falsos positivos.
- Si las pruebas automatizadas se inician manualmente en lugar de a través de CI (Integración continua), existe el riesgo de que no se ejecuten con regularidad y, por lo tanto, pueden provocar la falla de las pruebas.
- Las pruebas automatizadas no reemplazan una prueba manual exploratoria. Para obtener la calidad esperada del producto, se requiere una mezcla de tipos y niveles de prueba.
- Muchas herramientas de automatización disponibles comercialmente proporcionan funciones simples como automatizar la captura y reproducción de casos de prueba manuales. Dicha herramienta fomenta las pruebas a través de la interfaz de usuario y conduce a pruebas inherentemente frágiles y difíciles de mantener. Además, almacenar casos de prueba fuera del sistema de control de versiones crea una complejidad innecesaria.
- Para ahorrar tiempo, muchas veces el plan de prueba de automatización está mal planificado o no está planificado, lo que provoca que la prueba falle.
- Los procedimientos de configuración y desmontaje de una prueba generalmente se pierden durante la automatización de la prueba, mientras que la realización de pruebas manuales, los procedimientos de configuración y desmontaje de una prueba suenan perfectamente
- Las métricas de productividad, como una cantidad de casos de prueba creados o ejecutados por día, pueden ser terriblemente engañosas y podrían llevar a realizar una gran inversión en la ejecución de pruebas inútiles.
- Los miembros del equipo de automatización ágil deben ser consultores eficaces: accesibles, cooperativos e ingeniosos, o este sistema fallará rápidamente.
- La automatización puede proponer y entregar soluciones de prueba que requieran demasiado mantenimiento continuo en relación con el valor proporcionado.
- Las pruebas automatizadas pueden carecer de la experiencia necesaria para concebir y ofrecer soluciones eficaces.
- Las pruebas automatizadas pueden tener tanto éxito que se quedan sin problemas importantes que resolver y, por lo tanto, se convierten en problemas sin importancia.
Conclusión
La metodología ágil en las pruebas de software implica realizar pruebas lo antes posible en el ciclo de vida del desarrollo de software. Exige una gran participación del cliente y un código de prueba tan pronto como esté disponible. El código debe ser lo suficientemente estable para llevarlo a la prueba del sistema. Se pueden realizar extensas pruebas de regresión para asegurarse de que los errores se corrijan y se prueben. Principalmente, la comunicación entre los equipos hace que las pruebas de modelos ágiles tengan éxito
