Tema 3.3 - Técnicas en proyectos ágiles

Criterios de aceptación, cobertura adecuada y otra información para las pruebas

Los proyectos ágiles describen los requisitos iniciales como historias de usuario en una cartera de pedidos priorizada al inicio del proyecto, los requisitos iniciales son breves y normalmente siguen un formato predefinido, los requisitos no funcionales, como la usabilidad y el rendimiento, también son importantes y pueden especificarse como historias de usuarios únicas o conectarse a otras historias de usuarios funcionales, los requisitos no funcionales pueden seguir un formato o estándar predefinido, como ISO25000, o un estándar específico de la industria.

Las historias de usuario sirven como base de prueba importante, otras posibles bases de prueba incluyen:

• Experiencia de proyectos anteriores
• Funciones, características y características de calidad existentes del sistema
• Código, arquitectura y diseño
• Perfiles de usuario (contexto, configuraciones del sistema y comportamiento del usuario)
• Información sobre defectos de proyectos existentes y anteriores
• Una categorización de defectos en una taxonomía de defectos
• Estándares aplicables (por ejemplo, DO-178B para software de aviónica)
• Riesgos de calidad

Durante cada iteración, los desarrolladores crean un código que implementa las funciones y características descritas en las historias de usuario, con las características de calidad relevantes, y este código se verifica y valida mediante pruebas de aceptación, para ser comprobable, los criterios de aceptación deben abordar los siguientes temas cuando sea relevante

• Comportamiento funcional:

  El comportamiento observable externamente con acciones del usuario como entrada que opera bajo ciertas configuraciones.

• Características de calidad:

  cómo el sistema realiza el comportamiento especificado, las características también pueden denominarse atributos de calidad o requisitos no funcionales, las características de calidad comunes son rendimiento, confiabilidad, facilidad de uso, etc.

• Escenarios (casos de uso): una secuencia de acciones entre un actor externo (a menudo un usuario) y el sistema, con el fin de lograr una meta o tarea comercial específica.

• Reglas comerciales: actividades que solo se pueden realizar en el sistema bajo ciertas condiciones definidas por procedimientos y restricciones externas por ejemplo, (los procedimientos utilizados por una compañía de seguros para manejar reclamos de seguros).

• Interfaces externas: Descripciones de las conexiones entre el sistema a desarrollar y el mundo exterior. Las interfaces externas se pueden dividir en diferentes tipos (interfaz de usuario, interfaz con otros sistemas, etc.).

• Restricciones: cualquier restricción de diseño e implementación que restrinja las opciones para el desarrollador, los dispositivos con software integrado a menudo deben respetar las limitaciones físicas como el tamaño, el peso y las conexiones de interfaz.

• Definiciones de datos:

  el cliente puede describir el formato, tipo de datos, valores permitidos y valores predeterminados para un elemento de datos en la composición de una estructura de datos comerciales compleja (por ejemplo, el código postal en una dirección de correo de EE. UU.).

Además de las historias de usuario y sus criterios de aceptación asociados, otra información que es relevante para el evaluador, incluye:

• Cómo se supone que debe funcionar y usarse el sistema
• Las interfaces del sistema que se pueden usar / acceder para probar el sistema
• Si el soporte de herramientas actual es suficiente
• Si el probador tiene suficiente conocimiento y habilidad para realizar las pruebas necesarias.

Los probadores a menudo descubrirán la necesidad de información adicional (por ejemplo, cobertura de código) a lo largo de las iteraciones y deben trabajar en colaboración con el resto de los miembros del equipo Agile para obtener esa información, la información relevante juega un papel importante en la determinación de si una actividad en particular puede considerarse realizada, este concepto de la definición de hecho es fundamental en los proyectos ágiles y se aplica de varias formas diferentes, como se explica en las siguientes subsecciones.

 

Niveles de prueba

Cada nivel de prueba tiene su propia definición de terminado. La siguiente lista ofrece ejemplos que pueden ser relevantes para los diferentes niveles de prueba.

Prueba unitaria:

• Cobertura de decisiones del 100% cuando sea posible, con revisiones cuidadosas de cualquier camino inviable
• Análisis estático realizado en todo el código.
• Sin defectos importantes no resueltos (clasificados según la prioridad y la gravedad)
• No queda ninguna deuda técnica inaceptable conocida en el diseño y el código
• Se revisaron todos los códigos, las pruebas unitarias y los resultados de las pruebas unitarias.
• Todas las pruebas unitarias automatizadas
• Las características importantes están dentro de los límites acordados (por ejemplo, rendimiento)

 

Prueba de integración:

• Todos los requisitos funcionales probados, incluidas las pruebas positivas y negativas, con el número de pruebas según el tamaño, la complejidad y los riesgos.
• Todas las interfaces entre unidades probadas
• Todos los riesgos de calidad cubiertos de acuerdo con el alcance acordado de las pruebas.
• Sin defectos importantes no resueltos (priorizados según riesgo e importancia)
• Todos los defectos encontrados se informan
• Todas las pruebas de regresión automatizadas, cuando sea posible, con todas las pruebas automatizadas almacenadas en un repositorio común

 

• Prueba del sistema
• Pruebas de extremo a extremo de historias de usuario, características y funciones.
• Todas las personas del usuario cubiertas
• Las características de calidad más importantes del sistema cubierto (por ejemplo, rendimiento, solidez, confiabilidad)
• Pruebas realizadas en un entorno similar a la producción, incluido todo el hardware y software para todas las configuraciones compatibles, en la medida de lo posible.
• Todos los riesgos de calidad cubiertos de acuerdo con el alcance acordado de las pruebas.
• Todas las pruebas de regresión automatizadas, cuando sea posible, con todas las pruebas automatizadas almacenadas en un repositorio común
• Todos los defectos encontrados se informan y posiblemente se corrigen
• Sin defectos importantes no resueltos (priorizados según riesgo e importancia)

 

Historia del usuario

La definición de hecho para historias de usuario puede determinarse mediante los siguientes criterios:

• Las historias de usuario seleccionadas para la iteración están completas, son entendidas por el equipo y tienen criterios de aceptación detallados y comprobables.

• Se han especificado y revisado todos los elementos de la historia del usuario, incluidas las pruebas de aceptación de la historia del usuario.

• El equipo ha identificado y estimado las tareas necesarias para implementar y probar las historias de usuario seleccionadas.

 

Feature

La definición de hecho para features, que pueden abarcar múltiples historias de usuarios o épicas, puede incluir:

• Todas las historias de usuarios constituyentes, con criterios de aceptación, son definidas y aprobadas por el cliente.
• El diseño está completo, sin deuda técnica conocida
• El código está completo, sin deuda técnica conocida o refactorización inconclusa
• Se han realizado pruebas unitarias y se ha alcanzado el nivel de cobertura definido.
• Las pruebas de integración y las pruebas del sistema para la función se han realizado de acuerdo con los criterios de cobertura definidos.
• No quedan defectos importantes por corregir
• La documentación de las funciones está completa, que puede incluir notas de la versión, manuales de usuario y funciones de ayuda en línea.

 

Iteración

La definición de hecho para la iteración puede incluir lo siguiente:

• Todas las funciones para la iteración están listas y probadas individualmente de acuerdo con los criterios de nivel de función.
• Cualquier defecto no crítico que no se pueda arreglar dentro de las limitaciones de la iteración agregado a la cartera de productos y priorizado
• Integración de todas las funciones para la iteración completada y probada
• Documentación escrita, revisada y aprobada

En este punto, el software es potencialmente liberable porque la iteración se ha completado con éxito, pero no todas las iteraciones dan como resultado una versión.

 

Lanzamiento

La definición de hecho para un lanzamiento, que puede abarcar varias iteraciones, puede incluir las siguientes áreas:

• Cobertura: Todos los elementos de base de prueba relevantes para todos los contenidos de la versión han sido cubiertos por pruebas. La adecuación de la cobertura está determinada por lo que es nuevo o modificado, su complejidad y tamaño, y los riesgos de falla asociados.

• Calidad: La intensidad del defecto (por ejemplo, cuántos defectos se encuentran por día o por transacción), la densidad de defectos (por ejemplo, el número de defectos encontrados en comparación con el número de historias de usuario, esfuerzo y / o atributos de calidad), estimado el número de defectos restantes está dentro de los límites aceptables, las consecuencias de los defectos no resueltos y restantes (por ejemplo, la gravedad y la prioridad) se entienden y son aceptables, el nivel residual de riesgo asociado con cada riesgo de calidad identificado se comprende y es aceptable.

• Hora: si se ha alcanzado la fecha de entrega predeterminada, se deben considerar las consideraciones comerciales asociadas con la liberación y no la liberación.

• Costo: El costo estimado del ciclo de vida debe usarse para calcular el retorno de la inversión para el sistema entregado (es decir, el costo de desarrollo y mantenimiento calculado debe ser considerablemente más bajo que las ventas totales esperadas del producto). La mayor parte del costo del ciclo de vida a menudo proviene del mantenimiento después de que el producto ha sido lanzado, debido a la cantidad de defectos que se escapan a la producción.

 

