Diez formas de ahorrar tiempo con prácticas ágiles de calidad

El deseo de adoptar Agile generalmente proviene del desarrollo. Después de todo, se creó ágil por desarrolladores para desarrolladores. Pero sin una estrategia sólida de calidad ágil que satisfaga eficazmente las demandas del negocio, los equipos ágiles permanecerán en la banca.

Para evitar esto, puede ampliar las prácticas de calidad ágil conocidas para garantizar que su software satisfaga las necesidades comerciales de manera eficaz y eficiente. Así es cómo:

1. Amplíe la calidad más allá del control de calidad

En el desarrollo ágil, todos los miembros del equipo, desde el desarrollador hasta el gerente de producto, deben ser muy conscientes de la calidad en todo el proceso, siendo la calidad una parte integral de su flujo de trabajo diario y las múltiples tareas de calidad que se realizan simultáneamente. Esto permite descubrimiento y reparación más rápidos de defectos ... reduciendo el tiempo, el esfuerzo y el costo necesarios para eliminar cada defecto.

Por ejemplo, en un momento dado, es posible que tenga las siguientes tareas al mismo tiempo:

• Control de calidad realizando pruebas funcionales de alto nivel en un requisito para la iteración actual.
• Desarrolladores que escriben pruebas unitarias y código para otra.
• Un gerente de producto, preocupado por la confiabilidad / desempeño general del producto, ajustando la política de calidad del equipo para abordar dicha inquietud.

Para adaptar la calidad a las actividades diarias de los distintos miembros del equipo, puede seguir esta distribución de tareas:

Función	tareas
Gerentes de desarrollo / Scrum Masters	Requisitos de distribución Establecer pautas de codificación Establecer la política de prueba de desarrollo Estimación del costo de desarrollo Seguimiento del trabajo en curso
Desarrolladores	Requisitos de lectura Implementación de requisitos Tiempo de seguimiento Seguimiento de cambios Requisitos de prueba Participar en revisiones de código de pares Siguiendo la política de calidad
Probadores de control de calidad	Revisión de los esfuerzos de prueba de los desarrolladores Realización de pruebas adicionales de requisitos Trabajar de forma iterativa durante el desarrollo Detectar y notificar defectos rápidamente Investigar la causa de los defectos Influir en la política de desarrollo
Gerentes de producto	Requisitos de escritura Establecer plazos Seguimiento del progreso y el costo Supervisión del estado de calidad de alto nivel Ajuste de requisitos y horarios

2. Adoptar la política como equipo

La política no se asocia tradicionalmente con las pruebas de desarrollo ágiles, y muchos "Agilistas" puros se preocupan de que toda la noción de política contradiga la naturaleza colaborativa y ligera de los procesos ágiles. Sin embargo, hemos descubierto que muchos equipos que trabajan con metodologías de desarrollo ágiles en realidad aprecian tener expectativas claras con respecto a cómo se debe escribir y probar el código. Con las expectativas claramente definidas, el equipo no necesita perder tiempo tratando de averiguar exactamente qué se espera y cuándo, o reelaborando constantemente el código para remediar malentendidos.

Puede comenzar implementando una política que simplemente formalice las prácticas de codificación y calidad que el equipo ya está siguiendo. Luego, trabajando desde esa línea de base, puede introducir gradualmente nuevas políticas que el equipo ha discutido y acordado seguir.

Las posibles modificaciones de la política se pueden discutir en reuniones diarias de pie o durante las revisiones del código. Esto permite a los miembros del equipo proporcionar comentarios valiosos con respecto a los refinamientos de políticas (por ejemplo, ajustar una regla de análisis estático para permitir ciertas excepciones) y extensiones (por ejemplo, requerir cobertura de prueba adicional en un módulo que QA informa como especialmente defectuoso).

