2017A EjecucionReporteDePruebas

EJECUCIÓN Y
REPORTE DE
PRUEBAS
FUNCIONALES Y
NO-FUNCIONALES
TÉCNICAS DE PRUEBAS DE SOFTWARE
INGENIERÍA DE SISTEMAS
UNIVERSIDAD DEL VALLE
DOCENTE BEATRIZ FLORIAN GAVIRIA
Basado parcialmente en material de la empresa GreenSQA S.A
AGENDA
§  Generalidades de la fase de ejecución de pruebas

§  Definición de iteración
§  Preparación del ambiente de pruebas
§  Ejecución de pruebas por iteraciones
§  Reporte de hallazgos
§  Retroalimentación
§  Actividad práctica
EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 2

GENERALIDADES
DE LA FASE DE
EJECUCIÓN DE
PRUEBAS
FASE EJECUCIÓN DE PRUEBAS
Preparación de ambiente
§  Definición de ambiente controlado para
pruebas funcionales. (Fichas Técnicas)
§  Definición de ambiente para pruebas no-
funcionales (Fichas Técnicas)
Iteraciones Pruebas Seguimiento / Control /

Retroalimentación
§  Ejecución de requerimientos de pruebas
§  Ejecución de scripts para pruebas §  Calculo de indicadores de producto
§  Registro de hallazgos de NC §  Informe avance proceso pruebas
§  Reproceso de NC §  Informe cierre pruebas funcionales
§  Análisis de resultados de pruebas
§  Informe cierre pruebas no-funcionales

PROPÓSITO
•  Ejecución de pruebas mediante la definición de las

actividades requeridas para ejecutar los requerimientos de
pruebas identificados en la fase de diseño de pruebas.
q  La fase de ejecución de pruebas se realiza por iteraciones

de pruebas. (Total o un subconjunto de los requerimientos
de pruebas).
•  Reportar los hallazgos y asegurar su corrección por parte

del equipo de desarrollo de software.
q  En cada iteración de pruebas se registran los hallazgos o

No Conformidades (NC) de software.

ALCANCE
•  Nuevos productos
•  Mantenimiento: Actualización de funcionalidades a

productos
•  Pruebas funcionales: Aplica para los diferentes tipos de

pruebas dinámicas de software.
•  Pruebas no-funcionales:
q  Pruebas de Rendimiento

q  Pruebas de Seguridad
q  Pruebas de Compatibilidad
q  Pruebas de Usabilidad.

RESPONSABILIDADES EN EJECUCIÓN
Cliente de pruebas
•  Brindar un ambiente de pruebas controlado.
•  Gestionar las mejoras de procesos identificadas por el equipo de

pruebas.
•  Apoyar el cumplimiento de los acuerdos de nivel de servicio

previamente establecido.
•  Apoyar la gestión de datos de

producción para la ejecución
de pruebas.

Gerente de pruebas de software

•  Comunicar a los gerentes de proyecto los cambios metodológicos
vigentes en el proceso de pruebas
•  Gestionar los recursos necesarios para la ejecución de pruebas
•  Definir y hacer cumplir los

acuerdos de nivel de servicio
•  Realizar seguimiento y
control al plan de proyecto

Líder de pruebas de software

•  Velar por un ambiente de pruebas controlado.
•  La gestión de las actividades definidas en los procedimientos de

ejecución de pruebas.
•  Presentación a la gerencia de pruebas de informes parciales,

que permiten verificar el seguimiento
del proceso.
•  Analizar información de causa de no

conformidades y realizar informes.

Ingeniero de Pruebas de software

•  Seleccionar los requerimientos de pruebas a ejecutar en cada iteración.
•  Registrar las no conformidades identificadas.
•  Ejecutar las actividades de pruebas definidas en el plan de pruebas.
•  Reportar los hallazgos en las herramientas definidas.
•  Calcular los indicadores de pruebas por funcionalidad.

•  Identificar acciones de mejora que minimicen la
aparición de NC.
•  Almacenar la información de acuerdo al plan de

almacenamiento definido en el plan de pruebas.
•  Retroalimentar al líder de pruebas sobre

el avance en la ejecución de pruebas.
DEFINICIÓN DE
ITERACIÓN

DEFINICIÓN DE ITERACIÓN
Selección de Requerimientos a Ejecutar
•  Estrategia de ejecución definida en el plan: De acuerdo al alcance y

secuencia de entregas definida en el cronograma de desarrollo de
software.
q Relevancia de las funcionalidades del negocio.
q Estabilidad del componente de software: Para la primera iteración de

