CURSO DE TESTING MANUAL O QUALITY CONTROL

MATERIAL DE LECTURA

Ejecución de pruebas
PINTRODUCCIONP
Durante el Módulo 2 analizamos el STLC y sus etapas. Nos enfocamos en las primeras fases
donde priorizamos el orden, el diseño y la planificación. En la siguiente guía veremos las
etapas finales. Encontrarás algunos conceptos relacionados con los tipos y gestión de
pruebas que veremos más adelante.

Al finalizar la guía encontraras una tabla que te ayudará a repasar el STLC completo.

OBJETIVOS DE LA GUIA
• Reconocer y diferenciar las últimas etapas del STLC
• Identificar los criterios de entrada y salida y las actividades de cada etapa.
• Diferenciar el entorno de pruebas del banco de pruebas
• Configurar correctamente entorno de pruebas
• Identificar los informes resultantes de la etapa de ejecución
• Comprender la importancia de las actividades de cierre
• Comprender el papel del Control y monitoreo de las pruebas.

PIMPLEMENTACIONP
Es el proceso de desarrollar y priorizar procedimientos de prueba, crear datos de prueba y,
opcionalmente, preparar arneses de prueba y escribir scripts de prueba automatizados.
Aquí es cuando las pruebas se organizan y priorizan y cuando los diseños de prueba se
implementan como casos de prueba, procedimientos de prueba y datos de prueba.

Es de gran importancia elegir las pruebas correctas y ejecutarlas en el orden correcto. La

importancia de esto incluso crece exponencialmente en las estrategias basadas en el riesgo
cuando priorizamos en función de la probabilidad de riesgo y problemas.

En esta etapa, el Gerente de Pruebas debe asegurar:

• entrega del entorno de prueba

• entrega de datos de prueba
• se comprueban las limitaciones, los riesgos y las prioridades
• el equipo de prueba está listo para la ejecución
• se comprueban los criterios de entrada (explícito/implícito)
Algunas organizaciones pueden seguir el estándar IEEE829 para definir las entradas y los
resultados esperados asociados durante las pruebas. Otros solo tienen reglas rigurosas
cuando necesitan proporcionar evidencia de cumplimiento para proyectos regulatorios o
para el cumplimiento de estándares.

En los casos más comunes, las entradas de prueba generalmente se documentan junto con
los resultados esperados, los pasos de prueba y los datos de prueba almacenados.

Al igual que las condiciones de prueba y los casos de prueba, incluso durante la
implementación de la prueba nos enfrentaremos a la decisión de pasar a una etapa extensa
(detallada) o tener un enfoque ligero (genérico). Esta decisión debe ser tomada por su
comprensión del ciclo de vida del desarrollo y por la previsibilidad de las características del
software bajo prueba.
No descarte la extensa preparación para la implementación debido a lo anterior:

• Los casos de prueba concretos proporcionan ejemplos prácticos de cómo se

comporta el software.
• Cuando las pruebas se archivan a largo plazo y se reutilizan en la regresión, estos
detalles pueden volverse valiosos.
• Es probable que los expertos de dominio verifiquen frente a una prueba concreta
en lugar de una regla comercial abstracta.
• Se identifica una mayor debilidad en la especificación del software.
Algunos defectos solo se pueden encontrar en entornos de prueba similares a los de
producción. Suelen ser costosos de adquirir y difíciles de configurar y administrar. También
se enfrentan desafíos similares para el uso de datos de producción o datos similares a la
producción que incluso pueden conducir a la privacidad de los datos u otros dolores de
cabeza.

La implementación de la prueba no se trata solo de pruebas de software manuales, esta es

la etapa en la que se lleva a cabo la secuencia de comandos de prueba de software
automatizada, la etapa en la que se establece la automatización frente a la priorización
manual y el orden de ejecución. Y no estamos hablando solo de la automatización de
pruebas de software, incluso la adquisición de herramientas de pruebas de software se
realiza aquí, especialmente para la generación de datos de prueba necesarios para
prepararse para las pruebas de carga, volumen o rendimiento.

La implementación de pruebas es la práctica de organizar y priorizar las pruebas. Esto lo

llevan a cabo los analistas de pruebas que implementan los diseños de prueba como casos
de prueba reales, procesos de prueba y datos de prueba.

Si está observando el estándar IEEE 829, también debe definir estos parámetros:

• Entradas de prueba
• Resultados esperados para cada caso de prueba
• Pasos a seguir para cada proceso de prueba
Estos tres se documentan juntos y los datos de prueba se almacenan en forma de tablas de
base de datos, archivos planos, etc.

De sebe garantizar que el equipo esté preparado para ejecutar el diseño de la prueba es
una parte importante del proceso de implementación de la prueba. Algunas de las
comprobaciones que podrían realizarse para confirmar que el equipo está listo para ejecutar
las pruebas incluyen:

• Asegurarse de que el entorno de prueba está en su lugar.

• Garantizar que cada caso de prueba esté bien documentado y revisado.
• Poner el entorno de prueba en un estado de preparación.
• Verificación contra criterios de entrada explícitos e implícitos para el nivel de
prueba especificado.
• Describir el entorno de prueba, así como los datos de prueba con gran detalle.
• Realización de una verificación de aceptación de código ejecutándolo en un
entorno de prueba.
La granularidad (nivel de detalle) y la complejidad relacionada de las tareas realizadas en el
curso de la implementación de la prueba a menudo se ven influenciadas por la granularidad
de los productos de trabajo de prueba, como casos de prueba, condiciones de prueba, etc.
Por ejemplo, si las pruebas se van a documentar para usarlas nuevamente en el futuro para
pruebas de regresión, los documentos de prueba registrarán una descripción paso a paso
de la ejecución de la prueba. Esta explicación detallada permitirá que otros testers de
software realicen la prueba de manera confiable y consistente, independientemente de su
experiencia.

De manera similar, si las pautas reglamentarias son aplicables al procedimiento de prueba,

el cumplimiento de la prueba con los estándares relevantes debe documentarse como
evidencia.

Los gerentes de prueba también son responsables de crear un cronograma para la

ejecución de la prueba, detallando el orden de ejecución de las pruebas automáticas y
manuales. Deben verificar diligentemente las restricciones como riesgos, prioridades, etc.
que pueden requerir que las pruebas se ejecuten en un orden específico o utilizando un
equipo específico. Los gerentes de prueba también deben verificar las dependencias en los
datos de prueba o el entorno de prueba.

DESVENTAJAS DE LA IMPLEMENTACIÓN TEMPRANA DE PRUEBAS

La implementación temprana de las pruebas también puede tener algunas desventajas.

• Por ejemplo, si se ha adoptado el ciclo de vida ágil para el desarrollo de productos,

el código en sí puede sufrir cambios drásticos entre iteraciones consecutivas. Esto
hará que toda la implementación de la prueba sea inútil.
• De hecho, cualquier ciclo de vida de desarrollo iterativo afectará el código entre
iteraciones, incluso si no es tan drástico como en el ciclo de vida Agile.
• Esto hará que las pruebas predefinidas queden obsoletas o requieran un
mantenimiento continuo y con muchos recursos.
• De manera similar, incluso en el caso de ciclos de vida secuenciales, si el proyecto
está mal administrado y los requisitos siguen cambiando incluso cuando el
proyecto se encuentra en un estado avanzado, la implementación de la prueba
inicial puede volverse obsoleta.
Por lo tanto, antes de iniciar el proceso de implementación de pruebas, Test Manager debe
considerar estos puntos importantes:

• Ciclo de vida de desarrollo de software que se utiliza

• Características que deben probarse
• Probabilidad de cambio en el requisito tarde en el ciclo de vida del proyecto
• Posibilidad de cambios en el código entre dos iteraciones

VENTAJAS DE LA IMPLEMENTACIÓN TEMPRANA DE PRUEBAS

La implementación temprana de la prueba también ofrece algunas ventajas.

• Las pruebas concretas, por ejemplo, brindan ejemplos listos del comportamiento
apropiado del software si se documentan de acuerdo con las condiciones de la
prueba.
• A los expertos en dominios les resulta más fácil verificar las pruebas concretas que
las reglas comerciales no concretas, lo que les permite detectar fallas en las
especificaciones del software.
DESAFÍOS PARA LA IMPLEMENTACIÓN EN EL STLC

Los scripts de prueba escritos en la fase de implementación del ciclo de vida de las pruebas
de software cubren tanto las pruebas manuales como las automatizadas.

Las pruebas automatizadas están diseñadas para seguir el ritmo de la implementación

rápida y el cronograma de lanzamiento del desarrollo ágil. Los métodos de prueba más
rápidos y el software especial controlan y administran la ejecución de las pruebas, lo que
aumenta la velocidad de las pruebas. Por lo general, las pruebas automatizadas se usan
cuando se repiten los scripts, las pruebas se realizan varias veces con diferentes datos y
condiciones, o las pruebas son tediosas y difíciles de ejecutar manualmente.

A pesar de los beneficios percibidos, existen desafíos asociados con las pruebas
automatizadas. La automatización es costosa y su implementación puede llevar mucho
tiempo. Dependiendo de las complejidades del negocio, puede haber un beneficio limitado
para las pruebas automatizadas.

Los errores en las pruebas automatizadas pueden generar problemas significativos y

errores costosos. Una empresa que depende demasiado de las pruebas automatizadas o
intenta automatizar procesos que deberían ejecutarse manualmente aumentará el costo, la
duración y el riesgo de su proyecto.

Estos desafíos han llevado a muchas empresas a cuestionar el retorno de la inversión (ROI)
de las pruebas automatizadas.

Mantener los scripts de prueba diseñados también puede ser un desafío. Con el tiempo, los
procesos comerciales cambiarán, especialmente cuando son dinámicos. Si el equipo no
instala un proceso para actualizar los scripts de prueba o no utiliza los datos de usuario más
recientes y relevantes, las pruebas se volverán defectuosas y obsoletas.

MEJORES PRÁCTICAS DE IMPLEMENTACIÓN EN EL STLC

• Use procesos comerciales, en lugar de instrucciones simples, para un escenario de

prueba más completo y fácil de usar.
• Cada script de prueba debe basarse en casos de uso y procesos comerciales de la
vida real, en lugar de la funcionalidad del producto.
• Consulte con los usuarios y los propietarios del proceso comercial para garantizar
la validez del caso de prueba.
• Cree un proceso para mantener y actualizar los scripts de prueba para garantizar
que continúen siendo una herramienta poderosa para los usuarios y el equipo del
proyecto.

PCONFIGURACIÓN DEL ENTORNO DE PRUEBAP

El entorno de prueba proporciona el entorno en el que se lleva a cabo la prueba real. Esta
es una fase crucial del ciclo de vida de las pruebas de software y requiere la ayuda de otros
miembros de la organización. Los tester deben tener acceso a las capacidades de informe
de errores, así como a la arquitectura de la aplicación para respaldar el producto. Sin estos
elementos, es posible que los tester no puedan hacer su trabajo.
Una vez listos, los testers establecen los parámetros para el entorno de prueba, que
incluyen el hardware, el software, los datos de prueba, los marcos, las configuraciones y la
red. En esta fase STLC, los testers ajustan estos parámetros ambientales según lo que
requiera el caso de prueba. Por ejemplo, la mayoría de los usuarios de un producto pueden
estar en un dispositivo Android, usar una determinada versión de un navegador Chrome y
tener una cierta cantidad de potencia de procesamiento en esos dispositivos; estos son
parámetros que incluiría el entorno de prueba.

Las pruebas de humo dentro de estos entornos de prueba proporcionan una verificación
muy temprana y rudimentaria de que el software está listo para pruebas más completas.
Estas pruebas de humo contra las construcciones son parte del entregable en esta fase
STLC.

¿QUÉ ES UN ENTORNO DE PRUEBA?

La configuración de entornos de prueba presenta muchas dificultades nuevas, como la

forma de administrar todos estos entornos. A menudo es difícil crear una réplica exacta de
su entorno de producción. Además de eso, la creación manual de esos entornos requiere
mucho tiempo y esfuerzo por parte del ingeniero de pruebas.

Un entorno de prueba es un servidor que le permite ejecutar los casos de prueba que ha
definido. El entorno de prueba incluye más que simplemente configurar un servidor para
ejecutar pruebas. También implica la configuración del hardware y la red.

En otras palabras, un entorno de prueba le permite crear entornos idénticos cada vez que
necesite probar su producto. Es la herramienta más importante para que un ingeniero de
pruebas tenga confianza en los resultados de las pruebas.

Un entorno de prueba es una configuración de software y hardware para que los equipos
de prueba ejecuten casos de prueba. En otras palabras, admite la ejecución de pruebas
con hardware, software y red configurados.

El banco de pruebas o el entorno de pruebas se configura según la necesidad de la

aplicación bajo prueba. En algunas ocasiones, el banco de pruebas podría ser la
combinación del entorno de prueba y los datos de prueba que opera.

La configuración de un entorno de prueba adecuado garantiza el éxito de las pruebas de

software. Cualquier falla en este proceso puede generar costos y tiempo adicionales para el
cliente.

¿QUÉ ES UN BANCO DE PRUEBAS?

Un banco de pruebas es un entorno de prueba que se ha preparado con datos de prueba.

Los datos de prueba lo ayudan a verificar los casos de prueba que requieren una
determinada configuración de datos.

Por ejemplo, supongamos que desea probar si una función específica crea facturas para los
datos de ventas que están presentes en una base de datos específica. Dado que
necesitamos preparar la base de datos con datos, este entorno de prueba se considera un
banco de pruebas. De hecho, la diferencia entre un entorno de prueba y un banco de
pruebas es bastante pequeña, pero es importante conocer el matiz entre ambos términos.
IMPORTANCIA DEL ENTORNO DE PRUEBA

Un entorno de prueba proporciona información precisa sobre la calidad y el

comportamiento de la aplicación que se está probando. En otras palabras, un entorno de
prueba le proporciona la configuración necesaria para ejecutar sus casos de prueba.

Un entorno de prueba lo ayuda aún más al proporcionar un entorno dedicado para que
pueda aislar el código y verificar el comportamiento de la aplicación. Esto garantiza que no
se esté ejecutando en el servidor ninguna otra actividad que pueda influir en el resultado de
las pruebas.

Además, un entorno de prueba puede actuar como una copia exacta del entorno de
producción. Este es el elemento más crucial para que usted tenga confianza en los
resultados de las pruebas. El ingeniero de pruebas debe estar 100 por ciento seguro de que
la aplicación se comporta de la misma manera en el entorno de prueba que en el entorno
de producción.

ÁREAS CLAVE PARA CONFIGURAR EN EL ENTORNO DE PRUEBA

Para el entorno de prueba, un área clave para configurar incluye

• Sistema y aplicaciones
• Datos de prueba
• Servidor de base de datos
• Entorno de ejecución frontal
• Sistema operativo del cliente
• Navegador
• El hardware incluye el sistema operativo del servidor
• La red
• Documentación requerida como documentos de referencia/guías de
configuración/guías de instalación/manuales de usuario

ELEMENTOS CLAVE PARA CREAR UN ENTORNO DE PRUEBA

Como dije en la introducción, crear el entorno de prueba adecuado requiere muchos

elementos. Aquí hay una lista de requisitos que deberá completar al crear entornos de
prueba:

• Cree datos de prueba e insértelos en el entorno de prueba (banco de prueba)

• Configurar base de datos
• Configurar el entorno
• Seleccione el hardware y el sistema operativo adecuados (por ejemplo, evalúe la
diferencia entre ejecutar la aplicación en Windows 8.1 y Windows 10)
• Configurar la red (por ejemplo, uso compartido de recursos de origen cruzado)

El paso más importante es documentar todas las acciones. Esto es clave para que otros
usuarios puedan replicar el entorno. Además, la documentación detallada permite al
ingeniero de pruebas configurar diferentes entornos de prueba, como entornos de ensayo y
producción.
PROCESO DE CONFIGURACIÓN DEL ENTORNO DE PRUEBA DE
SOFTWARE

Las pruebas se limitan a lo que se puede probar y lo que no se debe probar. Las siguientes
personas están involucradas en la configuración del entorno de prueba

• Administradores del sistema

• Desarrolladores
• Tester
• A veces, usuarios o técnicos con afinidad por las pruebas.

El entorno de prueba requiere la configuración de varias áreas distintas como,

Configuración del servidor de prueba

Es posible que no se ejecuten todas las pruebas en una máquina local. Es posible que
necesite establecer un servidor de prueba, que pueda admitir aplicaciones.

Por ejemplo, configuración de Fedora para PHP, aplicaciones basadas en Java con o sin
servidores de correo, configuración de cron, aplicaciones basadas en Java, etc.

La red

Red configurada según el requisito de prueba. Incluye,

• configuración de internet
• Configuración de red wifi
• Configuración de red privada

Garantiza que la congestión que se produce durante las pruebas no afecte a otros
miembros. (Desarrolladores, diseñadores, redactores de contenido, etc.)

Configuración de PC de prueba

Para las pruebas web, es posible que deba configurar diferentes navegadores para
diferentes testers. Para las aplicaciones de escritorio, necesita varios tipos de sistemas
operativos para diferentes PC de prueba.

Por ejemplo, la prueba de la aplicación de Windows Phone puede requerir

Instalación de Visual Studio

emulador de teléfono de Windows

Alternativamente, asignando un teléfono de Windows al tester.

Informe de errores

Se deben proporcionar herramientas de informe de errores a los tester.

CÓMO ORGANIZAR MÚLTIPLES ENTORNOS PARA PRUEBAS

La forma más fácil de administrar sus entornos de prueba es a través de la automatización.

Al contar con la automatización de la compilación y la implementación, puede administrar
entornos con éxito.

Las herramientas de integración continua (CI) como Jenkins son ideales para este propósito.
Jenkins es un servidor de automatización de código abierto gratuito escrito en Java y es
una de las herramientas de CI más populares en la industria del software. La herramienta no
solo ayuda a automatizar este proceso de implementación, sino que también ayuda a
ejecutar conjuntos de pruebas.

Otro enfoque para administrar sus entornos de prueba es tener documentación detallada
que describa, por ejemplo, cómo crear una réplica exacta de su entorno de producción. Sin
embargo, este enfoque más manual es propenso a errores humanos.

CREACIÓN DE DATOS DE PRUEBA PARA EL ENTORNO DE PRUEBA

Muchas empresas utilizan un entorno de prueba independiente para probar el producto de

software. El enfoque común utilizado es copiar datos de producción para probar. Esto ayuda
al tester a detectar los mismos problemas que un servidor de producción en vivo, sin
corromper los datos de producción.

El enfoque para copiar datos de producción a datos de prueba incluye:

• Configurar trabajos de producción para copiar los datos en un entorno de prueba

común

Toda la PII (información de identificación personal) se modifica junto con otros datos
confidenciales. La PII se reemplaza con datos lógicamente correctos, pero no personales.

• Elimine los datos que sean irrelevantes para su prueba.

Los testers o desarrolladores pueden copiar esto en su entorno de prueba individual.

Pueden modificarlo según su requerimiento.

• La privacidad es el problema principal en la copia de datos de producción. Para

superar los problemas de privacidad, debe buscar datos de prueba ofuscados y
anónimos.

Para la anonimización de datos se pueden utilizar dos enfoques,

BlackList: en este enfoque, todos los campos de datos se dejan sin cambios. Excepto
aquellos campos especificados por los usuarios.

WhiteList: de forma predeterminada, este enfoque anonimiza todos los campos de datos.
Excepto por una lista de campos que se pueden copiar. Un campo en la lista blanca implica
que está bien copiar los datos tal como están y no se requiere la anonimización.

Además, si está utilizando datos de producción, debe ser inteligente sobre cómo obtener
datos. Consultar la base de datos mediante un script SQL es un enfoque eficaz.
GESTIÓN DEL ENTORNO DE PRUEBA

Test Environment Management se ocupa del mantenimiento y conservación del banco de

pruebas.

La lista de actividades de la función de gestión del entorno de prueba incluye:

• Mantenimiento de un repositorio central con toda la versión actualizada de los

entornos de prueba.

• Gestión del entorno de prueba según las demandas del equipo de prueba.

• Según los nuevos requisitos creando nuevos entornos.

• Monitoreo de los ambientes

• Actualización/eliminación de entornos de prueba obsoletos

• Investigación de problemas sobre el medio ambiente.

• Coordinación hasta la resolución de un problema.

Hardware

Si este no es el caso,
¿Verificar si el equipo requerido para la prueba
1 ¡analice el tiempo de
está disponible?
suministro!

Tales como escáneres,

Comprobar si hay equipos periféricos disponibles. impresoras especiales,
portátiles, etc.

Software / conexiones

Una aplicación como excel,

2 ¿Se especifican las aplicaciones necesarias?
word, dibujos, etc.

¿Tiene la organización
Para el nuevo software, ¿existe el entorno de experiencia con el uso y
prueba para la organización? mantenimiento del
software?

Datos ambientales

Con el conjunto de pruebas

de regresión, considere la
Comprobar si los conjuntos de datos de prueba
3 administración de defectos
estándar están disponibles.
para recopilar datos de
prueba.

¿Existen acuerdos con los propietarios de los datos Considere el mantenimiento

de prueba sobre los datos de prueba? funcional.
 Herramientas/procesos de mantenimiento

Si no, prepare una lista de

todos los posibles
miembros involucrados en
Comprobar si existe un único punto de contacto
4 mantener el entorno de
para el mantenimiento del entorno de prueba.
prueba en funcionamiento.
Debe incluir su información
de contacto también.

Por ejemplo, criterios de

aceptación, requisitos de
mantenimiento, etc.
¿El acuerdo alcanzado sobre la disponibilidad y
Además, verifique si otros
calidad del entorno de prueba?
atributos de calidad
adicionales para los
entornos están de acuerdo.

¿Se conocen todos los miembros involucrados en

el proceso de mantenimiento?

Además de estas, hay algunas preguntas más que responder antes de configurar el entorno
de prueba.

• ¿Si desarrollar un entorno de prueba interno o subcontratar?

• ¿Seguir una norma interna de la empresa o seguir alguna Externa (IEE, ISO, etc.)?
• ¿Cuánto tiempo se requiere el entorno de prueba?
• Deben determinarse las diferencias entre los sistemas de prueba y de producción y
su impacto en la validez de la prueba.
• ¿Puede reutilizar una configuración existente para otros proyectos en la empresa?

DESAFÍOS EN LA CONFIGURACIÓN DE LA GESTIÓN DEL ENTORNO DE PRUEBA

Planificación adecuada del uso de recursos. La planificación ineficaz del uso de recursos
puede afectar el resultado real. Además, puede dar lugar a conflictos entre equipos.

Entorno remoto. Es posible que un entorno de prueba esté ubicado geográficamente

aparte. En tal caso, el equipo de prueba debe confiar en el equipo de soporte para varios
activos de prueba. (Software, hardware y otros temas).

Tiempo de configuración elaborado. A veces, la configuración de la prueba se vuelve

demasiado elaborada en casos de pruebas de integración.

Uso compartido por equipos. Si el entorno de prueba es utilizado por el equipo de

desarrollo y prueba simultáneamente, los resultados de la prueba se dañarán.

Configuración de prueba compleja. Cierta prueba requiere una configuración de entorno

de prueba compleja. Puede representar un desafío para el equipo de prueba.
PRÁCTICAS RECOMENDADAS PARA CONFIGURAR UNA GESTIÓN DEL ENTORNO
DE PRUEBA

Comprenda los requisitos de la prueba a fondo y eduque a los miembros del equipo de
prueba.

• La conectividad debe verificarse antes del inicio de la prueba.

• Compruebe el hardware y el software necesarios, las licencias
• navegadores y versiones
• Planificación del uso programado del entorno de prueba.
• Herramientas de automatización y sus configuraciones.

PEJECUCIONP
La ejecución de prueba es el proceso de prueba de software de ejecutar una prueba en el
componente o sistema bajo prueba, produciendo un resultado real.

Las pruebas están diseñadas o al menos definidas. Existen herramientas para la gestión de
pruebas y la gestión de defectos y la automatización de pruebas (si corresponde)

1. Se publican los estándares para el registro de pruebas y el informe de defectos.

2. La ejecución de la prueba comienza una vez
3. El objeto de prueba se entrega
4. Se cumplen los criterios de entrada para la ejecución de la prueba.
Durante la ejecución, una función de los administradores de pruebas es:

• Supervisar el progreso de acuerdo con el plan.

• Iniciar y llevar a cabo acciones de control para guiar las pruebas.
Asegúrese de que los registros de prueba proporcionen un registro adecuado de detalles
relevantes para pruebas y eventos.

Durante la ejecución, es importante mantener una capacidad de seguimiento entre las

condiciones de la prueba, la base de la prueba y el objetivo de la prueba y tener el nivel
adecuado de registro de la prueba.

Se debe reservar tiempo para las sesiones de prueba basadas en la experiencia y en los
defectos impulsadas por los hallazgos del tester.

Una vez que se ha entregado un objeto de prueba y se cumplen las condiciones de entrada
para la ejecución de la prueba, comienza la fase de ejecución de la prueba. Idealmente, las
pruebas deben realizarse según los casos de prueba definidos. Sin embargo, el
administrador de pruebas puede permitir que los testers realicen pruebas adicionales para
detectar comportamientos nuevos e interesantes observados durante las pruebas.

Durante la ejecución, el equipo realizará las pruebas. Se registrarán todas las discrepancias
y se identificarán los defectos. Las discrepancias se miden como la diferencia entre los
resultados de la prueba reales y esperados.
Los testers seguirán los planes de prueba desarrollados en la primera fase y utilizarán los
scripts de prueba escritos en la segunda fase. Las pruebas deben ejecutarse siguiendo
estrictamente el plan, con todas las discrepancias, defectos, fallas, problemas y errores
registrados tan pronto como se identifiquen. Los defectos y discrepancias deben asignarse
a los casos de prueba y luego volver a probarse para garantizar la validez de los resultados
de la prueba.

Al final de la fase de ejecución, se debe completar todo el plan de prueba, con todos los
defectos identificados y documentados. Este documento, un informe de defectos, es una
herramienta importante para administrar el proyecto y garantizar una versión de alta calidad.

Para una ejecución de prueba efectiva y eficiente, estas condiciones deben cumplirse antes
de que comience la ejecución real de la prueba:

• El diseño o definición de las pruebas debe ser completo.

• Las herramientas de prueba, especialmente las herramientas de gestión de pruebas
deben estar listas
• Los procesos para el seguimiento de los resultados de las pruebas, incluidas las
métricas, deben estar funcionando.
• Cada miembro del equipo debe comprender los datos a rastrear
• Los criterios para registrar pruebas y reportar defectos deben publicarse y estar
disponibles para todos los miembros del equipo.
• Si la estrategia de prueba que se utiliza es reactiva, aunque sea parcialmente, se
debe asignar tiempo adicional para aplicar metodologías basadas en defectos y
experiencia.
Obviamente, si se detecta alguna falla durante tales pruebas no planificadas, se deben
documentar las variaciones de los casos de prueba predefinidos, para que puedan
reproducirse en el futuro.

Las pruebas automatizadas siempre siguen las instrucciones escritas, sin ninguna
desviación.

La responsabilidad fundamental de un administrador de pruebas en la fase de ejecución de

la prueba es observar el progreso de la prueba y compararlo con el plan de prueba. Si se
observa alguna desviación, el Gerente de Pruebas debe iniciar y ejecutar actividades de
control de pruebas para conducir las pruebas hacia un final exitoso, de acuerdo con los
objetivos, estrategias y misión definidos.

El Gerente de Pruebas puede emplear la trazabilidad hacia atrás desde los resultados de la
prueba hasta las condiciones de la prueba, la base de la prueba y, finalmente, los objetivos
de la prueba y la trazabilidad hacia adelante desde los objetivos de la prueba hasta los
resultados de la prueba.

La ejecución de prueba es el proceso de ejecutar el código y comparar los resultados

esperados y reales. Se deben considerar los siguientes factores para un proceso de
ejecución de prueba:

• En función de un riesgo, seleccione un subconjunto del conjunto de pruebas que se

ejecutará para este ciclo.
• Asigne los casos de prueba en cada conjunto de pruebas a los tester para su
ejecución.
• Ejecute pruebas, informe errores y capture el estado de las pruebas de forma
continua.
• Resuelva los problemas de bloqueo a medida que surjan.
• Informe el estado, ajuste las asignaciones y reconsidere los planes y prioridades
diariamente.
 • Informar sobre los resultados y el estado del ciclo de prueba.
Los siguientes puntos deben tenerse en cuenta para la ejecución de la prueba.

• En esta fase, el equipo de control de calidad realiza la validación real de AUT

(Application Under Test*) en función de los casos de prueba preparados y compara
el resultado paso a paso con el resultado esperado.
• El criterio de entrada de esta fase es la finalización del Plan de prueba y la fase de
Desarrollo de casos de prueba, los datos de prueba también deben estar listos.
• Siempre se recomienda la validación de la configuración del entorno de prueba
mediante pruebas de humo antes de ingresar oficialmente a la ejecución de la
prueba.
• El criterio de salida requiere la validación exitosa de todos los Casos de Prueba;
Los defectos deben ser cerrados o diferidos; La ejecución del caso de prueba y el
informe de resumen de defectos deben estar listos.
*AUT: es "Aplicación bajo prueba". Después de diseñar y codificar la sección del ciclo de
desarrollo, cuando la aplicación (construcción) se somete a prueba, en ese momento el
estado de la aplicación está bajo prueba, por lo que en ese período de tiempo esa
aplicación (construcción) se llama "Aplicación bajo prueba".

DESAFÍOS PARA LA EJECUCIÓN EN STLC

Muchos de los desafíos relacionados con la fase de ejecución del ciclo de vida de las
pruebas de software se relacionan con la documentación, la consistencia y la tecnología.

A menudo, en el rápido ritmo de desarrollo y lanzamiento, las pruebas se vuelven de baja

prioridad. El equipo sacrificará las pruebas críticas para sacar el lanzamiento más rápido, lo
que puede generar problemas que solo se descubren más tarde.

Según una encuesta reciente, los tomadores de decisiones de pruebas de TI en los Estados
Unidos y el Reino Unido identificaron la dificultad para usar software y herramientas de
prueba como el mayor desafío para la ejecución exitosa de las pruebas. Las herramientas
que no son fáciles de usar y requieren una capacitación extensa y que requiere mucho
tiempo para los testers no técnicos pueden aumentar el costo y limitar la eficiencia de las
pruebas.

MEJORES PRÁCTICAS DE EJECUCIÓN EN STLC

• Registre las pruebas realizadas para respaldar cada requisito.

• Verificar que se hayan cumplido los requisitos en el producto, utilizando una Matriz
de Trazabilidad de Requisitos (RTM).
• Utilice el RTM para analizar el trabajo realizado en un proyecto. Con este análisis,
el equipo de control de calidad puede estimar mejor los ciclos de trabajo
posteriores, se pueden eliminar las reelaboraciones innecesarias y redundantes
para reducir los costos y los proyectos tendrán menos defectos y problemas.

BENEFICIOS DE LA EJECUCIÓN EN STLC

Administrar e identificar los defectos en una versión de software es el objetivo de la fase de

ejecución. La preparación y el trabajo realizado en las fases de planificación e
implementación dan como resultado una ejecución más eficaz y eficiente.

Los procesos están estandarizados, lo que garantiza que se completen las pruebas y que el
equipo tenga todas las oportunidades para identificar defectos antes de ponerlo en marcha.
La finalización de una fase de ejecución efectiva da como resultado una versión de software
de mayor calidad.

ACTIVIDADES PARA LA EJECUCIÓN DE PRUEBAS

El objetivo de esta fase es la validación en tiempo real de AUT antes de pasar a

producción/lanzamiento. Para finalizar esta fase, el equipo de control de calidad realiza
diferentes tipos de pruebas para garantizar la calidad del producto. Junto con este informe
de defectos y nuevas pruebas también es una actividad crucial en esta fase. Las siguientes
son las actividades importantes de esta fase:

PRUEBAS DE INTEGRACIÓN DEL SISTEMA (SIT)

La verdadera validación de producto/AUT comienza aquí. La prueba de integración del

sistema (SIT) es una técnica de prueba de caja negra que evalúa el cumplimiento del
sistema frente a requisitos específicos/casos de prueba preparados.

La prueba de integración del sistema generalmente se realiza en un subconjunto del

sistema. La SIT se puede realizar con un uso mínimo de herramientas de prueba, verificar las
interacciones intercambiadas y también se investiga el comportamiento de cada campo de
datos dentro de la capa individual. Después de la integración, hay tres estados principales
de flujo de datos:

• Estado de datos dentro de la capa de integración

• Estado de datos dentro de la capa de base de datos
• Estado de datos dentro de la capa de aplicación
Nota − En las pruebas SIT, el equipo de control de calidad trata de encontrar tantos defectos
como sea posible para garantizar la calidad. El objetivo principal aquí es encontrar tantos
errores como sea posible.

INFORME DE DEFECTOS

Un error de software surge cuando el resultado esperado no coincide con el resultado real.
Puede ser un error, bugg o fallo en un programa de computadora. La mayoría de los errores
surgen de buggs y errores cometidos por desarrolladores o arquitectos.

Mientras realiza las pruebas SIT, el equipo de control de calidad encuentra este tipo de
defectos y estos deben informarse a los miembros del equipo interesados. Los miembros
toman medidas adicionales y los corrigen. Otra ventaja de los informes es que facilita el
seguimiento del estado de los defectos. Hay muchas herramientas populares como ALM,
QC, JIRA, Version One, Bugzilla que admiten el seguimiento y el informe de defectos.

El informe de defectos es un proceso de detección de defectos en la aplicación que se está

probando o en el producto mediante la prueba o el registro de los comentarios de los
clientes y la creación de nuevas versiones del producto que solucionen los defectos en
función de los comentarios del cliente.

El seguimiento de defectos también es un proceso importante en la ingeniería de software,

ya que los sistemas complejos y críticos para el negocio tienen cientos de defectos. Uno de
los factores más desafiantes es gestionar, evaluar y priorizar estos defectos. La cantidad de
defectos se multiplica durante un período de tiempo y, para administrarlos de manera
efectiva, se utiliza un sistema de seguimiento de defectos para facilitar el trabajo.
MAPEO DE DEFECTOS

Una vez que se informa y se registra el defecto, debe mapearse con los casos de prueba
fallidos/bloqueados y los requisitos correspondientes en la Matriz de trazabilidad de
requisitos. Este mapeo lo realiza el Defect Reporter. Ayuda a hacer un informe de defectos
adecuado y analizar el producto. Una vez que los casos de prueba y los requisitos se
mapean con el defecto, las partes interesadas pueden analizar y tomar una decisión sobre si
reparar o diferir el defecto en función de la prioridad y la gravedad.

VOLVER A PROBAR

Volver a probar es ejecutar una prueba fallida anteriormente contra AUT para verificar si el
problema se resolvió. Una vez que se ha solucionado un defecto, se realiza una nueva
prueba para verificar el escenario en las mismas condiciones ambientales.

Durante la nueva prueba, los tester buscan detalles granulares en el área modificada de la
funcionalidad, mientras que la prueba de regresión cubre todas las funciones principales
para garantizar que no se rompa ninguna funcionalidad debido a este cambio.

PRUEBAS DE REGRESIÓN

Una vez que todos los defectos están en estado cerrado, aplazado o rechazado y ninguno
de los casos de prueba está en estado de progreso/fallido/no ejecutado, se puede decir
que la prueba de integración del sistema se basa completamente en los casos de prueba y
los requisitos. Sin embargo, se requiere una ronda de pruebas rápidas para garantizar que
ninguna de las funciones se interrumpa debido a cambios en el código/arreglos de
defectos.

TIPOS DE PRUEBAS DE REGRESIÓN

Pruebas de regresión finales: se realiza una "prueba de regresión final" para validar la
compilación que no ha sufrido cambios durante un período de tiempo. Esta compilación se
implementa o envía a los clientes.

Pruebas de regresión: se realiza una prueba de regresión normal para verificar si la

compilación NO ha roto ninguna otra parte de la aplicación debido a los cambios recientes
en el código para corregir defectos o mejorar.

DIAGRAMA DE BLOQUES DE ACTIVIDADES

El siguiente diagrama de bloques muestra las actividades importantes realizadas en esta

fase; también muestra la dependencia de las fases anteriores
DIRECTRICES DE EJECUCIÓN DE PRUEBAS

Hagamos ahora una lista de todas las cosas que son importantes para comprender la fase
de ejecución de la prueba:

La compilación (el código escrito por el equipo de desarrollo está empaquetado en lo que
se conoce como una compilación; esto no es más que una pieza de software instalable
(AUT), lista para implementarse en el entorno de control de calidad) que se está
implementando (en otras palabras, instalado y disponible) para el entorno de control de
calidad es uno de los aspectos más importantes que debe suceder para que comience la
ejecución de la prueba.

La ejecución de la prueba ocurre en el entorno de control de calidad. Para asegurarse de

que el trabajo del equipo de desarrollo en el código no esté en el mismo lugar, donde el
equipo de control de calidad está probando, la práctica general es tener un entorno de
desarrollo y control de calidad dedicado. (También hay un entorno de producción para
alojar la aplicación en vivo).

Esto es básicamente para preservar la integridad de la aplicación en varias etapas del ciclo
de vida de SDLC. De lo contrario, idealmente, los 3 entornos son de naturaleza idéntica.

El tamaño del equipo de prueba no es constante desde el comienzo del proyecto. Cuando
se inicia el plan de prueba, es posible que el equipo solo tenga un líder de equipo. Durante
la fase de diseño de la prueba, se incorporan algunos testers. La ejecución de la prueba es
la fase en la que el equipo alcanza su tamaño máximo.

La ejecución de la prueba también ocurre en al menos 2 ciclos (3 en algunos proyectos). Por

lo general, en cada ciclo, se ejecutarán todos los casos de prueba (el conjunto de pruebas
completo). El objetivo del primer ciclo es identificar cualquier bloqueo, defectos críticos y la
mayoría de los defectos altos. El objetivo del segundo ciclo es identificar defectos altos y
medios remanentes, corregir lagunas en los guiones y obtener resultados.
La fase de ejecución de prueba consiste en: Ejecutar los scripts de prueba + Mantenimiento
del script de prueba (corregir las lagunas en los scripts) + Informes (defectos, estado,
métricas, etc.) Por lo tanto, al planificar esta fase, se deben estimar los programas y los
esfuerzos teniendo en cuenta consideración todos estos aspectos y no solo la ejecución del
script.

Después de que se realiza el script de prueba y se implementa el AUT, y antes de que

comience la ejecución de la prueba, hay un paso intermedio. Esto se denomina "Revisión
de preparación para la prueba (TRR)". Este es un tipo de paso de transición que finalizará la
fase de diseño de la prueba y nos facilitará la ejecución de la prueba.

Además del TRR, hay algunas verificaciones adicionales antes de asegurarnos de que
podemos seguir adelante con la aceptación de la compilación actual que se implementa en
el entorno de control de calidad para la ejecución de la prueba. Esas son las pruebas de
Humo y Sanidad (que veremos en guías posteriores)

Las pruebas exploratorias se llevarán a cabo una vez que la compilación esté lista para la
prueba. El propósito de esta prueba es asegurarse de que se eliminen los defectos críticos
antes de que puedan comenzar los siguientes niveles de prueba. Esta prueba exploratoria
se lleva a cabo en la aplicación sin scripts de prueba ni documentación. También ayuda a
familiarizarse con el AUT.

Al igual que las otras fases del STLC, el trabajo también se divide entre los miembros del
equipo en la fase de Ejecución de prueba. La división puede basarse en el módulo o en el
recuento de casos de prueba o en cualquier otra cosa que pueda tener sentido.

El resultado principal de la fase de ejecución de la prueba es principalmente en forma de

informes, es decir, informe de defectos e informe de estado de ejecución de la prueba. El
proceso detallado para generar informes se puede encontrar en Informes de ejecución de
pruebas.

REVISIÓN DE PREPARACIÓN PARA LA PRUEBA (TRR)

¿Podemos usar listas de verificación en nuestros proyectos de TI formalmente

(específicamente QA) y, en caso afirmativo, cuándo y cómo?

• Es versátil, se puede utilizar para cualquier cosa.

• Fácil de crear/usar/mantener
• Analizar los resultados (progreso de la tarea/estado de finalización) es muy fácil
• Muy flexible: puede agregar o eliminar elementos según sea necesario

¿Por qué necesitamos listas de verificación?: Para el seguimiento y la evaluación de la

finalización (o no finalización). Para tomar nota de las tareas, para que nada se pase por alto.

¿Cómo creamos Checklists?: Bueno, esto no podría ser más simple. Simplemente, anota
todo punto por punto.

Ejemplo de listas de verificación para procesos de control de calidad:

REVISIÓN DE PREPARACIÓN PARA LA PRUEBA

Cuando dejar de probar o lista de verificación de criterios de salida

1. Revisión de preparación para la prueba

Esta es una actividad muy común que realiza cada equipo de control de calidad para
determinar si tienen todo lo que necesitan para pasar a la fase de ejecución de la prueba.
Además, esta es una actividad recurrente antes de cada ciclo de pruebas en proyectos que
involucran múltiples ciclos.

Para no tener problemas después de que comience la fase de prueba y darnos cuenta de
que ingresamos a la fase de ejecución prematuramente, cada proyecto de control de
calidad debe realizar una revisión para determinar que tiene todas las entradas necesarias
para una prueba exitosa.

Una lista de verificación facilita perfectamente esta actividad. Le permite hacer una lista de
"cosas necesarias" con anticipación y revisar cada elemento secuencialmente. Incluso
puede reutilizar la hoja una vez creada para ciclos de prueba posteriores.

Información adicional: la revisión de preparación para la prueba generalmente se crea y la

revisión la realiza el representante del equipo de control de calidad. Los resultados se
comparten con los PM y los demás miembros del equipo para indicar si el equipo de prueba
está listo o no para pasar a la fase de ejecución de la prueba.

A continuación, se muestra un ejemplo de una lista de verificación de revisión de

preparación para el examen de muestra:

Criterios de revisión de preparación para la prueba (TRR) Estado

Todos los Requerimientos finalizados y analizados

Plan de prueba creado y revisado Hecho
Preparación de casos de prueba hecha
Revisión del caso de prueba y aprobación
Disponibilidad de datos de prueba
Prueba de humo
¿Se realizan pruebas de cordura?
Equipo consciente de los roles y responsabilidades
Equipo consciente de los entregables que se esperan de ellos
Equipo consciente del protocolo de Comunicación
Acceso del equipo a la aplicación, herramientas de control de versiones,
Gestión de Pruebas
Equipo entrenado
Aspectos técnicos: ¿servidor 1 actualizado o no?
Se definen los estándares de notificación de defectos.

Ahora, todo lo que tienes que hacer con esta lista es marcar hecho o no hecho.

2. Lista de verificación de criterios de salida

Como su nombre lo indica, esta es una lista de verificación que ayuda en la toma de
decisiones sobre si una fase/ciclo de prueba debe detenerse o continuarse.

Dado que no es posible obtener un producto libre de defectos y tendremos que

asegurarnos de realizar las pruebas en la mayor medida posible en el tiempo determinado,
se crea una lista de verificación del siguiente efecto para rastrear los criterios más
importantes que deben cumplirse considerar satisfactoria una fase de prueba.

Criterio de salida Estado

100% de scripts de prueba ejecutados
Tasa de aprobación del 95 % de los guiones de prueba
Sin defectos abiertos críticos y de alta gravedad
Se ha cerrado el 95 % de los defectos de gravedad media
 Todos los defectos restantes se cancelan o documentan como solicitudes de
cambio para una versión futura
Todos los resultados esperados y reales se capturan y documentan con el
script de prueba.
Todas las métricas de prueba se recopilan en función de los informes de HP
ALM
Todos los defectos se registran en HP ALM
El memorándum de cierre de prueba está completado y firmado

LISTA DE VERIFICACIÓN DE PRUEBAS

La lista es en su mayoría equivalente al plan de prueba, cubrirá todos los estándares de

prueba y garantía de calidad.

Lista de verificación de prueba:

1. Crear Sistema y Pruebas de Aceptación [ ]

2. Iniciar creación de prueba de aceptación [ ]
3. Identificar equipo de prueba [ ]
4. Crear plan de trabajo [ ]
5. Crear enfoque de prueba [ ]
6. Vincular los criterios y requisitos de aceptación para formar la base de la prueba de
aceptación [ ]
7. Utilice un subconjunto de casos de prueba del sistema para formar la parte de
requisitos de la prueba de aceptación [ ]
8. Cree guiones para que los use el cliente para demostrar que el sistema cumple con
los requisitos [ ]
9. Cree un programa de prueba. Incluya personas y todos los demás recursos. [ ]
10. Realizar Prueba de Aceptación [ ]
11. Iniciar la creación de pruebas del sistema [ ]
12. Identificar a los miembros del equipo de prueba [ ]
13. Crear plan de trabajo [ ]
14. Determinar los requisitos de recursos [ ]
15. Identificar herramientas de productividad para pruebas [ ]
16. Determinar los requisitos de datos [ ]
17. Llegar a un acuerdo con Data Center [ ]
18. Crear enfoque de prueba [ ]
19. Identifique las instalaciones que se necesitan [ ]
20. Obtener y revisar el material de prueba existente [ ]
21. Crear un inventario de elementos de prueba [ ]
22. Identificar estados de diseño, condiciones, procesos y procedimientos [ ]
23. Determinar la necesidad de pruebas basadas en código (caja blanca). Identificar
condiciones. [ ]
24. Identificar todos los requisitos funcionales [ ]
25. Finalizar creación de inventario [ ]
26. Iniciar la creación del caso de prueba [ ]
27. Crear casos de prueba basados en el inventario de elementos de prueba [ ]
28. Identificar grupos lógicos de funciones comerciales para el nuevo sistema [ ]
29. Divida los casos de prueba en grupos funcionales rastreados al inventario de
elementos de prueba [ ]
30. Diseñar conjuntos de datos para corresponder a casos de prueba [ ]
31. Fin de la creación del caso de prueba [ ]
32. Revise las funciones comerciales, los casos de prueba y los conjuntos de datos con
los usuarios [ ]
 33. Obtenga la aprobación del diseño de prueba del líder del proyecto y control de
calidad [ ]
34. Diseño de prueba final [ ]
35. Comenzar la preparación para la prueba [ ]
36. Obtener recursos de soporte de prueba [ ]
37. Resuma los resultados esperados para cada caso de prueba [ ]
38. Obtener datos de prueba. Validar y rastrear casos de prueba [ ]
39. Preparar scripts de prueba detallados para cada caso de prueba [ ]
40. Preparar y documentar los procedimientos de configuración ambiental. Incluir
planes de copia de seguridad y recuperación [ ]
41. Terminar la fase de preparación de la prueba [ ]
42. Realizar prueba del sistema [ ]
43. Ejecutar secuencias de comandos de prueba [ ]
44. Compare el resultado real con el esperado [ ]
45. Documente las discrepancias y cree un informe de problemas [ ]
46. Preparar la entrada de la fase de mantenimiento [ ]
47. Vuelva a ejecutar el grupo de prueba después de reparar el problema [ ]
48. Cree un informe de prueba final, incluya una lista de errores conocidos [ ]
49. Obtener firma formal [ ]

¿CÓMO SABER SI NECESITO AUTOMATIZAR MIS PRUEBAS?

Al testear hágase las siguientes preguntas, si responde sí a cualquiera, entonces su prueba

debe ser considerada seriamente para la automatización.

1. ¿Se puede definir la secuencia de acciones de prueba?

Respuesta: ¿Es útil repetir la secuencia de acciones muchas veces? Ejemplos de esto serían
las pruebas de aceptación, las pruebas de compatibilidad, las pruebas de rendimiento y las
pruebas de regresión.

2. ¿Es posible automatizar la secuencia de acciones?

Respuesta: Esto puede determinar que la automatización no sea adecuada para esta
secuencia de acciones.

3. ¿Es posible “semi-automatizar” una prueba?

Respuesta: Automatizar partes de una prueba puede acelerar el tiempo de ejecución de la

prueba.

4. ¿El comportamiento del software bajo prueba es el mismo con automatización que
sin ella?

Respuesta: Esta es una preocupación importante para las pruebas de rendimiento.

5. ¿Está probando aspectos del programa que no son de interfaz de usuario?

Respuesta: Casi todas las funciones que no son de interfaz de usuario pueden y deben ser
pruebas automatizadas.
 6. ¿Necesita ejecutar las mismas pruebas en varias configuraciones de hardware?

Respuesta: Ejecute pruebas ad-hoc (Nota: Idealmente, cada error debería tener un caso de
prueba asociado. Las pruebas ad hoc se realizan mejor manualmente. Debe tratar de
imaginarse a sí mismo en situaciones del mundo real y usar su software como lo haría su
cliente. Como errores se encuentran durante las pruebas ad-hoc, se deben crear nuevos
casos de prueba para que se puedan reproducir fácilmente y para que las pruebas de
regresión se puedan realizar cuando llegue a la fase Zero Bug Build).

Una prueba Ad-hoc es una prueba que se realiza manualmente donde el tester intenta
simular el uso real del producto de software. Es cuando se ejecutan pruebas ad hoc cuando
se encuentran la mayoría de los errores. Cabe destacar que la automatización nunca puede
ser un sustituto de las pruebas manuales.

Puntos a tener en cuenta:

Los dos anteriores son ejemplos para mostrar el uso de listas de verificación para los
procesos de control de calidad, pero el uso no se limita a estas dos áreas.

Los elementos de cada lista también son indicadores para dar una idea a los lectores sobre
qué tipo de elementos se pueden incluir y rastrear; sin embargo, la lista se puede expandir
y/o compactar según sea necesario.

NUEVAS COLUMNAS EN EL DOCUMENTO DE CASOS DE PRUEBA

El documento del caso de prueba ahora se expande con las siguientes dos columnas:
estado y resultado real.

COLUMNA DE ESTADO

La ejecución de la prueba no es más que usar los pasos de prueba en el AUT, proporcionar
los datos de prueba (como se identifica en el documento del caso de prueba) y observar el
comportamiento del AUT para ver si satisface o no el resultado esperado.

Si no se cumple el resultado esperado, puede interpretarse como un defecto. Y el estado

del caso de prueba se convierte en "Falla" y si se cumple el resultado esperado, el estado
es "Aprobado". Si el caso de prueba no se puede ejecutar por algún motivo (un defecto
existente o un entorno que no es compatible), el estado sería "Bloqueado".

El estado de un caso de prueba que aún no se ha ejecutado se puede establecer en No

ejecutado/sin ejecutar o se puede dejar vacío.

Para un caso de prueba con varios pasos, si no se cumple el resultado esperado de un

determinado paso (en medio de los pasos del caso de prueba), el estado del caso de
prueba se puede establecer en "Falló" allí mismo y no es necesario ejecutar los siguientes
pasos.

El estado "Fallo" se puede indicar en color rojo, si desea llamar la atención sobre él de
inmediato.

COLUMNA DE RESULTADOS REALES

Este es un espacio donde los testers podemos registrar cuál es la desviación en el resultado
esperado. Cuando se cumple el resultado esperado (o un caso de prueba cuyo estado es
"Aprobado"), este campo puede dejarse vacío. Porque, si se cumple el resultado esperado,
significa que el resultado real = resultado esperado, lo que significa que volver a escribirlo
en la columna de resultado real será una repetición y una redundancia.
Se puede adjuntar una captura de pantalla de la desviación a esta columna para una mayor
claridad de cuál es el problema.

INFORMES DE ESTADO DE PRUEBA DE SOFTWARE

INFORME DE ESTADO DIARIO

La información que debe ser parte del "Informe de estado diario" de una persona es:

• ¿Qué hiciste hoy?

• ¿Qué piensas hacer mañana?
• ¿Enfrentó algún problema durante su día? En caso afirmativo, ¿cómo los resolvió o
todavía están abiertos?
• ¿Necesitas algún aporte para mañana? En caso afirmativo, ¿de quién y qué son?

El destinatario de este correo electrónico/informe es generalmente el gerente, también los

miembros del equipo pueden recibir CC en algunos casos; esto depende del protocolo de
comunicación que siga el equipo.

INFORMES DE LAS PRUEBAS

Ahora es el momento de ser específico y aprender todo acerca de los informes que envían
los equipos de pruebas/control de calidad.

Los equipos de prueba envían varios informes en diferentes fases del STLC.

• Estado del plan de prueba

• Estado de la documentación de prueba
• Estado de ejecución de prueba (estado de defecto)

Plan de Pruebas: Es suficiente para comunicarse con el resto de los equipos del proyecto,
cuando se crea un plan de pruebas o cuando se realiza un cambio importante en el mismo.

Documentación de prueba: informe a todos los equipos cuándo comenzó el diseño de las
pruebas, la recopilación de datos y otras actividades y también cuándo finalizó. Este informe
no solo les informará sobre el progreso de la tarea, sino que también les indicará a los
equipos que deben revisar y aprobar los artefactos que son los siguientes.

Ejecución de prueba: La ejecución es la fase de un proyecto en la que el equipo de prueba

es el foco principal, tanto positiva como negativamente, somos tanto los héroes como los
villanos.

Un día típico durante un ciclo de prueba no se realiza a menos que se envíe el Informe de
estado diario. En algunos equipos, podrían acordar un informe semanal, pero enviarlo
diariamente es la norma.

Tampoco es raro tener una reunión de estado todos los días (o semanas) para presentar el
estado del equipo de control de calidad a las partes interesadas.

Por lo tanto, el modo de un informe de estado puede ser:

• Correo electrónico/documento
• Reunión/presentación
• Ambos: correo electrónico diario y reunión semanal más o menos.
INFORME DE ESTADO DE EJECUCIÓN DE PRUEBA

Informe de ejecución de prueba diario/semanal:

¿Qué es? Por lo general, se trata de una comunicación enviada para establecer la
transparencia de las actividades del día del equipo de control de calidad durante el ciclo de
prueba; incluye información sobre defectos e información sobre la ejecución del caso de
prueba.

¿A quién debería ir? – Normalmente, el equipo de desarrollo, el equipo de soporte del

entorno, el analista comercial y el equipo del proyecto son los destinatarios/participantes de
la reunión. El Plan de prueba es el mejor lugar para encontrar esta información.

¿Qué contiene un informe de estado de ejecución de prueba?

1. Número de casos de prueba planificados para ese día

2. Número de casos de prueba ejecutados ese día
3. Número de casos de prueba ejecutados en general
4. Número de Defectos encontrados ese día/y sus respectivos estados
5. Número de Defectos encontrados hasta el momento/y sus respectivos estados
6. Número de defectos críticos: aún abiertos
7. Tiempos de inactividad del entorno, si los hay
8. Showstoppers - si los hay
9. Adjunto de la hoja de ejecución de pruebas / Enlace a la herramienta de Gestión de
Pruebas donde se ubican los casos de prueba
10. Archivo adjunto al informe de error/enlace a la herramienta Defecto/Prueba/Gestión
utilizada para la gestión de incidentes

Los 10 puntos anteriores, si observa de cerca, son los datos sin procesar. Reportar los
hechos es una cosa y reportar algunos hechos “inteligentes” es otra. ¿Cómo refinamos esta
información?

Muestra el estado general con un indicador de color. Por ejemplo, Verde: a tiempo, Naranja:
Ligeramente atrasado, pero puede absorber el retraso, Rojo: Retrasado.

Incluya algunas métricas simples como el % de casos de prueba aprobados hasta el

momento, la densidad de defectos, el % de defectos graves; Al hacer esto, no solo está
dando números, en realidad está dando una idea de la calidad del producto que está
probando.

Si una fase significativa está completa, resáltela.

Si hay un defecto crítico que va a bloquear toda/una parte de la ejecución futura, resáltelo.

Si usa una presentación, asegúrese de incluir algunos gráficos para tener un mejor impacto.

Por ejemplo, el siguiente gráfico es una representación del número de defectos abiertos,
por módulo:
Aparte de estos, también puede incluir opcionalmente:

• ¿Cuáles son las próximas actividades previstas?

• ¿Necesita algún aporte de alguno de los otros equipos y, de ser así, qué?

Por último, algunos consejos para ayudar en el proceso:

Ser conciso a la vez que completo.

Asegúrese de que los resultados que informe sean precisos

Use puntos con viñetas para que el informe sea muy legible

Vuelva a verificar para incluir la fecha, el asunto, la lista y los archivos adjuntos correctos.

Si el Informe es demasiado grande y tiene demasiados factores para informar: colóquelo en

una ubicación común como un archivo y envíe un enlace en el correo electrónico en lugar
del archivo en sí. (Asegúrese de que los destinatarios tengan permisos de acceso a esta
ubicación y al archivo)

Si se trata de una reunión de estado: prepárese para la presentación, llegue a tiempo y, lo

que es más importante, mantenga un tono uniforme (no se enorgullezca demasiado de los
defectos, en general son "malas noticias").

INFORME DE ESTADO DE MUESTRA

Informe de estado de las pruebas de control de calidad:

Siguiendo estas pautas, llegamos al siguiente informe de estado.

ACTIVIDADES DE CIERRE
Las actividades de cierre de prueba son aquellas actividades que se realizan al final del
proceso de prueba. Por lo general, se realizan después de que se entrega el producto,
como generar un informe de prueba, etc. De acuerdo con el proceso de prueba, es esencial
garantizar que los procesos para entregar información de origen esencial para evaluar los
criterios de salida y los informes estén disponibles y sean efectivos.

