CURSO DE TESTING MANUAL O QUALITY CONTROL

MATERIAL DE LECTURA

TESTING ÁGIL
OBJETIVOS DE LA GUÍA
• Aplicar las metodologías agiles al testing

• Comprender las diferencias entre el testing tradicional y el ágil

• Implementar el cuadrante del testing ágil

• Identificar las diferencias y similitudes del STLC y del ciclo ágil

• Identificar las ceremonias aplicadas al testing ágil

• Comprender los riesgos y ventajas de las pruebas manuales y automizadas

¿QUÉ SON LAS PRUEBAS ÁGILES?

Es la práctica que sigue las reglas y principios del desarrollo ágil de software. A diferencia del
método cascada o tradicional, El Testing ágil puede comenzar al inicio del proyecto con una
integración continua entre el desarrollo y las pruebas. La metodología de testing Agile no es
secuencial (en el sentido de que se ejecuta solo después de la fase de codificación) sino que es
continua.

CARACTERISTICAS

Pruebas continuas: la metodología ágil sigue el principio de pruebas continuas, lo que significa
que las pruebas son continuas lo que garantiza el progreso continuo del software o producto.

Comentarios continuos: las pruebas ágiles le brindarán comentarios continuos, lo que garantizará
que el software o producto cumpla con las expectativas de los clientes o usuarios.

Código simplificado y limpio: en las pruebas ágiles, el error se corrige en la misma iteración. Esto
ayudará a garantizar un código limpio y simplificado.

Menos documentación: esta prueba funciona en una lista de verificación reutilizable y se centra
en las pruebas en lugar de la documentación detallada.

PRINCIPIOS DEL TESTING ÁGIL

De forma similar a que el Manifiesto Ágil contiene principios que se aplican al desarrollo ágil de
software, el Agile Testing engloba los siguientes principios:

• El Testing no es una fase: El testing continuo es la única forma de garantizar avance

continuo, por esto, el testing se realiza continuamente junto con el desarrollo de software
y demás actividades.
• El Testing hace avanzar el proyecto: Bajo métodos convencionales, el testing es una
alcabala, en cambio en Agile Testing se proporciona retroalimentación continua,
permitiendo corregir el rumbo continuamente durante el desarrollo de software.
• Todo el equipo realiza pruebas: en Agile Testing, los Analistas de negocio y
Desarrolladores de software también ejecutan pruebas, no sólo los testers como en
métodos convencionales.
 • Reducir el tiempo para recibir retroalimentación: En Agile Testing, los equipos del área
de negocio (el cliente) están involucrados en cada iteración, no solo al final durante la
fase de aceptación, como resultado, el tiempo de retroalimentación se reduce y el costo
de correcciones también es menor.
• Código limpio: Los defectos en el código se corrigen en la misma iteración, por lo que se
mantiene el código limpio.
• Reducir la documentación de pruebas: Los Agile Testers usan listas de chequeo reusables
en lugar de documentación extensa, se enfocan en la esencia de la prueba en lugar de
detalles. Siguiendo principios ágiles estas listas de chequeo son el inicio de las
definiciones de las pruebas y no el final, y el tester cuenta con libertad para aportar valor.
• Guiado por pruebas: El Agile Testing, las pruebas se hacen “durante” el desarrollo y no
después del desarrollo como en métodos convencionales.

TESTING ÁGIL VERSUS TRADICIONAL

Metodologías tradicionales Testing Agil

Actividades de Se pueden iniciar hasta que la Las tareas quedan

prueba especificación de requisitos se encuentre inmersas dentro de cada
completa. iteración.

Errores Encontrar bugs. Prevenir bugs.

Ciclo de vida El testing es una fase del ciclo de vida de El testing es una actividad
desarrollo del software, teniendo que que se puede hacer todo el
esperar que se termine la programación tiempo.
para testear.

Responsabilidad El tester es responsable de la calidad. La responsabilidad es de

todo el equipo.

Objetivo La validación del producto desarrollado. Guiar el desarrollo del

software.

¿CUÁL ES EL ROL DEL TESTER ÁGIL?