pruebas implica ejecución de todos los requerimientos.
q Para iteraciones posteriores, se selecciona un subconjunto de

requerimientos de pruebas de acuerdo a la estabilidad funcional
determinada por la medición de los indicadores de calidad.
q Lo determinado por el backlog priorizado (metodologías ágiles)


•  Tipo de prueba a ejecutar: De acuerdo al tipo de pruebas a ejecutar,
se seleccionan los requerimientos de pruebas registrados en el
Matriz de Requerimientos de Prueba (MRP)
Requerimiento de prueba (RP) Matriz de Requerimientos de Prueba (MRP)
Una condición o aspecto •  Procesos o funcionalidades a probar (1 fila x RP)

particular que requiere ser q  Identificador del requerimiento de prueba
verificado o probado sobre una q  Pasos o descripción del requerimiento de
unidad o conjunto de unidades prueba
de software desarrolladas o q  Datos de entrada o elemento a probar
modificadas, para garantizar q  Resultado esperado
que éstas se incorporan al q  Iteración de la prueba
producto con calidad y cumplen q  Observaciones: Precondiciones, pos-
con las especificaciones condiciones, requisitos.
pactadas con el usuario o el q  Versión
alcance definido para dicha
funcionalidad

GENERALIDAD DEL DISEÑO DE CASOS DE PRUEBAS
Requerimiento de Prueba


•  Para productos en mantenimiento: Requerimientos

diseñados para probar la funcionalidad que se actualiza +
el impacto funcional sobre otras funcionalidades.
•  Es necesario programar un conjunto de pruebas de

sistema de los procesos posiblemente impactados.
(Pruebas de regresión sobre el SW)

PREPARACIÓN DE
AMBIENTE DE
PRUEBAS

PREPARACIÓN DE AMBIENTE DE PRUEBAS
Utilizando la Ficha Técnica (FT) de producto:

•  Especificación de la configuración de máquinas (clientes
y servidores) en que se ejecutarán las pruebas; el
sistema operativo, browser y configuración TCP/IP .
•  Especificación del software de sistema y de apoyo a la

prueba, motor de base de datos, maquinas virtuales,
servidor web, simuladores.
q Instancia de Software Independiente: (Aplicación y Base

de Datos). El acceso exclusivo para el equipo de pruebas
de software.

PREPARACIÓN DE AMBIENTE DE PRUEBAS
•  Hardware necesario para las pruebas: Procesador,

memoria, disco duro, dispositivos de multimedia,
impresora, etc.
q Especificación de recursos especiales requeridos: Dispositivos
móviles, lectores de barras, PDA´s, monitores touch.
•  Sistema de gestión de configuración: práctica estándar de

gestión de configuración, que permita mantener
controlado el ambiente de pruebas y el paso de los
objetos probados al ambiente de producción.

GENERACIÓN DE DATOS DE PRUEBAS
Datos de Pruebas:
•  Datos de producción .
•  Datos generados.
•  Datos capturados.
•  Datos creados manualmente.
•  Datos aleatorios (útiles en pruebas de estrés y carga)
•  Cuando la aplicación es completamente nueva, se

ejecutan las pruebas en la secuencia necesaria para
hacer manualmente la carga inicial de datos, en caso
contrario, se tratará de reutilizar datos de un cliente en
operación, es decir datos de producción.

EJECUCIÓN DE
PRUEBAS

EJECUCIÓN DE PRUEBAS
•  Ejecutar en el software los requerimientos de

pruebas seleccionados
•  HH (costo) invertido en la ejecución y la cantidad de
hallazgos.
Clasificación (severidad) de No Conformidades

•  Bloqueantes
q  Es el tipo de no conformidad que detiene la operación de un programa / componente
o hace que este arroje resultados que impiden la continuidad de la operación del
cliente.
q  Ejemplos de este tipo son:
§  Al ejecutar un proceso se muestra un mensaje de error que indica que no
puede continuar.
§  Al ejecutar el programa se cierra la sesión.
§  Al ejecutar el programa se bloquea la aplicación.
•  Funcionales
q  Se presenta cuando al ejecutar un programa sus resultados no corresponden al
resultado esperado.
q  Ejemplos de este tipo son:
§  No realiza validaciones necesarias, o ejecuta validaciones innecesarias.
§  El total de un reporte no corresponde a la suma de los valores relacionados.
•  Presentación
q  Son no conformidades relacionadas con la presentación del programa, estos deben
ajustarse a los estándares definidos y con las reglas gramaticales y ortográficas del
idioma en que es presentado el programa.

El resultado real de ejecución debe cumplir con

