CURSO DE TESTING MANUAL O QUALITY CONTROL

MATERIAL DE LECTURA

METODOLOGÍAS
ÁGILES
OBJETIVOS DE ESTA GUÍA:
• Entender Scrum y su funcionamiento
• Comprender con que entornos laborales trabaja Scrum
• Identificar los elementos del Manifiesto Ágil
• Diferenciar los roles de Scrum
• Saber qué es un Sprint y cómo funciona
• Conocer el valor de las ceremonias de Scrum
• Entender la importancia del rol del QA en Scrum
• Conocer las responsabilidades del rol del QA en Agile
• identificar las diferentes actividades de prueba dentro del proceso Scrum

SCRUM
¿QUÉ ES LA METODOLOGÍA SCRUM Y CÓMO FUNCIONA?

Scrum es un framework adaptable, iterativo, rápido, flexible y eficaz que está diseñado para
entregar valor al cliente durante todo el desarrollo del proyecto. El objetivo primordial es satisfacer
las necesidades del cliente a través de un entorno de transparencia en la comunicación,
responsabilidad colectiva y progreso continuo.

Este framework es muy ágil y completo para el desarrollo de proyectos. En Scrum la palabra
producto hace referencia a un producto o servicio o cualquier otro resultado que esté de acuerdo
con definición de la visión del proyecto, es decir que puede aplicarse a TODO tipo de proyectos,
pero no todos los proyectos requieren el uso de Scrum.

¿QUÉ EQUIPOS NECESITAN TRABAJAR CON LA METODOLOGÍA SCRUM?

Piensa por ejemplo que tu proyecto es la construcción de un conjunto de apartamentos, éste no

es un proyecto que vaya a tener altas probabilidades de cambios a lo largo de su ejecución,
además requiere que desde el comienzo esté todo perfectamente documentado con planos y
materiales. No es fácilmente adaptable su desarrollo a etapas y no es necesaria la participación
permanente del cliente para lograr el mejor resultado, como ves usar Scrum en este caso no traería
ventajas.

Aquí entramos en un tema que genera mucha polémica: ¿qué es ser ágil en cuanto a desarrollo
de proyectos se refiere?

Es fácil confundirse por la palabra y pensar que ser ágil es ser rápido y esto es un error que puede
ser costoso. Ser ágil en desarrollo de proyectos es optimizar el uso de recursos y buscar la mejor
forma de llevar a cabo un proyecto aprovechando la experiencia propia y la de los colaboradores.

LOS 4 ELEMENTOS DEL MANIFIESTO ÁGIL: SCRUM

El manifiesto ágil está basado en 4 elementos y aquí es importante esclarecer que, si bien son más
valorados los elementos siguientes cuatro elementos, no quiere decir que los otros elementos
deban ser olvidados o no ejecutarlos.

1. Individuos e interacciones sobre procesos y herramientas

2. Software funcionando sobre documentación extensiva
3. Colaboración con el cliente sobre negociación contractual
4. Respuesta ante el cambio sobre seguir un plan
Basados en estos elementos han surgido a través del tiempo diferentes frameworks de desarrollo
de proyectos que de una u otra manera siguen estos objetivos, uno de éstos es Scrum.

ROLES EN SCRUM

En Scrum tenemos dos categorías de roles:

1. Roles centrales

Los roles centrales son aquellos que su participación es indispensable para la realización del
proyecto, están comprometidos con el proyecto y son responsables del éxito de cada sprint y del
proyecto en general. Estos son:

a. Product Owner
b. Scrum master
c. Equipo Scrum

2. Roles no centrales

Los roles no centrales son aquellos cuya participación en el proyecto es importante pero no
depende de ellos el éxito o fracaso del proyecto, es importante siempre identificar los individuos
de esta categoría y mantenerlos siempre presentes, en cualquier momento su rol puede ser
decisivo para el proyecto (por ejemplo, si es un sponsor). Estos son:

a. Stakeholders
a. Cliente
b. Usuarios
c. Patrocinador (sponsor)
b. Vendedores
c. Scrum Guidance Body

En la siguiente gráfica vemos una descripción general y cómo se relacionan los roles centrales del
Equipo Scrum.

Scrum define cinco ceremonias principales para cumplir con el control de sus procesos, todas con
un sentido de ser propio que hace que sean imprescindibles para esta metodología.

Aunque el proceder general de algunas compañías es el de adecuar las ceremonias prescritas a

sus necesidades y, si bien esto puede tener sentido en algunas organizaciones que cuentan con
una larga tradición en otras metodologías, la tímida aplicación de las ceremonias y su exagerada
adaptación a la cultura preexistente en la organización terminan en muchos casos por generar lo
mismo que venían produciendo, pero con nuevos nombres que suenan más “Agile”, lo cual suele
acabar en sonoros fracasos.

La razón por la que Scrum cuenta con estas cinco ceremonias es la de mantener los mínimos
necesarios para facilitar que el control empírico de procesos funciona. El gran problema de adaptar
estos eventos o de transformarlos en otra realidad es el de dinamitar uno de los pilares
fundamentales de Scrum y, por lo tanto, asumir correr el riesgo al que conlleva. Analicemos a
continuación lo que es un Sprint y las ceremonias que van asociadas al mismo:

¿QUÉ ES UN SPRINT?

