 |
| Imagen de: Blog de Lisa Crispin |
Cuando aplicamos metodologías de desarrollo de software predictivas (como por ejemplo cascada), las pruebas de software deben abarcar diferentes tipos de pruebas destinadas a probar tanto el lado funcional cliente como el lado técnico de la aplicación.
En metodologías ágiles, y en particular cuando aplicamos enfoques del Agile Testing, debemos igualmente considerar todos estos tipos de pruebas, con la complejidad adicional que debemos considerar iteraciones cortas, refactorizaciones e integraciones continuas.
Por lo tanto se hace necesario contar con un marco de referencia para planificar las pruebas en el Agile Testing, y esto es precisamente lo que nos suministrar los 4 cuadrantes del Agile Testing.
PMOInformatica presenta Pruebas de software Agile: Planificar con los 4 cuadrantes del Agile Testing (1era parte). En esta primera parte nos enfocaremos en describir las herramientas y en la segunda veremos como realizar la planificación.
Pruebas de software Agile: Planificar con los 4 cuadrantes del Agile Testing (1era parte)
¿Qué actividades debemos considerar en la planificación del Agile Testing?
Al igual que en proyectos de software de tipo predictivo (cascada), cuando usamos un enfoque Agile Testing debemos usar diferentes tipos de pruebas de software para distintos objetivos:
La ingeniería de software define múltiples tipos de pruebas que podemos realizar, tales como pruebas unitarias, pruebas funcionales de sistema, pruebas de desempeño, entre otras.
En un marco Agile Testing basado en técnicas de desarrollo guiado por pruebas (Test Driven Development – TDD), deberíamos considerar en nuestra planificación lo siguiente:
¿Qué actividades debemos considerar en la planificación del Agile Testing?
Al igual que en proyectos de software de tipo predictivo (cascada), cuando usamos un enfoque Agile Testing debemos usar diferentes tipos de pruebas de software para distintos objetivos:
- Asegurar que la funcionalidad entrega se ajusta a los requisitos del usuario.
- Identificar errores, es decir, se cumple la funcionalidad pero no puede concluir por un error.
- Identificar escenarios de ejecución no previstos por el usuario.
- Asegurar que la aplicación presta servicio bajo parámetros aceptables de desempeño (tiempo de respuesta), que soporta la carga y no colapsa.
- Asegurar que el código desarrollado es confiable, mantenible y puede crecer con la aplicación.
La ingeniería de software define múltiples tipos de pruebas que podemos realizar, tales como pruebas unitarias, pruebas funcionales de sistema, pruebas de desempeño, entre otras.
En un marco Agile Testing basado en técnicas de desarrollo guiado por pruebas (Test Driven Development – TDD), deberíamos considerar en nuestra planificación lo siguiente:
- Pruebas unitarias con TDD.
- Integración continúa.
- Garantizar que los requerimientos están definidos correctamente.
- Pruebas funcionales / Acceptance Test Driven Development (ATDD).
- Automatización de pruebas.
- Testing no funcional.
- Testing exploratorio.
Como podemos ver son muchas variables e información que considerar, ¿por dónde empezamos?, pues primero deberíamos clasificar los tipos de pruebas Agile que podemos hacer.
Más Información sobre Software Testing
> Visita nuestra página de Recursos en Pruebas de Software
¿Cómo puedo organizar y planificar las pruebas Agile Testing?
Como vimos en el artículo sobre Que es el Agile Testing y cuáles son sus principios y estrategias, para dar sentido a toda esta información nos apoyamos en los 4 cuadrantes del Agile Testing.
Los cuadrantes del Agile Testing fueron definidos originalmente por Brian Marick en un post sobre el tema y luego adaptados por Lista Crispin y Janet Gregory en su obra “Agile Testing”.
Son una herramienta que nos otorga una librería de tipos de pruebas Agile que podemos hacer para lograr distintos objetivos. Aquí una imagen de los cuadrantes.
 |