dos características fundamentales que permiten
evidenciar su cumplimiento:
•  La correctitud: exactitud de los resultados reales vs los

esperados.
•  La completitud: cobertura de los resultados reales vs los

esperados.

Criterio de Cierre de Iteración de Pruebas
• El criterio de cierre de una iteración,

corresponde a la ejecución todos aquellos
requerimientos de prueba planeados y que no
se afectan por la identificación de No
conformidades funcionales o incumplimientos
en la entrega de los grupos de desarrollo.

REPORTE DE
HALLAZGOS

REPORTE DE HALLAZGOS
Análisis
•  Analizar los resultados obtenidos en la prueba versus los
resultados esperados , con base en lo cual determinaran
la presencia de ‘no conformidades’.
Tener en cuenta previamente:

•  Los datos de prueba,
•  La ejecución de los pasos de la prueba
•  El ambiente de pruebas
•  La definición del requerimiento de prueba

OJO con la mala redacción en el reporte de las no conformidades:
No Conformidades “Agresivas”
•  “No es lógico crear un grupo vacío, se debe colocar una validación de
algunos campos requeridos en la creación”
•  “No se encuentra aún el sentido para el perfil dependencia, actualmente sólo
puede entrar, cerrar sesión y cambiar el perfil a otro. El calendario como
actuaría en este perfil?”
No Conformidades “Preguntas”
•  “Hola PEPITO este tipo de etiquetas aparecen en el diccionario sobre e-mail.
Qué tipo de información publico? Email.feedingAlarm.FailText
Email.StateAlarm.Yellow Y muchas más... Qué texto pongo?”
•  “Como agregarle la función y/o icono del calendario a un campo de la
forma.”

Mala redacción en el reporte de las no conformidades:
•  No Conformidades Incompletas
q “SIGUE EL ERROR EN EL SCROLL, EL CAMBIO QUE HICIERON NO ERA

EL QUE YO MANDE EN EL ARCHIVO...... REVÍSENLO POR FAVOR ”
q “La forma que esta bien es la segunda y al comparar esta información con la
primera no concuerdan.”
q “Se registran errores en los resultados”
q “Hay error de carga de pagina.”

Reporte de No Conformidades
•  Una de las actividades más importantes y comunes que hace un Ingeniero
de Pruebas es reportar “no conformidades” y la forma como se reporta afecta
directamente la forma en que ésta será corregida por el Desarrollador.
•  La estructura para la redacción de las No Conformidades debe considerar de
manera explícita los siguientes elementos:
Funcionalidad, forma, plantilla, API o

Dónde? unidad de software
Condiciones mediante las cuales se
Cuándo? originó la No Conformidad
Lo que se vio en realidad sin
ambigüedad con captura de pantalla
No conformidad
Hallazgo Clasificación
Log generado (si aplica)
Lo que se esperaba ver. “Se espera

Se espera que ..”

Ejemplo - Reporte de No Conformidades
•  “GENERAL/ADMON DE USUARIOS/USUARIO: Cuando se está almacenando un

usuario y el sistema encuentra que faltan datos muestra el mensaje: "Se encontraron
caracteres no válidos" y borra los datos que se ingresaron en clave, confirmar clave y
activo/Inactivo. Se espera que el sistema muestre los datos ingresados hasta que se
complete la operación exitosamente.”
DONDE: GENERAL/ADMON DE USUARIOS/USUARIO

CUANDO: Al almacenar un usuario y el sistema encuentra que faltan datos muestra el
mensaje: "Se encontraron caracteres no válidos"
HALLAZGOS: El sistema borra los datos que se ingresaron en los campos clave y confirmar
clave.
SE ESPERA: Que el sistema muestre los datos que se ingresaron hasta que se complete la
operación exitosamente

Registro de Ejecución de Requerimientos de Pruebas
•  Ok, si el requerimiento se ejecuto de manera normal.
•  NoK, si se generó una no conformidad.
•  PTE ENT, si el requerimiento no se pudo ejecutar debido a la entrega

incompleta del release.
•  PTE_NC, si el requerimiento no se pudo ejecutar por la identificación de NC

previas.
•  N/A, en caso que el requerimiento ya no aplique para la funcionalidad a

probar.

Resumen de ejecución de la Iteración:
1ra. Iteración
Total NC Total NC Total NC Total Reqs Prueba Reqs Prueba Reqs Pendientes por
Total NC Reqs Prueba con fallos Reqs Prueba OK
Bloqueantes Funcionales Presentación Diseñados Ejecutados ejecutar
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0 0 0 0 0 0 0