Sprint es un contenedor para el resto de los eventos de Scrum. El Sprint es continuo, es decir, su
duración no debe cambiar mientras está en marcha el desarrollo del producto, y se puede
interpretar como una medida de ritmo constante a lo largo del tiempo, permitiéndonos reducir
complejidad y comparar resultados a lo largo de diferentes Sprints. El Sprint permite la
transparencia, así como inspeccionar y adaptar los otros eventos de Scrum.

Scrum prescribe que un Sprint debe durar 4 semanas más o menos. Aunque es bastante habitual
que los equipos Scrum elijan tener Sprints de diversas duraciones según la finalidad perseguida.
Cada caso es diferente y es el equipo Scrum el que debe descubrir cuál es su periodo mínimo
necesario para generar valor a través de un incremento terminado. Partiendo de la experiencia
más inmediata en la implantación de “Agile” a lo largo de diferentes organizaciones, la duración
real de los Sprints es la siguiente:

2 semanas: poco frecuente, generalmente usada en proyectos de I+D o PoCs que requieren de
un rápido ciclado para obtener resultados a muy corto plazo.

3 semanas: frecuente, se asemeja al anterior, pero generalmente en iniciativas de algo más de

envergadura.

4 semanas: lo más frecuente, parece un ritmo adecuado para la mayor parte de los productos.

5 semanas: frecuente también, aunque es una duración fuera de los estándares de Scrum. Es
habitual encontrarnos este escenario en las organizaciones, demandado por los propios equipos
Scrum. Resulta muy útil en proyectos que se encuentran en fases iniciales, así como en periodos
estimados como menos productivos.

La duración de un Sprint está determinada por el periodo mínimo en que un equipo de desarrollo
puede generar valor a través de un incremento determinado. El Sprint es una iteración definida
(time boxed) que sirve al desarrollo iterativo e incremental.

La duración del Sprint se determina por un horizonte de planning aceptable, determinado por el
propio equipo Scrum junto al Product Owner. No hay fases en Scrum, sólo Sprints. No existen
Sprints específicos de testing, hardening, release o análisis.

Un Sprint normal tendría los siguiente eventos o ceremonias:

1. El Sprint Planning al comienzo del Sprint

2. Daily Scrums a diario
3. Un Sprint Review al final del Sprint para inspeccionar el incremento realizado.
4. Y, finalmente, una Retrospectiva para inspeccionar el equipo y levantar mejoras que se
apliquen en el siguiente Sprint.
5. Adicionalmente se ha incorporado también una reunión de Grooming o Refinamiento
(Refinement), que sirve para, dentro del Sprint, afinar y aclarar ciertas historias de usuario
que pudieron quedar pendientes durante el Sprint Planning.
Todo ocurre en un sólo Sprint y en cada Sprint. La mentalidad de un proyecto por Sprint es uno
de los cambios más difíciles de asumir para las organizaciones que están haciendo una transición
a esta metodología Agile-Scrum. A diferencia de la gestión tradicional de proyectos, donde un
proyecto puede durar meses o años, en Scrum un “proyecto” dura un sólo un Sprint, de modo que
todas las tareas necesarias para llevar el proyecto a cabo (como el diseño, la planificación o el
testing) se realizan dentro del mismo Sprint, siempre orientado a generar el máximo valor.

En Scrum, los proyectos se financian por cada Sprint y es el Product Owner quien decide dónde y
a qué dedicar los recursos. Entender esto es crítico para asegurar el éxito en el empleo de Scrum
en una organización.

1ª CEREMONIA: SPRINT PLANNING

El Sprint Planning es una reunión que se realiza al comienzo de cada Sprint donde participa el
equipo Scrum al completo; sirve para inspeccionar el Backlog del Producto (Product Backlog) y
que el equipo de desarrollo seleccione los Product Backlog Ítems en los que va a trabajar durante
el siguiente Sprint. Estos Product Backlog Ítems son los que compondrán el Sprint Backlog.

Durante esta reunión, el Product Owner presenta el Product Backlog actualizado que el equipo de
desarrollo se encarga de estimar, además de intentar clarificar aquellos ítems que crea necesarios.

Si bien en el Sprint Planning participa el equipo Scrum al completo, no participan los Stakeholders.
En el Sprint Planning se inspeccionan el Product Backlog, los acuerdos de la Retrospectiva, la
capacidad y la Definition of Done y se adaptan el Sprint Backlog, Sprint Goal y el plan para poder
alcanzar ese Sprint Goal.

El Sprint Planning se divide en dos partes. En la primera parte de la reunión se trata Qué se va a
hacer en el siguiente Sprint y, en la segunda parte, se discute el Cómo. La primera parte está
organizada y liderada por el Product Owner, mientras que de la segunda parte se encarga el
Development Team. La única labor del Scrum Master es asegurarse de que la reunión existe como
parte de Scrum y que se mantiene dentro de las duraciones estimadas.

El Sprint Planning puede durar hasta 8 horas para Sprints de 4 semanas. En la práctica esta
ceremonia suele llevar una mañana completa -alrededor de 5 horas- y, sólo si el producto o el
Sprint definido por el Product Owner son complejos o están poco claros, se llegan a alcanzar las
8 horas definidas en la metodología. La razón del Sprint Planning es conseguir alineamiento entre
negocio y desarrollo de producto en relación con las prioridades.

