MÓDULO

Área: NEGOCIOS

2 Curso: ASEGURAMIENTO DE CALIDAD

Módulo: Diseño de un plan de pruebas
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD

Diseño de un plan de pruebas

Índice
Introducción ......................................................................................................................................................... 1
1. Tipos de Pruebas............................................................................................................................................... 1
1.1. Pruebas de Caja Negra................................................................................................................................................ 1
1.2. Pruebas de Caja Blanca ............................................................................................................................................... 2
1.3. Pruebas de Caja Gris ................................................................................................................................................... 2
2. Técnicas de Prueba ........................................................................................................................................... 3
3. Definición de Plan de Pruebas .......................................................................................................................... 6
3.1 Relación entre Artefactos ............................................................................................................................................ 6
3.2. Secciones Principales del Plan de Pruebas ................................................................................................................. 6
a. Nombre ..................................................................................................................................................................... 6
b. Introducción .............................................................................................................................................................. 7
c. Alcance de la prueba ................................................................................................................................................. 7
d. Características a probar ............................................................................................................................................ 7
e. Características que no serán probadas ..................................................................................................................... 8
f. Estrategia de prueba .................................................................................................................................................. 8
g. Criterios de entrada................................................................................................................................................... 8
h. Criterios de salida ...................................................................................................................................................... 9
i. Entregables ................................................................................................................................................................. 9
j. Tareas de prueba ........................................................................................................................................................ 9
k. Necesidades de ambientes de prueba .................................................................................................................... 10
l. Responsabilidades, personal requerido y necesidades de entrenamiento .............................................................. 10
m. Calendario de las pruebas ...................................................................................................................................... 10
n. Riesgos y Contingencias .......................................................................................................................................... 11
3.3. Checklist de Validación del Plan de Pruebas ............................................................................................................ 12
4. Caso de Prueba ............................................................................................................................................... 12
4.1. Secciones Principales de un Caso de Prueba ............................................................................................................ 12
4.2. Técnicas para hacer casos de prueba ....................................................................................................................... 13
4.3. Checklist de Validación de un Caso de Prueba ......................................................................................................... 13
5. Script de Prueba ............................................................................................................................................. 14
5.1. Secciones principales de un Script de Pruebas ......................................................................................................... 14
5.2. Checklist de Validación de un Script de Pruebas ...................................................................................................... 14
Cierre .................................................................................................................................................................. 15
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD

Diseño de un plan de pruebas

Mapa de Contenido

Plan de Pruebas

Técnicas de Definición del

Tipos de prueba Casos de prueba Script de prueba
prueba plan de pruebas

Prueba de caja Relación entre Seccciones Secciones

negra artefactos. principales principales

Técnicas para
Prueba de caja Secciones Checklist de
hacer casos de
blanca principales. valiadación
prueba

Prueba de caja Checklist de Checklist de

gris validación validación
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 1

Diseño de un plan de pruebas

Resultado de
• Diseña un plan de pruebas para la detección de errores en un programa
aprendizaje del
computacional.
módulo

Introducción
Actualmente, observamos que la industria TI se enfrenta a los siguientes desafíos:
✓ La complejidad creciente de los proyectos.
✓ La presencia de más requerimientos de
integración entre los diferentes sistemas de la
organización y de las componentes de los
sistemas.
✓ Los plazos de entrega requeridos por el mercado
son cada vez más cortos.
✓ Una creciente intolerancia a los fallos del
software debido al impacto que los fallos tienen
en los usuarios.
✓ Con los mismos recursos, se exige más, en menos tiempo y menos plazo.

Enfrentar estas problemáticas ya no es posible sin planificar correctamente las actividades de desarrollo, para
intentar mitigar al máximo los impactos de los riesgos que estos desafíos conllevan y en este sentido las
pruebas del software no son ajenas.

