UNIVERSIDAD MAYOR DE SAN SIMON

FACULTAD DE CIENCIAS Y TECNOLOGIA

DIRECCIÓN DE POSGRADO

“ROLES DE QA EN PROYECTOS ÁGILES”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE

DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES EMPRESARIALES
VERSIÓN I
.

POSTULANTE : HAROLD HUMBERTO BUHEZO CALDERON

TUTOR : LIC. VALENTIN LAIME ZAPATA

Cochabamba – Bolivia
2018
 Dedicado a toda mi familia por todo el apoyo
brindado en este largo camino.
Agradezco a la empresa Digital Harbor por
la oportunidad brindada.
Agradezco a todas las personas que creyeron
en mí, amigos/amigas y familiares.

ii
ÍNDICE
INTRODUCCIÓN ........................................................................................................................ 5
1. GENERALIDADES.............................................................................................................. 6
1.1 Antecedentes Generales ............................................................................................. 6
1.2 Antecedentes Específicos ........................................................................................... 6
2. METODOLOGÍA ................................................................................................................. 9
2.1 QA en metodología Ágil ............................................................................................... 9
2.2 Ágil testing ................................................................................................................... 9
2.3 Principios del Agile Testing........................................................................................ 10
2.4 La pirámide del Testing ............................................................................................. 10
2.5 Los cuadrantes del Agile Testing ............................................................................... 11
2.5.1 Pruebas de apoyo al equipo (Supporting the Team) .............................................. 12
2.5.2 Pruebas de críticas al producto (Critique the Product) ........................................... 15
2.5.3 Uso de los 4 cuadrantes ........................................................................................ 16
3. ESTRATEGIAS ÁGIL TESTING........................................................................................ 17
3.1 Iniciación de Proyecto ............................................................................................... 17
3.2 La estrategia organizacional del "equipo completo" ................................................... 18
3.3 El equipo de Test independiente (estrategia avanzada) ............................................ 20
3.4 Configuración del entorno de Testing ........................................................................ 21
3.5 Estrategias de prueba del equipo de desarrollo ......................................................... 23
4. DESARROLLO DIRIGIDO POR PRUEBAS (TEST-DRIVEN DEVELOPMENT-TDD) ....... 24
5. TEAM QA INDEPENDIENTE ............................................................................................ 26
5.1 Cuando se debe tener Equipo QA independiente ...................................................... 27
5.2 Testing fin de ciclo de vida del Producto.................................................................... 29
6. GESTIÓN DE DEFECTOS................................................................................................ 31
6.1 Seguimiento de Defectos e Informes ......................................................................... 36
CONCLUSIÓN .......................................................................................................................... 38
BIBLIOGRAFÍA ......................................................................................................................... 40

3
ÍNDICE DE CUADROS, GRÁFICOS Y FIGURAS

Figura 1. Ciclo de Vida de Pruebas. ............................................................................................... 7

Figura 2. Lugar de Test en el ciclo de vida del desarrollo de Software. ........................................ 8
Figura 3. Diferencias entre test tradicional y Ágil. ...................................................................... 11
Figura 4. Cuadrantes Ágil Testing. .............................................................................................. 12
Figura 5. Pruebas a lo largo del SDLC ......................................................................................... 17
Figura 6. Cómo ATDD y el desarrollador TDD encajan. ............................................................ 25
Figura 7. Paralelo Independiente Testing. .................................................................................... 26
Figura 8. Cuando las pruebas independientes tienen sentido. ...................................................... 28
Figura 9. Pruebas de fin de ciclo de vida...................................................................................... 29
Figura 10. Proceso ágil de gestión del cambio de defectos. ......................................................... 31
Figura 11. Pruebas / prácticas de validación en equipos ágiles. ................................................... 33
Figura 12. Cómo los equipos ágiles validan su propio trabajo. ................................................... 34
Figura 13. Enfoque primario de las pruebas de aceptación. ......................................................... 35
Figura 14. Enfoque primario para pruebas de desarrollador. ....................................................... 35

4
INTRODUCCIÓN

¿Qué aporta el personal con perfil QA en proyectos Ágiles? en una empresa de desarrollo de
software que utiliza metodología ágil, es una pregunta que se realiza toda persona que inicia en
este mundo de QA (Quality Assurance) para tratar de conseguir engranar en el agilismo y poder
en gran medida sentirse orgulloso por un producto que cumple con las expectativas de calidad.

La definición y especificación de roles que cumple un QA en un equipo ágil es muy importante a

la hora de cooperar en el desarrollo de un producto. Con esta monografía se tratará de subsanar
las dudas a que realmente está enfocado el trabajo de un QA en un equipo ágil dentro un entorno
real en una empresa, centrándonos en los roles.

Palabras clave: Rol, Calidad del software, Metodología Ágil.

5
1. GENERALIDADES

Ágil se ha convertido en una de esas palabras de moda que se repite con tanta frecuencia que
comienza a perder sentido. Cuando se trabaja en TI (Tecnologías de Información), probablemente
un gerente comenta que tiene un equipo ágil, o un programador que se describe a sí mismo como
un desarrollador ágil. Aunque se asume que significa que son flexibles, capaces de adaptarse a
nuevas situaciones y proyectos.

1.1 Antecedentes Generales

A lo largo de la historia, la metodología ágil ha sido un enfoque para la gestión de TI y proyectos

de desarrollo de software (aunque se extiende a otros campos, también). En 2001, al darse
cuenta de que sus proyectos de desarrollo estaban fallando, a menudo por razones similares
como el tiempo y costos excesivos también la velocidad y eficiencia, un pequeño equipo de TI
elaboró el manifiesto ágil.

Hay una serie de enfoques ágiles en uso por las organizaciones, prácticas comunes en la mayoría
de las organizaciones ágiles incluyen creación colaborativa de historias de usuarios,
retrospectivas, integración continua y planificación para cada iteración, así como para la versión
general.

Uno de los más utilizados es SCRUM fundamentada en una estrategia de desarrollo incremental,
el proyecto es fácilmente adaptable y tiene mayor flexibilidad ante nuevos requerimientos o
prioridades del mismo.

Por otro lado, conviene conocer también cuáles son los actores que intervienen durante el
proceso de desarrollo de un proyecto SCRUM. Estos son básicamente tres: el producto owner (o
PO), el equipo de desarrollo (conformado, evidentemente, por uno o más desarrolladores donde
se encuentra el personal QA) y el Scrum Master.

1.2 Antecedentes Específicos

La calidad forma parte del desarrollo del software. Consiste en asegurar que el producto
entregado cubre las necesidades del cliente, es decir, que el software hace lo que el cliente quiere
y de manera correcta. Debe aplicarse en todo el proceso de desarrollo, ya que cuanto más tarde
se encuentre un defecto, más caro será repararlo.

6
Para garantizar la calidad existen ciertas reglas básicas. Fundamentalmente, se trata de cumplir
con la pirámide de la calidad (Figura 1), realizando las pruebas correspondientes en cada uno de
los niveles: se cumplen con esas normas, se conseguira un producto que cumpla con las
expectativas y los requisitos del cliente.