Un Tester en un proyecto Ágil, se desempeña de manera diferente a uno que trabaja en un

proyecto tradicional.

Estos Testers deben entender los valores y principios que sustentan los proyectos ágiles y cómo
forman parte integral de un enfoque completo de equipo junto con los desarrolladores y
representantes del negocio.

Es aconsejable que los testers se involucren en testing Unitario ayudando y guiando a los
desarrolladores a diseñar esos tests unitarios. De esta manera, el desarrollador puede aprender
técnicas para realizar los tests unitarios de forma más eficiente, y el tester puede aprender de
desarrollo como funcionan los tests unitarios y entender la forma en la que trabaja el
desarrollador.
Recordar que al final el objetivo del equipo es el mismo, entregar un software de calidad, y esta
calidad es responsabilidad de todo el equipo. Por eso es importante el soporte continuo entre
todo equipo.

Un tester ágil aporta una visión intermedia entre desarrollo y negocio: entiende el punto de vista
del usuario, pero a la vez, tiene conocimientos a alto nivel de la complejidad que conlleva
desarrollar software.

El software está siempre cambiando en un proyecto ágil por lo cual hay código nuevo que se
agrega para testear en forma diaria. En un proyecto ágil el sistema bajo test se transforma en un
blanco móvil. Se necesitan nuevos enfoques de prueba para enfrentar este tipo de cambios, con
diferentes habilidades, tácticas y herramientas.

En un proyecto con cambios continuos, es importante tomar buenas decisiones respecto a lo que
se testea, y cuándo se testea. Si se prueban características que todavía no están terminadas y se
generan defectos, perderemos credibilidad ante el resto del equipo (y esto es un error común
que se comete cuando el software evoluciona rápidamente).

Hay algunos aspectos del testeo que no cambian, como ser la ejecución de los test, pero muchos
testers necesitarán realizar cambios importantes a su estrategia de testing para brindar valor real
a un proyecto de software ágil.

Material de apoyo sugerido:

a) [Link]
b) [Link]
c) [Link]
d) [Link]

LOS CUADRANTES DEL AGILE TESTING

Lisa Crispin, experta en Agile, desarrolló estos cuatro cuadrantes de prueba de Agile como una
guía para crear estrategias de prueba. El diagrama Agile Testing Quadrants es simplemente un
modelo para ayudar a los equipos a planificar sus pruebas y que no existen reglas estrictas sobre
qué pruebas pertenecen a qué cuadrante y en qué orden se deben realizar las diferentes pruebas.
La idea es, básicamente, colocar la tabla vacía en una pizarra y completarla progresivamente con
las ideas de cada uno de los miembros del equipo de trabajo.

Ahora bien, creemos que es importante explicar que significan cada una de las partes de los
cuadrantes de Agile Testing.

1. Pruebas de apoyo al equipo (Supporting the team). Se realizan en los cuadrantes Q1 y

Q2 del Agile Testing, y se basan en apoyar al equipo de desarrollo en la medida de que
este se encuentra elaborando el producto. No suelen buscar algo nuevo, sino más bien
validar algo que ya conocen. Se les llaman pruebas de apoyo al equipo ya que en estos
cuadrantes las pruebas realizadas son la base de un equipo de desarrollo ágil.

2. Pruebas de críticas al producto (Critique de product). Estas pruebas se realizan en los

cuadrantes Q3 y Q4, y se aplican para encontrar errores en el producto. Cuando se indica
“críticas al producto”, no tiene necesariamente un sentido negativo, pues éstas pueden
ser para resaltar aspectos positivos o incluso sugerir mejoras.

3. Pruebas enfrentadas a la tecnología (Technology view). Son pruebas que se realizan en

los cuadrantes Q1 y Q4, y son de mayor naturaleza técnica. Generalmente, los resultados
son de mayor interés para el desarrollador, el técnico, el arquitecto, etc. La intención es
analizar y someter a pruebas de extremo a características no funcionales como el
desempeño, robustez y seguridad.
 4. Pruebas enfrentadas al negocio (Business view). Se realizan en los cuadrantes del Agile
