Proceso de Testing

Módulo 2

Ing. María Belen Vera Calle

mbvera@[Link]
Contenido
● Proceso de desarrollo de testing.
● Análisis de pruebas.
● Diseño de pruebas.
● Implementación de pruebas.
● Herramientas de administración.
● Defecto, error y falla.
● Definición de bug.
● Comparación con anomalia segun IEEE.
● Relación defecto falla.
● Estructura de un Bug.
● Impacto de un defecto.
● Gestión de defectos.
● Como registrar un bug.
● Como se comunica un bug.
● Reporte de un bug.

Software Testing /QA

Contenido
● Atributos de un bug.
● Planilla de bugs.
● Seguimiento de un bug.
● Tips para registrar un bug.
● Ciclo de vida de un bug.
● Causa- Raiz de un bug.
● Gestión de proyecto.
● Alcance.
● La triple restricción.
● Proyecto segun PMI.
● Qué es un riesgo.
● Gráficos de riesgos.
● Planillade riesgos.
● Gestión del riesgo.
● Definición de estrategias.

Software Testing /QA

Contenido
● Estrategia y enfoque de pruebas.
● Ciclo de estrategias.
● Especificaciones de estrategias.
● Estimaciones.
● Ecosistema de testing.
● Defincion de plan de pruebas.
● Tabla de contenidos.
● Completitud de las pruebas.
● Tipo de cobertura de pruebas.
● Organigrama de QA.
● Qué es un KPI.
● Gestión de KPI.
● Otros informes.

Software Testing /QA

Proceso de desarrollo de testing (IEEE829)
Etapas:

➢ Análisis de pruebas
➢ Diseño de pruebas
➢ Implementación de las pruebas de pruebas

Software Testing /QA

Proceso de desarrollo de testing (IEEE829)
❖ Análisis de pruebas: Análisis de requerimientos, documentos para
saber QUE se va a testear

Condición de Test o prueba

Es un ítem o evento que se puede verificar por uno p mas casos de pruebas

Ejemplo: Función, transacción, características, módulo.

Software Testing /QA

Proceso de desarrollo de testing (IEEE829)
❖ Diseño de los casos de pruebas
Los test cases (casos de pruebas) y set de datos son creados en esta
instancia.

IEEE 829:
✓Especificaciones de Diseño de la prueba(Test Design Specifications)
•Se determina QUE necesita ser probado.
•Se determina como seria una prueba exitosa
•Se deriva de los requerimientos

✓Especificaciones del caso de prueba (Test case Specifications).

•Valores exactos de entradas y otros que se requieran
•Valores exactos de salidas y cambios del sistema esperados
•Pasos para ejecutar las pruebas
•Documentación del caso de prueba.
Software Testing /QA
Proceso de desarrollo de testing (IEEE829)
❖ Diseño de los casos de pruebas

Definición de Caso de prueba o Test case

Conjunto de valores de entrada, precondiciones de
ejecución, resultados esperados y postcondiciones de
ejecución, desarrollado con un objetivo en particular o
condición de prueba, tales como probar un determinado
camino de ejecución o para verificar el cumplimiento de un
requisito determinado.
ISTQB

Set de Datos→ Datos que existen (por ejemplo, en la base de

datos) antes que la prueba sea ejecutada, y que afecta o es
afectada por el componente o sistema dentro de la prueba.

Software Testing /QA

Proceso de desarrollo de testing (IEEE829)
❖ Diseño de los casos de pruebas
Esquema de un caso de prueba

Ambiente de la prueba

Caso de
Uso
Pre-Cond

Set dedatos Resultado

TEST Obtenido
CAS E

Resultado
Esperado

Software Testing /QA

Proceso de desarrollo de testing (IEEE829)
❖ Diseño de los casos de pruebas

Características
1. Es identificado unívocamente.
2. Es único en cuanto a contenido.
3. Posee un estado asociado (Pendiente, Aprobado, Fallido).
4. Es re-utilizable.
5. Contiene información sobre la versión del producto.
6. Posibilita el tracking del avance de las pruebas.

Software Testing /QA

 Proceso de desarrollo de testing (IEEE829)
❖ Diseño de los casos de pruebas
Características
1. Es identificadounívocamente.
• único en cuanto a contenido.
2. Es 7. Informa responsable, fecha de creación y ejecución.
• osee
3. P un estado asociado (Pendiente, Aprobado, Fallido). re-utilizable.
8. Soporta histórico de modificaciones y resultado de
4. Es ejecuciones.
•ontiene información sobre la versión del producto. osibilita el
5. C 9. Permite el manejo de prioridades según su criticidad.
6. P [Link]
tracking Contiene información sobre tiempos estimados de
avance de las pruebas.
ejecución.
11. Es independiente al Ambiente de Pruebas.