Esta planificación recibe el nombre de Plan de Pruebas que, específicamente, es el documento que detalla de
forma sistemática cómo se probará un sistema y las consideraciones que se tendrán en cuenta. Además, es
una de las principales herramientas que hoy tiene el Gerente de Pruebas (Testing Manager), para asegurar
que todos los requerimientos sean probados con las técnicas de prueba correctas, y que estarán disponibles
todos los recursos necesarios a tiempo.

1. Tipos de Pruebas
Existen tres tipos de Prueba en la Ingeniería de Software: pruebas de caja negra; pruebas de caja blanca y
pruebas de caja gris. A continuación definiremos cada una de ellas.

1.1. Pruebas de Caja Negra

Son el tipo de prueba más común, porque no requiere de conocimientos
teóricos estrictos lo que hace que su costo de ejecución sea menor.

Ellas utilizan casos de prueba, orientados a probar y examinar el

cumplimiento de pruebas funcionales de una aplicación, sin evaluar la
estructura interna del sistema, enfocándose en las salidas generadas en
respuesta a entradas seleccionadas.
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 2

Diseño de un plan de pruebas

1.2. Pruebas de Caja Blanca
En este tipo de pruebas, el tester examina la estructura interna de la aplicación, y va eligiendo datos de
prueba con el fin de verificar las diferentes rutas o caminos que realizará el programa, determinando las
salidas apropiadas y las que no lo son.

Se requiere tener conocimiento del diseño del sistema, las herramientas

utilizadas en su construcción y que el Tester sepa programar. Se utilizan
en pruebas de componentes unitarias especializadas, cuya falla puede
reportar un costo crítico para la empresa.

Las herramientas de revisiones de código realizan pruebas de este tipo

en forma automática, y se usan como una forma de abaratar costes en este tipo de pruebas.

Ventajas Desventajas
Creación de casos de prueba en base a lógica de Las pruebas tienen una menor cobertura.
la aplicación.
No es posible probar todo, porque los caminos de
Conocimiento de cómo el comportamiento del ejecución que puede tomar un programa son
software está siendo verificado y este cumple con muchos. Un caso de esto son los sitios Web, en que
las buenas prácticas de programación, con el fin es difícil estimar todos los intentos de ejecución que
de evitar errores por construcción de los hará un usuario.
programas
Se requiere conocimientos de programación y de las
herramientas usadas para programar, por lo que el
Tester debe ser más especializado, lo que encarece
el costo de este tipo de pruebas

1.3. Pruebas de Caja Gris

Son una combinación de pruebas de Caja Blanca y la Caja Negra. El
objetivo de esta prueba, es buscar defectos ocasionados por uso
inadecuado o estructura inapropiada de la aplicación. Generalmente
se usan en pruebas de rendimiento para saber si el tiempo de
ejecución será el adecuado, así como el uso de recursos del sistema.

Un tester de caja Gris sabe parcialmente la estructura de la aplicación

y conoce la lógica de los algoritmos. No obstante, no necesariamente
tiene acceso al código y la lógica implementada.

Al igual que en el caso de las pruebas de Caja Blanca, se requieren conocimientos de ingeniería de software
para poder efectuar la prueba.
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 3

Diseño de un plan de pruebas

2. Técnicas de Prueba
Una técnica de prueba es una forma de probar el software, que se utiliza dependiendo del tipo de aplicación
que se debe probar. A continuación revisaremos las principales:

Técnica Objetivo Ventajas Desventajas Uso

Exploratorias Diseñar, Los defectos se El alcance de las Se utilizan cuando la
documentar y encuentran y pruebas depende de la documentación de las
ejecutar pruebas resuelven más experiencia y aplicaciones no está
en forma rápido. habilidades del tester. lista.
simultánea a la
ejecución de las Requiere de menos Sirve para probar
pruebas. preparación y prototipos de
planificación. productos, juegos, y
Es decir, evaluar y en desarrollo con
conocer la No es necesario que metodologías ágiles,
aplicación, el equipo de pruebas en que el Tester
mientras se tenga experiencia en trabaja en conjunto
ejecuta. la aplicación. con el desarrollador