Testing Q2 y Q3. Acá entran las pruebas que tienen foco en el negocio, podrían pensarse
como las pruebas que dan resultados que un Product Owner (o Project Manager) estará
interesado en escuchar, que podrá entender. Permiten confirmar que el comportamiento
de una determinada funcionalidad es el deseado por el cliente o los expertos de negocio.
Hablamos aquí de satisfacer las condiciones de calidad externa solicitadas por el cliente.

BENEFICIOS DE PRUEBAS ÁGILES

El factor destacado que juega un papel clave para garantizar el éxito de las pruebas ágiles para
un producto es tener un equipo con las características esenciales de un tester ágil, que puede
construir una cultura de autoorganización y pensamiento independiente.

Hay ocho beneficios simples para promover las pruebas ágiles:

• Es lo suficientemente flexible como para adaptar cambios entre sprints incorporando

requisitos modificados.
• Como las tareas están segregadas, da claridad y elimina errores.
• Brinda soporte para el uso de índices reutilizables y le permite concentrarse en las
necesidades y expectativas más recientes de los clientes, en lugar de seguir los amplios
requisitos documentados.
• Este método es más eficiente, ya que los errores y defectos se resuelven más de cerca
debido a que se prueban pequeños fragmentos de código.
• Ayuda a entregar software de calidad de manera oportuna.
• Para garantizar que el software sea aceptable para las partes interesadas y los usuarios
finales, se agradecen los comentarios recibidos para diseñar el software de acuerdo con
su punto de vista.
• Los principios ágiles dependen de la simplicidad para proporcionar facilidad en los
procesos del equipo, como las reuniones de Scrum y las prácticas de desarrollo.
• Con las reuniones de seguimiento diarias, los informes de prueba se pueden discutir y
los errores se pueden abordar rápidamente.

CICLO DE VIDA DEL TESTING ÁGIL

Hemos visto el ciclo de vida de prueba de software, ahora llevaremos ese proceso al ámbito de
las metodologías ágiles.

¿QUÉ ES UN CICLO DE VIDA ÁGIL DE PRUEBAS DE SOFTWARE?

El ciclo de vida de las pruebas de software se refiere a un proceso de pruebas que tiene pasos
específicos que deben ejecutarse en una secuencia definida para garantizar que se hayan
cumplido los objetivos de calidad.

En este proceso, cada actividad se realiza de forma planificada y sistemática. Cada fase tiene
diferentes objetivos y resultados. Las organizaciones tienen diferentes fases del ciclo de vida; sin
embargo, las bases siguen siendo las mismas.

Recordemos que la metodología de testing Agile no es secuencial (en el sentido de que se ejecuta
solo después de la fase de codificación) sino que es continua. En el esquema podemos observar
esa continuidad y como el testing es parte integrante de cada sprint.
PLANIFICACIÓN DE PRUEBAS ÁGILES

Los sprints son el núcleo de las metodologías ágiles, un enfoque que toma proyectos grandes y
complejos y los fragmenta en piezas más pequeñas y manejables. Es el período de tiempo
previamente acordado en el que el equipo tiene que trabajar sobre el conjunto de requisitos y
concluir dentro de la duración.

En escenarios prácticos, la planificación de pruebas es el primer paso del proceso de pruebas. En

esta fase, identificamos las actividades y los recursos que ayudarían a cumplir los objetivos de
las pruebas. Durante la planificación también tratamos de identificar las métricas, el método de
recopilación y seguimiento de esas métricas.

¿Sobre qué base se hace la planificación? hay varios factores que influyen en la planificación de
las pruebas ágiles

• Requisitos
• Niveles y profundidad de las pruebas
• La complejidad del producto.
• Riesgos de productos y proyectos
• Ciclo de vida de desarrollo de software involucrado.
• Gestión de pruebas
• Habilidades y conocimientos del equipo.
• Disponibilidad de los interesados.

Recordemos las demás etapas del ciclo de vida, adaptadas al testing agil

ANÁLISIS DE REQUISITOS

