Vea cómo la solución de calidad continua de Parasoft ayuda a controlar y administrar los entornos de prueba para ofrecer software de alta calidad con confianza. Regístrese para la demostración >>
Tiempo de leer: 12 minutosEl 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:
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:
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 |
|
| Desarrolladores |
|
| Probadores de control de calidad |
|
| Gerentes de producto |
|
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.
Si los defectos derivados de un código implementado de manera deficiente se transmiten constantemente al control de calidad, esto finalmente da como resultado:
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:
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:
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.
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:
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.
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.
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.
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:
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.
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..
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:
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:
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.
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.
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:
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.
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:
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.
Las herramientas de prueba de software automatizadas líderes en la industria de Parasoft respaldan todo el proceso de desarrollo de software, desde que el desarrollador escribe la primera línea de código hasta las pruebas unitarias y funcionales, hasta las pruebas de rendimiento y seguridad, aprovechando los entornos de prueba simulados en el camino.