Además de garantizar que todo el equipo esté a bordo, también es esencial asegurarse de que la aplicación de la política sirva como guía, no como una intrusión. Idealmente, una infraestructura automatizada verifica el cumplimiento automáticamente en segundo plano y funciona de manera invisible a menos que no se cumplan las expectativas acordadas. En ese momento, determina qué miembro del equipo debe ser notificado y le recuerda que debe realizar las tareas necesarias para cumplir con las expectativas acordadas.

Esencialmente, la infraestructura automatizada funciona como un sistema de electrocardiograma que está conectado a un paciente del hospital, midiendo constantemente la actividad eléctrica. Si todo está bien, se ejecuta discretamente en segundo plano. Pero si las lecturas comienzan a ser planas, suenan las alarmas y la gente comprende que es necesario actuar.

3. Utilice pruebas automatizadas para detectar tantos errores como sea posible antes del control de calidad

Si los defectos derivados de un código implementado de manera deficiente se transmiten constantemente al control de calidad, esto finalmente da como resultado:

• Pruebas de aceptación menos exhaustivas por parte de QA,
• Ciclos de control de calidad frecuentes / prolongados que afectan el plazo y el alcance de la iteración, y / o
• Defectos que se deslizan en los productos liberados y luego requieren reparación / parcheo durante el tiempo asignado para una iteración posterior.

Muchos de estos defectos podrían detectarse mediante pruebas de desarrollo completamente automatizadas, pruebas que se pueden realizar en el servidor de integración o desde el escritorio con un solo clic.

El punto de partida es tener una política de codificación efectiva e implementarla con análisis de código estático. El análisis de código estático verifica los antipatrones conocidos en las construcciones de código fuente e informa cada ocurrencia de una coincidencia. Se puede realizar rápidamente y se garantiza que encontrará todos los casos de código que coincidan con un patrón.

La codificación defensiva puede hacer que el código sea inmune a muchas categorías de defectos, incluidos muchos defectos que son extremadamente difíciles de detectar en las pruebas, al eliminar sus causas fundamentales.

Por ejemplo, puede prevenir muchas causas de:

• Excepciones
• Puntos muertos
• Condiciones de carrera
• Notificaciones perdidas
• Bucles infinitos
• Problemas de inicialización
• Problemas de uso de memoria
• Problemas de serialización
• Corrupción de datos
• Fugas de recursos y memoria

No todos los tipos de defectos se pueden prevenir mediante el análisis de código estático. Pero cada defecto que puede prevenir es un defecto menos que ralentiza la iteración del equipo. QA no tiene que buscar y documentar el defecto. El desarrollo se libera de tener que detener lo que sea que estén haciendo, actualizar su memoria del código problemático, arreglar el código y verificar que el problema esté resuelto. Y QA no tiene que volver a probar la modificación del desarrollador.

Para encontrar los tipos de defectos que están más allá del alcance del análisis estático, pruebe las siguientes técnicas, las cuales no requieren ningún esfuerzo manual adicional:

• Corral análisis estático de flujo de datos durante la noche. El análisis de flujo de datos simula estáticamente las rutas de ejecución de la aplicación, que pueden cruzar varias unidades, componentes y archivos. Es como probar sin realmente ejecutar el código. Con el flujo de datos, puede "probar" una gran cantidad de rutas de ejecución sin tener que escribir o ejecutar un solo caso de prueba.
• permitir detección de errores en tiempo de ejecución a medida que se ejecutan sus pruebas funcionales existentes (pruebas unitarias y pruebas manuales o con secuencias de comandos). Esto le ayuda a exponer defectos críticos que aparecen solo en tiempo de ejecución (por ejemplo, sobrescritura de archivos) y concentrarse en la causa raíz de la falla de la aplicación, la ejecución lenta o el comportamiento impredecible. Los resultados indican errores que realmente ocurrieron durante la ejecución. Por lo tanto, los defectos se informan con una precisión sin precedentes.