Durante esta fase, los testers analizan y estudian los requisitos. Organizan sesiones de tormentas
de ideas con otros equipos e intentan averiguar si los requisitos son comprobables o no. Esta fase
ayuda a identificar el alcance de la prueba. Si alguna característica no es comprobable, se debe
comunicar durante esta fase para que se pueda planificar la estrategia de mitigación.
DISEÑO DE PRUEBAS:

Es importante que el equipo de pruebas mantenga una cadencia con el equipo de desarrollo. El
equipo de prueba diseña los casos de prueba según los requisitos proporcionados en el
documento de requisitos funcionales y los documentos de diseño del proyecto. Esta fase define
el "CÓMO" probar.

IMPLEMENTACIÓN DE PRUEBAS:

La tarea principal en esta fase es la creación de casos de prueba detallados. El tester debe
priorizar los casos de prueba e identificar qué caso de prueba se convertirá en parte del conjunto
de regresión. Antes de finalizar el caso de prueba, es importante realizar la revisión para
garantizar la corrección de los casos de prueba.

El tester deberá detallar las condiciones de la prueba. Por ejemplo, para una aplicación web de
comercio electrónico, puede tener una condición de prueba como "El usuario debe poder realizar
un pago". O puede detallar diciendo "El usuario debe poder realizar el pago a través de tarjeta
de débito y tarjeta de crédito".

Reunión de seguimiento diario

La reunión diaria consiste en reunirse todos los días el equipo de tester (puede ser junto con los
desarrolladores) para que cada cada miembro secuencialmente hable durante 2-3 minutos
respondiendo a estas 3 preguntas:

• ¿Qué hiciste ayer?

• ¿Qué harás hoy?
• ¿Hay algún impedimento?

Los objetivos que se buscan respondiendo a estas 3 preguntas son:

• Compartir con el equipo el compromiso para avanzar hacia los objetivos

• Tomar decisiones coordinadas entre todos para eliminar impedimentos que nos impidan
llegar a ese objetivo

EJECUCIÓN DE PRUEBAS:

Esta es la fase del ciclo de vida de prueba de software en la que tiene lugar la ejecución real.
Aquí el tester prueba que la aplicación o software cumpla con los requerimientos y los criterios
de entrada, para finalmente registrar defectos en caso de discrepancia.

CIERRE DEL CICLO DE PRUEBA

Dependiendo de la elección de su proyecto y de las partes interesadas, puede decidir si desea

enviar un informe diario del informe semanal, etc.

Hay diferentes tipos de informes que se pueden enviar, pero el punto importante es que el
contenido del informe cambia y depende de a quién envíe sus informes.
Si los gerentes de proyecto pertenecen a la experiencia de prueba, entonces están más
interesados en el aspecto técnico del proyecto, así que se deben incluir puntos como: número de
casos de prueba aprobados, fallidos, defectos surgidos, defectos de gravedad 1, etc.

Pero si está informando a las partes interesadas superiores, es posible que no estén interesadas
en los aspectos técnicos, así que debe informarse sobre los riesgos que se han mitigado a través
de las pruebas.

Reunión de cierre o retrospectiva:

Una vez finalizado el ciclo de vida, se deben realizar las actividades de cierre que incluyen lo
siguiente:

• Comprobar la finalización de la prueba: Si todos los casos de prueba se ejecutan o mitigan

deliberadamente. Compruebe que no haya defectos de gravedad 1 abiertos.
• Haga una reunión de lecciones aprendidas y cree un documento de lecciones aprendidas.
Incluya lo que salió bien, dónde está el alcance de las mejoras y qué se puede mejorar.

Encontramos 5 fases en el ciclo de vida de las pruebas ágiles:

 1. Evaluación de impacto: la evaluación de impacto es la primera fase del ciclo de vida de
las pruebas ágiles en la que tenemos que recopilar toda la información de las partes
interesadas.
2. Planificación de pruebas ágiles: en esta fase del ciclo de vida de las pruebas ágiles, las
partes interesadas pueden unirse para planificar y programar el proceso de prueba y los
entregables.
3. Scrums diarios: esto incluirá la reunión de la mañana para verificar el estado de las
pruebas y establecer objetivos para el día siguiente.
4. Revisión de la prueba: esta es la fase final en la que se lleva a cabo una reunión con las
partes interesadas para revisar y verificar el progreso con respecto al hito.
5. Preparación para el lanzamiento: en esta fase, tenemos que probar la función
desarrollada para verificar que funcione según las expectativas del cliente y que esté lista
para funcionar.

