Metodología ágil en pruebas de software

¿Qué es la metodología ágil en las pruebas?

Metodología Ágil significa una práctica que promueve iteración continua de desarrollo y pruebas durante todo el ciclo de vida de desarrollo de software del proyecto. En el modelo Agile de pruebas de software, tanto las actividades de desarrollo como las de prueba son simultáneas, a diferencia del modelo Waterfall.

¿Qué es el desarrollo ágil de software?

La Desarrollo Ágil de Software La metodología es uno de los procesos más simples y efectivos para convertir una visión de una necesidad empresarial en soluciones de software. Ágil es un término utilizado para describir enfoques de desarrollo de software que emplean planificación continua, aprendizaje, mejora, colaboración en equipo, desarrollo evolutivo y entrega temprana. Fomenta respuestas flexibles al cambio.

El desarrollo ágil de software enfatiza cuatro valores fundamentales.

Interacciones individuales y de equipo sobre procesos y herramientas.
Software de trabajo sobre documentación completa
Colaboración del cliente sobre negociación de contrato
Responde al cambio sobre el siguiente plan

Modelo ágil versus modelo en cascada

Los modelos Agile y Waterfall son dos métodos diferentes para el proceso de desarrollo de software. Aunque difieren en su enfoque, ambos métodos son útiles en ocasiones, según los requisitos y el tipo de proyecto.

Modelo ágil	Modelo de cascada
Metodología ágil en la definición de pruebas de software: las metodologías ágiles proponen un enfoque incremental e iterativo para el diseño de software	Modelo en cascada: el desarrollo del software fluye secuencialmente desde el punto inicial hasta el punto final.
La Proceso ágil en las pruebas de software se divide en modelos individuales en los que trabajan los diseñadores	El proceso de diseño no se divide en modelos individuales.
El cliente tiene oportunidades tempranas y frecuentes para observar el producto y tomar decisiones y cambios en el proyecto.	El cliente sólo puede ver el producto al final del proyecto.
El modelo ágil en las pruebas se considera no estructurado en comparación con el modelo en cascada.	Los modelos en cascada son más seguros porque están muy orientados al plan.
Los proyectos pequeños se pueden implementar muy rápidamente. Para proyectos grandes, es difícil estimar el tiempo de desarrollo.	Se pueden estimar y completar todo tipo de proyectos.
El error se puede solucionar en medio del proyecto.	Sólo al final se prueba todo el producto. Si se encuentra el error de requisito o es necesario realizar algún cambio, el proyecto debe comenzar desde el principio.
El proceso de desarrollo es iterativo y el proyecto se ejecuta en iteraciones cortas (2-4) semanas. La planificación es muy menor.	El proceso de desarrollo es por fases y la fase es mucho más grande que la iteración. Cada fase finaliza con la descripción detallada de la siguiente fase.
La documentación tiene menos prioridad que Desarrollo de software ad-hoc	La documentación es una prioridad máxima e incluso se puede utilizar para capacitar al personal y actualizar el software con otro equipo.
Cada iteración tiene su propia fase de prueba. Permite implementar pruebas de regresión cada vez que se lanzan nuevas funciones o lógica.	Sólo después de la fase de desarrollo se ejecuta la fase de prueba porque las partes individuales no son completamente funcionales.
En las pruebas ágiles, cuando finaliza una iteración, las características entregables del producto se entregan al cliente. Las nuevas funciones se pueden utilizar inmediatamente después del envío. Es útil cuando se tiene buen contacto con los clientes.	Todas las funciones desarrolladas se entregan inmediatamente después de una larga fase de implementación.
Los probadores y desarrolladores trabajan juntos	Los probadores trabajan por separado de los desarrolladores
Al final de cada sprint, se realiza la aceptación del usuario.	La aceptación del usuario es realizado al final del proyecto.
Requiere una comunicación estrecha con los desarrolladores y juntos analizar los requisitos y la planificación.	El desarrollador no participa en el proceso de planificación y requisitos. Por lo general, hay retrasos entre las pruebas y la codificación.

También verifique: Agile Vs Waterfall: conozca la diferencia entre metodologías

Proceso ágil

Compruebe lo siguiente Metodología ágil proceso para entregar sistemas exitosos rápidamente.

Hay varios Métodos ágiles presentes en las pruebas ágiles, y se enumeran a continuación:

Melé