Software Testing /QA

Proceso de desarrollo de testing (IEEE829)
❖ Diseño de los casos de pruebas
¿Cómo diseñar un caso de prueba?
1. Analizar el requerimiento funcional o caso de uso.

2. Documentar casos felices, alternativos o de excepción.

3. Seleccionar un caso de prueba a diseñar.

4. Describir los pre-condicionales.

5. Seleccionar / Generar datos de entrada.

6. Especificar el / los ambientes de prueba.

7. Documentar resultado esperado como salida.

Software Testing /QA

Proceso de desarrollo de testing (IEEE829)

Caso de Uso
Un diagrama de caso de uso es una descripción En el contexto de ingeniería del software,
de las actividades que deberá realizar alguien o representa a un sistema como un conjunto
algo para llevar a cabo algún proceso. de interacciones.
Sirven para especificar la comunicación y el
comportamiento

Software Testing /QA

Software Testing /QA
Proceso de desarrollo de testing (IEEE82)
Ejemplos de Descripción Caso de Uso

Software
Software Testing
Testing /QA /QA
Proceso de desarrollo de testing (IEEE829)
Caso de Uso y Caso de Prueba

Software
SoftwareTesting
Testing /QA /QA
Proceso de desarrollo de testing (IEEE829)
Historia de usuario
• Una historia de usuario es la unidad de trabajo más pequeña en un marco ágil. Es un
objetivo final, no una función, expresado desde la perspectiva del usuario del software.

• El propósito de una historia de usuario es articular cómo un elemento de trabajo

entregará un valor particular al cliente

• Son unas pocas frases en lenguaje sencillo que describen el resultado deseado

• Las historias de los usuarios describen el por qué y el qué que hay detrás del trabajo
diario de los miembros del equipo de desarrollo; a menudo las historias de usuario se
expresan de la siguiente manera: perfil + necesidad + propósito.

• Los criterios de aceptación son una serie de preceptos que validan

la implementación de nuestra historia de usuario.

Software Testing
Software /QA
Testing /QA
Proceso de desarrollo de testing (IEEE829)
Historia de usuario

Software Testing
Software /QA
Testing /QA
Proceso de desarrollo de testing (IEEE829)
Diagrama de Caso de Prueba (DER)

1 1 1 n Step
Req Test Case Step
Step

Use Case UsRe

Use Case
Req eCqase

Test Case
Test Case Test Case
Test Case

Software Testing /QA

Proceso de desarrollo de testing (IEEE829)
Diagrama de Caso de Prueba Ejecutado (DER)

1 n Step
Test Step
Step
Case

1 n Step 1 n
Run Step Bug
Run Step
TC

Software Testing /QA

Proceso de desarrollo de testing (IEEE829)
Atributos de un Caso de Prueba
● Id: identificador único.
● Resultado obtenido: descripción de lo
● Descripción: título breve, qué se va a probar. que realmente se obtuvo después de la
● Datos: datos necesarios para ejecutar el CP. ejecución.

● Precondiciones: condiciones a cumplir ● Post-condiciones: descripciones de las

previa ejecución del CP. condiciones luego de la ejecución del CP.

● Prioridad (severidad): identifica cuál es ● Pasos a ejecutar: Detalle a seguir para

la importancia de CP. poder ejecutar el CP.

● Tipo de Caso: positivo (camino feliz),

negativo (alternativo, excepción).
● Resultado esperado: descripción de lo
que debería verse una vez ejecutado el
CP.

Software
SoftwareTesting
Testing /QA /QA
Proceso de desarrollo de testing (IEEE829)
Ejemplos de atributos de un Caso de Prueba

● Id: 3D-P-CP-001. ● Resultado esperado: emisión de ticket

(impresora o pdf).
● Descripción: Comprar 2 entradas para función
3D, viernes 22 hs., pago con Tarjeta Crédito. ● Resultado obtenido: emisión de ticket
(impresora o pdf).
● Datos: Tabla de datos de entradas para esa
función (Excel). ● Post-condiciones: entradas vendidas y
facturadas.
● Precondiciones: Tarjeta de crédito habilitada y
con fondos suficientes. ● Pasos a ejecutar: descrito en el Step by
Step.
● Prioridad (severidad): High (47% son compras
con CP)
● Tipo de Caso: positivo.

Software
SoftwareTesting
Testing /QA /QA
Proceso de desarrollo de testing (IEEE829)
Ejemplos de atributos de un Caso de Prueba

Definición del nombre del Test Case

▪Proyecto: Originacion
▪Función: Slide Domicilio
▪Subfuncion: Campo Numero
▪Descripción: Ingreso numero valido

TC89_Ori_Domicilio_CampoNro_IngresarNumeroValido

