Pruebas ágiles

Las pruebas ágiles son un proceso de pruebas iterativo e incremental en el que los requisitos de software se incluyen/trabajan gradualmente a lo largo del proceso de prueba.

Han ganado mucha popularidad en los últimos 10 años, es una forma eficiente de probar software que ofrece resultados finales más eficientes que los métodos de prueba tradicionales.

Dado que el desarrollo y las pruebas se integran en este proceso, permite la detección y eliminación temprana de errores, lo que se traduce en menos costo y tiempo de desarrollo, tambien permite una alta calidad del producto ya que los errores se eliminan en la etapa inicial.

Los principios básicos sobre los que se realizan las pruebas ágiles son:

• Las pruebas ágiles son un proceso continuo y aseguran un progreso fluido del proyecto.
• Los requisitos de productos y negocios se realizan mediante retroalimentación continua, y esta se da de manera continua.
• En Agile Testing, el equipo de desarrollo, el equipo de pruebas y el cliente, están involucrados en el proceso de prueba
• Se requiere poca documentación en Agile Testing ya que todos los testers usan checklists reutilizables en lugar de documentos extensos. El principal enfoque esta en el proceso de pruebas
• El equipo de pruebas resuelve los errores a medida que ocurren, en la misma iteración. Esto da como resultado un código más simple y limpio.
• Las pruebas tradicionales se realizan después de que se desarrolla el software. Las pruebas ágiles se realizan junto con el proceso de desarrollo, lo que ayuda a reducir el tiempo de construcción.

Metodologias de Testing Ágil

TDD (Test Driven Development)

Desarrollo guiado por pruebas de software, o Test-driven development (TDD) es una práctica que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés) que normalmente son automatizadas. En primer lugar, se escribe una prueba y se verifica que la nueva prueba falla. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione. La idea es que los requisitos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que el software cumple con los requisitos que se han establecido.

ATDD (Acceptance Test Driven Development)

Acceptance test–driven development (ATDD) es una metodología de desarrollo basada en la comunicación entre los clientes, los desarrolladores y los testers. Ayuda a los desarrolladores y testers a comprender las necesidades del cliente antes de la implementación y permite que los clientes puedan conversar en su propio idioma de dominio.

ATDD está estrechamente relacionado con el desarrollo basado en pruebas (TDD). Se diferencia por el énfasis en la colaboración desarrollador-tester-cliente. ATDD abarca las pruebas de aceptación, pero se enfoca en que las pruebas de aceptación se escriban antes de que los desarrolladores comiencen a codificar.

BDD (Behaviour Driven Development)

BDD se basa en los mismos principios que TDD y ATDD. Por lo tanto, el código también se desarrolla de acuerdo con el caso de prueba creado en esta metodología de prueba.

El objetivo principal de este desarrollo es centrarse en la identificación de las necesidades y los resultados de negocio. El desarrollo debe estar relacionado con un resultado de negocio.

Los pasos que se siguen en BDD son:

• Primero, describe el comportamiento
• Creando el caso de prueba
• Escritura de código según el caso de prueba definido
• Continuar el proceso hasta que el código pase el caso de prueba.

Exploratory Testing

El testing exploratorio o pruebas exploratorias es un estilo o enfoque para la realización de pruebas de software. Su principal característica es que el aprendizaje, el diseño y la ejecución de las pruebas se realizan de forma simultánea. Se define el testing exploratorio como "un estilo de testing que enfatiza la libertad personal y la responsabilidad del tester para optimizar continuamente la calidad de su trabajo tratando el aprendizaje a través de las pruebas, el diseño de las pruebas, la ejecución de las pruebas y la interpretación del resultado de las pruebas como actividades que se apoyan mutuamente y que se ejecutan en paralelo a lo largo del proyecto."

Session-Based Testing

Es un método de prueba de software que tiene como objetivo combinar la responsabilidad y las pruebas exploratorias para proporcionar un descubrimiento rápido de defectos, un diseño de prueba creativo sobre la marcha, control de gestión e informes de métricas.

Las pruebas basadas en sesiones se pueden utilizar para introducir la medición y el control en un proceso de prueba inmaduro y pueden formar una base para mejoras significativas en la productividad y la detección de errores. Las pruebas basadas en sesiones pueden ofrecer beneficios cuando los requisitos formales no están presentes, están incompletos o cambian rápidamente.

Plan de Pruebas Ágil