2ª CEREMONIA: DAILY SCRUM

El Daily Scrum, conocido comúnmente sólo como “La Daily”, es una reunión diaria de 15 minutos
en la que participa exclusivamente el Development Team.

En esta reunión todas y cada una de las personas del Development Team responden a las
siguientes preguntas:

• ¿Qué hice ayer para contribuir al Sprint Goal?

• ¿Qué voy a hacer hoy para contribuir al Sprint Goal?
• ¿Tengo algún impedimento que me impida entregar?

Mucha gente confunde el Daily Scrum con el Standup Meeting, sin embargo, este último es una
práctica de extreme Programming (XP) orientada a controlar y gestionar el trabajo motivada por
un manager, mientras que el primer término, Daily Scrum, hace referencia a la práctica que permite
la inspección y adaptación a través de la autoorganización del equipo.

3ª CEREMONIA: SPRINT REVIEW

El Sprint Review es la reunión que ocurre al final del Sprint, generalmente el último viernes del
Sprint, donde el product owner y el Develpment Team presentan a los stakeholders el incremento
terminado para su inspección y adaptación correspondientes. En esta reunión organizada por el
product owner se estudia cuál es la situación y se actualiza el Product Backlog con las nuevas
condiciones que puedan afectar al negocio.

El equipo ha pasado hasta cuatro semanas desarrollando un incremento terminado de software

que ahora mostrará a los stakeholders. No se trata de una demostración, sino de una reunión de
trabajo. El software ya ha sido mostrado y validado junto con el product owner previamente a esta
reunión.

Por un lado, se revisará el incremento terminado. Se mostrará el software funcionando en

producción y los stakeholders tendrán la oportunidad de hacer cuantas preguntas estimen
oportunas sobre el mismo. El software funcionando ha sido validado previamente por el product
owner, que se ha encargado de trabajar con el equipo durante el Sprint para asegurarse que
cumple con la Definition of Done y, efectivamente, hace que el Sprint Goal sea válido. Si no existe
software funcionando, el Sprint Review carece de sentido, aunque en ciertas ocasiones y
oportunidades se sigue manteniendo.

El Development Team tiene que tener un papel importante en esta reunión. Muchas veces no es
el product owner quien demuestra el incremento producido, sino que son los propios miembros
del Development Team quienes lo hacen. Es una buena práctica no sólo el que lo lleven a cabo,
sino también el que lo hagan de forma rotatoria y, tras varios Sprints, hayan participado todos.

El equipo de desarrollo comenta posteriormente qué ha ocurrido durante el Sprint, los

impedimentos que se han encontrado, así como soluciones tomadas y actualizan a los
stakeholders con la situación del equipo. Por último, el product owner actualiza -con la información
de negocio recibida en esta reunión- el Product Backlog para el siguiente Sprint.

En contra de lo que comúnmente se cree, el Sprint Review no se trata de una demo para un cliente
o para los stakeholders o incluso para el product owner, ni es tampoco una reunión para felicitar
al Equipo de Desarrollo. Es una reunión de trabajo, una de las más importantes porque sirve para
marcar la estrategia de negocio. La duración estimada en el estándar para un Sprint Review es de
8 horas para un Sprint de 4 semanas, aunque habitualmente estas reuniones se ejecutan en un
entorno de entre 2 y 3 horas.

4ª CEREMONIA: SPRINT RETROSPECTIVE

La retrospectiva ocurre al final del Sprint, justo después del Sprint Review. En algunos casos y por
comodidad de los equipos, se realiza conjuntamente con el Sprint Planning, siendo la retrospectiva
la parte inicial de la reunión.

El objetivo de la retrospectiva es hacer de reflexión sobre el último Sprint e identificar posibles

mejoras para el próximo. Aunque lo habitual es que el Scrum Master sea el facilitador, es normal
que distintos miembros del equipo Scrum vayan rotando el rol de facilitador durante la
retrospectiva.

Un formato común es analizar qué ha ido bien durante el Sprint, qué ha fallado y qué se puede
mejorar. Este formato se puede facilitar pidiendo a los miembros del equipo Scrum que escriban
notas –en post-its- para luego agruparlas y votar aquellos ítems más relevantes, dando la
oportunidad a todos de hablar y expresar sus inquietudes.

También se utiliza el formato de retrospectiva basado en cinco fases:

1. Preparar el ambiente: un pequeño ejercicio para romper el hielo.

2. Recolectar información: durante esta fase, se utilizan actividades para intentar construir
una imagen de lo que ha sido el último Sprint, resultando una imagen conjunta de equipo.
3. Generación de ideas: el equipo intenta generar ideas para identificar acciones que
ayuden a mejorar el rendimiento del equipo durante el siguiente Sprint.
 4. Decidir qué hacer: de las ideas generadas, se proponen acciones que el equipo pueda
implementar en el próximo Sprint.
5. Cierre: Una pequeña actividad de cierre, normalmente unida a una evaluación de la
propia retrospectiva, ayuda al equipo a decidir hacia dónde dirigirse en próximas
ocasiones. Un recordatorio de la mejora continua.

La duración recomendada por Scrum para un Sprint de 4 semanas es de un máximo de 3 horas,

aunque habitualmente se destina entre 1 y 2 horas a este evento.

5ª CEREMONIA: SPRINT GROOMING O REFINEMENT