Software
SoftwareTesting
Testing /QA /QA
Proceso de desarrollo de testing (IEEE829)
❖ Diseño de los casos de pruebas

Tips para diseñar casos de pruebas

1. Definir una tarea por paso y simples

2. Utilizar verbos en infinitivo
3. Evitar faltas de ortografía
4. Utilizar lenguaje simple y entendible
5. El nombre del TC debe describir la funcionalidad y el objetivo a evaluar
6. Cuando el TC sea negativo deberá comenzar con la palabra “Intentar”
7. No debe existir TC con ID o con nombres iguales
8. Deben ser atómicos
9. Buena practica: Los TC diseñados por una persona deben ser probados por otra.

Software
SoftwareTesting
Testing /QA /QA
Proceso de desarrollo de testing (IEEE829)
Nota: Realizar ejercicios de
Planilla de Casos de Prueba Registración en Planilla.

Id del CU Id del CP Título del CP Descripción del CP Ciclo Tipo Prioridad

Identificador Identificador Nombre Breve descripción del CP Ciclo de Positivo Orden de
mnemotécnico mnemotécnico mnemotécnico ejecución de (camino felíz), ejecución o de
del CU del CP del CP pruebas Negativo importancia
(alternativo, (alta, media,
excepción) baja)

Severidad Status Pre-condiciones Pos-condiciones Datos Generales Resultado Esperado

Identifica la Estado (Pasó, Condiciones a Describir las Datos requeridos Resultado esperado que se
criticidad (negocio, Falló, En Proceso, cumplir previa condiciones luego de para realizar el CP quiere obtener con estos
funcional, formal) Anulado, ejecución la ejecución datos y configuración del
Suspendido) ambiente

Resultado obtenido Ambiente de Test Versión de SW Responsable del CP Fecha y Hora

Descripción de lo que Entorno donde se Versión del producto, Persona responsable del Fecha/hora de diseño y/o
realmente se obtuvo ejecuta el CP (servidores, software o paquete a diseño y/o ejecución. ejecución
después de la ejecución. redes, infraestructura) testear.

Software Testing /QA

P ro c e s o d e d e s a r ro l l o d e t e st i n g ( I E E E 8 2 9 )
Planilla de P a s o s de C a s o s de Prueba

Id del CP Número de Paso Descripción del Paso Precondiciones Datos

Identificador Número secuencial Descripción concisa, concreta, Condiciones a cumplir previa Datos concretos
mnemotécnico del CP correlativo del paso precisa del paso. ejecución del paso (valores) para
realizar el paso.

Resultado Esperado Resultado obtenido Status Evidencia

Resultado esperado que se Descripción de lo que realmente se Estado del paso Print de la pantalla, archivo, tabla u
quiere obtener en este paso. obtuvo después de la ejecución. (Pasó, falló) otro elemento demostrando que se ha
realizado el paso

Software Testing /QA

Proceso de desarrollo de testing (IEEE829)
Actividad- Diseño de un Caso de Prueba
Actividad: Diseñar los casos de pruebas de las siguientes historias de usuarios

Link:

US1: Buscar vuelos

Como usuario
Quiero cargar fechas
Para buscar vuelos disponibles

Criterios de Aceptación
•Cuando se seleccione una fecha menor a la actual de partida, sistema muestra mensaje
de error
•Cuando se seleccione una fecha menor a la actual de llegada, sistema muestra mensaje
de error

Software
SoftwareTesting
Testing /QA /QA
Proceso de desarrollo de testing (IEEE829)
Actividad- Diseño de un Caso de Prueba
US2: Registro de pasajeros

Como usuario
Quiero poder cargar mis datos personales
Para registrarme en la pagina

Criterios de Aceptación

•Asegurarse que el campo nombre y apellido solo acepten letras

•Asegurarse el que el campo phone solo acepte valores numéricos.
•La opción de país es obligatoria.
•Los inputs Address, city, state/province, postal code no son obligatorios.
•Campo username es obligatorio debe estar compuesto por 8 dígitos con letras
mayúsculas y minúsculas
•Campo password debe estar compuesto de 6 dígitos alfanuméricos.

Software
SoftwareTesting
Testing /QA /QA
Proceso de desarrollo de testing (IEEE829)
Actividad- Diseño de un Caso de Prueba

Software
SoftwareTesting
Testing /QA /QA
 Proceso de desarrollo de testing (IEEE829)

Diseño de casos de pruebas- Pruebas APIS

El término API es una abreviatura de Application Programming Interfaces, que en español significa
interfaz de programación de aplicaciones. Se trata de un conjunto de definiciones y protocolos que se
utiliza para desarrollar e integrar el software de las aplicaciones, permitiendo la comunicación entre dos
aplicaciones de software a través de un conjunto de reglas.