Además, recomendamos encarecidamente revisión de código de pares, que requiere esfuerzo, pero es la única forma efectiva de exponer defectos de alto nivel relacionados con la lógica, el diseño, etc. El consejo n. ° 10 discutirá algunas formas de usar la automatización para agilizar las revisiones de código.

4. Desarrolle continuamente su política de calidad en respuesta a los defectos detectados

Cuando su desarrollador o los esfuerzos de prueba de control de calidad exponen defectos que superaron la política de calidad de su equipo, no se limite a arreglar ese defecto y seguir adelante.

Esto es como un fabricante de automóviles que se da cuenta de que un automóvil salió de la línea de ensamblaje con una instalación de freno defectuosa, arregla los frenos de ese automóvil y espera que el problema no vuelva a ocurrir. Un enfoque más seguro, uno que ahorraría mucho tiempo, molestias y dolor a largo plazo, sería examinar la línea de montaje, determinar cómo se introdujo ese problema, luego solucionar su causa raíz.

En términos del proceso de desarrollo de software, este enfoque implica trabajar con el desarrollo y el control de calidad para:

1. Aislar la causa raíz de este tipo general de defecto.
2. Determinar cómo modificar el proceso de desarrollo. para evitarlo
3. Determina como medir si la modificación se está practicando realmente.

En muchos casos, un cambio de política de codificación hará el truco: por habilitar o reconfigurar ciertas reglas de análisis estático, puede encontrar todas las demás instancias de código existente que son propensas al mismo tipo de defecto, y también puede asegurarse de que el código nuevo o modificado evite el peligro conocido. A menudo, la detección de errores en tiempo de ejecución y el flujo de datos estáticos analizadores de código incluso señalarle las reglas precisas de análisis estático que puede seguir para evitar los defectos específicos que exponen.

Otras veces, la resolución puede implicar cambiar la forma en que el código se desarrolla, se prueba o se agrega a una lista de elementos para revisar durante las inspecciones manuales del código.

En última instancia, esto inmuniza su proceso de prueba de desarrollo de software contra muchos de los defectos de software más comunes.

5. Gestionar la complejidad del código

Dado que se ha demostrado una y otra vez que el código demasiado complejo es más lento, más difícil y más riesgoso de actualizar y extender que el código más simple, es útil concentrarse en el código complejo, por ejemplo, cualquier clase o método cuya complejidad ciclomática sea 10 o más. Este código podría funcionar bien en este momento, pero podría causarle al equipo un dolor considerable en el futuro cuando lo que parecía ser una extensión de funcionalidad simple termine requiriendo una reescritura a gran escala.

Usando los cálculos de métricas para uno de sus proyectos fáciles de mantener como guía, establezca límites y umbrales realistas para las métricas seleccionadas, luego asegúrese de que los miembros del equipo sean alertados cuando las métricas estén fuera del rango prescrito. Esto reducirá el tiempo y el esfuerzo necesarios para modificar y ampliar el código en iteraciones posteriores. También ayudará a los nuevos desarrolladores a ponerse al día más rápido.

6. Amplíe la TDD y las pruebas funcionales con pruebas de regresión generadas automáticamente

Si ya está practicando el desarrollo basado en pruebas (TDD) y las pruebas de regresión automatizadas continuas, tiene una base excelente para determinar cuándo las modificaciones cambian o rompen su funcionalidad previamente validada. Sin embargo, si realmente quiere estar seguro de que sus modificaciones no cambiar o romper algún comportamiento de la aplicación que no probó explícitamente con sus casos de prueba TDD, mas extenso pruebas de regresión se necesita.

Ampliación de TDD Test Suite

Una opción es dedicar mucho tiempo a escribir muchos más casos de prueba. ¿Pero quién tiene tiempo para eso? Un enfoque mucho más simple es automáticamente generar una batería de pruebas de regresión que lo ayudarán a verificar el comportamiento de la aplicación:  