SCRUM es un método de desarrollo ágil que se concentra específicamente en cómo gestionar tareas dentro de un entorno de desarrollo basado en equipos. Básicamente, Scrum se deriva de la actividad que ocurre durante un partido de rugby. Scrum cree en empoderar al equipo de desarrollo y aboga por trabajar en equipos pequeños (digamos, de 7 a 9 miembros). Agile y Scrum constan de tres roles y sus responsabilidades se explican a continuación:

Scrum Master
- Scrum Master Es responsable de configurar el equipo, la reunión de sprint y eliminar los obstáculos para el progreso.
Propietario del producto
- El propietario del producto crea el trabajo pendiente del producto, prioriza el trabajo pendiente y es responsable de la entrega de la funcionalidad en cada iteración.
Equipo Scrum
- El equipo gestiona su propio trabajo y organiza el trabajo para completar el sprint o ciclo.

Retraso del producto

Este es un repositorio donde se hace un seguimiento de los requisitos con detalles sobre la cantidad de requisitos (historias de usuario) que se deben completar para cada versión. El propietario del producto debe mantenerlo y priorizarlo, y debe distribuirlo al equipo Scrum. El equipo también puede solicitar la incorporación, modificación o eliminación de un nuevo requisito.

Prácticas Scrum

Las prácticas se describen detalladamente:

Flujo de proceso de Metodologías Scrum:

Flujo de proceso de prueba de scrum es el siguiente:

Cada iteración de un scrum se conoce como Sprint
El backlog del producto es una lista donde se ingresan todos los detalles para obtener el producto final.
Durante cada Sprint, las principales historias de usuarios de la cartera de productos se seleccionan y se convierten en Sprint del backlog
El equipo trabaja en el backlog de sprint definido
Controles del equipo para el trabajo diario.
Al final del sprint, el equipo entrega la funcionalidad del producto.

Programación extrema (XP)

La técnica de programación extrema es muy útil cuando las demandas o requisitos de los clientes cambian constantemente o cuando no están seguros de la funcionalidad del sistema. Aboga por “lanzamientos” frecuentes del producto en ciclos de desarrollo cortos, lo que mejora inherentemente la productividad del sistema y también introduce un punto de control donde se pueden implementar fácilmente los requisitos del cliente. El XP desarrolla software manteniendo al cliente en el objetivo.

Los requisitos comerciales se recopilan en términos de historias. Todas esas historias se guardan en un lugar llamado estacionamiento.

En este tipo de metodología, los lanzamientos se basan en ciclos más cortos llamados Iteraciones con una duración de 14 días. Cada iteración incluye fases como codificación, pruebas unitarias y pruebas del sistema donde en cada fase se creará alguna funcionalidad menor o mayor en la aplicación.

Fases de la programación eXtreme:

Hay 6 fases disponibles en el método Agile XP y se explican a continuación:

Planificación

Identificación de partes interesadas y patrocinadores.
Requisitos de infraestructura
Seguridad información relacionada y recopilación
Acuerdos de Nivel de Servicio y sus condiciones

Analisis

Captura de historias en el estacionamiento
Priorizar historias en el estacionamiento
Eliminación de historias para estimación.
Definir iteración SPAN (tiempo)
Planificación de recursos para los equipos de desarrollo y control de calidad.

Design

Desglose de tareas
Preparación del escenario de prueba para cada tarea.
Marco de automatización de regresión

Ejecución

Codificación
Examen de la unidad
Ejecución de escenarios de prueba manuales.
Generación de informes de defectos
Conversión de casos de prueba de regresión manual a automatización
Revisión de iteración media
Revisión de fin de iteración

Envoltura

Pequeños lanzamientos
Pruebas de regresión
Demostraciones y reseñas
Desarrollar nuevas historias basadas en la necesidad.
Mejoras de proceso basadas en comentarios de revisión de final de iteración

de la Brecha

Lanzamiento piloto
Inscripción en beneficios
Lanzamiento de producción
Garantía de SLA
RevVer la estrategia SOA
Soporte de producción

Hay dos guiones gráficos disponibles para realizar un seguimiento del trabajo diariamente, y se enumeran a continuación como referencia.

Cartón de historia
- Esta es una forma tradicional de recopilar todas las historias en un tablero en forma de notas adhesivas para realizar un seguimiento de las actividades diarias de XP. Como esta actividad manual implica más esfuerzo y tiempo, es mejor cambiar a un formulario en línea.
Guión gráfico en línea
- La herramienta en línea Storyboard se puede utilizar para almacenar las historias. Varios equipos pueden utilizarlo. para diferentes propósitos.

Metodologías cristalinas

La Metodología Crystal se basa en tres conceptos