Función Probar una Fácil de No garantiza que Pruebas a cambios

funcionalidad a la implementar y todas las realizados a una
vez y de forma ejecutar. funcionalidades del aplicación existente o
aislada. producto operen bien una a parte de ella.
en forma conjunta e
integrada.
Basadas en la Verificar que la Fácil identificación Los requerimientos Pruebas de sistemas
especificación aplicación se del alcance de las que no fueron con documentación
comporta según lo pruebas. incluidos en la completa, revisada y
descrito en la documentación aprobada.
documentación tampoco serán
del sistema. verificados, aunque Aplicaciones que
hayan sido deben contemplar el
construidos. uso de normativas
internas y/o externas.
Documentación
defectuosa, puede
implicar reportar
defectos que en
realidad no lo son.
Basadas en Encontrar Ayuda a optimizar la La identificación de las Se utiliza para probar
riesgo defectos críticos lo priorización de las funcionalidades aplicaciones que
antes posible, pruebas, críticas de la aplicación sufren cambios en
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 4

Diseño de un plan de pruebas

priorizándolos considerando puede tornarse
forma muy frecuente,
sobre el resto. funciones críticas. subjetiva, sino se por lo que se hace
maneja información necesario limitar el
de las funcionalidadesalcance de las pruebas
críticas y su
a la verificación de las
desempeño antes de funcionalidades que
la prueba. se utilizan con mayor
frecuencia, o que se
definen como
procesos críticos para
la organización.
Análisis de Reducir la Permite verificar Se pueden ignorar Verificar el
Equivalencia cantidad de que la aplicación se defectos provocados comportamiento de
pruebas comporta por datos que no campos numéricos.
dividiendo el correctamente forman parte de la Ej.: RUT.
dominio de los ejecutando una muestra seleccionada,
datos de modo menor cantidad de pero que representan Verificar el
que sean elegidos pruebas. defectos graves comportamiento de
para las pruebas, igualmente. funcionalidades con
sólo los más muchas variables.
representativos. Ej.: interfaces
Ej.: Tipos de bancarias
cliente.
Escenario Probar situaciones Permite verificar el Es posible plantear Probar aplicaciones
que pueden correcto escenarios irreales si el que tienen muchas
presentarse en la comportamiento de analista o el tester no reglas de negocio y
vida real la aplicación ante conocen las combinan muchos
situaciones del día a situaciones posibles. datos según su lógica.
día.
Regresión Detectar defectos Permite verificar No es posible verificar Probar aplicaciones
producidos por los que las el 100% de las que han sido
cambios funcionalidades funcionalidades de la modificadas,
realizados en una anteriores de la aplicación cada vez particularmente en
aplicación, no aplicación continúan que se introduce un situaciones de
provocan otros funcionando cambio, por lo que integración de
errores de correctamente pueden ignorarse sistemas en
acarreo. defectos que pueden situaciones de riesgo
detectarse después en para el negocio
producción.
Aceptación Validar que la Permite obtener El alcance de la prueba Este tipo de pruebas
aplicación cumple retro alimentación no está garantizado se realizan en la etapa
los requerimientos del usuario final pues depende de la de pruebas de
acordados con las sobre el experiencia del aceptación del usuario
partes interesadas comportamiento de usuario final y la forma (Pruebas de UAT), y se
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 5

Diseño de un plan de pruebas

la aplicación. en que se han deben realizar antes
acordado las pruebas de poner el software
en el plan. en producción.

Si se ha ignorado algún
requerimiento vital
para el usuario final,
puede existir la
necesidad de retomar
todo el desarrollo en
una etapa muy tardía
del desarrollo.
Estrés Determinar la Permite identificar Se detectan defectos De uso común en
robustez de la debilidades que que son muy difíciles aplicaciones que serán
aplicación presentará la de reproducir y utilizadas por muchos
mediante la aplicación cuando se corregir, sobre todo usuarios en forma
prueba de encuentre en cuando el ambiente simultánea.
condiciones que producción queda inestable, el
van más allá de los dato queda inservible.
límites
considerados Los defectos pueden
normales. requerir soluciones de
hardware y no sólo de
software.