• REST → Transferencia de Estado Representacional. Es un estilo de arquitectura de software que

posee reglas (restricciones), que los desarrolladores deben seguir. Sin embargo, una de las
limitaciones más importantes es que la aplicación web debería poder entregar los datos
(información) siempre que se dé un comando.

Software
SoftwareTesting
Testing /QA /QA
 Proceso de desarrollo de testing (IEEE829)

Diseño de casos de pruebas- Pruebas APIS

Métodos Https

➢Get
➢Post
➢Delete
➢Put/Patch

Tipos e pruebas de APIS:

Manuales
Automatizadas

Software Testing /QA

Software Testing /QA
Proceso de desarrollo de testing (IEEE829)

Diseño de casos de pruebas- Pruebas APIS

✓ En este tipo de pruebas la verificación que se hace es al RESPONSE y al código de respuesta.

✓ Códigos de respuestas pueden ser:

200 → Indica que la prueba es exitosa.

400 → Indica que los parámetros enviados son no validos.
404 → Indica que los valores enviados son inconsistentes.
405 → Indica que existe un error en el tipo de método.
500 → Error en el servidor.

Software Testing /QA

Software Testing /QA
Proceso de desarrollo de testing (IEEE829)

Diseño de casos de pruebas- Pruebas APIS

✓ Para escribir los casos de pruebas de Apis utilizamos Gherkin

GHERKIN → Define la estructura y una sintaxis básica para la descripción de las pruebas que pueden
ser entendidas tanto por los integrantes técnicos del equipo como así también por los Analistas/PO o
quien quiera que este como representante del cliente. De esta manera mientras se generan pruebas se
esta generando documentación viva que describe perfectamente como se comporta el sistema
enriqueciendo y manteniendo la documentación.

Software Testing /QA

Software Testing /QA
Proceso de desarrollo de testing (IEEE82)

Diseño de casos de pruebas- Pruebas APIS

Estructura de GHERKIN

Scenario (Escenario) → Es una lista de pasos que comienza con algunas de las siguientes palabras
claves:

Given (Dado) → es la precondición

When (Cuando)
Then (Entonces) → Valida/verifica la respuesta.
But (pero) o And (Y)

Software Testing /QA

Software Testing /QA
Proceso de desarrollo de testing (IEEE829)
Diseño de casos de pruebas- Pruebas APIS

Estructura de GHERKIN

Software Testing /QA

Software Testing /QA
Proceso de desarrollo de testing (IEEE829)
Actividad- Diseño de un Caso de Prueba Con Gherkin
US2: Registro de pasajeros

Como usuario
Quiero poder cargar mis datos personales
Para registrarme en la pagina

Criterios de Aceptación

•Asegurarse que el campo nombre y apellido solo acepten letras

•Asegurarse el que el campo phone solo acepte valores numéricos.
•La opción de país es obligatoria.
•Los inputs Address, city, state/province, postal code no son obligatorios.
•Campo username es obligatorio debe estar compuesto por 8 dígitos con letras
mayúsculas y minúsculas
•Campo password debe estar compuesto de 6 dígitos alfanuméricos.

Software
SoftwareTesting
Testing /QA /QA
Proceso de desarrollo de testing (IEEE829)
Actividad- Diseño de un Caso de Prueba Con Gherkin
US1: Creacion de usuarios

Como usuario admin de sistemas administrativo

Quiero poder crear usuarios con perfiles IT
Para que se puedan ingresar a intranet oganizacional

Criterios de Aceptación
*Dado endpoitn con servicio Post "[Link] el codigo de respuesta existosa
es 201
*Verificar manejo de errores: Falta informacion 400, error de servidor 500, error en metodo 405
* Respuesta del servicio contener los datos "name","job", "id" y "createdAt"

Consideraciones:

Body del servicio posee esta estructura:

{
"name": "morpheus",
"job": "leader"
}
Software
SoftwareTesting
Testing /QA /QA
 Proceso de desarrollo de testing (IEEE829)

Diseño de casos de pruebas- Pruebas APIS

Trazabilidad

Software
SoftwareTesting
Testing /QA /QA
Proceso de desarrollo de testing (IEEE829)

❖Implementación de los casos de pruebas

Software Testing /QA

Software Testing /QA
Herramientas de administración del Testing

Software Testing /QA

Software Testing /QA
 Defecto, Error y Falla

Software Testing /QA Software Testing /QA

 Definiciónde Bug
Imperfección en un componente o sistema que
puede causar que el mismo falle en desempeñar las
funciones requeridas, por ejemplo en una sentencia
o una definición de datos incorrectas.

ISTQB

Software Testing /QA Software Testing /QA

 Comparación con anomalía
según el IEEE

Anomalía: Cualquier condición que se desvíe de