PASO A PASO

El plan de prueba ágil incluye tipos de prueba realizados en esa iteración, como requisitos de
datos de prueba, infraestructura, entornos de prueba y resultados de prueba. A diferencia del
modelo en cascada, en un modelo ágil, se escribe y actualiza un plan de prueba para cada versión.
Los planes de prueba típicos en Agile incluyen

• Alcance de prueba
• Nuevas funcionalidades que se están probando
• Nivel o Tipos de pruebas basadas en la complejidad de las características
• Pruebas de carga y rendimiento
• Consideración de infraestructura
• Plan de Mitigación o Riesgos
• Recursos
• Entregables e hitos
• Estrategias de prueba ágiles

El ciclo de vida de las pruebas ágiles se extiende a través de cuatro etapas

Iteración 0

Durante la primera etapa o iteración 0, realiza tareas de configuración inicial. Incluye la

identificación de personas para las pruebas, la instalación de herramientas de prueba, la
programación de recursos (laboratorio de pruebas de usabilidad), etc. Los siguientes pasos se
establecen para lograr en la iteración 0

a) Establecer un caso de negocio para el proyecto

b) Establecer las condiciones de contorno y el alcance del proyecto
c) Resuma los requisitos clave y los casos de uso que impulsarán las ventajas y desventajas
del diseño.
d) Resuma una o más arquitecturas candidatas
e) Identificación del riesgo
f) Estimación de costos y elaboración de anteproyecto

Iteraciones de construcción

La segunda fase de la metodología de pruebas ágiles son las iteraciones de construcción, la

mayoría de las pruebas se realizan durante esta fase. Esta fase se observa como un conjunto de
iteraciones para construir un incremento de la solución. Para hacer eso, dentro de cada iteración,
el equipo implementa un híbrido de prácticas de XP, Scrum, modelado ágil y datos ágiles, etc.

En la iteración de construcción, el equipo ágil sigue la práctica de requisitos priorizados: con cada
iteración, toman los requisitos más esenciales restantes de la pila de elementos de trabajo y los
implementan.

La iteración de construcción se clasifica en dos, pruebas de confirmación y pruebas de

investigación. Las pruebas de confirmación se concentran en verificar que el sistema cumple con
la intención de las partes interesadas tal como se describe al equipo hasta la fecha, y es realizado
por el equipo. Mientras que las pruebas de investigación detectan el problema que el equipo de
confirmación ha omitido o ignorado. En las pruebas de investigación, el tester determina los
problemas potenciales en forma de historias de defectos. Las pruebas de investigación se ocupan
de problemas comunes como las pruebas de integración, las pruebas de carga/estrés y las
pruebas de seguridad.

Nuevamente, para las pruebas confirmatorias, hay dos aspectos, la prueba del desarrollador y la
prueba de aceptación ágil. Ambos están automatizados para permitir pruebas de regresión
continuas a lo largo del ciclo de vida. Las pruebas confirmatorias son el equivalente ágil de las
pruebas según la especificación.

Las pruebas de aceptación ágiles son una combinación de pruebas funcionales tradicionales y
pruebas de aceptación tradicionales, ya que el equipo de desarrollo y las partes interesadas lo
hacen juntos. Mientras que las pruebas de desarrollador son una combinación de pruebas de
unidades tradicionales y pruebas de integración de servicios tradicionales. Las pruebas del
desarrollador verifican tanto el código de la aplicación como el esquema de la base de datos.
Juego final de liberación o fase de transición

El objetivo de "Release, End Game" es implementar su sistema con éxito en producción. Las
actividades que se incluyen en esta fase son la formación de usuarios finales, personas de apoyo
y personas operativas. Además, incluye la comercialización del lanzamiento del producto, la copia
de seguridad y la restauración, la finalización del sistema y la documentación del usuario.