El plan de pruebas ágiles incluye todos los tipos de pruebas realizadas en una iteración en particular. Incluye lo siguiente:

• Define el alcance de la prueba, los objetivos del sprint, la prueba y el grado en que se realizará la prueba.

• Especifica las herramientas de prueba que se utilizarán, los datos y las configuraciones para la prueba y el entorno en el que se realizará la prueba.

• Programa las tareas y frecuencia de las pruebas

• Define los métodos y técnicas de prueba

• Determina la experiencia y la formación necesarias para realizar las pruebas.

• Establece la prioridad de las pruebas según el punto de vista del cliente.

Cuadrantes del testing ágil

El cuadrante de prueba ágil divide todo el proceso de prueba en 4 partes. Esto hace que el proceso de prueba Agile sea fácil de entender.

El cuadrante Q1 incluye pruebas unitarias y pruebas de componentes, que pueden ser lo mismo, según el proyecto. Además, las pruebas de integración y API encajarían en el cuadrante Q1.

Estas pruebas suelen estar automatizadas con un marco de pruebas unitarias, las realiza el desarrollador y se pueden desarrollar utilizando técnicas como TDD. Estas pruebas están orientadas hacia la tecnología, en lugar de pruebas técnicas de bajo nivel que generalmente se ejecutan con integración continua.

El cuadrante Q2 incluye pruebas funcionales, ejemplos, pruebas de historia, prototipos, simulaciones y otros tipos de pruebas que podrían describirse como pruebas a nivel de sistema. Estas pruebas están automatizadas si es posible, pero también se pueden ejecutar manualmente. Están diseñados desde la perspectiva empresarial y pueden implicar el uso de técnicas como ATDD y BDD. Apoyan al equipo (o guían el desarrollo) de manera similar a las pruebas Q1. Por lo tanto, siempre se pueden ejecutar al considerar si se ha desarrollado lo correcto y también para verificar si algo se ha roto con el nuevo código.

El cuadrante Q3 incluye pruebas exploratorias, pruebas de escenarios, pruebas de usabilidad, pruebas de aceptación del usuario (UAT), pruebas alfa y beta y tipos de pruebas similares que son buenas para encontrar defectos y verificar si el sistema realmente hace lo que los usuarios esperan, no produce un lado desagradable efectos y no hace nada más que no debería hacer. Este cuadrante puede considerarse nivel de prueba de sistema o de aceptación. Estas pruebas suelen ser manuales, ya que son difíciles de automatizar y requieren experiencia e innovación del usuario y del evaluador.

El cuadrante Q4 incluye pruebas de rendimiento, carga, estrés y escalabilidad, pruebas de seguridad y otros tipos de pruebas no funcionales que Gregory y Crispin denominan atributos de calidad o pruebas de '-ilidad' en sus libros, es decir, pruebas de atributos de calidad como mantenibilidad, portabilidad e interoperabilidad. , así como pruebas de gestión de memoria, recuperación, migración de datos e infraestructura. Estas pruebas encuentran defectos no funcionales que están relacionados con los diferentes atributos de calidad. A menudo son de naturaleza bastante técnica y pueden requerir el uso de herramientas adicionales. El tester involucrado suele ser bastante técnico, ya sea un desarrollador o un tester especializado en estos tipos de pruebas. Estas pruebas se automatizan tanto como sea posible. Este cuadrante se puede clasificar como nivel de prueba de aceptación operativa o de sistema.

 Diferencia entre testing ágil y testing de cascada o waterfall

Ventajas del testing ágil

Ahorro de tiempo y dinero ya que las pruebas se llevan a cabo junto con el desarrollo. Los errores se corrigen al momento y no se requiere tiempo adicional para probar todo el software, encontrar errores y resolverlos.

Se requiere poca o ninguna documentación en las pruebas ágiles, ya que los testers utilizan técnicas que permiten minimizar la dependencia a los documentos.

• La retroalimentación también es parte del ciclo de vida de las pruebas ágiles y los usuarios y todo l equipo la dan después de cada iteración.

Conclusión

Agile testing ofrece un muy buen enfoque de pruebas y una gran cantidad de herramientas que nos ayudan a entregar un producto de calidad, el tener un enfoque en donde todo el equipo, incluido el cliente, esta involucrado durante todo el proceso y que además existe una mentalidad enfocada a la calidad con un aire de respeto y mejora continua definitivamente ayuda a que podamos entregar un producto de calidad en tiempo record