El refinamiento del Product Backlog es una práctica recomendada para asegurar que éste siempre
esté preparado. Esta ceremonia sigue un patrón similar al resto y tiene una agenda fija específica
en cada Sprint. Se estima su duración en 2 horas máximo por semana del Sprint. Es
responsabilidad del product owner agendar, gestionar y dirigir esta reunión.

Los participantes de esta reunión son todo el equipo Scrum, así como cualquier recurso adicional
que considere necesario el PO y que pueda contribuir a aclarar el requerimiento. Es necesario,
por tanto, que antes de la reunión todos conozcan los requerimientos o historias de usuario que
van a ser tratados en la misma y sólo asistan aquellos cuya presencia sea estrictamente relevante.

¿QUÉ SON LAS ÉPICAS Y LAS HISTORIAS DE USUARIO?

Recordemos estos conceptos que ya trabajamos y aplicaremos ampliamente al utilizar esta

metodología de trabajo.

Las historias de usuario son breves requisitos o solicitudes escritas desde el punto de vista del
usuario final.

Las épicas son grandes cantidades de trabajo que se pueden desglosar en un número de tareas
más pequeñas (llamadas "historias"). Por lo tanto, las épicas son un conjunto de historias de
usuarios.

En cierto momento del scrum definimos todas las historias de usuario que necesitamos para
perseguir un objetivo en común, ese conjunto de historias es una épica. El proceso de creación
de historias de usuario lo hacemos en conjunto con los requerimientos de los clientes.
Recordemos que, la base principal de las metodologías ágiles es definir cada acción siempre a la
par de lo que el cliente necesita y cuando lo necesita.

Al redactar historias de usuario nos ponemos en el lugar del cliente para adaptar lo que queremos
hacer a su lenguaje y tal y como él mismo nos lo pide. Por ejemplo, tener la posibilidad de vincular
actividades entre sí, si estamos desarrollando un planificador online.

Material de apoyo sugerido:

a) https://youtu.be/sLexw-z13Fo
b) https://youtu.be/lSYZ1sZWvbQ
c) https://youtu.be/8qa6io8wHQA
d) https://youtu.be/Kxz0_rDmRho

EL QA EN SCRUM
- QA: Como responsable de la calidad del producto, no apruebo que se realice el
lanzamiento, no funciona correctamente en Internet Explorer.
- Product Owner: Como la persona responsable de maximizar el valor del producto,
apruebo la puesta en marcha AHORA. Además, no tenemos clientes que utilicen Internet
Explorer. Esto no es un bloqueador en absoluto.
 - QA: Tenemos que cubrir Internet Explorer, es parte de la cobertura de nuestros
navegadores. Por lo tanto, no se activará hasta que se solucione el problema de
compatibilidad.
- Product Owner: No tiene sentido. Necesitamos revisar los navegadores que está
probando en función de nuestra audiencia. De lo contrario, perdemos nuestro tiempo.
¡Pero por ahora, la puesta en marcha debe suceder!

A pesar de que el PO y el QA están en el mismo equipo y comparten los mismos objetivos, la

tensión entre ellos es cada vez mayor y, sin embargo, la discusión no lleva a ninguna parte. Esta
es una situación típica entre el control de calidad y el propietario del producto ¿Cómo podríamos
evitar tales disputas? ¿Cómo podríamos colaborar más?

¿QUÉ ES LA CALIDAD EN SCRUM?

Como mencionamos antes, hay dos tipos de calidad en Scrum que es un subconjunto de Agile:

Calidad intrínseca. Consiste en todas las cualidades incorporadas que posee el producto. Eso
incluye idoneidad, durabilidad o confiabilidad, junto con uniformidad y mantenibilidad. Podemos
medir este tipo de calidad cuantitativamente gracias a la cobertura de pruebas, los defectos
escapados o los errores por línea de código, etc.

Calidad extrínseca. Este tipo sirve como la percepción de calidad del cliente y, al mismo tiempo,
el valor de la calidad para el cliente. La calidad extrínseca requiere una medición más cualitativa
que depende de las ventas, el uso o los comentarios de los compradores.

Cuando la mayoría de la gente habla de calidad, habla de la intrínseca. Es por eso que las
empresas deben tener miembros del equipo llamados especialistas en Garantía de Calidad (QA).
Estos profesionales no evalúan la percepción del comprador sobre el producto; su responsabilidad
es realizar la verificación y validación. Ambas etapas de prueba deben dar respuesta a las
siguientes preguntas:

• ¿Estamos construyendo bien el producto?

• ¿Estamos construyendo el producto correcto?

Por lo tanto, el objetivo de la verificación y validación es probar si el producto corresponde a los

requisitos comerciales y técnicos recopilados. Lea más sobre las etapas de prueba en el desarrollo
de software para saber si puede responder las preguntas anteriores correctamente mientras
realiza la verificación y validación.

En los productos Agile, las empresas crean productos teniendo en cuenta que todos los requisitos
se vinculan con una visión y una propuesta de valor orientada al cliente. Si los requisitos técnicos
y comerciales no se alinean con esa visión, su confiabilidad no importa porque no brindan ningún
valor. El objetivo de todas las iteraciones y lanzamientos es proporcionar las funciones de mayor
valor que se equilibren con los costos de desarrollo necesarios para crear dichas funciones. En
última instancia, es el objetivo de todos los sprints de scrum.