La etapa final de prueba de la metodología ágil incluye pruebas completas del sistema y pruebas
de aceptación. De acuerdo con terminar su etapa de prueba final sin ningún obstáculo, debe
probar el producto más rigurosamente mientras está en iteraciones de construcción. Durante el
juego final, los testers trabajarán en sus historias de defectos.

Producción

Después de la etapa de lanzamiento, el producto pasará a la etapa de producción.

Desafíos de control de calidad con el desarrollo de software ágil

a) Las posibilidades de error son más ágiles, ya que se le da menos prioridad a la

documentación, lo que finalmente ejerce más presión sobre el equipo de control de
calidad.
b) Las nuevas funciones se introducen rápidamente, lo que reduce el tiempo disponible para
que los equipos de prueba identifiquen si las funciones más recientes se ajustan a los
requisitos y si realmente se adaptan a los negocios.
c) A menudo se requiere que los testers desempeñen un rol de semidesarrollador
d) Los ciclos de ejecución de pruebas están muy comprimidos.
e) Muy menos tiempo para preparar el plan de prueba
f) Para las pruebas de regresión, tendrán un tiempo mínimo
g) Cambio en su papel de ser un guardián de la calidad a ser un socio en Calidad
h) Los cambios y actualizaciones de requisitos son inherentes a un método ágil,
convirtiéndose en el mayor desafío para el control de calidad.

RIESGO DE AUTOMATIZACIÓN EN PROCESOS ÁGILES

La interfaz de usuario automatizada brinda un alto nivel de confianza, pero son lentas de ejecutar,
frágiles de mantener y costosas de construir. Es posible que la automatización no mejore
significativamente la productividad de las pruebas a menos que los testers sepan cómo probar

Las pruebas poco fiables son una preocupación importante en las pruebas automatizadas.
Arreglar las pruebas fallidas y resolver los problemas relacionados con las pruebas frágiles debe
ser una prioridad para evitar falsos positivos.

Si las pruebas automatizadas se inician manualmente en lugar de a través de CI (Integración

continua), existe el riesgo de que no se ejecuten regularmente y, por lo tanto, pueden fallar las
pruebas.

Las pruebas automatizadas no reemplazan las pruebas manuales exploratorias. Para obtener la
calidad esperada del producto, se requiere una combinación de tipos y niveles de prueba.
Muchas herramientas de automatización disponibles comercialmente brindan funciones simples
como la automatización de la captura y reproducción de casos de prueba manuales. Dicha
herramienta fomenta las pruebas a través de la interfaz de usuario y conduce a pruebas
intrínsecamente frágiles y difíciles de mantener. Además, el almacenamiento de casos de prueba
fuera del sistema de control de versiones genera una complejidad innecesaria.

Para ahorrar tiempo, muchas veces el plan de prueba de automatización está mal planificado o
no planificado, lo que da como resultado que la prueba falle.

Los procedimientos de configuración y desmontaje de la prueba generalmente se pierden durante

la automatización de la prueba, mientras que la realización de pruebas manuales, los
procedimientos de configuración y desmontaje de la prueba suenan perfectos.

Las métricas de productividad, como una cantidad de casos de prueba creados o ejecutados por
día, pueden ser terriblemente engañosas y podrían llevar a realizar una gran inversión en la
ejecución de pruebas inútiles.

Los miembros del equipo de automatización ágil deben ser consultores efectivos: accesibles,
cooperativos e ingeniosos, o este sistema fallará rápidamente

La automatización puede proponer y ofrecer soluciones de prueba que requieren demasiado

mantenimiento continuo en relación con el valor proporcionado

Las pruebas automatizadas pueden carecer de la experiencia para concebir y ofrecer soluciones
efectivas

Las pruebas automatizadas pueden tener tanto éxito que se queden sin problemas importantes
para resolver y, por lo tanto, se conviertan en problemas sin importancia.

12 TAREAS CLAVE QUE TODO PROFESIONAL DE PRUEBAS ÁGILES DEBE REALIZAR