las expectativas basadas en las especificaciones de
requisitos, documentos de diseño, documentos de
usuario, estándares, etc., o de la percepción o
experiencia de alguien.
Las anomalías pueden ser encontradas durante,
aunque no se limitan sólo a, revisiones, proceso de
pruebas, análisis, compilación, o uso de productos
de software o documentación aplicable.
IEEE 1044

Software Testing /QA Software Testing /QA

 Relación Defecto- Falla
• Un DEFECTO puede producir 1 o más FALLAS
• Una FALLA puede estar causada por 1 o más DEFECTOS

Software Testing /QA Software Testing /QA

 Esquema de un Bug

Ambiente de laprueba

Resultado
Esperado
Resultados
Caso de diferentes Bugs
Prueba

Resultado
Obtenido

Software Testing /QA Software Testing /QA

Impacto de un defecto
● Cambios en el código.
● Cambios en el diseño de casos de pruebas.
● Cambios en Requerimientos.
Por esto es que cuando se detecta
● Cambios en el cronograma.
un defecto lo mejor es corregirlo
lo más temprano posible.

Software Testing /QA

Software Testing /QA
Gestión de defectos
● La diferencia entre el resultado actual y el esperado, debe ser registrado como un
incidente.

● Incidente = Bug, defecto, error, issue, etc.

● Un incidente puede ser registrado en CUALQUIER punto del ciclo de vida de

desarrollo del sistema:

✓ Revisión de requerimientos
✓ Revisión de diseño
✓ Codificación
✓ Pruebas

Software
SoftwareTesting
Testing /QA /QA
Gestión de defectos
Un defecto puede ser registrado CONTRA cualquier producto dentro del ciclo de vida:

✓ Libro de requerimientos
✓ Diseño de sistemas
✓ Codigo fuente
✓ Materia de pruebas
✓ Manual de guía de usuarios

Software Testing
Software Testing /QA /QA
Gestión de defectos
❑ Todos los incidentes deben ser reportados.

❑ Los incidentes deben ser seguidos desde su descubrimiento y clasificación hasta

su corrección y confirmación de la solución.

❑ Con el fin de gestionar de forma eficaz todos los incidentes hasta su finalización, la
organización debería establecer un proceso y las normas para la clasificación.

Software
SoftwareTesting
Testing /QA /QA
 Cómo registrar bugs
1. Analizar el desvío real entre lo esperado y
lo obtenido.
2. Verificar si el defecto ya fue reportado.
3. Si existe por la misma causa, asociarlo al CP.
4. De ser nuevo, darlo de alta y asociarlo al CP.
5. Documentar e informar.
6. Asociarlo al TC correspondiente, si es q
estamos en a ejecución de una test set.

Software Testing /QA Software Testing /QA

 Cómo se comunica un bug
Ejercicio: ¿Cómo se comunica un defecto?
De la vida real:
1. Informar el defecto verbalmente al desarrollador…
2. Armar un avioncito de papel y tirárselo por la cabeza al
desarrollador…
3. Mandar un mail “bomba” con copia a todos y
prender fuego al desarrollador…
4. Formalmente a través de reportes.

Software Testing /QA

Software Testing /QA
 Reporte de un Bug

Software Testing /QA Software Testing /QA

 Reporte de un Bug
❖ El reporte de incidentes hace referencia a registrar los detalles de
cualquier incidente que se haya producido.

❖ El objetivo , documentar cada evento que haya ocurrido durante el

proceso de testing q requiera investigación.

❖ IEE829 define un template para el reporte de incidentes:

✓ Identificador del reporte de incidentes

✓ Resumen
✓ Descripción del incidente
✓ Impacto

Software Testing /QA Software Testing /QA

 Atributos de un bug
● Id: identificador único. ● Ciclo: etapa en la que fue encontrado.
● Descripción: título breve del bug.
● Status: abierto, en proceso, asignado,
● Datos: datos necesarios para ejecutar el CP y resuelto, cerrado, anulado.
obtener el bug.
● Tester: responsable que encontró el
● Tipo: de software, de datos, de ambiente, de defecto.
interconexiones, etc.
● Evidencia: print-screen, archivo o foto
● Prioridad : identifica cuál es la importancia del en donde se visualiza el bug.
bug para el negocio.
● Asignado: responsable
● Severidad: identifica cuál es la importancia del (desarrollador) que resolverá el bug.
bug de acuerdo a nuestro conocimiento del
sistema.

Software
SoftwareTesting
Testing /QA /QA
Atributos de un bug - Severidad

Software
SoftwareTesting
Testing /QA /QA
Atributos de un bug - Prioridad

Software
SoftwareTesting
Testing /QA /QA
 Planilla de B u g s