EL ROL DE CONTROL DE CALIDAD DENTRO DEL EQUIPO SCRUM

El Equipo de Desarrollo es responsable de cada trabajo requerido para construir un producto

potencialmente disponible. Los miembros no tienen títulos. En este caso significa que QA es una
actividad dentro del equipo. Un miembro específico del equipo puede realizarlo. Sin embargo, el
equipo es responsable como un todo.

A pesar de la claridad en la Guía Scrum dentro de la estructura del equipo, las empresas a menudo
usan títulos para cada miembro del equipo, lo que impide que los equipos funcionen de la manera
óptima que deberían.
LOS MALENTENDIDOS SOBRE LAS PRUEBAS

Durante la retrospectiva, el propietario del producto planteó una inquietud: "¿Por qué tardamos
tanto en probar cada elemento de la cartera de productos? Tengo la sensación de que estamos
complicando demasiado nuestro trabajo en lugar de simplificarlo”.

El Equipo de Desarrollo es responsable del trabajo realizado dentro del Sprint. Por lo tanto, los
métodos y enfoques de prueba son parte de las responsabilidades del Equipo de Desarrollo.
Independientemente de si los miembros tienen un título de control de calidad o no, al final, la
responsabilidad recae en todo el equipo.

La definición de “HECHO” (DoD) del equipo establece la granularidad de las pruebas. Sin embargo,
el equipo de desarrollo a menudo define los detalles sin involucrar al propietario del producto. Ahí
es cuando comienzan los problemas porque crea un desajuste de expectativas entre el propietario
del producto y el equipo de desarrollo. El DoD define lo que significa "Terminado" para todo el
Equipo Scrum. Por lo tanto, todos los miembros deben desempeñar un papel en la elaboración del
DoD.

El Equipo Scrum debe apuntar a la simplicidad, para que el equipo evite el desperdicio. Entonces,
las expectativas importan mucho. El propietario del producto debe colaborar con el equipo de
desarrollo para comprender dónde tiene sentido probar. Por ejemplo, en una tienda online, ¿qué
navegadores admitimos? Eso debería quedar claro; de lo contrario, los malentendidos son
inevitables.

Las expectativas claras sobre la calidad del producto son vitales para un Equipo Scrum
eficiente. Sin ella, el equipo necesita adivinar qué significa calidad, lo que conduce a la
ineficiencia.

¿CÓMO DEBE PROBAR EL EQUIPO LOS ELEMENTOS DE LA CARTERA DE PRODUCTOS?

En Scrum, el Equipo de Desarrollo presenta el resultado del Sprint durante la Revisión del Sprint,
el Product Owner y los Stakeholders invitados asisten al evento. Sin embargo, la práctica no suele
ir de la mano de la teoría.

Un escenario típico es que el propietario del producto proporciona comentarios al equipo de

desarrollo durante el Sprint. Por ejemplo, el equipo de desarrollo terminó una función y luego le
pide al propietario del producto una validación. Sin embargo, en este caso, ¿cuándo debe el
propietario del producto proporcionar comentarios?

Hay diferentes escenarios:

Después de "Hecho": la tarea coincide con los criterios del DoD. Luego, el propietario del producto
valida la tarea en un entorno de prueba y proporciona comentarios. En este caso, si el propietario
del producto rechaza, el equipo de desarrollo deberá volver a ejecutar completamente algunas
actividades después de cambiar la tarea, por ejemplo, las pruebas.

“Lo antes posible”: el equipo de desarrollo solicita comentarios durante la fase de desarrollo. En
este caso, el propietario del producto colabora con un miembro del equipo, probablemente en el
entorno local, para validar la comprensión del equipo.

Basandonos en la sencillez y la colaboración. Si el Product Owner proporciona retroalimentación

lo antes posible, el equipo será más productivo y eficiente.

Yendo más allá, un excelente Product Owner alentará al Equipo de Desarrollo a tomar decisiones
sin él o ella, lo que no significa que el Product Owner deba estar ausente. Un Product Owner
altamente colaborativo que entrena a los equipos para resolver problemas en tiempo real en el
Sprint construye un equipo sólido. Los equipos de alto rendimiento tienen esta característica.

¿CUÁLES SON LAS RESPONSABILIDADES DEL QA EN AGILE?

QA tiene una amplia variedad de nuevos roles y responsabilidades en el desarrollo de software
Agile y la gestión de proyectos.

En la metodología ágil, los miembros del control de calidad no solo son responsables de escribir
casos de prueba y probar el código, el alcance de su función va mucho más allá. Estas son algunas
de las responsabilidades del especialista en control de calidad en procesos ágiles:

• Proporcione un análisis de los aportes de los clientes, las partes interesadas, los usuarios
finales y otros participantes del proyecto.
• Revisar historias de usuarios, como generación de requisitos, historias fuera de alcance,
historias faltantes, etc.
• Consulte sobre características con los desarrolladores.
• Cree casos de prueba automatizados, pruebas de regresión y criterios de aceptación.
• Consulta sobre desarrollo de sprints, duración, desarrollo de requisitos, especialmente en
Scrum.
• Asegúrese de que las características de funcionalidad no afecten negativamente a otras
características.

¿QUÉ ES IMPORTANTE PARA EL QA EN AGILE TEAM?

