Dalia Trujillo

Líder en calidad y desarrollo de software. Hacemos que las empresas aumenten dramáticamente su calidad y velocidad de desarrollo, a través de Enjisst (Plataforma) y PAREX (Metodo de agilidad pragmática)

10 de abril de 2023

Introducción:

Las pruebas de software han evolucionado desde el modelo cascada al iterativo, del iterativo al ágil y de la ágil a DevOps. Cada uno más avanzado y exigente que el anterior.

Las metodologías iterativas nos concientizan de la necesidad de probar “por partes” dado que el proyecto que se realizan en “mini-cascadas”. Estas “mini-cascadas” ayudan a que las validaciones no queden al final dando la posibilidad de detectar errores de forma más pronta. También nos enseña que es necesario que los tiempos de ejecutar las pruebas de regresión sean menores, y por eso impulsan la automatización cuando el software que ya está desarrollado “y estable”.

Retos de la Agilidad:

Agilidad nos trae unos retos diferentes en pruebas, más allá de ejecutar varias veces las pruebas. Lo voy a resumir en dos retos principales:

El primer reto es la cross-funcionalidad que significa la colaboración entre los diferentes roles para poder ejecutar las pruebas no solamente al final de la iteración sino en medio de la iteración, incluso en los primeros días de la iteración. Ese es el reto que se tiene en pruebas, cuando estamos hablando de agilidad: Las iteraciones que dejan las pruebas al final no son agiles; las pruebas que se dejan para después de la iteración, mucho menos.

Las pruebas continuas a lo largo del sprint es un gran diferencial que hay entre la agilidad y el manejo iterativo.

Y el segundo reto que trae la agilidad es que se prevengan los errores por medio del TDD (desarrollo dirigido por pruebas). TDD nos invita a que al momento de definir el requerimiento se identifiquen los escenarios de prueba que deben ser cubiertos por el desarrollo que vamos a hacer, así se pueden prevenir los errores que se generan cuando un desarrollador no tiene claridad de todos los “caminos de uso” que debe cubrir su código. Y el reto más interesante es que nos invita a automatizar los escenarios de prueba antes de codificar.

¿Porque es útil este enfoque?

1. Para que haya disponibilidad para el desarrollador un conjunto suficientemente completo de pruebas, que se pueden ejecutar de forma rápida hasta que se valide que todo su desarrollo es correcto.

2. Queda de una vez listo para que se incluya en las pruebas de regresión, que ya sabemos que son fundamentales para demostrar que el software no se ha dañado a lo largo del desarrollo de nuevas funcionalidades.

3. El tercero, consecuencia del anterior y muy necesario cuando hablamos de agilidad, es que nos permite el refactoring. Se llama el refactoring el volver a desarrollar lo que ya estaba desarrollado cambiando su diseño para mejorarlo, o para ampliarlo. El refactoring es una consecuencia propia de la agilidad porque la agilidad está hecha para el cambio continuo del software, incluyendo el cambio de la conceptualización del software y diseño. Por ese motivo debemos prepararnos para el refactoring como algo propio de las metodologías ágiles: el TDD nos prepara para el refactoring.

El TDD nace desde el concepto de la automatización de las pruebas de componentes. Pero Dan North posteriormente cae en cuenta que, aunque este concepto es poderoso, es muy limitado dado que pierde la visión sistémica necesaria del desarrollo de software, y por eso crea el llamado BDD, en donde se pretende que tenga el mismo concepto de desarrollo dirigido por pruebas, pero ya no desde el punto de vista de componente, sino desde el punto de vista de pruebas de sistema, teniendo en cuenta el sistema completo.

¿Y DevOps?

DevOps efectúa la salida a producción continua y la colaboración requerida entre desarrolladores y operadores. La salida a producción continua nos quita el concepto que antes existía que era la fase de estabilización, debido al despliegue continuo.

¿Qué implicaciones tiene en término de pruebas?

Por un lado, la automatización de la validación del software pasa a otro nivel, dado que el objetivo ya no es solo disminuir los tiempos de ejecución, sino que se realice de forma autónoma sin intervención humana, como parte del pipeline del despliegue y con el poder de devolver automáticamente la puesta a producción si existe algún error en el software, todo sin asistencia.

Además, deben existir mecanismos orientados al seguimiento de la calidad en producción operación, para validar de forma automática que el comportamiento es el esperado después del despliegue y a lo largo de su uso, generar las alarmas si esto no llega a pasar, y mecanismos de seguimiento al error que permitan hacer verificación y posterior planeación de la solución de un error cuando se está en producción de forma continua, y corrección de datos si es necesario.