Requiere personal
especializado
técnicamente para su
ejecución.
Rendimiento Determinar el Ayuda a identificar Requiere personal Uso en aplicaciones
comportamiento la capacidad máxima especializado para la que serán usadas por
del sistema en de funcionamiento prueba. un volumen
condiciones de una aplicación, simultáneo de
normales y así como los cuellos Difícil análisis de los usuarios alto, y/o que
previstas de carga de botella, defectos detectados. manejan un volumen
máxima determinando que de datos alto.
elemento está
causando la
degradación.
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 6

Diseño de un plan de pruebas

3. Definición de Plan de Pruebas
Abordaremos el artefacto Plan de Pruebas de Software, recordando que es el documento que detalla de
forma sistemática cómo se probará un sistema y las consideraciones que se tendrán en cuenta para ello.

Este documento incluye:

• La cobertura de la prueba: todos los requerimientos deben tener al menos un caso de prueba.
• Los métodos o técnicas de prueba que serán utilizados.
• Las responsabilidades en el esfuerzo de pruebas: descripción de roles y actividades.

3.1 Relación entre Artefactos

Los artefactos de SQA están relacionados de la siguiente forma:

Plan de Pruebas

Casos de Prueba Suites de Prueba

Scripts de Pruebas Casos de Prueba

Scripts de Pruebas

Un plan de pruebas por lo tanto, puede tener:

• Uno o más casos de prueba y este, a su vez, puede tener uno o más scrips de pruebas.
• Tantas suites de pruebas como sea necesario, sin embargo, no es obligatorio que las posea.

3.2. Secciones Principales del Plan de Pruebas

Las siguientes son las secciones mínimas que puede tener un plan de pruebas de SQA.

a. Nombre
Identificador del Artefacto o documento, fecha de creación y autor.
Ejemplo:
Plan de Pruebas Calculadora Acme
29 de julio de 2017
Autor: Pablo Gómez
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 7

Diseño de un plan de pruebas

b. Introducción
Se explica la misión e intención del esfuerzo de pruebas.
Ejemplo:
En este documento se describe el plan de pruebas para verificar la aplicación Calculadora Acme.

El plan tiene los siguientes objetivos:

o Identificar la información existente del proyecto.
o Identificar los componentes que deberán ser probados.
o Enumerar los casos de prueba recomendados (alto
nivel).
o Recomendar y describir las estrategias de prueba que
han de emplearse.
o Identificar los recursos necesarios.
o Enumerar los entregables del esfuerzo de pruebas.
o Entregar una estimación de los esfuerzos y plazos que
tomarán las pruebas”.

c. Alcance de la prueba
Se describe cuál es la cobertura del esfuerzo de las pruebas. Se puede hacer referencia a los documentos que
contienen los requerimientos que deben ser verificados.
Ejemplo:

El alcance de las pruebas cubre todas las funcionalidades descritas

en el documento Especificación de Requerimientos para la
Calculadora Acme aprobado con fecha 31 de Enero de 2017.

d. Características a probar
Se mencionan todas las funciones y características que serán probadas.
Ejemplo:
Se probarán las siguientes funciones:
o Suma con y sin memoria.
o Resta con y sin memoria.
o Multiplicación con y sin memoria.
o División con y sin memoria.
o Carga del resultado en memoria.
o Borrado de memoria.
o Encendido/Apagado de la calculadora.

Para la verificación de estas funciones, se realizarán pruebas de Caja Negra.

 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 8

Diseño de un plan de pruebas