Causales en las No Conformidades

•  Análisis: Se evidencia problemas de completitud y alcance funcional
de un requerimiento.
•  Diseño: Relacionada con el modelo de BD, interfaz gráfica,

arquitectura del producto.
•  Desarrollo: Causados por la codificación del producto.
•  Gestión Configuración: actualizaciones del ambiente de pruebas o

con los objetos empaquetados en el instalador del producto.
•  Documentación: Coherencia en documentación técnica y funcional

del producto.
RETROALIMENTACIÓN
DEL PROCESO

RETROALIMENTACIÓN DEL PROCESO DE PRUEBAS
Retroalimentación realizada por Iteración y al final del

proceso.
•  Informes de Pruebas
q Estadísticas
q Indicadores
•  Uso de medios para Difusión de Resultados

q Carteleras
q Intranet
q Mails

Información de No Conformidades: Informe estadístico de

clasificación de las no conformidades: Severidad, Componente
Funcional, Causa, Estado.
Información del Proceso de Pruebas: Informe que permita resaltar o

identificar oportunidades de mejora sobre el proceso de pruebas: uso
de herramientas, desviaciones de tiempos, reutilización de diseño de
pruebas, uso de técnicas de diseño de pruebas.
Información de Mejora de Procesos: A partir del análisis de las

causas de las no conformidades, se identifican las acciones de mejora
necesarias para evitar futuras no conformidades por la misma causa.

Indicadores de Producto
• Correctitud: Permite identificar que porcentaje de las funcionalidades
evaluadas se comportan correctamente de acuerdo al resultado esperado
A: Funcionalidades con no conformidades en la evaluación

B: Total de funcionalidades evaluadas
Correctitud = 1-A/B
• Completitud en desarrollo: Permite identificar el porcentaje de

funcionalidades implementadas por el grupo de desarrollo y listas para ser
validadas por el grupo de aseguramiento de calidad.
A: Funcionalidades faltantes por desarrollar

B: Total de funcionalidades descritas en MDF
Completitud en desarrollo= 1- A/B

Densidad de NC: Permite identificar la razón de no conformidades

identificadas por requerimiento ejecutado en la actividad de pruebas.
A: No conformidades
B: Requerimientos ejecutados
Densidad NC = A/B
*Nota: Se deben excluir las NC anuladas.
Confiabilidad: Permite identificar el porcentaje de confiabilidad del

producto basado en la densidad de NC encontrada en cada iteración de
pruebas.
Confiabilidad= (1 - Densidad NC)*100


Indicadores de Proyecto
•  Desviación de tiempo de planeación
•  Desviación de esfuerzo en planeación
•  Avance total del proceso
•  Eficiencia en el diseño de pruebas
•  Reproceso
•  Eficacia en las pruebas
•  Impacto en detección de No Conformidades

PRÁCTICA

PRÁCTICA
Reporte de hallazgos
•  Haga la simulación de un reporte de posibles hallazgos
de no conformidades utilizando los diseños de pruebas
que entregó en sus tareas o sustentaciones.
Retroalimentación
•  Haga un análisis de indicadores de ejecución de pruebas
para el ejercicio anterior.

2017A EjecucionReporteDePruebas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

2017A EjecucionReporteDePruebas

Cargado por

Copyright:

Formatos disponibles

EJECUCIÓN Y

§ Generalidades de la fase de ejecución de pruebas

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 2

Iteraciones Pruebas Seguimiento / Control /

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 4

• Ejecución de pruebas mediante la definición de las

q La fase de ejecución de pruebas se realiza por iteraciones

• Reportar los hallazgos y asegurar su corrección por parte

q En cada iteración de pruebas se registran los hallazgos o

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 5

• Mantenimiento: Actualización de funcionalidades a

• Pruebas funcionales: Aplica para los diferentes tipos de

q Pruebas de Rendimiento

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 6

• Gestionar las mejoras de procesos identificadas por el equipo de

• Apoyar el cumplimiento de los acuerdos de nivel de servicio

• Apoyar la gestión de datos de

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 7

Gerente de pruebas de software

• Gestionar los recursos necesarios para la ejecución de pruebas

• Definir y hacer cumplir los

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 8

Líder de pruebas de software

• La gestión de las actividades definidas en los procedimientos de

• Presentación a la gerencia de pruebas de informes parciales,

• Analizar información de causa de no

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 9

Ingeniero de Pruebas de software

• Registrar las no conformidades identificadas.

• Ejecutar las actividades de pruebas definidas en el plan de pruebas.

• Reportar los hallazgos en las herramientas definidas.

• Calcular los indicadores de pruebas por funcionalidad.

• Almacenar la información de acuerdo al plan de

• Retroalimentar al líder de pruebas sobre

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 11

Selección de Requerimientos a Ejecutar

• Estrategia de ejecución definida en el plan: De acuerdo al alcance y

q Relevancia de las funcionalidades del negocio.

q Estabilidad del componente de software: Para la primera iteración de

q Para iteraciones posteriores, se selecciona un subconjunto de

q Lo determinado por el backlog priorizado (metodologías ágiles)

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 12

Selección de Requerimientos a Ejecutar

Una condición o aspecto • Procesos o funcionalidades a probar (1 fila x RP)

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 13

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 14

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 15

Selección de Requerimientos a Ejecutar

• Para productos en mantenimiento: Requerimientos

• Es necesario programar un conjunto de pruebas de

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 16

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 17

Utilizando la Ficha Técnica (FT) de producto:

• Especificación del software de sistema y de apoyo a la

q Instancia de Software Independiente: (Aplicación y Base

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 18

• Hardware necesario para las pruebas: Procesador,

• Sistema de gestión de configuración: práctica estándar de

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 19

• Cuando la aplicación es completamente nueva, se

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 20

EISC - TÉCNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 21

• Ejecutar en el software los requerimientos de

§  Generalidades de la fase de ejecución de pruebas

•  Ejecución de pruebas mediante la definición de las

q  La fase de ejecución de pruebas se realiza por iteraciones

•  Reportar los hallazgos y asegurar su corrección por parte

q  En cada iteración de pruebas se registran los hallazgos o

•  Mantenimiento: Actualización de funcionalidades a

•  Pruebas funcionales: Aplica para los diferentes tipos de

q  Pruebas de Rendimiento

•  Gestionar las mejoras de procesos identificadas por el equipo de

•  Apoyar el cumplimiento de los acuerdos de nivel de servicio

•  Apoyar la gestión de datos de

•  Gestionar los recursos necesarios para la ejecución de pruebas

•  Definir y hacer cumplir los

•  La gestión de las actividades definidas en los procedimientos de

•  Presentación a la gerencia de pruebas de informes parciales,

•  Analizar información de causa de no

•  Registrar las no conformidades identificadas.

•  Ejecutar las actividades de pruebas definidas en el plan de pruebas.

•  Reportar los hallazgos en las herramientas definidas.

•  Calcular los indicadores de pruebas por funcionalidad.

•  Almacenar la información de acuerdo al plan de

•  Retroalimentar al líder de pruebas sobre

•  Estrategia de ejecución definida en el plan: De acuerdo al alcance y

q Relevancia de las funcionalidades del negocio.

q Estabilidad del componente de software: Para la primera iteración de

q Para iteraciones posteriores, se selecciona un subconjunto de

q Lo determinado por el backlog priorizado (metodologías ágiles)

Una condición o aspecto •  Procesos o funcionalidades a probar (1 fila x RP)

•  Para productos en mantenimiento: Requerimientos

•  Es necesario programar un conjunto de pruebas de

•  Especificación del software de sistema y de apoyo a la

q Instancia de Software Independiente: (Aplicación y Base

•  Hardware necesario para las pruebas: Procesador,

•  Sistema de gestión de configuración: práctica estándar de

•  Cuando la aplicación es completamente nueva, se

•  Ejecutar en el software los requerimientos de

•  La correctitud: exactitud de los resultados reales vs los

•  La completitud: cobertura de los resultados reales vs los

• El criterio de cierre de una iteración,

q “SIGUE EL ERROR EN EL SCROLL, EL CAMBIO QUE HICIERON NO ERA

q “Se registran errores en los resultados”

q “Hay error de carga de pagina.”

•  “GENERAL/ADMON DE USUARIOS/USUARIO: Cuando se está almacenando un

•  Ok, si el requerimiento se ejecuto de manera normal.

•  NoK, si se generó una no conformidad.

•  PTE ENT, si el requerimiento no se pudo ejecutar debido a la entrega

•  PTE_NC, si el requerimiento no se pudo ejecutar por la identificación de NC

•  N/A, en caso que el requerimiento ya no aplique para la funcionalidad a

•  Diseño: Relacionada con el modelo de BD, interfaz gráfica,

•  Desarrollo: Causados por la codificación del producto.

•  Gestión Configuración: actualizaciones del ambiente de pruebas o

•  Documentación: Coherencia en documentación técnica y funcional

•  Uso de medios para Difusión de Resultados

• Completitud en desarrollo: Permite identificar el porcentaje de