En conclusión, ya no hay fase de prueba, ni mini-fase de prueba, ni micro-fase de prueba. Agilidad y DevOps requieren de continua interacción del equipo alrededor de la calidad y las diferentes actividades de pruebas se realizan todo el tiempo para servicio de todo el equipo y por supuesto, del cliente final.

Bibliografía

• Berg, Craig. DevOps for Beginners. A complete guide to DevOps Best Practices, Including How You Can Create World-Class Agility, Reliability, And Security In Technology Organizations With DevOps, Edición de Kindle.
• Bergstr, Stefan. Adopting the Rational Unified Process: Success with the RUP. Addison Wesley. 2004
• Crispin, Lisa. Agile Testing (Addison-Wesley Signature Series (Cohn)). Pearson Education. 2009. Edición de Kindle.
• Crispin, Lisa. Gregory, Janet. More Agile Testing, Learning Journeys for The Whole Team (Addison-Wesley Signature Series (Cohn)). Pearson Education. 2015. Edición de Kindle.
• J. Humble, C. Read and D. North, “The deployment production line,” AGILE 2006 (AGILE’06), Minneapolis, MN, 2006, pp. 6 pp.-118, doi: 10.1109/AGILE.2006.53.
• Krutchen, Phillippe. The Rational Unified Process: An introduction. Addison Wesley. 2004.
• Smith, Larry. “Shift-Left Testing”, Dr Dobbs, 2001

El cargo Pruebas ágiles, para llevar adecuadamente la agilidad en el desarrollo de software apareció primero en Enjisst.

Dalia Trujillo

Líder en calidad y desarrollo de software. Hacemos que las empresas aumenten dramáticamente su calidad y velocidad de desarrollo, a través de Enjisst (Plataforma) y PAREX (Metodo de agilidad pragmática)

21 de mayo de 2020

El tema de pruebas ha tenido evolución dramática a lo largo de los últimos años, según lo he visto y experimentado desde que inicié a trabajar en proyectos de software. Hace 28 años, cuando empecé mi experiencia en proyectos de software, había claridad que la metodología a aplicar era cascada, y se creía que el aspecto clave del éxito del proyecto era que los requerimientos estuvieran muy bien definidos; de forma que lo único que se debía hacer en la etapa de pruebas era validar el correcto cumplimiento de esos requerimientos. Sin embargo, en ese momento pruebas no era rol especial, más bien era una etapa donde se validaban los requerimientos, y no había conciencia de lo extenso y profundo que puede ser la validación del software.

Hace unos 20 años, por lo menos en Colombia, empiezan algunas organizaciones a crear conciencia de la necesidad del rol, y hace 10 años ya se podían encontrar en varias empresas las áreas de Calidad, pruebas, QA o el nombre que fuera más apropiado para la empresa.

Si bien, las técnicas de calidad son mayores en las organizaciones, lo que redunda en principio, en mayor calidad para el software, fue implementado de forma taylorista , por silos,  en donde después de hacer el desarrollo se pasa a una etapa de validación, para “filtrar” los errores y que no pasen a producción.

Al igual que en cualquier aprendizaje, el medio primero aplicó las técnicas básicas para entender los pasos necesarios para producir software con mayor calidad. Se crearon mecanismos para que las personas entendieran esas técnicas, lo que se puede encontrar en los entes certificadores de conocimiento sobre pruebas, y se ve mucha mayor evolución de conciencia en los aspectos y niveles funcionales y no funcionales que debe incluir la correcta y completa validación del software, por medio de pruebas y de aseguramiento de la calidad.

Sin embargo, a pesar de que las propuestas metodológicas han cambiado, y hay mayor enfoque hacia el manejo iterativo, como puede ser Scrum que trabaja por sprints, todavía no se ha comprendido el impacto en lo que significa tanto en la forma de probar como en la interacción entre el equipo.

Voy a explicar mi punto basado en una gráfica de Scaled Agile Framework (SAFe) que lo permite visualizar de forma clara:

En varias empresas he encontrado la forma de trabajo que SAFe llama “cascada entre iteraciones” (primera gráfica). Por eso se refieren a sprints de pruebas, sprints de desarrollo e incluso sprints de diseño. Si bien, puede ser una forma válida de trabajo, es importante aclarar que difiere de los principios ágiles, en donde según refiere el Manifiesto Ágil: “Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible”; es entregar software, no es desarrollar software.