La planificación, el seguimiento y el control de las pruebas también incluyen la explicación

de los requisitos de información y las técnicas utilizadas para recopilar la información.

Desde la fase de análisis de la prueba hasta la ejecución, pasando por el diseño y la

implementación, el Gerente de prueba debe asegurarse de que los miembros del equipo
proporcionen la información de manera correcta y oportuna. Esto es necesario para una
evaluación y un informe eficientes.

La tasa de informes y su profundidad depende del proyecto y de la organización. Ambos

factores deben discutirse durante la planificación de la prueba después de las
conversaciones con las partes interesadas del proyecto.

¿QUÉ SON LAS ACTIVIDADES DE CIERRE DE PRUEBA?

Una vez que se declara finalizada la fase de ejecución de la prueba, se deben capturar los
resultados importantes para archivarlos o transmitirlos a la persona interesada.

Juntas, estas tareas forman las actividades de cierre de prueba, que se dividen en estos
cuatro grupos clave:

1. COMPROBACIÓN DE LA FINALIZACIÓN DE LAS PRUEBAS

Aquí, el administrador de pruebas se asegura de que todos los trabajos de prueba se hayan
completado realmente. Por ejemplo, cada prueba planificada debe haberse ejecutado o
evitado deliberadamente.

Todos los errores conocidos deben corregirse, aplazarse o reconocerse como limitaciones
permanentes. En caso de corrección de errores, las correcciones también deben probarse.

2. ENTREGA DE OBJETOS DE PRUEBA

Los productos de trabajo relevantes deben pasarse a las personas relevantes. Por ejemplo,
los errores conocidos deben comunicarse al equipo de mantenimiento del sistema.

Las pruebas y su información de configuración deben transmitirse al equipo de pruebas de

mantenimiento. Los conjuntos de pruebas de regresión manuales y automáticas deben
registrarse y transmitirse al equipo de mantenimiento del sistema.

3. EXPERIENCIA DE APRENDIZAJE

Un componente importante de las actividades de cierre de pruebas son las reuniones que
analizan y documentan las lecciones aprendidas de las pruebas, así como el ciclo de vida
completo del desarrollo de software.

Estas discusiones se enfocan en asegurar que los buenos procesos se repitan y los malos
se eliminen en el futuro. Si quedan algunos problemas sin resolver, se vuelven parte de los
planes del proyecto.
Algunas de las áreas consideradas en futuros planes de prueba incluyen:

1. ¿Se involucró un amplio espectro de usuarios en el análisis de los riesgos de

calidad? Por ejemplo, muchas veces se descubren defectos inesperados al final del
proyecto.
• Podría haberse evitado si hubiera una representación más amplia de
usuarios en las sesiones de análisis de riesgos de calidad.
• Por lo que, en futuros proyectos, se incluirían más usuarios en estas
sesiones.
2. ¿Fueron correctas las estimaciones de la prueba? Si, por ejemplo, las estimaciones
han estado significativamente fuera de lugar, las futuras tareas de estimación deben
abordar las razones, como las pruebas ineficientes, detrás de esta estimación
incorrecta.
3. ¿Cuáles fueron los resultados del estudio de causa y efecto de los defectos y las
tendencias mostradas por ellos?
• Por ejemplo, si las solicitudes de cambio se propusieron tarde en el proyecto,
afectando la calidad del análisis y el desarrollo, Test Manager debe investigar
las tendencias que implican métodos incorrectos.
• Estas tendencias podrían ser como perder un nivel de prueba que tenía el
potencial de identificar defectos antes, uso de nuevas tecnologías, cambio en
los miembros del equipo, falta de experiencia, etc.
4. ¿Hay margen para mejorar los procesos de prueba?
5. ¿Hubo alguna desviación inesperada del plan de prueba, que debería incorporarse
en la planificación de pruebas futuras?
4. ARCHIVAR

Los documentos de prueba como los informes y registros de prueba y los productos de
trabajo deben archivarse en el sistema de gestión de configuración. Es decir, tanto los
planes de prueba como los de proyecto, con una relación clara con la versión y el sistema
utilizado para la prueba, deben estar disponibles en el archivo de planificación.

Las tareas mencionadas anteriormente son muy importantes, pero los equipos de prueba
generalmente las pasan por alto. Por lo tanto, deben estar claramente integrados en el plan
de prueba.

Una o más de estas tareas pueden quedar fuera debido a cualquiera de estas razones:

• Reasignación inoportuna
• Eliminación de miembros del equipo.
• Demanda de recursos para otros proyectos
• fatiga del equipo
Para garantizar la inclusión de estas tareas en el plan de pruebas, el contrato debe
mencionarlas explícitamente.

Considere el desarrollo de un sitio web de comercio electrónico simple.

El sitio web debe tener una página de inicio de sesión y el inicio de sesión debe ser exitoso
solo si se ingresan las credenciales correctas. En la página de inicio, se deben proporcionar
todos los detalles de la oferta y los enlaces rápidos a otras páginas. Pruébelo para
asegurarse de que está entrando en la página correcta. Asegúrese de que la búsqueda
funcione según el valor ingresado y que se muestren contenidos válidos. Además,
asegúrese de que, al realizar el pedido, el pago correspondiente sea correcto. Veamos en
detalle.

1. Pruebas de la página de inicio:

• ¿Se desplazará automáticamente?

• Si es así, ¿en qué momento se actualizará la imagen?
• Si el usuario navega por él, ¿seguirá desplazándose al siguiente?
• ¿Se puede mover en la parte superior?
• ¿Se puede hacer clic?
• Si es así, ¿conduce a la página correcta y al acuerdo correcto?
• ¿Se carga junto con el resto de la página o se carga al final en comparación con
otras funciones de la página?
• ¿Se puede ver todo el contenido?
• ¿Proporciona lo mismo para diferentes navegadores y diferentes resoluciones de
pantalla?
2. Prueba de algoritmo de búsqueda:

• Busque según el nombre del producto, el nombre del producto o, más

específicamente, la categoría. Ejemplo Cámara, Canon EOS 700D, electrónica, etc.
• Los resultados de búsqueda deben ser consistentes
• Deben estar disponibles diferentes tipos de opciones, según el producto, el precio,
las reseñas/calificaciones, etc.
• ¿Cuántos resultados se mostrarán por página?
• Con resultados de varias páginas, hay opciones de navegación.
• Además, se realizan búsquedas en muchos lugares. Considere rechazar la
búsqueda a múltiples niveles al verificar esta funcionalidad.
3. Página de detalles del producto:

• Fotografías o imágenes de productos.

• Precio del producto.
• Detalles de producto.
• Actualizaciones.
• Consulta las opciones.
• Opciones de entrega.
• Información de envío.
• Disponible / Caduca en stock.
• Múltiples colores u opciones de contraste.
4. Prueba de pago:

• Consulta las diferentes opciones de pago.

• Si acepta salir como invitado, simplemente complete la compra y ofrezca la opción
de registro al final.
• Clientes que regresan: inicie sesión para verificar.
• Registrar un usuario.
• Si conserva la tarjeta de crédito de un cliente o cualquier otra información financiera,
realice una verificación de seguridad para asegurarse de que sea segura (debe
cumplir con PCI).
• Si el usuario lleva mucho tiempo registrado, asegúrese de que la sesión haya
caducado o no. Cada sitio tiene un límite diferente. Para otros, 10 minutos. Para
otros, puede ser diferente.
• Correos electrónicos / Texto de verificación con el número de pedido generado.
5. Prueba del carrito de compras:

• Agregue artículos al carrito y continúe comprando.

• Si el usuario agrega el mismo artículo al carrito mientras continúa comprando, la
cantidad de artículos en el carrito debería aumentar.
• Todos los artículos y sus totales deben mostrarse en el carrito.
• Deben utilizarse los impuestos locales.
• El usuario puede agregar más artículos al carrito, el valor debe mostrar lo mismo.
• Actualizar el contenido agregado al valor del carrito también debería reflejar eso.
• Retire artículos del carrito.
• Pasar por la caja.
• Calcula los gastos de envío con diferentes opciones de envío.
• Introduce cupones.
• No marque, cierre el sitio y regrese más tarde. El sitio debe mantener los artículos
del carrito.
6) Después de la prueba de pedido

Verificar:

• Cambia el orden.
• Cancelar orden.
• Orden de pista.
• Está regresando.
Análisis de prueba para el sitio web:

• Comprobación de la compatibilidad de varios navegadores.

• Errores de visualización de página / Retraso en la descarga.
• Fecha de caducidad de la sesión y guardado automático de datos.
• Facilidad de acceso.
• 24 * 7 Disponible.
• Sin contenido ofensivo.
• Copia de seguridad y recuperación.
• Transacciones Garantizadas.
• Performance
Pruebas de rendimiento = Muy importante en el comercio electrónico

A veces hay retrasos de unos 250 milisegundos en el tiempo de carga de la página, que es
lo que hace que tu cliente siga compitiendo. Walmart, un minorista importante, está
ajustando la velocidad de su sitio y ha visto un aumento del 2 % en las tasas de conversión
de visitantes y un 1 % en los ingresos.

El rendimiento de su sitio depende de estos factores:

1. Rendimiento:

• Pregunta en un segundo.
• Actividad por minuto.
• Realizar con cada clic.
2. Tiempo de respuesta:

• Duración del trabajo.

• Segundos por clic.
• Carga de página.
• Comprobación de DNS.
• La duración entre los clics y la vista de página.
Revise los conceptos básicos de las pruebas: este es el primer y principal paso para lograr
el mismo objetivo. Cada especificación se implementa para que el equipo reciba
asesoramiento sobre funciones, características, interfaz de usuario, etc., lo que proporciona
una buena comprensión de la estructura del sistema.

