Pruebas Sistemas

CLASE # 9
EJECUCIÓN DE
PRUEBAS
750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE

INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
UNIVERSIDAD DEL VALLE
SEMESTRE 2013A - 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
2013 – EISC - TECNICAS 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.
 Definición de ambiente para pruebas no-
funcionales
Iteraciones Pruebas Seguimiento / Control /

Retroalimentación
 Ejecución de requerimientos de pruebas
 Registro de hallazgos de NC
 Calculo de indicadores de producto
 Reproceso de NC
 Informe avance proceso pruebas
 Ejecución de scripts para pruebas
 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.
 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.
 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:
 Pruebas de Rendimiento
 Pruebas de Seguridad
 Pruebas de Compatibilidad
 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
• 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.
 Relevancia de las funcionalidades del negocio.
 Estabilidad del componente de software: Para la primera iteración de

pruebas implica ejecución de todos los requerimientos.
 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.


• 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 Matriz de Requerimientos de Prueba (MRP)
Una condición o aspecto • Proceso o funcionalidad a probar

particular que requiere ser • Identificador del requerimiento de prueba
verificado o probado sobre una • Pasos o descripción del requerimiento de prueba
unidad o conjunto de unidades • Datos de entrada o elemento a probar
de software desarrolladas o • Resultado esperado
modificadas, para garantizar • Iteración de la prueba
que éstas se incorporan al • Observaciones: Precondiciones, pos-condiciones,
producto con calidad y cumplen requisitos.
con las especificaciones • Versión
pactadas con el usuario o el
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.
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.
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
 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.
 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
 Se presenta cuando al ejecutar un programa sus resultados no corresponden al
resultado esperado.
 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
 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

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
 “SIGUE EL ERROR EN EL SCROLL, EL CAMBIO QUE HICIERON NO ERA EL

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

Reporte de No Conformidades
• Una de las actividades mas 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
 Estadísticas
 Indicadores
• Uso de medios para Difusión de Resultados

 Carteleras
 Intranet
 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ó hoy en su tarea.
Retroalimentación
• Haga un análisis de indicadores de ejecución de pruebas
para el ejercicio anterior.

Pruebas Sistemas

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Pruebas Sistemas

Caricato da

Copyright:

Formati disponibili

CLASE # 9

750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE

Basado parcialmente en material de la empresa GreenSQA S.A

 Generalidades de la fase de ejecución de pruebas

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 2

Iteraciones Pruebas Seguimiento / Control /

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 4

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

• Reportar los hallazgos y asegurar su corrección por

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 5

• Mantenimiento: Actualización de funcionalidades a

• Pruebas funcionales: Aplica para los diferentes tipos de

2013 – EISC - TECNICAS 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 producción para la ejecución de

2013 – EISC - TECNICAS 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 acuerdos de nivel de servicio

• Realizar seguimiento y control al plan de proyecto

2013 – EISC - TECNICAS 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, que

• Analizar información de causa de no conformidades y realizar

2013 – EISC - TECNICAS 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.

• Identificar acciones de mejora que minimicen la aparición de NC

• Almacenar la información de acuerdo al plan de almacenamiento definido

• Retroalimentar al líder de pruebas sobre el avance en la ejecución de

2013 – EISC - TECNICAS 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

 Relevancia de las funcionalidades del negocio.

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

 Para iteraciones posteriores, se selecciona un subconjunto de

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 12

Selección de Requerimientos a Ejecutar

Una condición o aspecto • Proceso o funcionalidad a probar

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 13

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 14

2013 – EISC - TECNICAS 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

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 16

2013 – EISC - TECNICAS 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

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

2013 – EISC - TECNICAS 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

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 19

• Cuando la aplicación es completamente nueva, se

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 20

2013 – EISC - TECNICAS DE PRUEBAS DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 21

• Ejecutar en el software los requerimientos de