En un número mayor de empresas he encontrado que implementan “cascada dentro de las iteraciones” (segunda gráfica), que era la forma que proponía RUP ( Rational Unified Process), como forma de trabajo. Es una ganancia mayor con respecto a la primera porque al final de cada iteración se puede tener un entregable claro, ejecutable y probado.

Pero es el manejo de “iteraciones de funciones cruzadas” (tercera gráfica) la que permite implementar principios de Scrum tan importantes como es Timeboxing y entrega de valor basada en priorización.

Este manejo implica retos importantes como es el saber dividir las funcionalidades de forma que se pueda desarrollar por requerimientos tan cortos que puedan estar diseñados, desarrollados y probados en pocos días, que la automatización de pruebas esté implícita en el trabajo, porque la ejecución continua y repetitiva de pruebas será parte del día a día, y que el trabajo colaborativo sea la premisa, evitando desgastes entre los roles, que muchas veces se presentan entre desarrolladores y probadores. 

Bibliografía:

• SAFE Reference Guide 4.0. Dean Leffingwell
• The Rational Unified Process, An introduction. Phillippe Krutchen

El cargo Paradigmas de pruebas en las iteraciones apareció primero en Enjisst.

La industria del software es la industria más importante de nuestro tiempo [1], y está muy impactada por el ritmo de vida actual, que cambia cada vez más rápido.

Por ese motivo, requiere de prácticas que permitan producción continua de software, dentro de un ámbito de generación de valor incremental y permanencia de la calidad.

Si no se valida adecuadamente la calidad, pero se sale continuamente a producción, cada versión en lugar de aumentar el valor del activo (que es el software), lo está devaluando (generando deuda técnica).

Se requiere entonces un concepto metodológico de desarrollo que cumpla con la visión completa de la agilidad, como lo muestra Dan Leffinwell [2] en la siguiente gráfica:

“Evita las iteraciones “mini-cascadas”, a través de las iteraciones crossfuncionales.

Este artículo muestra el concepto de “Desarrollo Trenzado” como pilar fundamental de la metodología “Parex”, soportado por la plataforma “Enjisst”. Este concepto se puede aplicar dentro de las iteraciones, o incluso dentro de un flujo continuo Kanban. La aplicación de estos conceptos en diversos proyectos ha demostrado su efectivada para mejorar la calidad en mínimo un 70% y la velocidad de desarrollo en un 50% o más.

II.                 DESCRIPCIÓN

Para esto es necesario cambiar nuestros paradigmas, y dentro de ello modificar nuestro pensamiento de etapas a disciplinas. En desarrollo, la mayoría de equipos todavía piensa en las fases de requerimientos, desarrollo y pruebas, incluso como si fueran “mini-fases” dentro de la iteración.

Mientras mantengamos este paradigma seguiremos pensando en silos. Para explicar el paradigma tradicional pensemos en una carrera de relevos, que se compone de silos. Los silos son los pasos de la posta entre los atletas, en donde terminas los requerimientos para pasar la posta a desarrollo y luego termina la carrera las personas de pruebas.

Para pensar en agilidad es necesario cambiar de deporte: vamos a pasar del atletismo a un deporte de mayor interacción y agilidad como es el baloncesto.

Es de anotar que llamamos acá agilidad, la capacidad del equipo de responder ante el cambio, y de generar resultados de valor, en un deporte donde no se genera un solo valor (ganar la carrera), sino generar varios resultados de valor (anotar cestas).

En el baloncesto vamos a tomar roles: armador (base), aleros y postes (pivot); que utilizan una jugada llamada trenza. La trenza se caracteriza por:

·         Busca rápidamente generar un resultado de valor (trenza)

·         Los jugadores poco mantienen en sus manos el balón.

·         Se hace interacción continua entre los jugadores.

·         Los jugadores buscan recibir el balón en una posición que acerque hacia la cesta.

·         Los jugadores corren detrás de los otros, para no afectar el envío del balón.

·         Cada rol hace pequeñas carreras (dos pasos) pasando el balón a otro rol y recibirlo más adelante para nuevamente pasarlo pronto a otro rol.

En el “Desarrollo Trenzado” cada rol hace algunas actividades y pasa el balón a otro rol. Se hace de manera continua. A diferencia del baloncesto, el desarrollo trenzado es como si se jugara con dos o máximo tres balones.