1. Ayuda a definir "Done"

Antes del testing ágil, se tenía que esperar a que los analistas de negocios terminaran la fase de
requisitos antes de poder comenzar a construir su plan de prueba en detalle y asegurarse de
tener una cobertura completa y trazabilidad para todos los requisitos.

Hoy, las cosas son diferentes. En lugar de esperar a que los analistas comerciales terminen su
trabajo y se lo entreguen, usted es parte del proceso de definir historias de usuarios, agregarlas
al trabajo pendiente y ayudar al equipo a definir los criterios que se deben cumplir para cada
historia. ser considerado "hecho". Usted es miembro de un equipo que interactúa con frecuencia
con el propietario del producto (el propietario del negocio del sistema que está creando) y se
asegura de que todos estén alineados con las pruebas funcionales y no funcionales que tendrá
que pasar la historia de usuario.
2. Alcance y estimación

Como tester ágil, ayudará a estimar el alcance y el tamaño del esfuerzo de prueba para cada
historia de usuario. El esfuerzo estimado para la prueba es parte de la estimación general del
tamaño de la historia de usuario, que no se puede marcar como "terminado" hasta que pase
todas las pruebas. Después de cada sprint, su equipo revisará y actualizará las estimaciones de
las próximas historias de usuarios en función de la experiencia del equipo en el sprint anterior y
volverá a planificar los próximos sprints en función de las nuevas estimaciones, que deberían
mejorar con el tiempo.

3. Evaluar la capacidad de prueba

Participará en el diseño del software trabajando en estrecha colaboración con los desarrolladores
para evaluar y asesorar sobre los aspectos de capacidad de prueba. También analizará
inquietudes como si las pruebas de software se pueden automatizar, si los componentes se
pueden probar de forma independiente del resto del paquete y cuánta información se escribe en
los archivos de registro.

4. Diseñar y ejecutar casos de prueba

En un proyecto ágil, todos los miembros del equipo desempeñan un papel en las pruebas. Cada
miembro del equipo puede tener su propia especialidad, pero todos son responsables de entregar
las historias de usuario del equipo al final del sprint. El equipo escribirá pruebas unitarias
funcionales, de rendimiento y automatizadas, además de crear scripts para implementar código
automáticamente en entornos de prueba y ejecutar las pruebas. Como tester del equipo, ayudará
a diseñar y ejecutar pruebas automáticas y manuales, incluidas las pruebas exploratorias. Como
las pruebas se infunden a lo largo del proceso de desarrollo, usted se involucrará en las pruebas
a nivel de componente y API, así como a nivel de características y de extremo a extremo. También
estará probando esos requisitos no funcionales a los que los equipos a veces se refieren como
las "capacidades": seguridad, confiabilidad, mantenibilidad, escalabilidad, facilidad de uso, etc.

5. Automatiza

En un entorno de desarrollo ágil, hay pequeños incrementos de funcionalidad frecuentes al final

de cada sprint, lo que significa que el software cambia continuamente. La frecuencia de cambio
hace que la velocidad de las pruebas de regresión sea increíblemente importante, porque el
código debe probarse cada vez que se confirma un cambio. Esto significa que necesita
automatizar sus pruebas tanto como sea posible; las pruebas manuales simplemente toman
demasiado tiempo. Busque oportunidades para automatizar pruebas y scripts de implementación
y desarrolle marcos de automatización de pruebas para su equipo y el resto del tren de
lanzamiento ágil.

6. Colabora

Trabajará más de cerca que nunca con los desarrolladores. Si encuentra un defecto, infórmele al
desarrollador y permítales usar su sistema para depurar, de modo que puedan encontrar y
solucionar el problema lo más rápido posible. No los obligue a configurar su propio sistema. Están
trabajando juntos en el mismo código e historia de usuario, con el mismo objetivo de proporcionar
software funcional al final del sprint.
En ocasiones, también necesitará ayudar a los miembros del equipo que necesitan asistencia para
completar una historia de usuario que no ha progresado según lo planeado.