Id Bug Id Sistema Id CU Id CP Id CP Id Paso Título
Identificador Identificador Nombre Nombre Nombre Número de Nombre mnemotécnico
mnemotécnico mnemotécnico mnemotécnico mnemotécnico mnemotécnico paso del CP del bug o breve resumen
del Bug del Sistema o del CU del CP del CP
Proyecto

Descripción Status Prioridad Severidad Ciclo Evidencia (link)

Descripción que Estado(Abierto, Urgencia / importancia Alcance o grado de Ciclo de ejecución print-screen,
permita la Asignado, Resuelto, de de la correción (alta, impacto del negocio de pruebas archivo, XML, etc
reproducción del cerrado, etc) media, baja) según estrategia
bug y su resolución

Responsable Fecha Fecha estimada Área Descripción de Recha real Fecha …

Tester detectada de entrega asignad resolución entregada cierre
a

Software Testing /QA Software Testing /QA

 Seguimiento de bugs
1. Revisar backlog de defectos asignados.
2. Utilizar módulo de defectos.
3. Utilizar opciones de filtrado para revisar defectos asignados.
4. Reprobar los defectos que se encuentren resueltos.
5. Cerrar los defectos según corresponda con la evidencia pertinente.
6. Informar los defectos cerrados al líder para el correspondiente
informe de defectos.

Software Testing /QA Software Testing /QA

 Tips para registrar Bugs
✓ Deben ser concisos y precisos. ✓ Asociar el defecto al caso de prueba
(trazabilidad)

✓ Utilizar un lenguaje claro, simple, entendible. ✓ Antes de cargar un bug verificar que
no haya sido reportado.
✓ Evitar las faltas de ortografías.
✓ Ser cuidadosos en la redacción, no
usar palabras como “eso” o “la
✓ Pensar como debería reproducirlo el ventana”, porque no queda claro lo
desarrollador. que se esta viendo.

✓ El titulo del bug debe ser una única

✓ Agregar evidencia. oración. Debe describir primero el
error y después la causa.

Software
SoftwareTesting
Testing /QA /QA
 Ciclo de vida de un bug
• Los bugs tienen un inicio y un fin a lo largo del proyecto, es lo que denominamos ciclo
de vida.

• Esto esta estrechamente ligado a la herramienta de Bug Tracking seleccionada a ser

utilizada en el proyecto. Este workflow indicara cuales son las transiciones de estados
posibles de un bug.

Software Testing /QA Software Testing /QA

 Ciclo de vida de un bug C

Abierto

Anulado Enviado

Asignado

Resuelto
A Resolver
Tester BBDD Re abierto

Desarrollador Cerrado
A Resolver
Bug Manager REDES
Bajo acuerdo
F
Referente de Desarrollo de SLA, SLO

Software Testing /QA

Software Testing /QA
 Ciclo de vida de un bug - Estados

Software Testing /QA Software Testing /QA

 Causa-Raíz de un defecto
● Falta de comunicación o muy poca.
● Requerimientos poco claros y mala interpretación.
● Requerimientos cambiantes.
● Diseñar sin tener el requerimiento entendido.
● Personas obtusas o, al contrario, muy confiadas.

Software Testing /QA Software Testing /QA

 Causa-Raíz de un defecto
● Errores de programación.
● Código mal documentado.
● Herramientas de desarrollo de SW y sus versiones.
● Script de automatización obsoleto.
● Suposiciones erróneas en el desarrollo y pruebas.

Software Testing /QA

Software Testing /QA
 Causa-Raíz de un defecto
● Inestabilidad de los ambientes de pruebas.
● Introducir versiones nuevas sin cerrar la anterior.
● Falta de testers expertos.
● No capacitar al tester adecuadamente.
● Presiones de tiempo.
● No planificar coherentemente.
● No priorizar la ejecución de pruebas.

Software Testing /QA

Software Testing /QA
 Ejercicio

Realizar el hallazgo de los defectos que se encuentren en

la pantalla de búsqueda de vuelos de
[Link]

Organizar los test cases en las suites de prueba

correspondientes y ejecutarlos.
No olvidar el manejo de trazabilidad.

Software Testing /QA

Software Testing /QA
 Gestión de proyecto

❖ Se encarga de planificar todo el proceso de desarrollo del producto.

❖ Realiza un seguimiento del trabajo para que se cumplan los estándares, la agenda
definida y no se sobrepase del presupuesto.

Cuatro principios básicos → Las cuatro P

PERSONAL-PRODUCTO-PROCESO-PROYECTO

Software Testing /QA

Software Testing /QA
 Gestión de proyecto
La gestión del proceso de pruebas es necesaria para llevar cabo un proyecto
medido y controlado para cumplir los objetivos de pruebas necesarios.

Software Testing /QA