e. Características que no serán probadas
Se mencionan todas las funciones y características que no serán probadas.
Ejemplo:
• No se realizarán pruebas de verificación sobre características y
funciones que no estén descritas en el documento de
requerimientos Especificación de Requerimientos para la
Calculadora Acme aprobado con fecha 31 de Enero de 2017.
• No se realizarán pruebas de caja blanca, pruebas de caja gris,
pruebas de estrés y pruebas de rendimiento.
• Este plan no cubre las pruebas de aceptación del usuario, las que
quedarán de cargo del área de pruebas de mercado.

Las pruebas mencionadas se excluyen porque:

• No se consideran necesarias para garantizar la calidad de la aplicación.
• No se cuenta con el tiempo y recursos necesarios para efectuar dichas pruebas.
• No contribuyen a lograr la misión de este esfuerzo de pruebas.

f. Estrategia de prueba
Describe las técnicas que serán utilizadas para probar la aplicación y como serán implementadas para los
tipos de prueba se serán usados.
Ejemplo:
Pruebas de Caja Negra
Objetivo Asegúrese de ejecutar las pruebas conforme se señala en
el documento de requerimientos y los resultados
esperados que en él se señalan.
Técnica Ejecute cada todos los casos de prueba
Use datos válidos y no válidos
Verifique que:
Se producen resultados esperados cuando se usan datos
válidos
Si se usan datos no válidos, se producen los mensajes de
error esperados.
Criterio de Todos los casos de prueba han sido ejecutados
Completitud Todos los defectos han sido reportados
Consideraciones Los defectos serán reportados al final de cada día de
especiales pruebas.

g. Criterios de entrada
Se describen todas las condiciones que deben darse para que una aplicación pueda ser probada por el área
de SQA.
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 9

Diseño de un plan de pruebas

Ejemplo:
La aplicación podrá ser recibida en SQA cuando:
• Se ha terminado el desarrollo de la aplicación, el documento de requerimientos está
aprobado por el cliente y el documento de diseño está aprobado por el área de
arquitectura.
• La aplicación está instalada en la plataforma de pruebas.

h. Criterios de salida
Describe los motivos por los que puede salir del área de pruebas.
Ejemplos:
La aplicación saldrá del área de SQA cuando:
• La aplicación no funciona y/o no permite hacer las
pruebas.
• Se han terminado todas las pruebas del plan.

i. Entregables
En esta sección se presenta un listado de los artefactos que el área de pruebas generará y presentará a los
interesados.
Ejemplo:
El área de SQA generará los siguientes entregables de la prueba:
• El informe de resultado de las pruebas.
• El detalle de los defectos encontrados.

j. Tareas de prueba
Contiene un listado de diferentes las actividades que se realizarán para probar la aplicación.
Ejemplo:
El equipo de SQA será responsable de:
• Construir el plan de pruebas.
• Implementar las pruebas.
• Ejecutar las pruebas y reportar los defectos
encontrados.
• Entregar un informe de resultado de las pruebas.

Por su parte el equipo de desarrollo se encargará:

• Revisar y corregir los defectos reportados con 48 de plazo máximo.
• Reportar los defectos mal informados por SQA, explicando el error.
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 10

Diseño de un plan de pruebas

k. Necesidades de ambientes de prueba
Se especifican las características que debe tener el ambiente donde se probará la aplicación.
Ejemplo:

Se requiere instalar la aplicación en un equipo del área de QA con

Windows 10.

l. Responsabilidades, personal requerido y necesidades de entrenamiento

Se describen los roles que serán usados en el proceso, la cantidad de personas en cada uno, y las necesidades
de capacitación previa, si las hay.
Ejemplo:
Para efectuar la prueba se requiere un Tester y un Analista de
Pruebas, media jornada.

m. Calendario de las pruebas

Contiene el plan de fechas de las actividades principales del esfuerzo de pruebas.
Ejemplo:

Hito Fecha Inicio Fecha Inicio Fecha Fin Fecha Fin Real
Planificada Real Planificada
Planificación de 27/7/2017 28/7/2017
las Pruebas
Diseño de las 29/7/2017 30/7/2017
pruebas
Ejecución de las 31/7/2017 3/8/2017
pruebas
Confección 4/7/2017 4/7/2017
informe de
resultados
Entrega del 5/7/2017 5/7/2017
informe de
resultados
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 11

Diseño de un plan de pruebas

IMPORTANTE

El plan debe ser discutido y aprobado con los interesados, y el calendario puede sufrir cambios sujetos a
la negociación con estos.

n. Riesgos y Contingencias
Se plantean los riesgos identificados al momento de la planificación y su estrategia de mitigación,
identificando al responsable de dicha estrategia.
Ejemplo:

Riesgo Mitigación Responsable

Al minuto de la Las fechas presentadas en Testing Manager.
confección de este este informe son tentativas,
informe, aún no hay y se confirmarán o re
fecha planificada para el planificarán cuando el JP
término del desarrollo. confirme el término del
desarrollo.
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 12

Diseño de un plan de pruebas

3.3. Checklist de Validación del Plan de Pruebas
Para estar seguros de que el plan de pruebas está correctamente confeccionado, se debe revisar que exista
respuesta a las siguientes preguntas:

¿El plan de pruebas identifica claramente el alcance y esfuerzo de prueba?

¿Cada requerimiento de la aplicación tiene al menos un caso de prueba identificado o una

justificación de porque no será probado?

¿Se han identificado los tipos de prueba a realizar?

¿Se ha descrito una estrategia de pruebas para cada uno de los tipos de prueba a realizar?

¿Se han identificado todos los recursos necesarios para realizar las pruebas (Hardware, software y
personal)?

¿El plan contiene una lista de hitos con fecha de inicio, realización y responsable definido?

¿El plan lista los artefactos y entregables a ser producidos?

4. Caso de Prueba
4.1. Secciones Principales de un Caso de Prueba
Las secciones principales de un caso de prueba son:
Nombre
•Identificador o título de la prueba que debe ser ejecutada.
Descripción
•Objetivos de la prueba.
Orden de Secuencia en la Ejecución:
•Número en la lista de casos de prueba, en que este caso de prueba debe ser ejecutado. Este número debe
ser único por caso de prueba: no puede estar repetido con otros casos de prueba.
Requerimiento asociado:
•Identificación del requerimiento asociado a la prueba.
Pre – condición:
•Condiciones en que debe estar el sistema, antes de que se ejecute este caso de prueba. Lo anterior tanto
para datos como para la ejecución de tareas previas relacionadas. Por ejemplo, para la prueba de borrado
de memoria de la calculadora Acme mencionada, una precondición es que la memoria tenga datos
registrados.
Post – condición:
•Condiciones en las que debe quedar el sistema. Siguiendo con el ejemplo anterior, la memoria debe
quedar en cero luego de ejecutar el borrado de memoria.
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 13

Diseño de un plan de pruebas

Ejemplo de un caso de prueba:
Caso de Prueba Suma de Números en Calculadora Acme

Nombre Efectuar suma de valores sin decimales

Descripción Sumar cualquier cantidad de valores de distinto tamaño, para números
enteros, en cualquier cantidad.
Orden de 2
Ejecución
Requerimiento Suma de valores en Calculadora Acme.
Asociado
Pre condición La memoria de la calculadora está vacía.
La pantalla está en cero.
Post condición En la pantalla aparece el resultado de la suma.
Resultado La calculadora es capaz de sumar correctamente todos los valores que se le
Esperado indican.
La memoria no se carga con ninguno de los valores, sino se ha pedido.
No permite sumar cuando alguno de los valores no es un número.

4.2. Técnicas para hacer casos de prueba

Los casos de prueba deben considerar los siguientes tipos de prueba.

• Probar con datos válidos una funcionalidad de la aplicación.

Ejemplo: ingresar un RUT válido.

• Probar con datos no válidos una funcionalidad de la aplicación.

Ejemplo: ingresar un RUT no válido como 1 -K.