Fletamento Varias actividades involucradas en esta fase son la creación de un equipo de desarrollo, la realización de un análisis de viabilidad preliminar, el desarrollo de un plan inicial y el ajuste de la metodología de desarrollo.
Entrega cíclica: La fase principal de desarrollo consta de dos o más ciclos de entrega, durante los cuales el
1. El equipo actualiza y perfecciona el plan de lanzamiento.
2. Implementa un subconjunto de requisitos a través de una o más iteraciones integradas de prueba del programa.
3. El producto integrado se entrega a usuarios reales
4. RevVista del plan del proyecto y metodología de desarrollo adoptada.
Envolver: Las actividades que se realizan en esta fase son el despliegue en el entorno del usuario, se realizan revisiones y reflexiones post-despliegue.

Método de desarrollo de software dinámico (DSDM)

DSDM es un Desarrollo rápido de aplicaciones (RAD) para el desarrollo de software y proporciona un marco ágil de entrega de proyectos. El aspecto importante de DSDM es que se requiere que los usuarios participen activamente y los equipos tienen el poder de tomar decisiones. La entrega frecuente de productos se convierte en el foco activo de DSDM. Las técnicas utilizadas en DSDM son

Hora BoxIng.
Reglas de Moscú
prototipado

El proyecto DSDM consta de 7 fases

Anteproyecto
Estudio de factibilidad
Estudio de negocios
Iteración del modelo funcional
Diseñar y construir iteración.
Implementación
Post-proyecto

Desarrollo basado en características (FDD)

Este método se centra en el “diseño y la construcción” de características. A diferencia de otros métodos ágiles en ingeniería de software, FDD describe fases de trabajo muy específicas y breves que deben realizarse por separado para cada característica. Incluye un recorrido por el dominio, inspección del diseño, promoción a la construcción, inspección del código y diseño. FDD desarrolla el producto teniendo en cuenta los siguientes aspectos en el objetivo

Modelado de objetos de dominio
Desarrollo por característica
Propiedad de componente/clase
Equipos de funciones
Inspecciones
Configuration Management
Construcciones regulares
Visibilidad de los avances y resultados.

Desarrollo de software Lean

El método de desarrollo de software lean se basa en el principio de “producción justo a tiempo”. Su objetivo es aumentar la velocidad del desarrollo de software y reducir los costos. El desarrollo lean se puede resumir en siete pasos.

Eliminando Residuos
Ampliando el aprendizaje
Aplazar el compromiso (decidir lo más tarde posible)
Entrega temprana
Empoderando al equipo
Contruyendo Integrity
Optimizar el conjunto

Kanban

Kanban Surgió originalmente de una palabra japonesa que significa una tarjeta que contiene toda la información necesaria para realizar en el producto en cada etapa a lo largo de su camino hasta su finalización. Este marco o método está bastante adoptado en el método de prueba de software, especialmente en conceptos ágiles.

Scrum contra Kanban

Melé	Kanban
En la técnica Scrum, las pruebas deben dividirse para que puedan completarse dentro de un sprint.	No se prescribe ningún tamaño de artículo en particular
Prescribe una cartera de productos priorizada	La priorización es opcional.
El equipo Scrum se compromete a una cantidad particular de trabajo para la iteración.	El compromiso es opcional.
Se prescribe el gráfico de evolución	No se prescribe ningún tamaño de artículo en particular
Entre cada sprint, se reinicia un tablero de scrum.	Un tablero Kanban es persistente. Limita la cantidad de elementos en el estado del flujo de trabajo.
No puede agregar elementos a la iteración en curso.	Puede agregar elementos siempre que haya capacidad disponible.
WIP limitado indirectamente	WIP limitado directamente
Iteraciones con límite de tiempo prescrito	Iteraciones con límite de tiempo opcionales

También verifique: Kanban vs. Scrum: ¿Cuál es la diferencia?

Métricas ágiles

Las métricas que se pueden recopilar para un uso eficaz de Agile son:

Factor de arrastre
- Esfuerzo en horas que no contribuyen al objetivo del sprint
- El factor de arrastre se puede mejorar reduciendo la cantidad de recursos compartidos y reduciendo la cantidad de trabajo no contributivo.
- Las nuevas estimaciones se pueden incrementar por porcentaje del factor de arrastre -Nueva estimación = (Estimación anterior+factor de arrastre)
Rapidez
- Cantidad de backlog (historias de usuario) convertidas en funcionalidad entregable del sprint
No de pruebas unitarias agregadas
Intervalo de tiempo necesario para completar la construcción diaria
Errores detectados en una iteración o en iteraciones anteriores
Fuga por defecto de producción

Te podría gustar: