PROCESO BÁSICO DE Unidad 1. Introd.

a las pruebas de Software

PRUEBAS
Pruebas y Validación
de SW
Unidad 1
1.3 Proceso básico de pruebas.
Repetición de pruebas: Pruebas que
ejecutan los casos de prueba que
fallaron la última vez que se
ejecutaron, con el fin de verificar el
éxito de las acciones correctivas.
 Criterios de salida: El conjunto de
condiciones genéricas y específicas, acordadas
con los interesados del negocio, para permitir
que un proceso sea finalizado oficialmente. El
propósito de los criterios de salida es prevenir
que una tarea sea considerada por finalizada
cuando todavía hay partes pendientes de la
tarea que no han sido finalizadas. Los criterios
de salida se utilizan para planificar e informar
contra la cesación de las pruebas.
 z
Incidencia: Cualquier evento que
ocurre y necesita investigación.

Pruebas de regresión: Pruebas de un programa

previamente probado a raíz de una modificación
para garantizar qué defectos no han sido
introducidos o descubiertos en áreas no
modificadas del software, como resultado de los
cambios realizados. Se realizan cuando el
software o su entorno son modificados
Base de prueba: Todos los
documentos de los cuales los
requisitos de un componente o
sistema pueden ser deducidos. La
documentación acerca de la cual los
casos de prueba se basan.
 Condición de prueba: Un ítem o evento de un
componente o sistema que pudiera ser verificado por
uno o más casos de prueba, p.ej., una función,
transacción, característica, atributo de calidad o un
elemento estructural.
 Cobertura:
z

El grado, expresado como porcentaje, hasta

el cual, un ítem de cobertura especificado
ha sido ejercido por un juego de pruebas.
Tenga en cuenta que este término no ha
sido referenciado específicamente en esta
sección, pero se lo incluye aquí, porque es
un sinónimo de cobertura de pruebas.

Datos de prueba: Datos que existen (por

ejemplo, en una base de datos) antes que una
prueba sea ejecutada, y que afectan al
componente o sistema sometido a pruebas o son
afectados por estos.
Ejecución de pruebas: El proceso de ejecución de
una prueba en el componente o sistema sometido a
pruebas, produciendo resultado(s) real(es).
Registro de pruebas: Un registro cronológico de
detalles relevantes acerca de la ejecución de las
pruebas.
Plan de pruebas: Un documento que describe el
alcance, el método, los recursos y el cronograma de
las actividades de pruebas.
Política de pruebas: Un documento de alto
nivel que describe los principios, métodos y
objetivos principales de la organización con
respecto a las pruebas.

Estrategia de pruebas: Una descripción de

alto nivel de los niveles de pruebas que
deben ser realizados y las pruebas en esos
niveles para una organización o programa
(uno o más proyectos).
Informe del resumen de pruebas: Un documento
que resume las actividades de las pruebas y los
resultados. También contiene una evaluación de
los ítems de las pruebas correspondientes contra
los criterios de salida.

Testware: Artefactos producidos durante el

proceso de pruebas necesarios para planificar,
diseñar y ejecutar las pruebas, así como la
documentación, los guiones, las entradas, los
resultados esperados, los procedimientos.
Procesos críticos de las pruebas
Procesos básicos de las pruebas
Procesos básicos de las pruebas
 z
PLANIFICACIÓN DE LA PRUEBAS
.

 Determinar el alcance de las pruebas, los riesgos, los

objetivos y las estrategias
Determinar los recursos de las pruebas
necesarios. Implementar las estrategias de
las pruebas.
Crear un cronograma del análisis y el
diseño de las pruebas.
Crear un cronograma de la implementación, la
ejecución y la evaluación de las pruebas.
Determinar los criterios de salida de las
pruebas.
 z
EL CONTROL INCLUYE LAS SIGUIENTES
ACTIVIDADES:

Medir y analizar los resultados.

Monitorear y documentar el progreso, la

cobertura y los criterios de salida de las
pruebas.
Iniciar acciones correctivas
Tomar decisiones

Tenga en cuenta que muchas actividades de planificación y

control implican la obtención del acuerdo, el soporte y el
consenso del equipo del proyecto y la gerencia del
proyecto.
 z
EL ANÁLISIS INCLUYE LAS
SIGUIENTES ACTIVIDADES:

 Revisar la base de pruebas. La base de pruebas es

aquella en la cual las pruebas se basan, con
frecuencia, incluyendo los requisitos o las
especificaciones de diseño, las arquitecturas de red o
sistema o los riesgos de calidad.
 Identificar y priorizar las condiciones de pruebas, los
requisitos de pruebas o los objetivos de pruebas y los
datos de prueba necesarios.
 Evaluar la comprobabilidad (“testability”) de los
requisitos y el sistema.
 z
EL DISEÑO INCLUYE LAS
SIGUIENTES ACTIVIDADES:

 Diseñar y priorizar combinaciones específicas

de datos de prueba, acciones y resultados
esperados para cubrir la base de pruebas, los
riesgos importantes de calidad, y cualquier otra
cosa que necesite cobertura.
 Identificar los datos de prueba
necesarios para las condiciones y los
casos de prueba.
 Diseñar el entorno de pruebas.
 Identificaralguna infraestructura y algunas
herramientas necesarias
 z
LA IMPLEMENTACIÓN INCLUYE
LAS SIGUIENTES ACTIVIDADES:

Desarrollar, implementar y priorizar casos de

prueba, crear datos de prueba y escribir
procedimientos de prueba.
Preparar arneses de prueba y escribir scripts de
pruebas automatizadas.
Organizar juegos de prueba y secuencias de
procedimientos de prueba para la ejecución eficiente
de las pruebas, teniendo en cuenta las diversas
restricciones que podrían determinar el orden en el
cual las pruebas deben ser ejecutadas.
Verificar que el entorno de pruebas ha sido instalado
correctamente.
 z
LA EJECUCIÓN INCLUYE LAS
SIGUIENTES ACTIVIDADES:

Ejecutar casos de prueba tanto manuales

Registrar los resultados de las pruebas, incluyendo las
versiones del software sometido a pruebas, las
herramientas de pruebas y el testware.
Comparar los resultados reales y esperados, lo cual
podría requerir la identificación de anomalías donde los
resultados reales y esperados no coinciden.
La investigación de anomalías puede resultar en la
creación de informes y el análisis de las incidencias.
Repetir las pruebas corregidas y/o actualizadas donde
sea necesario.
Ejecutar las pruebas de confirmación y/o regresión,
cuando las nuevas versiones lleguen
 z

CIERRE
 La evaluación de los criterios de salida y la creación de
informes de los resultados de las pruebas están fuertemente
superpuestas con la ejecución de las pruebas, las cuales
consisten principalmente en actividades de gestión de
actividades de gestión, incluyendo las siguientes:
 Evaluar si son necesarias más pruebas o si los criterios de salida
especificados deben ser modificados.
 Escribir un informe del resumen de las pruebas para los
interesados del negocio.
 Comprobar los registros de las pruebas contra los criterios de salida de
las pruebas especificados durante la planificación de pruebas.
 z

ACTIVIDADES DEL CIERRE

 Confirmar los entregables de pruebas, la resolución

final o postergación de los informes de defectos y la

aceptación del sistema por las partes que lo reciben.
 Finalizar y archivar el testware, el entorno de
pruebas y la infraestructura de pruebas para su
uso posterior durante el mantenimiento.
Entregar el testware y la posibilidad de ítems
adicionales a la organización de mantenimiento
 Realizar un estudio retrospectivo para tomar en
cuenta las mejoras para las futuras versiones
 EQUIPOS-PRÁCTICA 2

• EQUIPO 1- ALEJANDRO CORREA-Casos de prueba, Plan de prueba –(Erick-Casos

de uso, Rafael-Requerimientos func, Roberto-Interfaces y Arquit)
• EQUIPO 2- EMILIANO RIVAK-Casos de uso(Jesús Ivan-Interfaz, Juan Pedro-BD,
Johan-Plan de pruebas)
• EQUIPO 3- JAVIER Casos de uso(Fernando-plan de pruebas,Ian-Doc Requeri,
Ernesto-Diseño interfaz)
• EQUIPO 4-DIEGO Casos de Prueba y Plan de prueba(Mario-Req y Casos de uso,
Toño-Requer y casos de uso, Mauricio-Diseño de interfaces, Axel-Diseño de
interfaces)
• EQUIPO 5- EMILIO-Plan de pruebas(Yamir-casos de uso, Vladimir-casos de uso,
Farid-Formato de prueba)
• EQUIPO 6- IRVING BDatos –B(Paco-Casos de uso-interfaz, Sandra-Requer, Dany-
Arquit, Mauritania-Diseño de pruebas)
• EQUIPO 7 –VIRIDIANA Historias de usuario- (Abi-Plan de pruebas, Jorge-Casos
de uso, Orlando-Interfaz)
1.4 Ética de las pruebas
 EL PÚBLICO - Los probadores de software certificados
deberían actuar coherentemente con el interés del público.

Por ejemplo, si está trabajando en un sistema de seguridad crítica y

se le pide silenciosamente que cancele algunos informes de los
defectos, ése es un problema ético.
EL CLIENTE Y EMPLEADOR - Los probadores de
software certificados deberían actuar de una manera
que es en el mejor interés de su cliente y empleador,
y de conformidad con el interés público.

Por ejemplo, si sabe que el proyecto principal de su

empleador está con problemas, y usted vende la acción
a bajo precio entonces se escapa información acerca de
los problemas del proyecto a Internet, esto es una real
falta ética—y también probablemente un delito.
EL PRODUCTO - Los probadores deberían
asegurar que los entregables que ellos
proporcionan (acerca de los productos y los
sistemas que ellos prueban), cumplan con los más
altos estándares posibles.

Por ejemplo, si está trabajando como un consultor y

deja afuera detalles importantes de un plan de pruebas
de tal forma que el cliente tiene que contratarlo en el
próximo proyecto, eso es una falta ética.
 EL JUICIO - Los probadores de
software certificados deberían mantener
la integridad e independencia en su
juicio profesional.

Por ejemplo, si un jefe de proyecto le pide no informar

acerca de los defectos en ciertas áreas por temor a las
reacciones potenciales de los inversores del negocio,
eso es un golpe a su independencia y un fracaso ético de
su parte si usted accede a su pedido.
LA GESTIÓN - Los jefes y líderes de
pruebas de software certificados
suscribirán y promoverán un método ético
para la gestión de las pruebas de
software.

LA PROFESIÓN - Los probadores de software

certificados deberían promover la integridad y
reputación de la profesión en conformidad con el
interés público.
 LOS COLEGAS - Los probadores de software
certificados deberían ser justos con sus colegas
además de ser de gran ayuda para ellos y promover
la cooperación con los desarrolladores de software.

Por ejemplo, no es ético manipular los resultados de las

pruebas para acordar el despido de un programador a
quién usted deteste.
UNO MISMO - Los probadores de software certificados
deberían participar en el aprendizaje permanente con
relación a la práctica de su profesión y deberían promover
un método ético para la práctica de la profesión. Por
ejemplo, la profesión, la participación en cursos, la lectura
de libros y la exposición en conferencias acerca de lo que
usted hace le ayuda a avanzar.