Figura 1. Ciclo de Vida de Pruebas.

Fuente: Software Quality Assurance: Integrating Testing, Security and Audit, Pag.64

La tendencia actual establece que los procesos de calidad del software ya no son solo tarea del
equipo de testing, sino que involucran a todos los perfiles y están presentes desde las primeras
etapas del desarrollo (Figura 2).

7
 Figura 2. Lugar de Test en el ciclo de vida del desarrollo de Software.

Fuente: Software Quality Assurance: Integrating Testing, Security and Audit, Pag. 64

8
2. METODOLOGÍA

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

• Método Bibliográfico, debido a que se realizará la lectura y compilación de libros

relacionados al tema de estudio.
• Método Analítico, debido a que se procederá a revisar y analizar ordenadamente
documentos relacionados al tema de estudio, para la redacción del Plan de Emergencia.
2.1 QA en metodología Ágil

Para entender mejor que rol cumple el perfil QA en una metodología ágil se debe tener un
conocimiento claro que es testing ágil, sus principios y la diferencia con la metodología tradicional.

2.2 Ágil testing

“Un probador profesional que acepta el cambio, colabora bien con personas tanto técnicas como
comerciales, y entiende el concepto de usar pruebas para documentar los requisitos e impulsar
el desarrollo” (Lisa Crispin, 2015, págs. 19-20).

Agile Testing es una práctica de pruebas de software que sigue los principios del desarrollo ágil
de software que involucra a todos los miembros de un equipo ágil multifuncional, en el cual el rol
del tester es el de un experto multifuncional, garante que entregue el valor de negocio deseado
por el cliente a un ritmo sostenible y continuo.

Las metodologías ágiles no ven al software testing como una fase separada, sino como parte
integral del Desarrollo de software al igual que la programación.

Agile Testing, incorpora una serie de prácticas, como por ejemplo: Testing de “todo el equipo”,
Testing independiente, Integración continua, Testing guiado por pruebas (Test Driven
Development – TDD), Desarrollo guiado por comportamiento (Behaviour Driven Development –
BDD), Desarrollo guiado por pruebas de aceptación (Acceptance Test Driven Development –
ATDD), entre otros.

Los equipos ágiles utilizan un enfoque de “todo el equipo” al testing, con la finalidad de integrar
la calidad al desarrollo del producto, al contrario de un enfoque de primero fabricar el producto y
luego inspeccionar para determinar su nivel de calidad.

9
2.3 Principios del Agile Testing

De forma similar 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

carga, 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: En Agile Testing, las pruebas se hacen “durante” el desarrollo y no
después del desarrollo como en métodos convencionales.

2.4 La pirámide del Testing

Originalmente propuesta por Mike Cohn, la pirámide del testing sirve para explicar las diferencias
del Software Testing trabajando con metodologías convencionales y trabajando con metodologías
ágiles o de forma iterativa.

10
Figura 3 en la forma tradicional (pirámide de la izquierda), la gran mayoría de las pruebas son
manuales y funcionales, pudiendo existir algún pequeño grado de automatización y de pruebas
unitarias por desarrolladores.

La pirámide de la derecha representa como se ejecuta el Software Testing en Agile, donde la

gran mayoría de las pruebas son unitarias automatizadas, de aceptación automatizadas y de
interfaz gráfica automatizadas, buscando reducir al mínimo las pruebas funcionales manuales.

Figura 3. Diferencias entre test tradicional y Ágil.

Fuente: Agile Couch Journal

2.5 Los cuadrantes del Agile Testing

Una taxonomía útil para poner el Agile Testing en contexto y guiar a los equipos y gerencia sobre
cómo integrar el Testing en sus prácticas de desarrollo iterativos son los cuadrantes del Testing
Agile, originados por Brian Marick en un post sobre el tema y luego adaptados por Lista Crispin y
Janet Gregory en su obra “Agile Testing”.

Los cuadrantes representan los diferentes propósitos y tipos de pruebas de software que se
puede realizar en un entorno Agile. Figura 4.

11
 Figura 4. Cuadrantes Ágil Testing.

Figura: Lisa Crispin, Agile Testing, 2015, pág. 97

La matriz tiene dos ejes o dimensiones, en el eje horizontal se divide en las pruebas en Apoyo al
equipo (Supporting the Team) y pruebas de crítica al producto (Critique the Product), mientras
que en el eje vertical se divide en las pruebas de cara a tecnología (Technology Facing) y de cara
al negocio (Business Facing).

2.5.1 Pruebas de apoyo al equipo (Supporting the Team)

Destinadas a apoyar al equipo de desarrollo en la medida en que este desarrolla el producto. Este
concepto es nuevo para muchos testers dado que el Testing tradicional es para encontrar fallas.

Se realizan en los cuadrantes 1 y 2 del Agile Testing.

Cuando se referencia a que son pruebas de apoyo al equipo, es porque las pruebas de cuadrante
1 y 2 se convierten prácticamente en la base de un equipo de desarrollo ágil.

Estas pruebas primeramente guían el desarrollo de la funcionalidad, y luego cuando se

automatizan sirven para apoyar la refactorización y la inclusión de nuevo código sin causar
resultados inesperados en el comportamiento del sistema.

12
Cuadrante 1: Pruebas de apoyo al equipo de cara a tecnología

Este cuadrante se encuentra en la parte inferior izquierda (Figura 4.) y representa el desarrollo
guiado por pruebas (Test Driven Development – TDD) que es la base fundamental del Agile
Testing.

El cuadrante 1 incluye los siguientes tipos de pruebas:

• Pruebas unitarias: Verifican la funcionalidad de un pequeño subconjunto del sistema

como por ejemplo un objeto o método.
• Pruebas de componente: Verifican el comportamiento de un grupo más grande del
sistema, por ejemplo, un grupo de clases que proveen cierto servicio.

También se les suelen ser llamados pruebas de programador, pruebas de cara a desarrollador o
pruebas de cara a tecnología. Suelen automatizarse usando alguna herramienta de la familia de
xUnit, en el mismo lenguaje de programación usado para fabricar la aplicación.

Estas son pruebas de calidad interna. La calidad interna no es definida por el cliente (son de
naturaleza técnica) sino por los programadores para lograr cumplir los requerimientos funcionales
y no funcionales solicitados.

Las pruebas unitarias y de componentes pasarán a formar parte del proceso de Check-in
ejecutado cada vez que se incluyen cambios en el código, otorgando así feedback inmediato.

Cuadrante 2: Pruebas de apoyo al equipo de cara al negocio

Este cuadrante se encuentra en la parte superior derecha (Figura 4.) y las pruebas de este
cuadrante, también sirven de apoyo al equipo de desarrollo de software, pero a un mayor nivel
de visión.

Las pruebas de cara a negocio también se pueden llamar pruebas de cara a cliente o simplemente
pruebas de cliente. Estas definen la calidad externa y las funcionalidades que el cliente solicita.

Las pruebas de cuadrante 2 (Funcionales, ejemplos, pruebas de historias, etc.)

• Se derivan de ejemplos que suministra el equipo del cliente.

• Describen los detalles de cada historia de usuario.
• Se ejecutan a un nivel funcional y verifican condiciones de satisfacción definidas por el
negocio.

13
 • Se escriben usando un lenguaje que los expertos en el negocio (no necesariamente
informáticos de profesión) puedan entender. De hecho, los expertos del negocio usan
estas pruebas en las definiciones de calidad externa y participan en su elaboración.
• Pueden duplicar pruebas ya realizadas en el cuadrante 1, pero a un nivel superior (nivel
funcional).
• Están orientadas a ilustrar y confirmar el comportamiento deseado del sistema.

Automatización de pruebas del cuadrante 2

Las pruebas del cuadrante 2 también pueden ser automatizadas.

• La automatización permite identificar y solucionar errores rápidamente.

• Deben ejecutarse con frecuencia para dar alerta temprana al equipo.
• Si es posible, es recomendable ejecutarlas directamente en la capa de lógica de negocio.
• Aún así algunas de estas pruebas deben ser ejecutadas desde la perspectiva del cliente,
es decir desde la interfaz de usuario.

La automatización de este último punto se puede realizar con herramientas como Selenium
WebDriver, que permite invocar pantallas de aplicaciones web como si lo estuviera realizando un
usuario.

Herramientas como Selenium permiten automatizar pruebas con una variedad de lenguajes de
programación para el Scripting, como por ejemplo Ruby, Python, Java y más.

Pruebas de prototipos de interfaces con el usuario

Las pruebas destinadas a validar la interfaz de usuario propuestas (prototipos) también

pertenecen a este cuadrante.

En estas pruebas, los encargados de diseñar la interfaz con el usuario elaboran pantallas de
ejemplos o wireframes, los cuales son válidos con el cliente (usuario) antes que inicie el
desarrollo.

Una vez iniciado el desarrollo, estos expertos son los encargados de explicar los desarrolladores
de software los diseños y resolver dudas que puedan presentarse.

14
2.5.2 Pruebas de críticas al producto (Critique the Product)

Cuando se hace referencia a “críticas al software”, no son necesariamente en un sentido negativo,

pues estás pueden ser inclusive para resaltar aspectos positivos o inclusive sugerir mejoras.

Para un cliente es muy difícil saber de antemano lo que quiere hasta verlo plasmado en un
producto de características mínimas, esta es una realidad con la que toda metodología de
desarrollo de software debe lidiar.

Cuadrante 3: Pruebas que critican el producto de cara al negocio

Este cuadrante se encuentra en la parte superior derecha (Figura 4.) y en la fase de análisis, los
analistas de sistemas y expertos de negocio se encargan de obtener ejemplos y especificar los
casos.

Este proceso no está libre de errores pues estos expertos podrían omitir casos o representarlos
erróneamente cuando por ejemplo están fuera de su área de conocimientos.

Inclusive, cuando el código esté desarrollado de acuerdo al ejemplo y pase la prueba, aún existe
la posibilidad que esto no sea lo que el cliente realmente quiere.

Aquí entran en juego las pruebas del cuadrante 3, en las cuales se ejecuta la aplicación en su
conjunto (es una prueba integral) para determinar si cumple o no las expectativas.

Cuando se realizan estas pruebas, se trata de emular lo más posible el entorno real en que serán
ejecutadas.

Por lo tanto, son pruebas funcionales manuales y sólo las pueden ejecutar personas (no
máquinas).

Se puede recurrir a un grado de automatización por ejemplo para preparar los datos de prueba,
sin embargo, al ejecutarla debe utilizarse la intuición para saber si el producto cumple las
expectativas y proporciona valor al área de negocio.

Usualmente estas pruebas son ejecutadas por el equipo del cliente (los usuarios finales), en la
forma de pruebas de aceptación (UAT).

Las pruebas de usabilidad forman parte de este cuadrante y representan en sí mismas todo un
campo de estudio. Pueden involucrar hasta inclusive los Focus Groups para identificar las formas
en que realmente los usuarios utilizarán el nuevo sistema.

15
En este cuadrante, el Testing exploratorio es un aspecto central. En el testing exploratorio, el
tester diseña y ejecuta la prueba al mismo tiempo. Ambos procesos se retroalimentan, es decir,
de la ejecución de la prueba y análisis crítico de los resultados, se aprende más sobre el negocio
y la aplicación se rediseña la prueba y se repite el proceso.

Cuadrante 4: Pruebas que critican el producto

Este cuadrante se encuentra en la parte inferior derecha (Figura 4.) y las pruebas del cuadrante
4 son enteramente de naturaleza técnica (no funcional) y son tan críticas para el Agile Testing
como cualquier metodología de desarrollo de sistemas.

La intención es analizar y someter a pruebas de extremo a características no funcionales como

el desempeño, robustez y seguridad.

Muchas de las herramientas para hacer estas pruebas ya estarán desarrolladas en el cuadrante
1, por ejemplo, reusando las pruebas unitarias para hacer múltiples ejecuciones multi-hilo, sin
embargo, esto no quiere decir que no se requiera de otra herramientas adicionales o personal
especializado.

2.5.3 Uso de los 4 cuadrantes

• Los 4 cuadrantes son una taxonomía para ayudar en la planificación del Agile Testing.
• La idea de usarlos es asegurar que se tomen en cuenta todos los recursos y métodos
necesarios para lograr la producción de software de calidad.
• Los 4 cuadrantes no son reglas rígidas ni en su contenido ni orden. Cada equipo de
desarrollo de software debe adaptarlos a su situación particular con amplia libertad.
• Los 4 cuadrantes no deben ejecutarse en orden del 1 al 4, pues eso sería aplicar una
metodología predictiva (en cascada) y no Agile.
• La numeración de los cuadrantes es arbitraria y eso se debe por ejemplo; un interlocutor
pueda referirse al “cuadrante 1” en lugar de “pruebas de tecnología de cara a cliente”.

16
3. ESTRATEGIAS ÁGIL TESTING

Para comprender cómo encajan las actividades de prueba en el desarrollo ágil del sistema, es
útil observarlo desde el punto de vista del ciclo de vida de entrega del sistema (System Delivery
Life Cycle-SDLC). La Figura 4 es una vista de alto nivel del SDLC ágil, que indica las actividades
de prueba en varias fases del SDLC. Esta sección está organizada en los siguientes temas:

Figura 5. Pruebas a lo largo del SDLC

Fuente: Scott Ambler

3.1 Iniciación de Proyecto

Durante la iniciación, a menudo llamado "Sprint 0" en Scrum o "Iteración 0" en otros métodos
ágiles, tu objetivo es hacer que un equipo vaya en la dirección correcta. Aunque a la comunidad
ágil dominante no le gusta hablar de esto, la realidad es que esta fase puede durar de varias
horas a varias semanas, dependiendo de la naturaleza del proyecto y la cultura de su
organización. Desde el punto de vista de las pruebas, las tareas principales son organizar cómo
aproximarse a las pruebas y comenzar a configurar su entorno de prueba si aún no existe.
Durante esta fase de un proyecto, realizará la previsión inicial de los requisitos (como se describió
anteriormente) y la visualización de la arquitectura. Como resultado de ese esfuerzo, debe

17
obtener una mejor comprensión del alcance, ya sea que el proyecto cumpla con regulaciones y
potencialmente algunos criterios de aceptación de alto nivel para su sistema.

Todo esto es información importante que ayudará a decidir la cantidad de pruebas que tendrá
que realizarse. Es importante recordar que un tamaño de proceso no se ajusta a todos, y que los
diferentes equipos de proyecto tendrán diferentes enfoques para las pruebas porque se
encuentran en diferentes situaciones cuanto más compleja es la situación, más complejo es el
enfoque de las pruebas (entre otras cosas). Los equipos que se encuentran en situaciones
simples pueden encontrar que un enfoque de "todo el equipo" para las pruebas será suficiente,
mientras que los equipos en situaciones más complejas también encontrarán que necesitan un
equipo de pruebas independiente trabajando en paralelo con el equipo de desarrollo. De todos
modos, siempre habrá un poco de esfuerzo en configurar su entorno de prueba.

3.2 La estrategia organizacional del "equipo completo"

Una estrategia organizacional común en la comunidad ágil, popularizada por Kent Beck en
Extreme Programming Explained 2nd Ed, es que el equipo incluya a las personas adecuadas
para que tengan las habilidades y las perspectivas requeridas para que el equipo tenga éxito.
Para entregar con éxito un sistema que funcione de manera regular, el equipo deberá incluir
personas con habilidades de análisis, diseño, programación, liderazgo y, sí, incluso personas con
habilidades de evaluación. Obviamente, esta no es una lista completa de las habilidades
requeridas por el equipo, ni implica que todos en el equipo tengan todas estas habilidades.
Además, todos los integrantes de un equipo ágil contribuyen de la manera que pueden,
aumentando así la productividad general del equipo. Esta estrategia se llama "equipo completo".

Con un enfoque de equipo completo, los evaluadores están "integrados" en el equipo de

desarrollo y participan activamente en todos los aspectos del proyecto. Los equipos ágiles se
están alejando del enfoque tradicional en el que alguien tiene una sola especialidad en la que se
centran - por ejemplo, Sally solo hace programación, Sanjiv solo hace arquitectura, y John solo
hace pruebas - a un enfoque donde las personas se esfuerzan por convertirse en especialistas
generalizadores con una gama más amplia de habilidades. Entonces, Sally, Sanjiv y John estarán
dispuestos a participar en actividades de programación, arquitectura y pruebas, y lo más
importante, estarán dispuestos a trabajar juntos y aprender unos de otros para mejorar con el
tiempo. Los puntos fuertes de Sally aún pueden estar en la programación, Sanjiv en arquitectura
y John en pruebas, pero eso no será lo único que harán en el equipo ágil. Si Sally, Sanjiv y John

18
son nuevos en agile y actualmente solo son especialistas, al adoptar prácticas de desarrollo que
no son solo y trabajar en cortos ciclos de retroalimentación, rápidamente recogerán nuevas
habilidades de sus compañeros (y transferirán sus habilidades existentes a sus compañeros de
equipo también).

Este enfoque puede ser significativamente diferente de lo que los equipos tradicionales están
acostumbrados. En los equipos tradicionales, es común que los programadores (especialistas)
escriban código y luego lo "tiren a la pared" a los probadores (también especialistas) que luego
lo prueban e informan a los programadores de un posible error. Aunque es mejor que ninguna
prueba en absoluto, esto a menudo resulta ser una estrategia costosa y lenta debido a las
transferencias entre los dos grupos de especialistas. En los equipos ágiles, los programadores y
los evaluadores trabajan lado a lado, y con el tiempo la distinción entre estos dos roles se difumina
en el rol único del desarrollador. Una filosofía interesante en la comunidad ágil es que los
verdaderos profesionales de TI deben validar su propio trabajo lo mejor que puedan, y esforzarse
para mejorar a lo largo del tiempo.

La estrategia de todo el equipo no es perfecta, y hay varios problemas potenciales:

• Pensar en grupo: Los equipos completos, al igual que cualquier otro tipo de equipo,
pueden sufrir lo que se conoce como grupo de pensar. El problema básico es que debido
a que los miembros del equipo están trabajando en estrecha colaboración, algo que los
equipos ágiles se esfuerzan por hacer, comienzan a pensar igual y, como resultado, se
vuelven ciegos a algunos problemas que enfrentan. Por ejemplo, el sistema en el que está
trabajando un equipo podría tener algunos problemas de usabilidad significativos, pero
nadie en el equipo los conoce, porque todos creen que la estrategia de interfaz de usuario
existente es un enfoque efectivo y cree que todos los demás también lo creen.

• El equipo puede no tener las habilidades que necesita. Es bastante fácil declarar que
estás siguiendo la estrategia de todo el equipo, pero no tan fácil de hacerlo en ocasiones.
Algunas personas pueden sobreestimar sus habilidades o subestimar las habilidades que
realmente se necesitan y, por lo tanto, poner en riesgo al equipo. Por ejemplo, una
debilidad común entre los programadores es el diseño de bases de datos debido a la falta
de capacitación en tales habilidades, a la especialización dentro de organizaciones donde
los "profesionales de datos" se enfocan en habilidades de datos y los programadores no,
y un desajuste de impedancia cultural entre desarrolladores y profesionales de datos que

19
 hace que sea difícil aprender habilidades de datos. Peor aún, las estrategias de
encapsulación de bases de datos tales como los marcos de mapeo relacional de objetos
motivan a estos programadores "desafiados por los datos" a creer que no necesitan saber
nada sobre el diseño de bases de datos porque han encapsulado el acceso a él. Por lo
tanto, los miembros del equipo individual creen que tienen las habilidades para realizar el
trabajo, pero de hecho no lo hacen, y en este caso el sistema sufrirá porque el equipo no
tiene las habilidades para diseñar y usar la base de datos de manera apropiada. O, en el
caso del problema de usabilidad mencionado en el punto anterior, el problema de
usabilidad puede existir porque nadie en el equipo tiene habilidades de usabilidad
suficientes para empezar.

• El equipo puede que ni siquiera sepa qué habilidades se necesitan. Peor aún, el
equipo puede ser ajeno a las habilidades que realmente se necesitan. Por ejemplo, el
sistema podría tener algunos requisitos de seguridad muy importantes, pero si el equipo
no sabía que era probable que la seguridad fuera una preocupación, entonces podrían
pasar por alto esos requisitos por completo, o malinterpretarlos, e inadvertidamente
colocar el proyecto en riesgo.

Afortunadamente, los beneficios del enfoque de todo el equipo tienden a superar con creces los
posibles problemas. En primer lugar, todo el equipo parece aumentar la productividad general al
reducir y, a menudo, reducir o incluso eliminar el tiempo de espera entre actividades. En segundo
lugar, hay menos necesidad de papeleo, como planes de prueba detallados debido a la falta de
transferencias entre equipos separados. En tercer lugar, los programadores comienzan
rápidamente a aprender las habilidades de prueba y calidad de los evaluadores y, como resultado,
hacen un mejor trabajo para comenzar. Cuando el desarrollador sabe que estarán activamente
involucrados en el esfuerzo de prueba, están más motivados para escribir textos de alta calidad,
código comprobable para comenzar.

3.3 El equipo de Test independiente (estrategia avanzada)

El enfoque de todo el equipo funciona bien en la práctica cuando los equipos de desarrollo ágiles
se encuentran en situaciones razonablemente sencillas. Sin embargo, los equipos que trabajan
a gran escala en entornos complejos, encontrarán que un enfoque de equipo completo para las
pruebas es insuficiente. En tales situaciones, este equipo de prueba realizará pruebas paralelas
e independientes durante todo el proyecto y, por lo general, será responsable de las pruebas de

20
final de ciclo de vida realizadas durante la fase de lanzamiento / transición del proyecto. El objetivo
de estos esfuerzos es averiguar dónde se rompe el sistema (las pruebas integrales del equipo a
menudo se centran en las pruebas de confirmación que muestran que el sistema funciona) e
informar dichas roturas al equipo de desarrollo para que puedan solucionarlas. Este equipo de
pruebas independiente se enfocará en formas más complejas de prueba que generalmente están
más allá de la capacidad del "equipo completo" para realizar sus propias tareas, más sobre esto
más adelante.

El equipo de prueba independiente apoyará a múltiples equipos de proyecto. La mayoría de las

organizaciones tienen muchos equipos de desarrollo trabajando en paralelo, a menudo docenas
de equipos y, a veces, incluso cientos, por lo que puede lograr economías de escala si un equipo
de pruebas independiente apoya a muchos equipos de desarrollo. Esto permite minimizar el
número de licencias de herramientas de prueba que necesita, compartir entornos de hardware
caros y habilitar especialistas en pruebas (tales como personas con experiencia en pruebas de
usabilidad o pruebas de investigación) para respaldar a muchos equipos.

Es importante tener en cuenta que un equipo de prueba independiente ágil trabaja de forma
significativamente diferente que un equipo de prueba independiente tradicional. El ágil equipo de
prueba independiente se enfoca en una pequeña minoría del esfuerzo de prueba, la parte más
difícil, mientras que el equipo de desarrollo hace la mayor parte del trabajo de prueba. Con un
enfoque tradicional, el equipo de prueba a menudo haría tanto el trabajo pesado como las
complejas formas de prueba. Para poner esto en perspectiva, la proporción de personas en
equipos de desarrolladores ágiles (incluyendo cualquier persona involucrada en pruebas de
equipo completo) para personas en el equipo de pruebas ágiles e independientes a menudo será
15: 1 o 20: 1, mientras que en el mundo tradicional estas relaciones son a menudo más cerca de
3: 1 o 1: 1 (y en entornos reguladores puede ser 1: 2 o más) (Cem Kaner, 2002, pág. 76).

3.4 Configuración del entorno de Testing

Al inicio de un proyecto, se necesitará comenzar a configurar un entorno, incluida la configuración

del área de trabajo, el hardware y herramientas de desarrollo (por nombrar algunos elementos).
Naturalmente, se necesitará configurar un entorno de prueba, desde cero, si actualmente no tiene
ese entorno disponible o si no está adaptando un entorno existente para satisfacer sus
necesidades. Hay varias estrategias que normalmente se sugiere cuando se trata de organizar
un entorno de prueba:

21
• Adoptar herramientas de software de código abierto (OSS) para desarrolladores. Hay
muchas herramientas de prueba de OSS disponibles, como el marco de prueba xUnit, que
están dirigidas a los desarrolladores. Estas herramientas a menudo son fáciles de instalar
y aprender a usar (aunque aprender a probar de manera efectiva demuestra ser otra
cuestión).

• Adopte tanto OSS como herramientas comerciales para probadores independientes.

Debido a que el equipo de pruebas independiente a menudo abordará problemas de
pruebas más complejos, como las pruebas de integración en múltiples sistemas (no solo
el sistema único en el que se enfoca el equipo de desarrollo), pruebas de seguridad,
pruebas de usabilidad, etc., se necesitarán herramientas de prueba que son lo
suficientemente sofisticados para abordar estos problemas.

• Tener un sistema de seguimiento de fallas / defectos compartido. Como se mencionó en

la sección anterior, el equipo de prueba independiente enviará informes de defectos al
equipo de desarrollo, quien a su vez considerará que estos informes de defectos son solo
otro tipo de requisito. La implicación es que necesitan tener soporte de herramientas para
hacer esto. Cuando el equipo es pequeño y compartido, esto podría ser tan simple como
una pila de fichas. En situaciones más complejas, necesitará una herramienta basada en
software, idealmente una que se utilice para administrar tanto los requisitos del equipo
como los defectos del equipo (o más importante, toda su lista de elementos de trabajo).

• Invierta en pruebas de hardware. Tanto el equipo de desarrollo como el equipo

independiente probablemente necesitarán hardware para realizar las pruebas.

• Invertir en herramientas de virtualización y administración de laboratorio de prueba. El

hardware de prueba es costoso y nunca es suficiente. El software de virtualización que le
permite cargar fácilmente un entorno de prueba en su hardware, así como herramientas
de administración de laboratorio de prueba que permiten rastrear configuraciones de
hardware, son fundamentales para el éxito de su equipo de pruebas independiente
(especialmente si son compatibles con múltiples desarrollos).

• Invertir en herramientas de integración continua (CI) y despliegue continuo (CD). No

explícitamente una categoría de herramienta de prueba, pero las herramientas CI / CD
son críticas para los equipos de desarrollo ágiles debido a prácticas como el desarrollo

22
 basado en pruebas (TDD), pruebas de regresión del desarrollador en general y la
necesidad de implementar construcciones operativas en entornos de prueba
independientes. entornos de demostración, o incluso producción. Hay una gran cantidad
de herramientas de código abierto disponibles.

3.5 Estrategias de prueba del equipo de desarrollo

Los equipos de desarrollo ágiles generalmente siguen una estrategia de equipo completa en la
que las personas con habilidades de prueba se integran efectivamente en el equipo de desarrollo
y el equipo es responsable de la mayoría de las pruebas. Esta estrategia funciona bien para la
mayoría de las situaciones, pero cuando su entorno es más complejo, encontrará que también
necesita un equipo de pruebas independiente que trabaje en paralelo con el desarrollo y
posiblemente también realice pruebas de final de ciclo de vida. Independientemente de la
situación, los equipos de desarrollo ágiles adoptarán prácticas tales como la integración continua,
lo que permite realizar pruebas de regresión continua, ya sea con un desarrollo impulsado por
prueba (TDD), inmediatamente después de la aproximación.

23
4. DESARROLLO DIRIGIDO POR PRUEBAS (TEST-DRIVEN DEVELOPMENT-TDD)

Es una práctica de técnica de desarrollo ágil que combina Refactorización de código y la Primera
prueba de desarrollo.

Existe dos niveles de TDD:

• Aceptación TDD (ATDD). Puede realizar TDD a nivel de requisitos escribiendo una única
prueba de cliente, el equivalente a una prueba de función o una prueba de aceptación en
el mundo tradicional. Aceptación TDD es llamado desarrollo guiado por comportamiento
(Behavior Driven Development-BDD) o desarrollo guiado por prueba de historia, donde
primero automatiza una prueba de historia fallida, luego maneja el diseño a través de TDD
hasta que la prueba de historia pasa (una prueba de historia es una prueba de aceptación
del cliente).

• Desarrollador TDD. También puede hacer TDD a nivel de diseño con pruebas de
desarrollador.

• Con un enfoque de desarrollo basado en pruebas (TDD), sus pruebas se convierten

efectivamente en especificaciones detalladas que se crean sobre una base de tiempo
justo (just in time-JIT). La mayoría de los programadores no leen la documentación escrita
de un sistema, en lugar de eso prefieren trabajar con el código. Y no hay nada de malo
en esto. Al tratar de entender una clase u operación, la mayoría de los programadores
buscarán primero un código de muestra que ya lo invoqué. Las pruebas de unidad /
desarrolladores bien escritas hacen exactamente esto: proporcionan una especificación
de trabajo de un código funcional y, como resultado, las pruebas unitarias se convierten
en una parte importante de la documentación técnica. De manera similar, las pruebas de
aceptación pueden formar una parte importante de la documentación de los requisitos.
Esto tiene mucho sentido cuando uno piensa en ello. Las pruebas de aceptación definen
exactamente lo que las partes interesadas esperan de un sistema, por lo tanto, especifican
requisitos críticos. La implicación es que la aceptación TDD es una técnica de
especificación de requisitos detallados JIT y el desarrollador TDD es una técnica de
especificación de diseño detallado JIT. Escribir especificaciones ejecutables es una de las
mejores prácticas de modelado ágil como se muestra en la figura 6.

24
Figura 6. Cómo ATDD y el desarrollador TDD encajan.

Fuente: Scoott W. Ambler.

25
5. TEAM QA INDEPENDIENTE

El enfoque del equipo de desarrollo completo donde los equipos ágiles prueban lo mejor de la
habilidad es un gran comienzo, pero no es suficiente en algunas situaciones. En estas
situaciones, que se describen a continuación, la creación de un equipo de prueba independiente
paralelo que realice algunas de las formas de prueba más difíciles (o tal vez más avanzadas).
Como puede ver en la Figura 7, la idea básica es que, de manera regular, el equipo de desarrollo
pone a disposición su equipo de prueba independiente, o tal vez lo implementen automáticamente
a través de herramientas de implementación continua, para que puedan probarlo. El objetivo de
este esfuerzo de prueba no es rehacer las pruebas de confirmación que ya está realizando el
equipo de desarrollo, sino identificar los defectos que han caído en las grietas. La implicación es
que este equipo de prueba independiente no necesita una especulación detallada de los
requisitos, aunque es posible que necesiten diagramas de arquitectura, una descripción general
del alcance y una lista de cambios desde la última vez que el equipo de desarrollo envió una
compilación. En lugar de realizar pruebas contra la especificación, el esfuerzo de prueba
independiente puede centrarse en:

Figura 7. Paralelo Independiente Testing.

Fuente: Disciplined Agile Consortium

26
El equipo de desarrollo sigue realizando la mayoría de las pruebas cuando existe un equipo de
pruebas independiente. Es solo que el equipo de prueba independiente está realizando formas
de prueba para que el desarrollo no tenga (aún) las habilidades para realizar o sea demasiado
caro para ellos.

El equipo de prueba independiente reporta los defectos al desarrollo, como se puede ver en la
Figura 7. El equipo de desarrollo trata estos defectos como un tipo de requisito en el sentido de
que son priorizados, estimados y colocados en la pila de elementos de trabajo.

5.1 Cuando se debe tener Equipo QA independiente

• Figura 8 describe los factores de escala del marco de contexto de desarrollo de software
(SDCF) e indica cuándo es probable que se requieran pruebas independientes. Hay varias
buenas razones por las que se debería considerar pruebas independientes paralelas:

• Cumplimiento normativo. Es posible que los equipos ágiles disciplinados que se

encuentran en situaciones de estricto cumplimiento normativo, típicas en ingeniería de
sistemas y entornos vitales, deban realizar pruebas independientes por ley.

• Outsourcing. Los equipos que están distribuidos organizativamente, por ejemplo, cuando
parte del trabajo se está subcontratando a otra organización, es muy probable que deseen
realizar pruebas independientes para validar el trabajo que realiza la otra empresa.

• Dominios complejos. Cuando tiene un dominio muy complejo, quizás esté trabajando en
software crítico para la vida o en el procesamiento de derivados financieros, los enfoques
de prueba de todo el equipo pueden resultar insuficientes. Tener un esfuerzo de prueba
independiente paralelo puede reducir estos riesgos.

• Entornos técnicos complejos. Cuando trabaja con múltiples tecnologías, sistemas

heredados o fuentes de datos heredados, la prueba de su sistema puede ser muy difícil.

• Equipos grandes o geográficamente distribuidos. Los equipos grandes o distribuidos a

menudo se subdividen en equipos más pequeños, y cuando esto sucede, las pruebas de
integración del sistema en general pueden llegar a ser lo suficientemente complejas como
para que un equipo separado considere la posibilidad de asumirlas. Por supuesto, la razón
por la que se tienen estos equipos es porque se enfrentan a un dominio significativo o a
una complejidad técnica.

27
 Figura 8. Cuando las pruebas independientes tienen sentido.

Fuente: Disciplined Agile Consortium

Es posible que muchos equipos de desarrollo no tengan los recursos necesarios para realizar
pruebas efectivas de integración del sistema, recursos que, desde un punto de vista económico,
deben compartirse entre varios equipos. La implicación es que necesitara un equipo de prueba
independiente que trabaje en paralelo con el (los) equipo (s) de desarrollo que aborda este tipo
de problemas. Las pruebas de integración del sistema a menudo requieren un entorno costoso
que va más allá de lo que tendrá un equipo de proyecto individual.

Una mala excusa para adoptar pruebas independientes es que su personal de pruebas / calidad
existente aún piensa, y con frecuencia prefiere trabajar, de una manera tradicional. La solución
real es superar estos desafíos culturales y ayudar a adquirir las habilidades y la mentalidad
necesarias para trabajar de manera ágil.

Algunos agilistas dirán que no necesita pruebas independientes paralelas, y en situaciones

simples esto es claramente cierto. La buena noticia es que es increíblemente fácil determinar si
su esfuerzo de prueba independiente proporciona valor o no: simplemente compare el impacto

28
probable de los defectos / historias de cambio que se informan con el costo de realizar la prueba
independiente. En resumen, todo el equipo de pruebas funciona bien para agile en lo pequeño,
pero para sistemas más complejos y ágiles a escala, debe ser más sofisticado.

5.2 Testing fin de ciclo de vida del Producto

Una parte importante del esfuerzo de lanzamiento para muchos equipos ágiles es la prueba del
final del ciclo de vida, donde un equipo de prueba independiente valida que el sistema está listo
para entrar en producción. Si se ha adoptado la práctica de pruebas paralelas independientes,
las pruebas de final del ciclo de vida pueden ser muy cortas, ya que los problemas ya se han
cubierto sustancialmente. Como se ve en la Figura 9, los esfuerzos de prueba independientes se
extienden a la fase de transición en la Entrega ágil disciplinada porque el equipo de prueba
independiente todavía tendrá que probar el sistema completo una vez que esté disponible.

Figura 9. Pruebas de fin de ciclo de vida.

Fuente: Scoott W. Ambler

Hay varias razones por las que aún necesita realizar pruebas de final de ciclo de vida:

29
 • Es profesional hacerlo. Como mínimo, es necesario una última ejecución de todas las
pruebas de regresión para declarar oficialmente que el sistema está completamente
probado. Esto ocurrirá claramente una vez que la iteración N, la última iteración de
construcción, finalice (o sea lo último que se realice en la iteración N).
• Usted puede estar legalmente obligado a hacerlo. Esto se debe al contrato que tiene con
el cliente comercial o al cumplimiento normativo (muchos equipos ágiles se encuentran
en tales situaciones, como lo descubrió la encuesta del estado de la Unión de TI de
noviembre de 2009).
• Sus partes interesadas lo requieren. Es probable que sus partes interesadas,
especialmente su departamento de operaciones, requieran algún tipo de esfuerzo de
prueba antes de lanzar la solución a producción para sentir satisfacción con la calidad del
trabajo.

No hay suficiente información que se discuta públicamente en la comunidad ágil de la corriente

principal acerca de las pruebas del final del ciclo de vida, la suposición de que muchas personas
siguen los métodos ágiles de la corriente principal, como Scrum, es que las técnicas como la TDD
son suficientes. Esto podría deberse a que gran parte de la literatura general de Agile se centra
en equipos de desarrollo ágil pequeños y de ubicación conjunta para trabajar en sistemas
bastante sencillos. Pero, cuando uno o más factores de escala (como el gran tamaño del equipo,
los equipos distribuidos geográficamente, el cumplimiento normativo o los dominios complejos)
son aplicables, entonces necesita estrategias de pruebas más sofisticadas. Independientemente
de la retórica que haya escuchado en público, como se muestra en la siguiente sección, un buen
número de profesionales de TDD están indicando lo contrario en privado.

30
6. GESTIÓN DE DEFECTOS

La gestión de defectos es a menudo mucho más simple en proyectos ágiles en comparación con
proyectos clásicos / tradicionales por dos razones. Primero, con un enfoque de todo el equipo
para probar cuando se encuentra un defecto, generalmente se corrige en el lugar, a menudo por
la (s) persona (s) que lo construyeron en primer lugar. En este caso, todo el proceso de gestión
de defectos es a lo sumo una conversación entre unas pocas personas. En segundo lugar,
cuando un equipo de prueba independiente trabaja en paralelo con el equipo de desarrollo para
validar su trabajo, generalmente utilizan una herramienta de informe de defectos para informar al
equipo de desarrollo lo que se encontró. Los equipos de entrega ágil y disciplinados combinan
sus estrategias de gestión de requisitos y gestión de defectos para simplificar su proceso general
de gestión de cambios. La Figura 10 muestra cómo se trabajan los elementos de trabajo en orden
de prioridad. Tanto los requisitos como los informes de defectos son tipos de elementos de trabajo
y se tratan de forma equitativa: se estiman, priorizan y se colocan en la pila de elementos de
trabajo.

Figura 10. Proceso ágil de gestión del cambio de defectos.

Fuente: Scott W. Ambler

Esto funciona porque los defectos son solo otro tipo de requisito. El defecto X se puede volver a
redactar en el requisito "corrija X". Los requisitos también son un tipo de defecto, de hecho, un

31
requisito es simplemente la funcionalidad faltante. De hecho, algunos equipos ágiles incluso
capturarán los requisitos utilizando una herramienta de gestión de defectos.

El principal impedimento para adoptar esta estrategia, el de tratar los requisitos y los defectos
como lo mismo, ocurre cuando el equipo de entrega ágil se encuentra en una situación de precio
fijo o de estimación fija. En tales situaciones, el cliente normalmente debe pagar por los nuevos
requisitos que no se acordaron al inicio del proyecto pero que no deberían pagar por la reparación
de defectos. En tales situaciones, el enfoque burocrático sería tener dos procesos de
administración de cambios separados y el enfoque pragmático sería simplemente marcar el
elemento de trabajo como algo que debe pagarse extra por (o no). Naturalmente, se está a favor
del enfoque pragmático. Si se encuentra en una situación de precio fijo, puede interesar que haya
escrito bastante sobre esto y, lo que es más importante, alternativas para financiar proyectos
ágiles. Se considera que las estrategias de precio fijo no son éticas o simplemente un signo de
incompetencia grotesca por parte de la organización que insiste en ello. La fusión de sus
requisitos y los procesos de gestión de defectos en un proceso de gestión de cambios único y
simple es una maravillosa oportunidad para mejorar los procesos. Las estrategias de
financiamiento de proyectos excepcionalmente cuestionables no deberían impedir aprovechar
esta estrategia.

La Figura 11 resume los resultados de una de las preguntas de la Encuesta de Desarrollo Dirigido
por Pruebas (TDD) de Ambysoft 2008 que se preguntó a la comunidad de TDD qué técnicas de
prueba estaban usando en la práctica. Debido a que esta encuesta se envió a la comunidad de
TDD, no representa con precisión la tasa de adopción de TDD, pero lo que es interesante es el
hecho de que los encuestados indicaron claramente que no estaban solo haciendo TDD (ni
tampoco todos estaban haciendo TDD, sorprendentemente). Muchos también realizaban
revisiones e inspecciones, pruebas de final de ciclo de vida y pruebas independientes paralelas,
actividades que los puristas ágiles rara vez parecen discutir.

32
 Figura 11. Pruebas / prácticas de validación en equipos ágiles.

Fuente: Ambysoft 2008

Además, la Figura 12, que resume los resultados del 2010 ¿Qué tan ágil es usted? La encuesta
proporciona información sobre las estrategias de validación que siguen los equipos que afirman
ser ágiles. Las tasas de adopción informadas para el desarrollador TDD y la aceptación TDD,
53% y 44% respectivamente, son mucho más realistas que las informadas en la Figura 11.

33
 Figura 12. Cómo los equipos ágiles validan su propio trabajo.

Fuente: Ambysoft 2010