• Genere automáticamente una línea de base creando casos de prueba que capturan la funcionalidad actual del código del proyecto. En la mayoría de los casos, este conjunto de pruebas se puede generar durante la noche utilizando herramientas automatizadas de prueba unitaria. Debido a que su objetivo es establecer una línea de base de comportamiento en lugar de verificar la funcionalidad actual de la aplicación, no hay necesidad de revisar, ni siquiera echar un vistazo, las pruebas generadas o las afirmaciones/ observaciones / resultados obtenidos.

• Detectar cambios a partir de esta línea de base ejecutando estas pruebas contra su base de código en evolución de forma regular. Por lo general, esto es tan simple como agregar estos nuevos casos de prueba a su infraestructura de pruebas de regresión automatizada actual. En ejecuciones de prueba posteriores, las fallas de prueba se informarán solo si el comportamiento del código actual no coincide con el comportamiento capturado en el conjunto de pruebas de línea de base.

El resultado es un una forma fácil y eficiente de determinar cuándo y cómo las modificaciones de su código afectan su código-incluso las partes de la aplicación que no están cubiertas por las pruebas funcionales / TDD que escribió manualmente.

Mantenerse sincronizado

El único trabajo necesario es mantener el conjunto de pruebas sincronizado con los cambios de la aplicación. Cuando los desarrolladores llegan al trabajo cada mañana, revisan y responden a cualquier falla de prueba informada para su código. Al hacerlo, ellos Abordar defectos funcionales en su código o actualizar el conjunto de pruebas para reflejar el comportamiento correcto del código..

7. Reducir la complejidad de las pruebas de los desarrolladores

Los sistemas que los equipos ágiles están construyendo hoy están creciendo en tamaño y complejidad. Como resultado. Los desarrolladores a menudo tienen dificultades para probar los componentes específicos en los que trabajaron porque estos componentes operan como parte de sistemas complicados.-están conectados al mundo exterior, los sistemas de estadificación son difíciles de establecer y mantener, cada prueba requiere una configuración considerable, etc.. Podría ser factible ejecutar una prueba una vez, pero realmente necesita ejecutar todas las pruebas de su equipo a diario para que reciba una alerta inmediata en caso de que sus modificaciones constantes terminen rompiendo la funcionalidad previamente verificada.

El rastreo de casos de prueba permite al equipo probar continuamente partes de la aplicación sin las molestias de lidiar con el complicado sistema. Con una tecnología de rastreo como Parasoft Tracer, puede crear casos de prueba unitaria que capturen la funcionalidad especificada en los requisitos.

Desde la GUI de la aplicación o utilizando un cliente de prueba SOA o web, simplemente ejercite sus casos de uso mientras el rastreo está habilitado. A medida que se ejecuta el caso de uso, la tecnología monitorea todos los objetos que se crean, todos los datos que entran y salen, y luego te crea un prueba de unidad que representa esta operación, e incluso establece las condiciones iniciales adecuadas.

Entonces puedes tomar esto caso de prueba unitario y ejecutarlo en una máquina separada, lejos del sistema original. Esto significa que Puede utilizar una sola máquina, como el servidor de integración continua o incluso un escritorio de desarrollador estándar, para reproducir el comportamiento de un sistema complicado durante su procedimiento de verificación.. Agregue todas estas pruebas a su conjunto de pruebas de regresión, ejecútelo continuamente y se le avisará de inmediato si esta funcionalidad que capturó se ve afectada por las modificaciones de su código.

Básicamente, esto le ayuda a abordar la complejidad de los sistemas actuales de dos formas:

• It configura automáticamente condiciones de prueba realistas, liberándolo del trabajo tedioso y que requiere mucho tiempo para lograrlo.
• It le ofrece un caso de prueba que puede ejecutar aparte del sistema: Un caso de prueba que puede ejecutar de forma continua y completamente automática.

8. Reduzca la complejidad de las pruebas de un extremo a otro con la virtualización de servicios