Para garantizar un producto de la mejor calidad, los miembros de QA deben participar en todos
los aspectos del proyecto:

EL CONTROL DE CALIDAD DEBE CENTRARSE EN EL CLIENTE

Con Agile, se centrará continuamente en el cliente. Debe aprender todo sobre cómo el cliente usa
el producto, comprender el diseño del producto y, en general, pensar como un cliente. Luego,
puede combinar eso con el conocimiento del sistema de trabajo para definir pruebas y escenarios
que pueden no ser evidentes desde el exterior.

EL QA DEBE AUTOMATIZAR EL CONJUNTO DE PRUEBAS

Dado que las pruebas ágiles se realizan en paralelo al desarrollo, la automatización se vuelve
crítica. Sin ella, el control de calidad volverá a probar la misma funcionalidad repetidamente y se
retrasará rápidamente.

El especialista en control de calidad podrá realizar pruebas desde el exterior como si la aplicación
fuera una caja negra. Con los desarrolladores y el control de calidad abordando las pruebas
automatizadas de forma ágil, el control de calidad obtendrá pruebas de caja negra y de caja
blanca. Además, con las pruebas automatizadas, QA creará pruebas que los ingenieros también
pueden usar. Estas pruebas pueden incluirse en la canalización de desarrollo y ejecutarse
automáticamente sin intervención manual.

LOS QA DEBEN MEJORAR CONTINUAMENTE SU TRABAJO

El control de calidad debe impulsar la mejora continua de las prácticas de prueba. Trabaje para
convertirse en un experto en metodologías y estrategias de pruebas ágiles. Ayude a los
desarrolladores a crear pruebas de integración que no sean inestables pero que garanticen que
el sistema funcione. Ayude a construir suites de prueba saludables y mantenibles.

EL CONTROL DE CALIDAD DEBE SER PARTE DEL EQUIPO DE DESARROLLO AGILE

El mayor cambio consiste en tener QA como parte del equipo de desarrollo ágil y no como un
equipo separado. Dado que los especialistas en control de calidad son participantes del equipo,
pueden ayudar en las pruebas continuas, en lugar de hacerlo todo al final de un sprint.

En un equipo ágil, todos son responsables de la calidad. Puede ser una gran oportunidad para
compartir la experiencia con el equipo. El objetivo principal del control de calidad en Agile implica
no solo encontrar errores y defectos, sino también prevenirlos durante el ciclo de desarrollo.

¿CUÁLES SON LAS DIFERENTES ACTIVIDADES DE PRUEBA EN UN PROCESO SCRUM?

Reunión de Sprint: Decidir qué elemento debe elegirse de los trabajos atrasados y el tiempo
estimado para desarrollar el componente. También debe centrarse en la priorización del trabajo.

Scrum diario: En la reunión diaria de scrum, el tester recopilaría la información sobre las tareas
realizadas anteriormente y también planificaría la próxima tarea que debe entregarse al
desarrollador.

Trabajo diario: El tester debe realizar la prueba de aceptación, la prueba del sistema y en la prueba
unitaria y la prueba de integración el tester debe realizar la prueba de automatización como parte
del trabajo diario del sprint actual.

COMUNICACIÓN CARA A CARA

Una discusión cara a cara con los miembros del equipo es una forma eficiente de comunicar ideas
al equipo. Un tester participaría en la planificación / Sprint Release. Las reuniones de diseño se
llevarían a cabo cada vez antes de que se realice la planificación del sprint. Los evaluadores
participan en esta reunión y plantearían sus preguntas sobre las historias que se discutieron. El
tester debería tener que imaginar un modelo sobre cómo se vería y funcionaría el sistema
dependiendo de las discusiones.

CAPACIDAD PARA ENCONTRAR AMBIGÜEDAD

El tester trabajaría en colaboración con el propietario del producto y el cliente para formar criterios
de aceptación. Un tester ágil sería capaz de describir bien la característica. Antes de que la historia
de un usuario se envíe al equipo de desarrollo, el tester y otros miembros del equipo discutirían
sobre la historia completa del usuario con los miembros del equipo para averiguar qué es lo que
el cliente realmente quiere.

PAPEL ABSOLUTO

El tester debe tener buenas habilidades interpersonales. El tester debe tener habilidades técnicas
aparte de que debe tener buenas habilidades de comunicación para entregar el proyecto al
cliente. Esto muestra que el tester debe tener una gama más amplia de funcionalidades.

HABILIDADES TÉCNICAS

Un tester ágil entendería cuán apropiadas son las habilidades técnicas. Él / ella siempre estaría
listo para participar en las discusiones técnicas del equipo. Su participación puede extenderse
hasta revisiones de código, preparación de historias de usuarios, comprensión de requisitos. El
tester de software ágil trabajaría con los desarrolladores mientras realizan pruebas unitarias y
compartiría la perspectiva de las pruebas desde el punto de vista del tester en lugar del punto del
desarrollador.
AUTOMATIZACIÓN

Agile también requeriría pruebas de automatización en el momento de las pruebas de unidad e

integración. Para la automatización hay muchas herramientas disponibles que no necesitan
ninguna formación previa.

PRUEBAS EXPLORATORIAS