Identificar escenarios de prueba: después del análisis del equipo, la siguiente tarea es
crear escenarios que validen el rendimiento y las funciones del sistema. Por ejemplo, un
usuario debería poder cancelar un pedido que haya realizado en un pedido de cancelación
de pedido.

Diseño de escenarios de prueba: después de identificar los diversos escenarios que deben
verificarse, existe la necesidad de crear escenarios experimentales mediante la preparación
de datos experimentales. Los datos de prueba incluyen la creación de valores de entrada y
salida sobre la base de la comprensión de la aplicación. Uno puede referirse al patrón de
uso de datos del usuario final. Un ejemplo de un estado de prueba sería el inicio de sesión
del usuario -> aplicar filtro por categoría-> agregar el producto al carrito. Los datos de
prueba reales se corrigen en esta etapa.

Entradas esperadas e inesperadas: ahora se compararon los resultados para determinar si

hay desviaciones esperadas y reales. La causa de la desviación se considera y se anota
para la misma corrección
CONTROL Y MONITOREO
El Monitoreo de Pruebas y el Control de Pruebas es básicamente una actividad de gestión.
El Monitoreo de Pruebas es un proceso de evaluación y retroalimentación sobre la fase de
prueba “actualmente en progreso”. Test Control es una actividad de guiar y tomar acciones
correctivas basadas en algunas métricas o información para mejorar la eficiencia y la
calidad.

La actividad de supervisión de pruebas incluye:

1. Proporcionar feedback al equipo y a los otros usuarios interesados en el progreso

de los esfuerzos de prueba.
2. Informar los resultados de las pruebas realizadas, a los miembros asociados.
3. Encontrar y rastrear las métricas de prueba.
4. Planificación y Estimación, para decidir el camino de acción futuro, en base a las
métricas calculadas.
Los puntos 1 y 2 hablan sobre los Informes de prueba, que es una parte importante del
Monitoreo de prueba. Los informes deben ser precisos y conscisos. Aquí es importante
comprender que el contenido del informe difiere para cada parte interesada.

Los puntos 3 y 4 hablan de las métricas. Las siguientes métricas se pueden utilizar para la
supervisión de pruebas:

• Métrica de cobertura de prueba.

• Métricas de ejecución de pruebas (Número de casos de prueba aprobados, fallidos,
bloqueados, en espera).
• Métricas de defectos.
• Métricas de trazabilidad de requisitos.
• Métricas varias como el nivel de confianza de los tester, hitos de fecha, costo,
cronograma y tiempo de respuesta.

MÉTRICA

Una métrica es una medida cuantitativa del grado en que un sistema, componente del
sistema o proceso posee un atributo dado. Las métricas se pueden definir como
"ESTÁNDARES DE MEDICIÓN".

Las métricas de software se utilizan para medir la calidad del proyecto. Simplemente, una
métrica es una unidad utilizada para describir un atributo. La métrica es una escala para
medir.

Supongamos que, en general, “Kilometro” es una métrica para medir el atributo “Distancia”.
De manera similar, en el software, "¿Cuántos problemas se encuentran en mil líneas de
código?", Aquí el número de problemas es una medida y el número de líneas de código es
otra medida. La métrica se define a partir de estas dos medidas.

Ejemplo de métricas de prueba:

o ¿Cuántos errores existen dentro del módulo?

o ¿Cuántos casos de prueba se ejecutan por tester?
o ¿Qué es el porcentaje de cobertura de prueba?
¿Por qué probar métricas?

La generación de métricas de prueba de software es la responsabilidad más importante del

líder/gerente de prueba de software. Las métricas de prueba se utilizan para:

o Tomar las decisiones necesarias para la siguiente fase de actividades.

o Comprender qué tipo de mejora se requiere para el éxito del proyecto.
o Tomar una decisión sobre las modificaciones a realizar.
Importancia de las métricas de prueba de software:

Por ejemplo, un analista de pruebas tiene que:

1. Diseñar los casos de prueba para 3 requisitos.

2. Ejecutar estos 3 casos de prueba diseñados.
3. Registrar los errores, buggs o fallos encontrados en los casos de prueba
relacionados
4. Una vez resuelto volver a ejecutar el caso de prueba fallido correspondiente.
En el escenario anterior, si no se siguen las métricas, el trabajo realizado por el analista de
pruebas será subjetivo, es decir, el informe de pruebas no tendrá la información adecuada
para conocer el estado de su trabajo/proyecto.

Si las métricas están involucradas en el proyecto, entonces se puede publicar el estado

exacto de su trabajo con los números/datos adecuados. Es la manera en la que los tester
cuantifican las pruebas.

CONTROL DE PRUEBAS

El Control de Pruebas implica orientar y tomar medidas correctivas de la actividad, con base
en los resultados del Monitoreo de Pruebas. Los ejemplos de control de prueba incluyen:

1. Priorización de los esfuerzos de prueba

2. Revisión de los horarios y las fechas de las pruebas
3. Reorganización del entorno de prueba
4. Repriorización de los casos/condiciones de prueba
La supervisión y el control de las pruebas van de la mano. Al ser principalmente una
actividad de gerente, un Analista de Pruebas contribuye a esta actividad recopilando y
calculando las métricas que eventualmente se utilizarán para el seguimiento y el control.

Material de apoyo sugerido:

a) https://youtu.be/dqXMsRNn9y8
b) https://youtu.be/J0npT0X5-9Y
c) https://youtu.be/AWuP4p5tZx8
 PFASES DE STLCP
Les dejamos un esquema para recordar las fases del STLC.

ETAPA STLC CRITERIO ACTIVIDAD CRITERIO DE ENTREGABLES

ENTRADA SALIDA

Documento de Analice la funcionalidad comercial RTM firmado RTM

ANALISIS DE requisitos para conocer los módulos Informe de Informe de
REQUERIMIEN disponible (tanto comerciales y las funcionalidades viabilidad de viabilidad de
funcional como no específicas de los módulos.
TOS funcional) automatizaci automatización (si
Identifique todas las transacciones ón de corresponde)
Criterios de en los módulos. pruebas
aceptación Identificar todos los perfiles de firmado por
definidos. el cliente
usuario.
Documento de
arquitectura de la Reúna los requisitos de
aplicación autenticación/interfaz de usuario y
disponible. distribución geográfica.
Identificar los tipos de pruebas a
realizar.
Reúna detalles sobre las
prioridades y el enfoque de las
pruebas.
Elaborar Matriz de Trazabilidad de
Requerimientos (RTM).
Identifique los detalles del entorno
de prueba donde se supone que se
llevarán a cabo las pruebas.
Análisis de factibilidad de
automatización (si se requiere).

PLANIFICACI Requisitos Analizar varios enfoques de prueba Plan de Plan de

ÓN Documentos disponibles prueba/docu prueba/document
mento de o de estrategia.
Matriz de Finalizar con el enfoque más estrategia
Trazabilidad de adecuado Documento de
Requerimientos. aprobado. estimación de
Preparación del plan de
Documento de prueba/documento de estrategia Documento esfuerzo.
viabilidad de para varios tipos de prueba de
automatización de estimación
Selección de herramienta de de esfuerzo
pruebas. prueba firmado.
Estimación del esfuerzo de prueba
Planificación de recursos y
determinación de roles y
responsabilidades.

DISEÑO Y Requisitos Cree casos de prueba, diseño de Casos/guion Casos de

ANÁLISIS Documentos prueba, scripts de automatización es de prueba prueba/guiones
RTM y plan de (cuando corresponda) revisados y Datos de prueba
pruebas Revisión y línea base de casos de firmados
prueba y scripts Datos de
Informe de análisis prueba
de automatización Crear datos de prueba revisados y
firmados

EJECUCIÓN Los documentos de Comprender la arquitectura La Entorno listo con

diseño y requerida, la configuración del configuración configuración de
arquitectura del entorno. del entorno datos de prueba
sistema están funciona
disponibles Preparar la lista de requisitos de según el plan Resultados de la
desarrollo de hardware y software prueba de humo
 El plan de Finalizar los requisitos de y la lista de
configuración del conectividad verificación
entorno está
disponible Preparar la lista de comprobación La
de configuración del entorno configuración
Configuración de prueba Entorno y de datos de
prueba está
datos de prueba completa
Realice una prueba de humo en la La prueba de
construcción.
humo es
Aceptar/rechazar la compilación exitosa
según el resultado de la prueba de
humo

RTM base, plan de Ejecutar pruebas según el plan Se ejecutan RTM completado
prueba, caso de Documente los resultados de las todas las con estado de
prueba/guiones pruebas y registre los defectos de pruebas ejecución
disponibles planificadas. Casos de prueba
los casos fallidos
El entorno de Defectos actualizados con
Actualizar planes de prueba/casos
prueba está listo de prueba, si es necesario registrados y resultados
rastreados
La configuración de Asignar defectos a casos de prueba hasta el Informes de
datos de prueba defectos
está hecha en RTM cierre
El informe de Vuelva a probar las correcciones de
defectos
prueba de
unidad/integración Pruebas de regresión de la
para la compilación aplicación
que se probará está Rastree los defectos hasta el cierre
disponible

ACTIVIDADES La prueba ha sido Evalúe los criterios de finalización Informe de Informe de cierre
DE CIERRE completada del ciclo en función de: tiempo, cierre de de prueba
Los resultados de cobertura de prueba, costo, calidad prueba Métricas de
las pruebas están del software, objetivos comerciales firmado por prueba
disponibles críticos el cliente
Prepare métricas de prueba
Los registros de basadas en los parámetros
defectos están anteriores.
disponibles
Documentar el aprendizaje del
proyecto.
Preparar informe de cierre de
prueba
Reporte cualitativo y cuantitativo de
la calidad del producto del trabajo
al cliente.
Análisis de resultados de pruebas
para averiguar la distribución de
defectos por tipo y gravedad