Los equipos ágiles suelen trabajar en aplicaciones heterogéneas distribuidas (p. Ej., SOA, Web, Cloud) donde uno o más componentes está incompleto, evolucionando, es inestable, inaccesible o no está disponible para la prueba. Las metodologías ágiles requieren pruebas de regresión continuas y automatizadas (cuando sea posible), pero ¿Cómo se pueden ejecutar pruebas funcionales automatizadas de extremo a extremo todas las noches cuando las partes del sistema bajo prueba no están disponibles fácilmente?? Si retrasa las pruebas hasta que todo esté listo y disponible para las pruebas, corre el riesgo de caer en un paradigma similar a una cascada.

Una forma de abordar este desafío es emular el comportamiento de los componentes necesarios. Básicamente, construye e implementa activos virtualizados que emulan (virtualizan) el comportamiento, el rendimiento y los datos de las aplicaciones. Esto se logra aplicando un concepto conocido como Virtualización de Servicios.

Service Virtualization se concibió para emular el comportamiento de servicios web no disponibles y en evolución, luego evolucionó más allá de los protocolos de servicio canónicos para admitir múltiples tipos de mensajes y protocolos: JDBC, MQ, JMS y más. Esta virtualización de servicio extendido reduce radicalmente el tiempo de configuración, la sobrecarga de hardware y los esfuerzos de administración de datos involucrados en el mantenimiento y la administración de un entorno de desarrollo / prueba realista y sostenible.

La virtualización de servicios ideal debe apuntar a activos virtualizados que puedan:

• Reemplazar los distintos puntos finales en la arquitectura del sistema (servicios, aplicaciones, mainframes, procedimientos almacenados, etc.) así como emular el comportamiento de la aplicación a nivel de unidad.
• Be agregado al entorno de prueba para reemplazar el comportamiento de varios componentes que, de otro modo, inhibirían la capacidad de su equipo para ejercitar y validar eficazmente el proceso empresarial de un extremo a otro.
• Be gestionado y compartido en un entorno de equipoy se implementa fácilmente entre servidores compartidos y escritorios de usuarios. Los datos comerciales utilizados por los activos virtualizados se pueden mantener fácilmente con hojas de cálculo u otras fuentes de datos.

Con estos activos virtualizados, puede Reemplazar sistemas, métodos o componentes dependientes. que de otro modo inhibirían la capacidad del equipo para validar eficazmente los requisitos que deben probarse o para verificar que los problemas detectados se hayan resuelto eficazmente.

Por ejemplo, considere un sistema de aprovisionamiento de cuentas basado en servicios que está perdiendo pedidos. Para resolver este problema, el equipo de desarrollo tiene que probar la aplicación fija en una caja de arena segura que emule los flujos de transacciones del entorno de producción, o arriesgarse a romper el sistema al volver a implementar la aplicación. Mediante la emulación, el equipo puede ejercer sus servicios en contexto, sin afectar las transacciones comerciales normales de los socios.

Este concepto no es nuevo, pero se está volviendo cada vez más importante a medida que los sistemas empresariales continúan volviéndose más distribuidos y heterogéneos. Además, esta mayor complejidad hace que sea necesario expandir el concepto de emulación para que se extienda más allá de los servicios y también incluya otros componentes esenciales del sistema, por ejemplo, la base de datos, la interfaz web, el intermediario, etc., y poder emular el varios protocolos que comúnmente coexisten en dichos sistemas.

9. Vuelva a realizar la prueba solo cuando sea necesario

Aunque las metodologías ágiles recomiendan pruebas automatizadas siempre que sea posible, siempre se requiere cierto grado de prueba manual. Cada vez que se actualiza la aplicación, el equipo de control de calidad suele repetir todas las pruebas manuales o dedicar una cantidad considerable de tiempo a tratar de averiguar cuál de esos casos de prueba podría estar relacionado con la parte de la aplicación que cambió. De cualquier manera, se pierde mucho tiempo.