Las pruebas exploratorias son un método extremadamente útil y poderoso a veces en el proceso
ágil. Un tester exploratorio puede usar las habilidades del tester para realizar pruebas con el fin
de evitar riesgos e incertidumbre en el producto. El tester obtendría nuevas ideas de las
discusiones iniciales de diseño y las reuniones con el equipo para descubrir el sistema y explorar
más en el sistema. Una vez que el tester puede descubrir las áreas de ambigüedad, podría
comenzar a trabajar de manera más sistemática y eficiente en el producto. Un tester ágil debe
compartir el conocimiento y la información con el resto del equipo de scrum.

PAPEL DEL TESTER EN LAS REUNIONES DE REVISIÓN Y RETROSPECTIVA

El tester debe identificar lo que salió mal y lo que salió bien en el sprint actual.

Necesita aprender nuevas lecciones y mejores prácticas del sprint actual.

Se alentaría al tester a escribir nuevas historias de usuario que ayudarían en las pruebas y también
historias de usuario que ayudarían al cliente.

El tester también discutiría si alguna historia de usuario no ha sido cubierta en el sprint actual.

Cualquier obstáculo en el proyecto se pondría bajo consideración de Scrum Master.

¿CUÁL ES LA HABILIDAD DEL TESTER EN UNA METODOLOGÍA ÁGIL?

El tester ágil debe tener una buena comunicación con los miembros del equipo y estar listo para
dar retroalimentación. El conocimiento de las pruebas de automatización es imprescindible para
agile tester.

BUENAS PRÁCTICAS PARA UN PROCESO DE QA ÁGIL

Cuando se trata de desarrollo de software, la calidad lo es todo. El control de calidad (QA) es un

proceso sistemático que garantiza la excelencia de los productos y servicios. Un sólido equipo de
control de calidad examina los requisitos para diseñar, desarrollar y fabricar productos fiables,
aumentando la confianza del cliente, la credibilidad de la empresa y la capacidad de prosperar en
un entorno competitivo. Queremos brindarle algunos de nuestros consejos de mejores prácticas
para el proceso ágil de control de calidad.

El proceso de control de calidad ágil comienza al inicio del ciclo de vida del desarrollo de software.
Desde la reunión de diseño inicial, pasando por la fase de desarrollo, hasta la prueba final y el
fortalecimiento de la aplicación. Este proceso se repite en sprints hasta que se lanza el proyecto.

1. DEFINE UN PROCESO DE CONTROL DE CALIDAD ÁGIL

La mayoría de las empresas han pasado de la metodología tradicional de desarrollo en cascada a

un proceso ágil. Las pruebas ágiles introducen el control de calidad en el proyecto lo antes posible
para prever problemas, escribir y ejecutar casos de prueba y descubrir cualquier brecha en los
requisitos. Con el proyecto dividido en etapas iterativas, los ingenieros de control de calidad
pueden agregar enfoque al proceso de desarrollo y proporcionar comentarios rápidos y continuos.

Los sprints benefician al cliente al entregar software que funciona más temprano que tarde,
anticipando el cambio, brindando mejores estimaciones en menos tiempo y permitiendo
correcciones de rumbo en lugar de descarrilar completamente el proyecto. El equipo de control
de calidad puede incorporar lecciones aprendidas de proyectos anteriores para mejorar el
proceso para proyectos futuros.

2. ANÁLISIS DE RIESGO

Un aspecto importante de cualquier proceso de control de calidad es el análisis de riesgos. El

análisis de riesgos se define como el proceso de identificación y evaluación de los riesgos
potenciales y su impacto. El proceso ayuda a las organizaciones a evitar y mitigar los riesgos.

Es muy poco probable que una aplicación esté 100% libre de errores, pero un equipo de control
de calidad dedicado debería intentar eliminar o prevenir los errores más problemáticos.
Comprender todos los posibles resultados de un proyecto le permite a su equipo establecer
medidas preventivas que reducen la probabilidad de ocurrencia.

3. PRUEBA TEMPRANO Y CON FRECUENCIA

El modelo ágil tiene como objetivo incorporar QA en cada etapa del ciclo de vida del proyecto
para identificar problemas lo antes posible. Dentro de cada sprint, los ingenieros de control de
calidad prueban y vuelven a probar el producto con cada nueva función agregada. Esto les permite
validar que las nuevas funciones se implementaron como se esperaba y detectar cualquier
problema que pueda haberse introducido. Las pruebas tempranas y frecuentes conducen a la
conservación del tiempo y el presupuesto.

4. CAJA BLANCA VS. CAJA NEGRA

Las pruebas de caja negra no asumen ningún conocimiento de cómo un sistema hace lo que hace.
Solo tiene una comprensión de lo que debe hacer desde la perspectiva del usuario. Las pruebas
de caja blanca permiten al ingeniero de control de calidad desarrollar una comprensión más
profunda de las partes internas del sistema. Armado con este conocimiento, el ingeniero de control
de calidad puede comenzar a realizar pruebas mucho antes. En un proceso de control de calidad
ágil, los ingenieros de pruebas necesitan este nivel adicional de comprensión del sistema para
validar las características tan pronto como se desarrollen.

Las pruebas de caja blanca permiten a los equipos de control de calidad anticipar posibles
condiciones de error y desarrollar mejores escenarios de prueba. Saber cómo funciona el sistema
garantiza que hayan probado todos los escenarios de entrada posibles. También puede ayudar a
identificar posibles problemas de seguridad. Quizás lo más importante: las pruebas de caja blanca
fomentan una estrecha colaboración entre el desarrollo y el control de calidad.