Aplicación del desarrollo basado en pruebas de aceptación

El desarrollo impulsado por pruebas de aceptación es un enfoque donde se debe realizar primero que todo las pruebas. Los casos de prueba se crean antes de implementar la historia del usuario, los casos de prueba son creados por el equipo Agile, incluido el desarrollador, el evaluador y los representantes comerciales y pueden ser manuales o automatizados.

• El primer paso es un taller de especificación en el que los desarrolladores, evaluadores y representantes comerciales analizan, discuten y escriben la historia del usuario, cualquier incompletitud, ambigüedades o errores en la historia del usuario se corrigen durante este proceso.

• El siguiente paso es crear las pruebas, esto puede hacerlo el equipo en conjunto o el evaluador individualmente, en cualquier caso, una persona independiente como un representante comercial, valida las pruebas, las pruebas son ejemplos que describen las características específicas de la historia del usuario, estos ejemplos ayudarán al equipo a implementar correctamente la historia del usuario. Dado que los ejemplos y las pruebas son los mismos, estos términos a menudo se usan indistintamente, el trabajo comienza con ejemplos básicos y preguntas abiertas. 

• Normalmente, las primeras pruebas son las pruebas positivas, que confirman el correcto comportamiento sin excepción o condiciones de error, que comprenden la secuencia de actividades ejecutadas si todo sale como se esperaba.

• Una vez realizadas las pruebas de ruta positivas, el equipo debe escribir pruebas de ruta negativas y cubrir también los atributos no funcionales por ejemplo, (rendimiento, usabilidad), Las pruebas se expresan de una manera que todos los interesados ​​pueden comprender, y contienen oraciones en lenguaje natural que incluyen las condiciones previas necesarias (si las hay), las entradas y las salidas relacionadas.
  

 

Los ejemplos deben cubrir todas las características de la historia del usuario y no deben agregarse a la historia, esto significa que no debería existir un ejemplo que describa un aspecto de la historia del usuario que no esté documentado en la historia misma, además, no hay dos ejemplos que describan las mismas características de la historia del usuario.

 

Diseño de prueba de caja negra funcional y no funcional

En las pruebas ágiles, los evaluadores crean muchas pruebas al mismo tiempo que las actividades de programación de los desarrolladores.

Así como los desarrolladores programan en función de las historias de usuario y los criterios de aceptación, los probadores también crean pruebas basadas en las historias de los usuarios y sus criterios de aceptación (Algunas pruebas, como las pruebas exploratorias y algunas otras pruebas basadas en la experiencia, se crean más tarde, durante la ejecución de la prueba).

los evaluadores pueden aplicar técnicas tradicionales de diseño de pruebas de caja negra, como la división por equivalencia, el análisis de valor límite, tablas de decisión y pruebas de transición de estado para crear estas pruebas, por ejemplo, el análisis de valor límite podría usarse para seleccionar valores de prueba cuando un cliente está limitado en el número de artículos que puede seleccionar para comprar, recordemos que las pruebas de caja negra, son aquellas en la cuales la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software; es decir,  nos enfocamos solamente en las entradas y salidas del sistema, sin preocuparnos en tener conocimiento de la estructura interna del programa de software, para obtener el detalle de cuáles deben ser esas entradas y salidas, nos basamos en los requerimientos de software y especificaciones funcionales

En muchas situaciones, los requisitos no funcionales se pueden documentar como historias de usuario. Las técnicas de diseño de pruebas de caja negra (como el análisis de valor límite) también se pueden utilizar para crear pruebas de características de calidad no funcionales, la historia de usuario puede contener requisitos de rendimiento o confiabilidad, por ejemplo, una ejecución determinada no puede exceder un límite de tiempo o varias operaciones pueden fallar menos de un cierto número de veces.

 

Pruebas exploratorias y pruebas ágiles

Las pruebas exploratorias son importantes en los proyectos ágiles debido al tiempo limitado disponible para el análisis de pruebas y los detalles limitados de las historias de usuario, para lograr los mejores resultados, las pruebas exploratorias deben combinarse con otras técnicas basadas en la experiencia como parte de una estrategia de prueba reactiva, combinadas con otras estrategias de prueba como las pruebas analíticas basadas en riesgos, las pruebas analíticas basadas en requisitos, las pruebas basadas en modelos y pruebas de aversión a la regresión.