Tenga en cuenta que la colaboración en organizaciones más grandes difiere del ideal de tener
equipos ubicados en Agile puro. Además de la interacción inevitable con la burocracia empresarial
y la necesidad de trabajar con equipos no ágiles, los miembros de equipos ágiles en grandes
organizaciones a menudo trabajan con colegas en el extranjero. Esto presenta desafíos tales
como diferentes zonas horarias, idiomas y culturas. Cuando está ubicado, gran parte de la
información valiosa (y los chismes) se intercambian en el enfriador de agua o mientras toman
una taza de café informal. Mantenga informados a sus colegas externos.

7. Verificar arreglos

ESTÁ BIEN. Esto no suena nuevo. Ayer, también estabas trabajando en la verificación de
correcciones. Pero es posible que estas correcciones se hayan realizado hace semanas o meses,
y solo pudo probarlas cuando se entregó una compilación formal al control de calidad. Sin
embargo, en ágil, el objetivo es corregir y verificar errores dentro del mismo sprint, porque de lo
contrario las pruebas no pasarán y la historia del usuario no se puede considerar "terminada".

En organizaciones más grandes, puede haber ocasiones en las que no sea posible corregir un
defecto en el mismo sprint, quizás porque estás trabajando con otra parte de la organización que
no está alineada con tus objetivos. Muchas organizaciones incluyen un sprint de innovación y
planificación, que le brinda la oportunidad de verificar las correcciones más adelante, pero aún
dentro del conjunto de sprints que componen el incremento del programa.

8. Asistir a reuniones diarias

Es importante asistir y contribuir a las reuniones diarias. Para ser realmente eficaz, no se limite a
hablar de lo que logró ayer y lo que va a hacer hoy. La parte más importante de una reunión
diaria es compartir los obstáculos que le impedirán progresar como tester en el equipo.

Concéntrese en identificar y describir estos obstáculos al resto del equipo y solicite la ayuda del
equipo para eliminarlos.

9. Seguimiento de diferentes métricas

Ayer, cuando formaba parte de un equipo de control de calidad, siguió las métricas que eran
importantes para su organización, como el estado de los requisitos, la cantidad de defectos
reabiertos, etc. Hoy, verá un nuevo conjunto de métricas que Necesitará realizar un seguimiento
como parte de una organización ágil, como el trabajo pendiente de sprint, la velocidad y el trabajo
pendiente de liberación.

10. Falla

Sí, puedes fallar. Está bien.

Incluso podría decir que es su responsabilidad fallar de vez en cuando, pero solo mientras falle
rápido y aprenda de sus fallas. En el desarrollo tradicional, no sólo se desalienta el fracaso, sino
que a menudo se lo castiga. En ágil, se acepta el fracaso y las lecciones aprendidas de los fracasos
se comparten con el equipo. El apoyo de la administración para adaptarse a las fallas es
fundamental para el éxito de Agile en la empresa.
11. Acepta el cambio

Hoy, puedes probar el segundo principio detrás del Manifiesto Ágil: dar la bienvenida al cambio.
Pasar a ágil en sí mismo es un gran cambio, pero ahora que eres ágil, debes estar preparado no
solo para esperar el cambio sino también para enfrentarlo. En un entorno tradicional, una
interrupción durante el desarrollo puede poner en peligro todo el proyecto. Pero en ágil, cualquier
historia de usuario que cumpla con los criterios de "terminado" está lista para continuar. Debido
a que preparar y reevaluar constantemente el backlog es parte del concepto ágil, el equipo puede
adaptarse y aceptar las interrupciones. La única víctima importante de una interrupción en ágil
debería ser el sprint actual, pero debido a que apunta a sprints cortos, solo hay un par de semanas
de trabajo en juego.

12. Aprende

Siempre ha tenido que mantenerse al día con el producto que está probando y las tecnologías
que está encontrando, así como con las pruebas en sí. Pero ahora que está en una organización
ágil, deberá aprender sobre la metodología ágil en sí misma, incluido lo que funciona y lo que no
funciona para usted. Realice los cambios que necesite y siga reevaluando si están funcionando o
si es necesario perfeccionarlos o eliminarlos.