Curso de Testing QA avanzado

MATERIAL DE LECTURA

Visión del QA en la gestión

de proyectos
 Objetivos de la Guia
En esta guía aprenderemos a:
● Conceptos generales de la gestión de proyectos
● Visión del tester en la gestión de proyectos.
● Como saber lo que quiere el cliente
● Objetivos de la gestión de proyecto
● Alcance de la gestión de proyecto
● Riesgos De la gestión de proyecto
● Modelo agil

INTRODUCCIÓN

Con este material abordaremos temas relacionados a la gestión de proyectos, la

importancia y retomaremos el ciclo de vida de las pruebas de software, desde el enfoque
estático (documentación) al dinámico (ejecución de pruebas), abordaremos temas
relacionados a los riesgos, alcance, restricciones, entre otros y aprenderemos a liderar
un proyecto de manera práctica y llevarlo de principio a fin.
Gestión de proyectos de Testing
El tester debe realizar diferentes actividades como parte de su evaluación del requerimiento, sprint
o proyecto. Es importante llevar un control desde el inicio de lo que serán esas actividades.

No todos los procesos de prueba son iguales y el tester tendrá que discriminar qué pruebas hacer,
cuánto tiempo le tomarán, qué entregables va a generar; entre otros aspectos, que varían según
cada sistema o empresa. Hoy especialmente cuando los testers deben ser autónomos en mesas
de trabajo bajo enfoque ágil, es necesario saber cómo gestionar el proceso de pruebas.

¿Cómo debe ser la visión del QA Analista / Tester?

La visión de Testing/QA debe estar siempre cercana al punto de vista del usuario, a sus
necesidades y sus expectativas.

Para lograrlo, el profesional de Testing/QA debe indagar y entender muy bien el negocio y al
usuario como tal. Esto significa, que la misión de Testing/QA es precisamente evaluar cuán
alineado está el sistema, con ese punto de vista.

El cliente muchas veces no sabe lo que quiere

Como analista QA muchas veces tendremos parte en reunión de toma de decisiones donde nos
veremos en la necesidad de opinar sobre diferentes pedidos de clientes, si bien una de las más
importantes es que un analista haga previamente la tarea de realizar las preguntas correctas
acerca de la problemática del mismo, hay muchas veces en las que, el cliente no tiene una idea
clara de lo que en verdad quiere con su proyecto.

Como se observa en la siguiente imagen:

Alcance
¿Cómo deben ser los criterios al definir los objetivos?

● Específicos (Specific): Los objetivos tienen que ser descritos específicamente de manera
positiva. Claro el qué, cuándo y cómo para definir el alcance.

● Medibles (Measurable): Los logros de los objetivos deben ser medibles. Que sea posible
cuantificar, para poder controlarlo.

● Alcanzables (Attainable): Debe ser atractivo para el equipo lograr los objetivos. Que
podamos asignar responsables.

● Realistas (Realistic): El objetivo debe ser alcanzable de manera realista. A la hora del
presupuesto y de los recursos que tenemos.

● Oportuno (Time-bound): El objetivo tiene que establecerse en un marco de tiempo

oportuno. Definir el período de tiempo para completarlo.

Ejemplo de Objetivos SMART:

1. Que el sistema pueda generar reportes en formato PDF, del resumen trimestral de las compras
que un cliente haya realizado; donde se incluya el logo del E-Commerce, los datos principales del
cliente (nombre, apellido y número de documento) y la información general de cada compra
(número de compra, ítems adquiridos con su precio y monto total).

2. Entregar al cliente el sistema administrativo sin fallas de criticidad alta, habiendo ejecutado
todos los casos de prueba definidos en el alcance y dentro del período de tres meses.
La triple restricción

¿Por qué un proyecto se hace incumplible en la realidad?

Todo proyecto de Testing estará siempre restringido por

algunas variables:

● Alcance: qué pruebas se han contemplado.

● Costo: qué recursos se necesitan para lograrlo
(humanos y materiales).
● Tiempo: cuánto tiempo requerirá.

Estas variables deben estar en cierto equilibrio. Si alguna de ellas se ve modificada, entonces
afectará al resto.
● Por ejemplo, si en un proyecto se amplía el alcance de las pruebas, seguramente
impactará en el costo o tiempo.

La triple restricción extendida y la satisfacción del cliente

Gestión de proyectos en Testing

Tal como lo indica el estándar de gestión de proyectos PMI, todo proyecto (incluyendo los de
pruebas) requerirá planificación, toma de conocimiento, análisis, ejecución, seguimiento, control y
cierre.

Los proyectos de Testing en particular tendrán incertidumbre, que debe ser controlada y detallada
como parte de la gestión correspondiente.

Es tarea del equipo de Testing identificar y considerar todos los factores que deben tomarse en
cuenta, como parte de la gestión del proyecto.

Modelo Tradicional

Dado que en el Modelo Tradicional, Testing recibirá insumos previamente analizados como el
Documento Funcional y el desarrollo, es probable que las tareas de estimación y planificación de
Testing tengan más certezas.

Adicionalmente bajo este modelo, seguramente se generarán diferentes entregables/documentos

como parte del proceso de gestión que inicia al recibir los insumos, pasando por la planificación,
ejecución y control de actividades.

Ciclo de vida del Testing

Enfoque Estático Enfoque Dinámico

Analista QA Analista QC (Tester)

Software
Análisis Plan de Análisis Diseño Construcción Test Test de Test de
UAT
de req. Pruebas de Doc. de CP de CP Unitario Integración Sistemas
Tiempo

● Test de
● Estimación
Performance
● Riesgos
● Test de Carga
● KPIs
● Test de stress
● …..
● …..
 Ciclo de vida del testing (marco Agile)

En el marco de trabajo Agile, el QA/Tester está conformando el Team. Su misión es trabajar cerca
del desarrollador previniendo defectos.

El QA/Tester toma los ‘Criterios de Aceptación’ descritos en las Historias de Usuario para generar
los escenarios y casos de pruebas.

Modelo Ágil
La Gestión de Proyectos en Testing bajo el Modelo Ágil, deja en manos del Tester todas las
actividades de gestión, convirtiéndose en un perfil mucho más autónomo e indagador, que debe
relevar la información que necesite para poder tener claridad sobre la planificación y decisiones
sobre las pruebas a realizar. En este Modelo, Testing recibe muy poca información, pero participa
en las actividades de análisis y durante todo el proceso de desarrollo.

Información de los
ejecutivos, el equipo,
los implicados, los
clientes, usuarios, etc.

1-4
Semanas
Cada
24 Hrs

Tareas Priorizadas Se indican las tareas a

realizar en un sprint

Trabajo
Terminado

Tareas
fecha de finalización y las
tareas no deben cambiar

Material de apoyo sugerido

Con los conocimientos de metodología ágil, sumados a los adquiridos podremos comenzar a ser parte
de un proyecto ágil, incluso participar en toma de decisiones y dirigir equipos de testing, sin embargo
para poder hacerlo es necesario entender la metodología, en el siguiente link encontrarás la
explicación del modelo.

Metricas de Calidad: https://www.youtube.com/watch?v=HhC75IonpOU

Riesgos

¿Qué es un riesgo?
Un riesgo es la probabilidad de una situación conocida u ocurrencia, que de producirse, afectará a
nuestra capacidad para cumplir los objetivos del proyecto (si es en negativo será un riesgo, y si es
en positivo una oportunidad).

Dependiendo del nivel de impacto, el riesgo puede ser de importancia. Por lo cual el análisis de
riesgo no solo apunta a saber qué puede ocurrir, sino también a cómo mitigarlo con acciones
preventivas o correctivas.

¿Riesgos en Testing?
Los riesgos serán una constante en los proyectos de Testing dado que la interacción y
dependencia de otras áreas (Funcional, Desarrollo) aumenta la incertidumbre al momento de
estimar y planificar el esfuerzo requerido para las pruebas de un sistema en particular.

Por ello, la Gestión de Riesgos propia del estándar PMI también debe ser considerada en el
ámbito del Testing sea cual sea la metodología o enfoque de trabajo.

¿Cómo se analizan los riesgos?

Cada uno de los eventos no esperados que podrían ocurrir y poner en peligro el cumplimiento de
las actividades de prueba, será un riesgo de Testing, que idealmente tendrá que ser identificado y
descrito.

Los riesgos se ponderarán en función a una escala (usualmente del 1 al 4) y generar un factor por
medio de la multiplicación de las variables:

● Probabilidad de que el riesgo ocurra.

● Impacto que generaría el riesgo en caso
de materializarse.

Gráfico de riesgos
¿Cómo debe ser la visión del SQA Analista/Tester?
Ejemplos de riesgos

Funcional/usuarios:

● Poca disponibilidad del funcional/usuarios para aclaración del requerimiento.

Desarrollo:
● Baja calidad del desarrollo entregado.
● Desconocimiento del negocio.

Testing:
● Desconocimiento del negocio.
● Rotación de personal.

Ambiente:
● Inestabilidad del entorno de pruebas.

Planilla de riesgos
Luego de identificar y ponderar la probabilidad e impacto de cada uno de los riesgos, es importante
desarrollarlos para determinar el plan de acción especificando:
● Descripción.
● Impacto.
● Causa.
● Responsable.
● Acción (aceptar, eliminar, mitigar).

Nombre del proyecto

Director del proyecto

Fecha de última actualización

Gestión del Riesgo

Evaluación de riesgos 13 Gestión de

riesgos
Gestión de ambientes

Involucra:
● HW en donde corren los programas.
● SW de sistemas operativos.
● Motor de BBDD.
● Arquitectura de datos.
● Versionado de la Aplicación.
● Configuración de la Parametrización.

El proceso de pruebas estará sujeto a la disponibilidad de un ambiente/entorno idóneo, que sea

análogo al de producción en cuanto a código fuente, datos e infraestructura. Por ello, será
importante que el equipo de Testing también pueda determinar oportunamente las necesidades de
ambiente que se requieran según el caso.

Por ejemplo: Un servidor de Base de Datos bajo un motor en particular, Dispositivos móviles bajo
cierto sistema operativo, entre otros.
Estrategias y estimaciones

Definiciones de Estrategia

“Una estrategia de prueba proporciona una descripción genérica del proceso de pruebas,
normalmente a nivel del producto u organización.”

“Se encarga de definir y planificar las pruebas que serán realizadas por el equipo de testing en las
distintas entregas de los proyectos, estableciendo el conjunto de servicios a aplicar en cada
proyecto en función de la tecnología, estado, criticidad y urgencia del mismo.”

Estrategia y enfoque
Al inicio del proceso de pruebas se deben tomar decisiones sobre su alcance y esto va más allá
de saber qué funcionalidades del sistema y qué requerimientos estarán involucrados.

Es importante definir la estrategia y enfoque que consiste en determinar:

● Los tipos y niveles de prueba.

● Cómo se van a ejecutar las pruebas.

Especificaciones de estrategia
Ciclos en estrategia

Ejemplo de enfoque de pruebas

Las decisiones sobre el enfoque de pruebas en un proyecto pueden incluir:

● Ejecutar pruebas en ciclos.
● Ejecución de pruebas exploratorias.
● Ejecución de pruebas en función a la prioridad definida
para los casos de prueba.
● Ejecución de pruebas de smoke como ciclo inicial.

Estimaciones

Estimación Experta

Estimación basada en analogías

Estimación basada en
porcentajes

Estimación experta
Es útil cuando se tiene conocimiento en el sistema que será sometido a pruebas. En este tipo de
estimación, el tester ya tiene experiencia sobre cuánto le podría tomar ejecutar pruebas sobre un
cambio en un sistema porque ya lo conoce.

Es una estimación bastante general que se recomienda pueda ser refinada con otras técnicas.
Estimación basada en analogías
Es útil cuando se tiene conocimiento en la ejecución de pruebas. En este tipo de estimación, el
tester ya tiene experiencia sobre cuánto le podría tomar ejecutar pruebas, porque previamente ha
participado en otros proyectos; con lo cual puede hacer similitudes con el requerimiento a probar.

Es una estimación bastante general que se recomienda pueda ser refinada con otras técnicas.

Estimación basada en porcentajes

Es una estimación muy utilizada cuando no se tiene experiencia en el sistema y además se cuenta
con muy poca información referente al requerimiento específico a evaluar.

En este caso se atribuye un porcentaje (que usualmente gira en torno al 30%) al esfuerzo de las
pruebas. Entonces, si un desarrollo debe estar en producción en 3 meses, se calcula un mínimo
de un mes para las actividades de prueba.

Ejemplo de porcentajes:

Valor promedio por fases Proyecto en 3 meses

● Inicio 8 % ● Inicio 8 % → 0.24 meses

● Plan 12 % ● Plan 12 % → 0,36 meses

● Análisis y Diseño 25 % ● Análisis y Diseño → 0.75 meses

● Ejecución (incluido Bugs) 45 % ● Ejecución (incluido Bugs) → 12 meses

● Cierre 10 % ● Cierre 10 % → 0,3 meses

Ecosistema de testing (Relación de ciclos de vida)

Sugerencias para reforzar la gestión de proyectos
En el siguiente Link podremos ver un video con información de puntos de vista de profesionales del
área de gestión con opiniones acerca de la gestión de proyectos, ejemplos y muchos recursos que
nos ayudarán a encarar la actividad práctica.

https://www.youtube.com/watch?v=Kx6L7Kjm-WU