Software Testing /QA
Alcance
¿Cómo debe ser la visión del SQA Analista / Tester?

Fuente: Google

Software Testing /QA

Software Testing /QA
 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 disponemos.

● Oportuno (Time-bound):
﹣ El objetivo tiene que establecerse dentro de un marco de
tiempo oportuno.
Fuente: Google
﹣ Definir el período de tiempo para completarlo.

Software Testing /QA Software Testing /QA

 La triple restricción
¿Por qué un proyecto se hace incumplible en la realidad?

Alcance

Proyecto Alcance
de Testing

Tiempo
Costo
Fuente: Google

Software Testing /QA

Software Testing /QA
 La triple restricción extendida
¿Por qué un proyecto se hace incumplible en la realidad?

Gestión de
Proyectos

Software Testing /QA Software Testing /QA

 Proyecto según PMI

Procesos de
Iniciación
Procesos de
Planeación

Procesos de Procesos de
Control Ejecución

Procesos de
Cierre

Software Testing /QA

Proyecto según PMI

Software
SoftwareTesting
Testing /QA /QA
 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.

Software Testing /QA

Software Testing /QA
 Qué es un riesgo
✓ No todos los riesgos son igualmente importantes. La importancia
de un riesgo se define por sus características de impacto y
probabilidad.

✓ El nivel de riesgo se usa para determinar la diferencia de

importancia de los distintos riesgos.

✓ El nivel de riesgo se puede utilizar para determinar la intensidad

de las pruebas a realizar.

Software Testing /QA Software Testing /QA

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

Fuente: Google

Software Testing /QA

Software Testing /QA
Planilla de riesgos

Fuente: Google

Software Testing
Software Testing /QA /QA
 Gestion del riesgo
OBJETIVOS

✓ Proveer la mayor reducción de riesgos.

✓ Utilizar recursos disponibles.

✓ Tener el menor impacto en el plan (schedule).

✓ Definir una estrategia de pruebas mas precisa.

Software Testing /QA Software Testing /QA

 Gestión deambientes
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.

Software Testing /QA Software Testing /QA

 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.

Fuente: ISTQB

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.
Fuente: [Link]

Software Testing /QA

Software Testing /QA
 Estrategia y enfoque de pruebas

E strategia Descripción a alto nivel de los niveles de prueba

de Prueba y las pruebas asociadas.

Enfoque
Implementación de la estrategia de prueba.
de Prueba

Software Testing /QA

Software Testing /QA
 Ciclos en estrategia

Ciclo 1 Ciclo 2 Ciclo 3

● Pruebas de Humo
● Pruebas de HUMO ● Prueba de Humo
● Casos normales
● Casos Críticos ● Regresión Manual
● Casos Alternativos
● Bugs anteriores ● Casos Automatizados
● Bugs todos, Re-test

Amb. Integración Amb. UAT

Cronograma del Proyecto

Software Testing /QA

Software Testing /QA
 Especificaciones de estrategia

Niveles de Técnicas de Tipos de Objetivos de

Prueba Pruebas Pruebas Calidad

● Componentes ● Caja Blanca ● Funcionales ● Modelos

● Integración ● Caja Negra ● Performance ● Estándares
● Sistemas ● Revisiones ● UI ● Criterios
● Aceptación

Software Testing /QA

Software Testing /QA
Estimaciones
Ejemplo de Porcentajes
Estimación experta Valor promedio por fases

● Inicio 8 %
Estimación basada en analogías ● Plan 12 %
● Análisis y Diseño 25 %
● Ejecución (incluido Bugs) 45 %
Estimación basada en porcentajes ● Cierre 10 %

Proyecto en 3 meses

Inicio 8 % → 0.24 meses

Plan 12 % → 0,36 meses
Análisis y Diseño → 0.75 meses
Ejecución (incluido Bugs) → 12 meses
Cierre 10 % → 0,3 meses

Software Testing /QA

Software Testing /QA
 Ecosistema de Testing (Relación de ciclos de vida )
Ciclo de Vida del Desarrollo de Software

Recepción Analizar Generar Analizar y Testear Versionar

Codificar
Requisitos Requisitos SW Plan Diseñar CU (Unit Test) SW

Ciclo de Vida del Testing

Analizar Generar Test Diseñar Ejecutar Describir

Requisitos Informar
Plan Casos P. Casos P Bugs

Ciclo de Vida de Datos

Analizar Diseñar Crear o Convertir Compartir o Mantener o

Requisitos Seleccionar o Usar Informar Eliminar

Ciclo de Vida del Ambiente

Disponibilizar y Disponibiliza Disponibiliza Disponibilizar
Homologar r Ambiente y r Accesos y Red y Comunicar
Versión SW BBDD perfiles Servicios

Software Testing /QA Software Testing /QA

 Definición del Plan de Pruebas