Así en el momento inicial, el product owner (o rol de requerimientos) define una historia bien refinada y con apoyo de QA define el paquete de ideas y bocetos de escenarios de pruebas de una historia. Los escenarios de pruebas son base para el desarrollo y así el programador cuenta con los escenarios de base para diseñar el requerimiento, y así mismo la forma de ejecutar desde la perspectiva de sistema su desarrollo. Los desarrollos se van completando por escenarios de prueba. El QA recibe los escenarios (por paquetes) que va validando continuamente en ambiente de certificación según criterio. En esta certificación ejecuta pruebas de regresión, haciendo validación por el producto de software completo (no solo las historias). La certificación continua se puede tomar como el encestar, en este caso varios balones al mismo tiempo.

De forma continua el product owner acompañado con usuarios va validando el comportamiento del sistema, también por escenarios que se vayan entregando.

Este proceso es cíclico y continuo hasta que el paquete de historias haya concluido.

Así, el proceso de desarrollo fluye entre los tres roles principales: PO, QA y desarrollador, como una danza alrededor de los escenarios de prueba que están diseñados para evaluar el impacto de las historias de usuario, pero no para validarlas.

III.              CONDICIONES

Una de las condiciones fundamentales en este manejo de escenarios es el pensamiento sistémico del producto de software, orientado a los escenarios completos de uso y validación del software para bajar el riesgo inherente al desarrollo. Se quiere ver reflejado un conjunto de escenarios básicos de uso y validación y todas sus variantes, la nueva forma de interactuar una vez se haya implementado la historia de usuario.

La segunda condición es contar con un mecanismo para automatizar pruebas rápidamente que siga el ritmo de “la jugada”.

Adicionalmente, la automatización en lenguaje de usuario permite que el equipo se pueda comunicar alrededor de las pruebas. Porque si el product owner, desarrollador o usuario tienen conflictos para el entendimiento de las pruebas automatizadas, no es posible llevar el “Desarrollo Trenzado” en la velocidad y fluidez requeridos para que este concepto lleve a la agilidad.

Por último, tener en el equipo el concepto de pruebas ágiles, en donde QA tiene como misiones “criticar el producto” y también “ser soporte al desarrollo”, como se ve en los cuadrantes de pruebas [3].

En esa medida, QA es un rol de colaboración, en donde sus habilidades de criticidad, visión de producto, identificación de riesgos entre otros, se ponen al servicio del equipo para la aplicación de las prácticas tanto de calidad como de agilidad.

IV.               CONCLUSIÓN

El desarrollo trenzado que propone “PAREX”, apoyado con la plataforma “Enjisst” para la automatización rápida de pruebas en lenguaje de usuario y por perfiles no especializados, incluye los siguientes conceptos de calidad:

1.       Definición de criterios de aceptación de requerimientos, basado en la definición de escenarios de pruebas.

2.       Walkthrough con usuarios para la revisión informal de los requerimientos.

3.       Shift-left-testing [4] como mecanismo para ejecutar pruebas funcionales y no funcionales en momentos muy tempranos del proceso de desarrollo

Unidos con conceptos de calidad como:

·         Crossfuncionalidad que consiste en la habilidad del equipo que combina las ideas desde las diferentes disciplinas

·         Roles T dado el aumento de capacidad del equipo de automatizar e interpretar las pruebas

·         BDD: [5] y [6] Desarrollo dirigido por pruebas de comportamiento que lleva a la compresión del equipo a través de la definición del comportamiento por escenarios de validación

·         ATDD: complementando la anterior definición, incluye la definición de las pruebas de aceptación

·         Y la entrega continua de software funcionando

Por los motivos anteriormente expuestos, la combinación PAREX-Enjisst ha demostrado resultados impactantes que hicieron merecedores a los galardones: premio ingenio al caso de éxito de servicio y el premio al ingenio y la innovación.

V.                 REFERENCIAS

[1] D. Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises, Kindle Edition ed., A. S. D. Series, Ed., Pearson Education.

[2] D. Leffingwell, SAFe® 4.0 Reference Guide: Scaled Agile Framework® for Lean Software and Systems Engineering., Edición de Kindle. ed., Pearson Education..

[3] C. Lisa y G. Janet., Agile Testing. A practical guide for testing and agile teams, Edición de Kindle ed., A. S. Series, Ed., Pearson Education..

[4] L. Smith, Shift-left Testing, Dr. Dobb’s Journal, vol. 26, no. 9, pp. 56–ff, 2001.

[5] N. S. A. S. A. &. C. R. Nascimento, «Behavior-Driven Development: An Expert Panel to evaluate benefits and challenges,» de SBES ’20, Natal, Brazil, 2020.

[6] A. Stellman y J. Greene, Learning Agile: Understanding Scrum, XP, Lean, and Kanban, O’Reilly Media, 2014.

El cargo Desarrollo Trenzado…un deporte de equipo apareció primero en Enjisst.