| Imagen de: Blog de Lisa Crispin |
La matriz tiene dos ejes o dimensiones, en el eje horizontal dividimos las pruebas en Apoyo al equipo (Supporting the Team) y pruebas de crítica al producto (Critique the Product), mientras que en el eje vertical dividimos las pruebas en de cara a tecnología (Technology Facing) y de cara al negocio (Business Facing).
Pruebas de apoyo al equipo (Supporting the Team)
Destinadas a apoyar al equipo de desarrollo en la medida en que este desarrolla el producto. Este concepto es nuevo para muchos testers dado que el Testing tradicional es para encontrar fallas.
Se realizan en los cuadrantes 1 y 2 del Agile Testing.
Cuando nos referimos que son pruebas de apoyo al equipo, es porque las pruebas de cuadrante 1 y 2 se convierten prácticamente en la base de un equipo de desarrollo ágil.
Estas pruebas primeramente guían el desarrollo de la funcionalidad, y luego cuando se automatizan sirven para apoyar la refactorización y la inclusión de nuevo código sin causar resultados inesperados en el comportamiento del sistema.
Cuadrante 1: Pruebas de apoyo al equipo de cara a tecnología
Es el de abajo a la izquierda y representa el desarrollo guiado por pruebas (Test Driven Development – TDD) que es la base fundamental del Agile Testing.
Tenemos una serie de artículos sobre Test Driven Development que te recomendamos consultar para ahondar más en el tema.
> Test Driven Development (TDD): Desarrollo de software guiado por pruebas
> Test Driven Development (TDD): 9 retos para su implementación
> Test Driven Development (TDD): Ventajas y desventajas
> Test Driven Development (TDD): Como llevarlo a la práctica
El cuadrante 1 incluye los siguientes tipos de pruebas:
- Pruebas unitarias: Verifican la funcionalidad de un pequeño subconjunto del sistema como por ejemplo un objeto o método.
- Pruebas de componente: Verifican el comportamiento de un grupo más grande del sistema, por ejemplo un grupo de clases, que proveen cierto servicio.
También se les suele llamar pruebas de programador, pruebas de cara a desarrollador o pruebas de cara a tecnología. Suelen automatizarse usando alguna herramienta de la familia de xUnit, en el mismo lenguaje de programación usado para fabricar la aplicación.
Estas son pruebas de calidad interna. La calidad interna no es definida por el cliente (son de naturaleza técnica) sino por los programadores para lograr cumplir los requerimientos funcionales y no funcionales solicitados.
Las pruebas unitarias y de componentes pasaran a formar parte del proceso de Check-in ejecutado cada vez que se incluyen cambios en el código, otorgando así feedback inmediato.
Cuadrante 2: Pruebas de apoyo al equipo de cara al negocio
Las pruebas de este cuadrante, también sirven de apoyo al equipo de desarrollo de software pero a un mayor nivel de visión.
Las pruebas de cara a negocio también se pueden llamar pruebas de cara a cliente o simplemente pruebas de cliente. Estas definen la calidad externa y las funcionalidades que el cliente solicita.
Las pruebas de cuadrante 2 (Funcionales, ejemplos, pruebas de historias, etc.)
- Se derivan de ejemplos que suministra el equipo del cliente.
- Describen los detalles de cada historia de usuario.
- Se ejecutan a un nivel funcional y verifican condiciones de satisfacción definidas por el negocio.
- Se escriben usando un lenguaje que los expertos en el negocio (no necesariamente informáticos de profesión) puedan entender. De hecho los expertos del negocio usan estas pruebas en las definiciones de calidad externa y participan en su elaboración.
- Pueden duplicar pruebas ya realizadas en el cuadrante 1, pero a un nivel superior (nivel funcional).
- Están orientadas a ilustrar y confirmar el comportamiento deseado del sistema.
Automatización de pruebas del cuadrante 2
Las pruebas del cuadrante 2 también pueden ser automatizadas.
- La automatización permite identificar y solucionar errores rápidamente.
- Deben ejecutarse con frecuencia para dar alerta temprana al equipo.
- Si es posible, es recomendable ejecutarlas directamente en la capa de lógica de negocio.
- Aún así algunas de estas pruebas deben ser ejecutadas desde la perspectiva del cliente, es decir desde la interfaz de usuario.
La automatización de este último punto se puede realizar con herramientas como Selenium WebDriver, que permiten invocar pantallas de aplicaciones web como si lo estuviera realizando un usuario.
Herramientas como Selenium permiten automatizar pruebas con una variedad de lenguajes de programación para el Scripting, como por ejemplo Ruby, Python, Java y más.
Pruebas de prototipos de interfaces con el usuario
Las pruebas destinadas a validar la interfaz de usuario propuestas (prototipos) también pertenecen a este cuadrante.
En estas pruebas, los encargados de diseñar la interfaz con el usuario elaboran pantallas de ejemplos o wireframes, los cuales validan con el cliente (usuario) antes que comience el desarrollo.
Una vez comienza el desarrollo, estos expertos son los encargados de comunicar a los desarrolladores de software esos diseños y resolver sus dudas que puedan presentarse.
Pruebas de críticas al producto (Critique the Product)
Cuando nos referimos a “críticas al software”, no tienen necesariamente un sentido negativo, pues estás pueden ser inclusive para resaltar aspectos positivos o inclusive sugerir mejoras.
Para un cliente es muy difícil saber de antemano lo que quiere hasta verlo plasmado en un producto de características mínimas, esta es una realidad con la que toda metodología de desarrollo de software debe lidiar.
Cuadrante 3: Pruebas que critican el producto de cara al negocio
- En la fase de análisis, los analistas de sistemas y expertos de negocio se encargan de obtener ejemplos y especificar los casos.
- Este proceso no está libre de errores pues estos expertos podrían omitir casos o representarlos erróneamente cuando por ejemplo están fuera de su área de experticia.
- Inclusive, cuando el código esté desarrollado de acuerdo al ejemplo y pase la prueba, aún existe la posibilidad que esto no sea lo que el cliente realmente quiere.
- Aquí entran en juego las pruebas del cuadrante 3, en las cuales se ejecuta la aplicación en su conjunto (es una prueba integral) para determinar si cumple o no las expectativas.
- Cuando se realizan estas pruebas, se trata de emular lo más posible el entorno real en que serán ejecutadas.
- Por lo tanto, son pruebas funcionales manuales y sólo las pueden ejecutar personas (no maquinas).
- Se puede recurrir a algún grado de automatización por ejemplo para preparar los datos de prueba, sin embargo al ejecutarla debe utilizarse la intuición para saber si el producto cumple las expectativas y proporciona valor al área de negocio.
- Usualmente estas pruebas son ejecutadas por el equipo del cliente (los usuarios finales), en la forma de pruebas de aceptación (UAT).
- Las pruebas de usabilidad forman parte de este cuadrante y representan en sí mismas todo un campo de estudio. Pueden involucrar hasta inclusive los Focus Groups para identificar las formas en que realmente los usuarios utilizaran el nuevo sistema.
- En este cuadrante, el Testing exploratorio es un aspecto central. En el testing exploratorio, el tester diseña y ejecuta la prueba al mismo tiempo. Ambos procesos se retroalimentan, es decir de la ejecución de la prueba y análisis crítico de los resultados, se aprende más sobre el negocio y la aplicación se rediseña la prueba y se repite el proceso.
Cuadrante 4: Pruebas que critican el producto
Las pruebas del cuadrante 4 son enteramente de naturaleza técnica (no funcional) y son tan críticas para el Agile Testing como cualquier metodología de desarrollo de sistemas.
La intención es analizar y someter a pruebas de extremo a características no funcionales como el desempeño, robustez y seguridad.
Muchas de las herramientas para hacer estas pruebas ya estarán desarrolladas en el cuadrante 1, por ejemplo reusando las pruebas unitarias para hacer múltiples ejecuciones multi-hilo, sin embargo, esto no quiere decir que no requieras herramientas adicionales o personal especializado.
Las pruebas del cuadrante 4 tienen mucho que ver con validar que se cumplan los requerimientos no funcionales, tenemos una serie de artículos sobre el tema si quieres profundizar más:
> Requerimientos No Funcionales: Porque son importantes
> Requerimientos no funcionales: Una clasificación
En la próxima parte
En esta primera parte nos enfocamos en describir la herramienta que usamos para seleccionar los tipos de pruebas de nuestra planificación de Agile Testing, que son los 4 cuadrantes del Agile Testing.
En la próxima parte, veremos como utilizar estas herramientas para definir el enfoque de pruebas y algunos tips para la planificación. Aquí el enlace a la segunda parte de este artículo:
Pruebas de software Agile: Planificar con los 4 cuadrantes del Agile Testing (2da parte)
¿Y qué opinas tú?
¿Has aplicado metodologías ágiles o el Agile Testing?, ¿Cuéntanos tu experiencia?, ¿Cuáles son los factores críticos para el éxito?, expresa tu opinión en la sección de comentarios.
<< Artículo anterior: Que es el Agile Testing y cuáles son sus principios y estrategias
¿Buscas más información de metodologías ágiles?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia de proyectos y metodologías ágiles?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
> Que es el Agile Testing y cuáles son sus principios y estrategias
No hay comentarios :
Publicar un comentario