• El plan de pruebas especifica todo lo que se realizará, en qué tiempo, con qué recursos,
qué y cómo se va a medir y controlar las tareas y actividades del testing.

• Documento que describe el alcance, enfoque, los recursos y cronograma de pruebas.

• Identifica, entre otros, los elementos de prueba, las prestaciones a ser probadas, las tareas de
pruebas, quien realiza cada tarea, el grado de independencia del probador, el entorno de
pruebas, las técnicas de diseño de pruebas y los criterios de entrada y salida a utilizar, y los
motivos para cada elección, y cualquier riesgo que requiera un plan de contingencia.

IEEE 829

Software Testing /QA Software Testing /QA

 Tabla de contenido
1. ID del plan de pruebas.
2. Referencias.
3. Producto a probar: Detalle del sistema y
documentación a probar.
4. Evaluación y Análisis de Riesgos.
5. Características a ser probadas.
6. Características que no serán probadas.

Software Testing /QA

Software Testing /QA
 Tabla decontenido

1. ID del plan de pruebas.

2. Referencias.
7. Estrategia y enfoque.
3. Producto a probar:
8. Criterios de Detalle del sistema
aceptación o falla. y
documentación a probar.
9. Criterios de suspensión y condiciones para
4. Evaluación y Análisis de Riesgos.
retomar.
5. Características a ser probadas.
10. Entregables: documentos a entregar.
6. Características que no
11. Actividades de serán probadas.
pruebas: documenta la
preparación y ejecución de pruebas.
12. Ambientes de pruebas.

Software Testing /QA

Software Testing /QA
 Tabla decontenido

1. ID del plan de pruebas.

2. Referencias.
7. Estrategia y enfoque.
3. Producto a probar:
8. Criterios de Detalle del sistema
aceptación y
o falla.y entrenamiento.
13. Colaboradores, apoyo
documentación a probar.
9. Criterios de suspensión y condiciones
14. Responsabilidades y roles. para
4. Evaluación y Análisis
retomar. de Riesgos.
15. Cronograma (Fases, actividades,tareas).
5. Características a ser probadas.
10. E ntregables: documentos a entregar.
16. Hitos y Aprobaciones.
6. Características que no
11. A ctividades de serán probadas.
pruebas: documenta la
17. Glosario.
preparación y ejecución de pruebas.
12. Ambientes de pruebas.

Software Testing /QA Software Testing /QA

 Completitud de pruebas
Establecer un criterio que ayude a determinar cuándo se
termina la prueba.
Se realiza en etapa de planificación:
● Por casos de pruebas.
● Por cantidad de errores estimados.
● Por cantidad de errores encontrados por unidad de tiempo.

Software Testing /QA Software Testing /QA

 Tipo de cobertura de pruebas
Establecer una medida de cuánto se ha abarcado con las pruebas.
Pueden depender de la técnica de diseño:
● Cobertura de Casos Usos (con TCs en Matriz de Req)
● Cobertura lógica (de código vía Caja Blanca)
● Cobertura funcional (vía técnicas de Caja Negra)

Software Testing /QA

Software Testing /QA
 Organigrama del área de QA / Testing
Gerente
QA/Testing Gerencia

Asegurador
KPI Manager
de Calidad

Líder
QA/Testing
Gestión

Data Tester Operación

Planificador Bug Manager QA Manager Analistas QA
Manager

Software Testing /QA

Software Testing /QA
 Qué es un KPI
Un KPI (key performance indicator), conocido también
como indicador clave o medidor de desempeño o
indicador clave de rendimiento, es una medida del
nivel del rendimiento de un proceso.

El valor del indicador está directamente relacionado

con un objetivo fijado previamente y normalmente
se expresa en valores porcentuales.

Software Testing /QA

Software Testing /QA
 Gestión de KPI
Pasos para generar Indicadores de Gestión.

Recopilación Agrupamiento
Cálculo de
de las tareas y Clasificación Comparativas Informes
Indicadores
realizadas de datos

Software Testing /QA

Software Testing /QA
Ejemplos de KPI

Software
SoftwareTesting
Testing /QA /QA
 Otros informes
● Distribución de tipos de defecto.
● Tiempo promedio del defecto.
● Avance de las pruebas.
● Cobertura de la ejecución del Test Plan.
● Número de defectos vs. defectos corregidos.

Software Testing /QA Software Testing /QA

Revisión

Repase
● Los puntos visto en la clase.

Realice
● Las preguntas necesarias al o la docente antes
de continuar.
● Realice los ejercicios de la práctica.

Software Testing /QA

¿Preguntas?graci
as!
¡Sigamos trabajando!

Software Testing /QA

Muchas gracias!!!
gracias!
¡Sigamos trabajando!

Software Testing /QA