En las pruebas exploratorias, el diseño de la prueba y la ejecución de esta ocurren al mismo tiempo, guiados por una carta de prueba preparada, una carta de prueba proporciona las condiciones de prueba que se deben cubrir durante una sesión de tiempo limitado, durante las pruebas exploratorias, los resultados de estas más recientes guían la siguiente prueba, se pueden utilizar las mismas técnicas de caja blanca y caja negra para diseñar las pruebas que cuando se realizan pruebas prediseñadas.

 

Una carta de prueba puede incluir la siguiente información:

• Actor: usuario previsto del sistema

• Propósito: el tema de la carta incluyendo el objetivo particular que el actor quiere lograr, es decir, las condiciones de prueba

• Configuración: lo que debe estar en su lugar para comenzar la ejecución de la prueba

• Prioridad: importancia relativa de esta carta, basada en la prioridad de la historia de usuario asociada o el nivel de riesgo

• Referencia: especificaciones (por ejemplo, historia de usuario), riesgos u otras fuentes de información

• Datos: cualquier dato necesario para llevar a cabo la carta

• Actividades: una lista de ideas de lo que el actor puede querer hacer con el sistema (por ejemplo, "Iniciar sesión en el sistema como súper-usuario") y lo que sería interesante probar (pruebas positivas y negativas)

• Notas de Oracle: cómo evaluar el producto para determinar los resultados correctos (por ejemplo, para capturar lo que sucede en la pantalla y compararlo con lo que está escrito en el manual del usuario)

• Variaciones: acciones alternativas y evaluaciones para complementar las ideas descritas en actividades

Para gestionar las pruebas exploratorias, se puede utilizar un método denominado gestión de pruebas basada en sesiones. Una sesión se define como un período ininterrumpido de prueba que puede durar de 60 a 120 minutos. Las sesiones de prueba incluyen lo siguiente:

• Sesión de encuesta (para saber cómo funciona)
• Sesión de análisis (evaluación de la funcionalidad o características)
• Cobertura profunda (casos de esquina, escenarios, interacciones)

La calidad de las pruebas depende de la capacidad de los evaluadores para hacer preguntas relevantes sobre qué probar. Los ejemplos incluyen lo siguiente:

• ¿Qué es más importante averiguar sobre el sistema?
• ¿De qué manera puede fallar el sistema?
• ¿Qué pasa si.....?
• ¿Qué debería suceder cuando.....?
• ¿Se cumplen las necesidades, requisitos y expectativas del cliente?
• ¿Es posible instalar el sistema (y eliminarlo si es necesario) en todas las rutas de actualización admitidas?

 

Durante la ejecución de la prueba, el evaluador utiliza la creatividad, la intuición, la cognición y la habilidad para encontrar posibles problemas con el producto, el evaluador también debe tener un buen conocimiento y comprensión del software bajo prueba, el dominio comercial, cómo se usa el software y cómo determinar cuándo falla el sistema.

Se puede aplicar un conjunto de heurísticas al realizar pruebas, una heurística puede guiar al evaluador sobre cómo realizar la prueba y evaluar los resultados, Ejemplos incluyen:

• Límites
• CRUD (Crear, Leer, Actualizar, Eliminar)
• Variaciones de configuración
• Interrupciones (por ejemplo, cerrar sesión, apagar o reiniciar)

Es importante que el evaluador documente el proceso tanto como sea posible, de lo contrario, sería difícil volver atrás y ver cómo se descubrió un problema en el sistema, la siguiente lista proporciona ejemplos de información que puede ser útil documentar:

• Cobertura de prueba: qué datos de entrada se han utilizado, cuánto se ha cubierto y cuánto queda por probar

• Notas de evaluación: observaciones durante la prueba, si el sistema y la característica bajo prueba parecen estables, si se encontraron defectos, lo que se planea como el próximo paso de acuerdo con las observaciones actuales y cualquier otra lista de ideas.

• Lista de riesgos / estrategias: qué riesgos se han cubierto y cuáles permanecen entre los más importantes, se seguirá la estrategia inicial, si necesita algún cambio

• Problemas, preguntas y anomalías: cualquier comportamiento inesperado, cualquier pregunta con respecto a la eficiencia del enfoque, cualquier inquietud sobre las ideas / intentos de prueba, entorno de prueba, datos de prueba, malentendidos de la función, guion de prueba o el sistema bajo prueba.

• Comportamiento real: registro del comportamiento real del sistema que debe guardarse (por ejemplo, video, capturas de pantalla, archivos de datos de salida)

La información registrada debe capturarse y / o resumirse en algún tipo de herramientas de gestión de estado (por ejemplo, herramientas de gestión de pruebas, herramientas de gestión de tareas, el tablero de tareas), de manera que sea fácil para las partes interesadas comprender el estado actual de todas las pruebas que se realizó.