• Probar la combinación de varias funcionalidades de la aplicación.

Ejemplo: Ingresar RUT y monto del depósito.

4.3. Checklist de Validación de un Caso de Prueba

• ¿Se ha indicado el objetivo de cada caso de prueba?
• ¿En cada caso de prueba indica el resultado esperado?
• ¿Se ha redactado al menos un caso de prueba para cada uno de los requerimientos?
• ¿En cada caso de prueba se indican las precondiciones y post condiciones?
• ¿Todos los nombres de los casos de prueba son diferentes y acorde con la prueba que se desea
realizar?
• ¿El orden de secuencia en la ejecución está establecido?
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 14

Diseño de un plan de pruebas

5. Script de Prueba
5.1. Secciones principales de un Script de Pruebas
Las secciones principales de un Script de pruebas son:
• Nombre: Identificador único o título del Script.
• Descripción: Objetivo del Script de Pruebas.
• Pasos: Instrucciones que indican al Tester las acciones que debe realizar sobre la aplicación y en qué
orden.
• Puntos de verificación: Son las acciones de verificación que debe ejecutar el Tester una vez que se
han realizado paso a paso cada una de las instrucciones a realizar.
• Resultados esperados: Todos los resultados que esperamos obtener, luego de que cada instrucción
ha sido ejecutada.
• Ejemplo:
Script de Prueba
Calculadora Acme
Nombre Suma con uso de la memoria de la Calculadora
Descripción Este script de prueba define los pasos y puntos de verificación necesarios para comprobar el
correcto funcionamiento de la función “uso de la memoria”
Tipo Pasos y Puntos de Verificación Resultados Esperados
Verificación Revise que la memoria está vacía. La memoria está en valor cero
Refiérase al caso de prueba
“Borrado de memoria”
Paso Ingrese un valor entero La calculadora tiene registrado en la pantalla el número
Paso Pulse la tecla M+ La memoria tiene registrado el valor ingresado
Paso Ingrese otro valor entero La calculadora tiene registrado en la pantalla el número
Paso Pulse la tecla M+ La memoria tiene registrado el valor sumado de los dos
valores ingresados.
Verificación Verifique que al pulsar la tecla El valor en la memoria no ha cambiado.
resultado de la memoria, el valor
sumado aún está en la memoria

5.2. Checklist de Validación de un Script de Pruebas

• ¿Se han redactado suficientes scripts como para alcanzar la cobertura de las pruebas?
• ¿Los nombres de cada script de prueba son diferentes y coherentes con la prueba que se desea
realizar?
• ¿Se han especificado los resultados esperados para cada uno de los puntos de validación?
 Área: NEGOCIOS M2
Curso: ASEGURAMIENTO DE CALIDAD Pág. 15

Diseño de un plan de pruebas

Cierre
En este módulo hemos aprendido sobre la estructura básica para construir un plan de prueba, que se
plantea, en la actualidad, como un instrumento fundamental para los Testing Manager, porque presenta de
forma detallada una síntesis de la metodología que se utilizará para probar un sistema. Por ello abordamos
su definición, los tipos de prueba, cada uno de los pasos que lo conforman, cómo se lleva a cabo para un caso
práctico, los aspectos fundamentales de un Script de prueba, entre otros de sus aspectos centrales.

Comprender su estructura, nos proporciona la base teórica que nos permitirá estar preparados para diseñar
de un plan de prueba, y posteriormente ejecutar las pruebas, evaluar de su resultado, para dar calidad al
proceso de detección de errores en softwares computacionales.

APORTE PARA TU FORMACIÓN

El plan de pruebas es el artefacto inicial y principal del Aseguramiento de la Calidad, actividad crítica en
el actual contexto de la Ingeniería de Software, porque facilita la mitigación de riesgos, comprobando las
técnicas de prueba, los recursos necesarios y la detección de errores. Por lo tanto, saber construirlo es
vital para la práctica profesional.