Con las pruebas basadas en cambios, el equipo puede ver instantáneamente qué requisitos se ven afectados por los cambios recientes. y qué pruebas deben ejecutarse nuevamente. Esto ahorra una enorme cantidad de tiempo y recursos de control de calidad que podrían aplicarse mejor a tareas de valor agregado.

Para habilitar las pruebas basadas en cambios, Los requisitos se correlacionan automáticamente con las pruebas, el código fuente y las tareas de desarrollo / prueba.. Con estas correlaciones en su lugar, el nivel actual de verificación para cada requisito o tarea (incluido el estado de aprobación / reprobación de la tarea y la cobertura) se puede evaluar en cualquier momento mediante el seguimiento de todas las pruebas asociadas.

Además, el equipo puede obtener instantáneamente una evaluación objetiva de qué requisitos funcionan realmente como se esperaba, qué defectos se resuelven y qué requisitos y defectos aún necesitan pruebas. Esta visibilidad en tiempo real del estado real de los requisitos y defectos lo ayuda a evitar sorpresas tardías que amenazan con descarrilar los programas y los presupuestos.

10. Utilice la automatización para optimizar las reuniones de pie

Las reuniones de pie son una parte importante de los procesos ágiles y son un foro ideal para mantener los problemas de calidad en la vanguardia del desarrollo. Para mantener estas reuniones en la duración recomendada de 15 minutos (y aún así tener algo de tiempo para cubrir la calidad), es importante optimizar lo que está cubierto y resolver problemas más complejos "sin conexión".

Dos estrategias que le ayudan a optimizar estas reuniones son:

• Distribución y seguimiento automatizados de tareas.
• Flujo de trabajo de revisión de código de pares automatizado.

Distribución y seguimiento automatizados de tareas

Muchos de los aspectos más aburridos y tediosos de las reuniones de pie se pueden eliminar con la distribución y el seguimiento automatizados de tareas.

Al utilizar un sistema de gestión de desarrollo de software como Parasoft DTP, el administrador o scrum master convierte los requisitos y problemas en tareas de trabajo medibles y procesables que luego se distribuyen automáticamente directamente al IDE del desarrollador responsable (de acuerdo con asignaciones manuales o pautas predefinidas).

Cuando un desarrollador está listo para comenzar a trabajar en una tarea asignada, la marca como "en progreso", trabaja en la tarea con normalidad y luego la marca como "terminada" cuando se completa. Sin interrumpir el flujo de trabajo del desarrollador, puede rastrear automáticamente qué archivos están relacionados con la tarea dada y cuánto tiempo se dedica a trabajar en estos archivos. La información de estado en tiempo real siempre está disponible en el sistema.

El seguimiento es clave para evaluar el progreso y la capacidad actual del equipo en preparación para las reuniones de pie. También mantiene al control de calidad bien informado sobre lo que está listo para la prueba.

Automatización del flujo de trabajo de revisión de código de pares

La revisión del código generalmente implica largas y tediosas reuniones que requieren una gran cantidad de preparación. Un sistema de revisión de código automatizado puede ayudar al equipo a optimizar las revisiones de código automáticamente:

1. La identificación de código actualizado desde el control de fuente o el sistema de archivos local.
2. Coincidencia de el código con revisores designados.
3. Alertando el revisor y le permite revisar el código dentro de su IDE.
4. Rastreo el progreso de cada elemento de revisión hasta el cierre.

El equipo es entonces libertad para centrarse en la revisión por pares real: un proceso creativo que no puede (ni debe) automatizarse.

Las revisiones de código no necesariamente deben cubrir todas las líneas de código. Por ejemplo, algunos equipos pueden preferir revisar solo los segmentos más peligrosos de su código (por ejemplo, las áreas más sensibles a la seguridad o propensas a bloqueos de la base del código). Las expectativas con respecto a la revisión del código deben discutirse con el equipo y establecerse en la política de calidad.