La Figura 13 y la Figura 14 resumen los resultados de la encuesta Agile Testing Survey 2012.
Estos gráficos indican el enfoque PRIMARIO de las pruebas de aceptación y las pruebas del
desarrollador, respectivamente. En la superficie hay discrepancias entre los resultados que se
muestran en la Figura 12, en la Figura 13 y la Figura 14. Por ejemplo, la Figura 12 muestra una
tasa de adopción del 44% para ATDD, pero la Figura 13 solo muestra una tasa del 9%. Esto es
porque las preguntas son diferentes. La encuesta de 2010 preguntó si un equipo estaba siguiendo
la práctica, mientras que la encuesta de 2012 preguntó si era el enfoque principal. Entonces, un
equipo puede estar tomando un enfoque de prueba de aceptación primero, pero otros enfoques
pueden ser más comunes, por lo tanto, ATTD no fue la estrategia principal para las pruebas de
aceptación en ese equipo. Cuando se trata de enfoques de prueba por primera vez, está claro
que todavía tenemos un largo camino por recorrer hasta que dominio total.

34
Figura 13. Enfoque primario de las pruebas de aceptación.

Fuente: Agile Testing Survey 2012

Figura 14. Enfoque primario para pruebas de desarrollador.

Fuente: Agile Testing Survey 2012

35
6.1 Seguimiento de Defectos e Informes

Los defectos que se identifican durante todos los aspectos de las pruebas son categorizados,
registrados y documentados por los equipos de desarrollo de software en una herramienta como
Jira o Rally.

Las diferentes categorías de defectos son:

Critico (Critical)

Para que se reporte con prioridad critico o bloqueado un problema dentro del sistema en
desarrollo se deberá tener en cuenta los siguientes aspectos:

• La gravedad del defecto es crítica significa que es capaz de bloquear el sistema de

software, afectando la pérdida potencial de datos y el uso.

• La gravedad del defecto es crítica significa que impide que el sistema de software ágil
cumpla con los requisitos del usuario.

• La gravedad del defecto es crítica significa que afecta significativamente la funcionalidad

y la solución del probador no está disponible.

• La gravedad del defecto es crítica significa que el rendimiento es lento durante las pruebas
e incluso las pruebas no pueden continuar al ritmo normal.

• La gravedad del defecto es crítica significa que hace que el sistema falle al realizar las
operaciones normales.

• La gravedad del defecto es crítica significa que hace que el sistema se detenga y requiere
que se reinicien las actividades transaccionales de los usuarios.

Alta (High)

Para que se reporte con prioridad Alta un problema dentro del sistema en desarrollo se deberá
tener en cuenta los siguientes aspectos:

• La gravedad del defecto es alta significa que se pierde una parte de la funcionalidad, pero
el solicitante todavía está funcionando.

• La gravedad del defecto es alta significa que evita que el sistema de software ágil cumpla
con los requisitos comerciales; Hay solución, pero engorroso.

36
 • La gravedad del defecto es alta significa que causa que un programa vital particular en el
sistema deje de funcionar con una solución alternativa.

Medio (Medium)

Para que se reporte con prioridad Medio un problema dentro del sistema en desarrollo se deberá
tener en cuenta los siguientes aspectos:

• La gravedad del defecto es media significa que afecta la funcionalidad del sistema y hay
una solución alternativa para el probador.

• La severidad del defecto es media significa que baja la calidad del producto; hay una
solución para conseguir que funcione la funcionalidad requerida del sistema.

• La gravedad del defecto es media significa que impacta las pruebas de otros componentes
del sistema. Sin embargo, otros módulos del código pueden ser probados
independientemente.

Baja (Low)

Para que se reporte con prioridad Baja un problema dentro del sistema en desarrollo se deberá
tener en cuenta los siguientes aspectos:

• La gravedad del defecto es baja significa que hay un mensaje de error poco claro, que no
afecta el uso del sistema o del producto.

• La gravedad del defecto es baja significa que el problema es de baja prioridad, que puede
solucionarse en cualquier momento.

• La gravedad del defecto es baja significa que no afecta el rendimiento de la aplicación.

• La gravedad del defecto es baja, lo que significa que las pruebas pueden continuar sin
interrupción.

37
CONCLUSIÓN

En conclusión, la figura de un Ingeniero QA va a estar presente en las diferentes tareas de la

iteración, se debería trabajar cerca de las personas de negocio, en la toma, análisis y revisión de
requisitos, para definir entre ambos una historia de usuario y cumpla con los criterios para evaluar
una historia de usuario que sea INVEST (Independiente, valuable, estimable, pequeño, testable).
Por lo que una de las funciones principales de un Ingeniero QA debe ser intentar que la historia
de usuario se cumpla en todos estos aspectos.

Otras de las tareas que se realiza dentro del equipo Development Team son: crear un plan de
pruebas, gestionar los riesgos, definir los criterios de aceptación, gestionar defectos y pruebas
exploratorias.

Una función importante en el trabajo es dar soporte a los developer para la creación y definición
de pruebas, con las técnicas que conocemos de TDD y ATDD, de forma que el código sea sencillo
evitando introducir complejidades innecesarias en este para que pueda ser testable rápidamente,
con pruebas de regresión y análisis de código (sonar).

Deberá gestionar la Integración Continua, asegurando que los despliegues cumplan con el DoD,
como la gestión de los defectos, dar seguimiento y verificar cuando sean corregidos, siendo
fundamental saber el estado en el que se encuentra cada tarea del proyecto en cada momento.

En todos los proyectos siempre surge la misma pregunta: ¿quién debería ser la persona que
automatice las pruebas? Las personas más adecuadas para automatizar las pruebas son los
desarrolladores ya que son especialistas en programación. En algunos casos, un Ingeniero QA
puede tener también ese rol, pero lo más común es que no esté especializado en programación.

También es motivo de confusión en los equipos ágiles sobre a quién corresponde la

responsabilidad de la calidad del proyecto, atribuyéndose normalmente solo al Ingeniero QA, pero
en realidad es responsabilidad de todos los miembros del equipo.

En resumen, el Ingeniero QA como se puede ver, si está integrado en un equipo ágil, desarrolla
el perfil, tareas y funciones concretas. En los proyectos ágiles donde existe la figura de Ingeniero
QA, los miembros del equipo ven el aporte de gran valor en la ejecución de los proyectos y su
correcta ejecución. Al final, en todos los equipos que se tiene presente la figura de Ingeniero QA,
lo mantienen y si se va a otro equipo se busca que exista esta figura dentro del nuevo equipo.

38
Si se quiere conocer más extensa y concretamente el papel de un Ingeniero QA se puede
encontrar definidas las funciones en la documentación de Agile Tester ISTQB y también en los
libros mencionados en el desarrollo de la monografía.

39
BIBLIOGRAFÍA

Cem Kaner, J. B. (2002). Lessons Learned in Software Testing. New York: Wiley.

Lisa Crispin, J. G. (2015). Agile Testing. Indiana: Addison-Wesley.

Lisa Crispin, J. G. (2015). Agile Testing: A Practical Guide for Testers and Agile Teams.

Crawfordsville, Indiana: The Addison-Wesley Signature Series.

Document Foundation Level Extension Syllabus Agile Tester Version 2014 de la ISTQB

Páginas web Referenciales

https://www.beeva.com/beeva-view/qa/el-rol-de-los-qa-en-equipos-agiles/

http://www.ambysoft.com/essays/agileLifecycle.html

https://www.istqb.org/downloads/syllabi/agile-tester-extension-syllabus.html

40