5. AUTOMATIZAR CUANDO SEA FACTIBLE

La automatización puede ayudar a maximizar la eficacia de su personal de control de calidad. Dado

que las pruebas de regresión pueden consumir un gran porcentaje del tiempo del equipo de
control de calidad, la automatización proporciona una forma de garantizar que los entregables
anteriores continúen funcionando mientras los ingenieros de control de calidad se enfocan en
probar las funciones recién entregadas. Ser capaz de reproducir pruebas de manera confiable
liberará recursos para pruebas exploratorias. La automatización le dará a su equipo de desarrollo
la confianza para realizar cambios en el sistema con el conocimiento de que cualquier problema
se identificará rápidamente y se podrá solucionar antes de entregarlo al equipo de control de
calidad.

Dicho todo esto, es importante tener cuidado con la automatización excesiva. Su equipo debe
priorizar los casos de prueba y luego determinar cuál de ellos debe automatizarse. Es posible que
las situaciones en las que los datos puedan cambiar o en las que un escenario no sea reproducible
de manera consistente no se beneficien de la automatización porque los resultados pueden
causar fallas falsas.

La implementación de la automatización cuesta más por adelantado, pero ahorra dinero a largo
plazo al aumentar la eficiencia entre los equipos de desarrollo y control de calidad.

6. CONOCE A TU AUDIENCIA

Comprender al público objetivo mejorará el proceso de control de calidad. Adaptar el desarrollo y

el proceso de control de calidad a las necesidades de sus usuarios permitirá a su equipo crear
aplicaciones generadoras de valor. Cuando esté familiarizado con quién utilizará el producto final
real, podrá priorizar mejor el proceso de control de calidad para ahorrar tiempo y dinero.

7. EL TRABAJO EN EQUIPO HACE QUE EL SUEÑO FUNCIONE

Detrás de cada producto de alta calidad, hay un equipo de profesionales que trabaja
incesantemente para mantener el alto estándar de calidad defendido por la organización. Aunque
cada equipo que trabaja en el proyecto debe asumir la responsabilidad de garantizar la calidad, la
responsabilidad principal de la calidad recae en el equipo de control de calidad. El equipo de
control de calidad comprende lo que el cliente necesita que haga el sistema y puede demostrar
la satisfacción del cliente con el sistema. Al usar el proceso Agile QA, los ingenieros son los
superdetectives que solucionan los problemas y ayudan al equipo a entregar productos de alta
calidad y garantizar la confianza del cliente, la credibilidad de la empresa y la entrega exitosa del
producto.

ESCENARIOS DE ANÁLISIS
1) Florencia forma parte es un equipo de Scrum Developers y está en su primera Daily. ¿Cuáles
crees que serían las preguntas que debería responder de forma breve y eficaz?

a) ¿Qué hice ayer para contribuir al Sprint Goal?

b) ¿Cómo me siento y que mejoras considero oportunas para el proyecto?
c) ¿Qué voy a hacer hoy para contribuir al Sprint Goal?
d) ¿Cuáles son los avances que he logrado a lo largo de todo el Sprint?
e) ¿Tengo algún impedimento que me impida entregar?

2) Darío es QA junior y está trabajando en un equipo de desarrollo que utiliza Scrum. Le han
pedido que ejecute las pruebas y requerimientos necesarios del proyecto. Entendiendo el
concepto de agilidad, le recomendarías que debe:

a) No dar importancia a los plazos estimados, sólo a la calidad del proyecto y

procesos de las pruebas.
b) Centrarse en la optimización de recursos y procedimientos necesarios para lograr
los resultados y la calidad esperada. Tratando de cumplimentar los plazos
estimados.
c) Centrarse en trabajar y entregar todo de forma rápida, siendo la calidad algo
secundario en su rol.
 d) No desarrollar su labor porque considera que los plazos son acotados. Comentar
esta situación en la Sprint Review.

3) Claudia es QA senior y fue asignada a un proyecto de Software donde su principal tarea

es liderar a los demás QA. Este proyecto está trabajando con Scrum pero hasta el momento
ningún integrante del equipo de QA se ha presentado a las ceremonias de Scrum. Claudia
debería:

a) No dar importancia a esta situación y encargarse que el equipo de QA haga su

trabajo y observaciones, aunque sea de manera individual.
b) Recomendar, incentivar y explicar la importancia de que el QA esté presente en
todas las etapas y ceremonias del proyecto. Ya que ellos también son parte
esencial del equipo Scrum Developers.

4) Amanda pertenece a un equipo de desarrollo que utiliza Scrum y le han asignado

encargarse del proceso de control de calidad. Ella decide empezar a generar este proceso
de control de calidad a la mitad del proyecto. Esta decisión es:

a) Correcta, ya que ella debe estimar el momento y tiempos necesarios para generar
este proceso.
b) Correcta, ya que el proceso de calidad se puede dar en cualquier etapa sin afectar
al proyecto o equipo.
c) Incorrecta, Amanda debería iniciar con el proceso de control de calidad desde
que comienza el inicio del ciclo de vida de Software hasta que finaliza el proyecto.
Respetando los procesos y sprints correspondientes que conciernen a todo el
equipo.