INSTITUTO TECNOLÓGICO SUPERIOR DE VALLADOLID.

ING. EN SISTEMAS COMPUTACIONALES.

ESPECIALIDAD: DESARROLLO DE SOFTWARE.

ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE.

LUIS ALBERTO BALAM MUKUL.

TEMA 3. PLAN DE PRUEBAS.

RESUMEN DEL TEMA 3.

Integrantes: Matricula:

ARCE NAHUAT RUBEN ULISES 18070023.

BERZUNZA PÉREZ MANUEL ELÍAS 18070013.

CEN POOL AARON MATEO 18070021.

OY CANSECO ADRIÁN LEONARDO 18070055.

PECH UN JOSUÉ OMAR 18070001.

8VO SEMESTRE

GRUPO A

VALLADOLID, YUCATÁN A 13 DE MAYO DE 2022.

Índice.
Introducción. .................................................................................................................... 3
3.1 Elementos de un plan de pruebas. ........................................................................... 4
3.2 Desarrollo de un plan de pruebas............................................................................. 7
Beneficios de las pruebas de software. ...................................................................... 8
3.3 Desarrollo de matriz de pruebas. .............................................................................. 8
Pasos para la realización de un plan de pruebas. ..................................................... 8
3.4 Desarrollo de casos de prueba. .............................................................................. 11
3.5 Definición de variables y constantes para las pruebas ........................................ 13
Sobre las variables de prueba ................................................................................... 13
Variables de matriz..................................................................................................... 14
Conclusión. .................................................................................................................... 16
Bibliografía. .................................................................................................................... 17
Introducción.

Todo desarrollo de productos de software independientemente de la metodología

que se está implementando, es necesario que se incluya la fase de pruebas, la cual
nos permitirá
determinar si el producto a entregar cumple con la calidad especificada y esperada
por el cliente. En la actualidad las personas que nos dedicamos a las pruebas de
software (Testing), necesitamos de un Plan de Pruebas de Software, el cual tiene
como propósito comunicar a todos los involucrados del proyecto los entregables, las
características a ser o no ser probadas, los aspectos de criterios de aprobación y
fallo, criterios de suspensión y reanudación, las necesidades ambientales, las
capacitaciones requeridas para los integrantes del equipo de pruebas, los riesgos y
el laboratorio de usabilidad.
EI Plan de Pruebas de Software se puede aplicar a todo proyecto de software, se
ajusta a las necesidades de cada empresa de software considerando el tamaño del
proyecto, el tiempo, el costo, el ciclo de vida del software, los involucrados, que son
algunos por mencionar. Cada empresa puede definir su propio Plan de Pruebas de
Software basándose en las buenas prácticas y en la mejora continua.
3.1 Elementos de un plan de pruebas.

En el desarrollo de software, la fase de pruebas es crítica para asegurar que el

producto sea enviado al ambiente de producción con la calidad esperada por el
cliente. Es por esto por lo que hoy en día es indispensable contar con un Plan de
pruebas de software para especificar minuciosamente las funciones a probar, cómo
serán ejecutadas esas pruebas, quienes serán los responsables y el cronograma
para su ejecución. El Plan de pruebas de software puede aplicarse a todo el
proyecto de desarrollo de Software, o puede acotarse a una iteración o conjunto de
casos. Además, puede definir jerarquías de casos de prueba a considerar.
A continuación, les daremos un listado de los elementos que conforman el plan de
pruebas:

● Historial de versiones: El histórico de las versiones del plan de pruebas de

software, indicando quien elaboró la versión y la fecha.
● Ficha del proyecto: Información sobre el nombre del proyecto,
departamento o área organizacional, líder o gerente del proyecto, el
Patrocinador (Sponsor) y el gerente o líder de pruebas.
● Aprobaciones: Lista de las personas que deben aprobar el plan de pruebas
de software, indicando su nombre, cargo, departamento y espacio para su
firma.
● Resumen ejecutivo: Resumen de todo el contenido del plan de pruebas de
software, describe cuál es su propósito, establece si es un plan maestro o un
plan detallado, identifica el alcance del plan de pruebas en relación con el
plan de proyecto de software, restricciones.
● Alcance de las pruebas:
a. Elementos de pruebas: Listado de todos los módulos, componentes
o elementos que se van a probar. Si es de alto nivel, se listan las áreas
funcionales (módulos o procesos que cubre el Testing), por otro lado,
si es de un nivel detallado se listan los programas, unidades o
módulos.
 b. Nuevas funcionalidades para probar: Es un listado de lo que se va
a probar “Desde el punto de vista del usuario”. No es una descripción
técnica del software sino sus características y funcionalidades.
c. Pruebas de regresión: Listado de las funcionalidades no
directamente involucradas en el desarrollo, pero cuyos componentes
están siendo afectados y por ende deben probarse para asegurar que
continúan funcionando adecuadamente.
d. Funcionalidades para no probar: Listado de las funcionalidades que
no se van a probar. Debe incluir información de las razones por las
cuales no se van a probar y los riesgos que se están asumiendo.
e. Enfoque de pruebas (Estrategia): La Estrategia de pruebas puede
definirse como un documento aparte, o puede ser incluido dentro del
Plan de pruebas según su extensión.
● Criterios de aceptación o rechazo:
a. Criterios de aceptación o rechazo: Son los criterios de aceptación
que serán considerados para dar por completado el Plan de Pruebas
de Software, por ejemplo: Completar 100% de pruebas unitarias,
cierto porcentaje de casos exitosos, cobertura de todos los
componentes y líneas de código, porcentaje de defectos corregidos,
entre otros.
b. Criterios de suspensión: Establece claramente bajo qué condiciones
se detienen un conjunto de casos de pruebas, por ejemplo en caso de
existir defectos que impidan la ejecución de más casos de pruebas,
cierto porcentaje de casos fallidos, o cualquier otro que se especifique.
c. Criterios de reanudación: Luego de haber suspendido las pruebas,
aquí se establece bajo qué criterios se reanudarán.
● Entregables: Establece que se entregará como parte de la ejecución del
plan, por ejemplo: Documento de plan de pruebas, casos de pruebas,
especificación de diseño de casos, Logs de errores, Reportes de errores
(bugs), evidencias de pruebas, reportes emitidos por herramientas de
pruebas y cualquier otro que se establezca.
● Recursos:
a. Requerimientos de entornos – Hardware: Lista de los
requerimientos de equipos, hardware y red necesarios para completar
las actividades del Plan de pruebas de software. Incluye servidores de
aplicación, bases de datos, equipos de PC que necesitan los testers,
conectividad a la red (incluyendo accesos), entre otros.
b. Requerimientos de entornos – Software: Lista de los
requerimientos de software necesarios para completar las actividades
de prueba, puede incluir accesos a Sistemas (en entorno de
pruebas) y bases de datos, así como instalación de software en los
Computadores asignados a los testers.
c. Herramientas de pruebas requeridas: Específica las herramientas
de software, metodologías o técnicas especiales empleadas en las
pruebas.
d. Personal: Lista del personal necesario para completar las actividades
de pruebas, especificando sus roles.
e. Entrenamiento: Necesidades de entrenamiento en el Sistema o
Aplicación que se está desarrollando, así como en las herramientas
de prueba a utilizar.
2. Planificación y Organización:
○ Procedimientos para las pruebas: Especifica los procedimientos o
metodología de pruebas de software a emplear durante la ejecución
del plan de pruebas de software.
○ Matriz de responsabilidades: Lista cada una de las personas
integrantes del equipo de QA y sus responsabilidades. Se puede
hacer uso de una Matriz RACI (responsable, Aprobador,
Consultado, Informado).
○ Cronograma: Debe estar basado en estimaciones de actividades
realizadas por el equipo de prueba. En él se identifican los hitos
relevantes en las pruebas de software, se establecen las
 dependencias (actividades predecesoras) y demás aspectos
componentes de un cronograma.
○ Premisas: Las premisas relacionadas con las tareas de pruebas de
software, incluyendo limitaciones de tiempo, disponibilidad de
recursos que se asumen, uso de una metodología de pruebas, uso de
una herramienta, entre otros.
○ Dependencias y Riesgos: Aquí se listan los riesgos identificados
en el proceso de pruebas de software, por ejemplo, algunas fuentes
de riesgos suelen ser:
○ Dependencias con Desarrollos.
○ Dependencias con otros proyectos.
● Referencias: Lista de todos los documentos que pueden citarse como apoyo
o para ampliar el contenido del plan de pruebas. Algunos ejemplos de lo que
se puede hacer referencia aquí son:
○ Plan de Proyecto.
○ Especificaciones de Requerimientos. o Matriz de trazabilidad de
requisitos
○ Diseño General.
○ Diseño Detallado.
○ Procedimientos y estándares de Desarrollo.
○ Procedimientos y estándares de Pruebas.
○ Metodologías, Procedimientos y estándares corporativos.
● Glosario: Definiciones de términos usados en la documentación, y general
sobre el área de pruebas.

3.2 Desarrollo de un plan de pruebas.

Un plan de pruebas es un documento que describe las estrategias de prueba, los

objetivos, los cronogramas y los entregables para un proyecto de software. El
propósito de este, similar a un modelo de estrategia empresarial, es asegurarse de
que no haya problemas con su producto antes de ponerlo en producción. Esto
también sirve como documentación para futuras referencias en caso de que surjan
preguntas más adelante sobre cómo se hicieron las cosas durante la etapa de
desarrollo.
Un plan de pruebas de software se puede usar como guía porque sirve para ambos
propósitos: esbozar lo que sucederá a lo largo del proceso y brindar una descripción
general de hacia dónde nos dirigimos.
Beneficios de las pruebas de software.

● Las pruebas de sistemas de software aseguran productos de software

confiables y de alta calidad.
● Un cliente satisfecho es una clave importante para el éxito de cualquier
negocio.
● Cuando sus clientes consideren que sus productos son confiables y que
aportan valor a sus vidas, pueden recomendarlos a sus amigos.
● Garantizar la calidad le ahorra costosas reparaciones después del
lanzamiento a los consumidores evitando el aumento de los niveles de
insatisfacción del cliente y afectaciones a la imagen comercial.
● Las pruebas ayudan a validar que la experiencia de usuario (UX) está
asegurada y nos permitirá crear un entorno aún más inmersivo que fidelice a
los usuarios.

3.3 Desarrollo de matriz de pruebas.

El plan de pruebas de software se elabora para atender los objetivos de calidad en

un desarrollo de sistemas, encargándose de definir aspectos como por ejemplo los
módulos o funcionalidades sujeto de verificación, tipos de pruebas, entornos,
recursos asignados, entre otros aspectos.
Pasos para la realización de un plan de pruebas.

1. Analizar los requerimientos de desarrollo de software.

Para elaborar un plan de pruebas de software lo primero que debes hacer es

entender los requerimientos de usuario que componen la iteración o proyecto, que
son el sujeto de la verificación de calidad que se va a realizar. Deberás analizar toda
la información de la ingeniería de requisitos, incluyendo la matriz de trazabilidad,
especificaciones y diseño funcional, requisitos no funcionales, casos de uso,
historias de usuario (si estás trabajando con metodologías ágiles), entre otra
documentación. También es muy importante realizar entrevistas con el equipo
encargado de la ingeniería de requisitos para aclarar dudas y ampliar la información
que sea necesaria.

2. Identificar las funcionalidades nuevas a probar.

A partir de la documentación del análisis de requisitos y de las entrevistas con el

equipo de ingeniería de requisitos y desarrollo, debes identificar e incluir en el plan
de pruebas de software en la lista de las funcionalidades. Si estás trabajando con
un sistema informático nuevo, no tendrás problemas en discernir, pues todas serán
nuevas.

En el caso de desarrollos de software integrados a un sistema existente es

necesario revisar con los analistas de negocio y también con los arquitectos de
software las funcionalidades que forman parte del desarrollo de software, en todas
las capas de la arquitectura.

3. Identificar las funcionalidades de sistemas existentes que deben

probarse.

Se debe identificar las funcionalidades existentes que estén siendo impactadas por
el desarrollo de alguna forma, considerando todos los componentes afectados en
todas las capas de la arquitectura de software. Existen dos situaciones que se
puede encontrar al identificar estas funcionalidades:

● Funcionalidades modificadas de cara al usuario: Por ejemplo, si una

funcionalidad está siendo modificada agregando más pantallas o cambios a
su flujo de proceso, debe ser incluida en el plan de pruebas de software.
● Funcionalidades modificadas en sus componentes internos: Son
funcionalidades no modificadas de cara al usuario, manteniendo la misma
interfaz gráfica y flujo de procesos, sin embargo, si se modifican
 componentes internos que comparten con otras funcionalidades del sistema,
en las capas de lógica de negocio o acceso a datos. Estas deben incluirse
en el plan de pruebas de software para determinar a partir de ellas pruebas
de regresión a realizar.

Quienes pueden suministrar la información serán los Analistas de negocio o

Arquitectos de software, familiarizados con el sistema informático implementado en
entorno de producción.

4. Definir la estrategia de pruebas

Consiste básicamente en seleccionar cuáles son los tipos de pruebas de software

que se deben realizar. Es recomendable seguir un marco de referencia para
determinar los tipos de prueba, como por ejemplo los tipos de pruebas de software
definidos por el ISTQB.

5. Definir los criterios de inicio, aceptación y suspensión de pruebas.

A. Criterios de aceptación o rechazo:

Para definir los criterios de aceptación o rechazo, es necesario definir el nivel de

tolerancia a fallos de calidad. Si la tolerancia a fallos es muy baja puede definirse
como criterio de aceptación que el 100% de los casos de prueba estén sin
incidencias. Lograr este margen en todos los casos de prueba principales y casos
bordes será muy difícil, y podría comprometer los plazos del proyecto (incrementa
los riesgos), pero asegura la calidad del producto.

B. Criterios de inicio o reanudación:

Definen las condiciones que deben cumplirse para dar inicio o reanudar las pruebas.
Por ejemplo, en el caso de inicio la condición podría ser la instalación de los
componentes de software en el ambiente y que los casos de pruebas de verificación
de ambiente sean exitosos. Para el caso de la reanudación las condiciones están
relacionadas, se determina a partir de cuales criterios de suspensión se presentaron
para detener las pruebas. Una vez que estás condiciones ya no existan (sean
solventadas) se procede con la reanudación.
 C. Criterios de suspensión:

Las condiciones van a depender de los acuerdos de nivel de servicio (SLAs) internos
de la organización y también de los acuerdos establecidos en cada proyecto
individual.

3.4 Desarrollo de casos de prueba.

La escritura de casos de prueba varía según lo que el caso de prueba esté midiendo
o probando. Esta es también una situación en la que compartir activos de prueba
entre los equipos de desarrollo y prueba puede acelerar las pruebas de software.
Pero todo comienza con saber cómo escribir un caso de prueba de manera efectiva
y eficiente. Los casos de prueba tienen algunas partes integrales que siempre deben
estar presentes en los campos. Sin embargo, cada caso de prueba se puede dividir
en 8 pasos básicos.
1. ID de caso de prueba

Todos los casos de prueba deben llevar ID únicos para representarlos. En la

mayoría de los casos, seguir una convención para este ID de nomenclatura ayuda
con la organización, la claridad y la comprensión.

2. Descripción de la prueba

Esta descripción debe detallar qué unidad, característica o función se está probando
o qué se está verificando.

3. Supuestos y condiciones previas

Esto implica que se cumplan las condiciones antes de la ejecución del caso de
prueba. Un ejemplo sería requerir una cuenta de Outlook válida para iniciar sesión.

4. Datos de prueba
Esto se relaciona con las variables y sus valores en el caso de prueba. En el ejemplo
de un inicio de sesión por correo electrónico, sería el nombre de usuario y la
contraseña de la cuenta.

5. Pasos para ejecutar

Estos deben ser pasos fácilmente repetibles ejecutados desde la perspectiva del
usuario final. Por ejemplo, un caso de prueba para iniciar sesión en un servidor de
correo electrónico podría incluir estos pasos:

1. Abra la página web del servidor de correo electrónico.

2. Introduzca su nombre de usuario.
3. Introducir la contraseña.
4. Haga clic en el botón "Entrar" o "Iniciar sesión".

6. Resultado Esperado

Esto indica el resultado esperado después de la ejecución del paso del caso de
prueba. Al ingresar la información de inicio de sesión correcta, el resultado esperado
sería un inicio de sesión exitoso.

7. Resultado real y condiciones posteriores

En comparación con el resultado esperado, podemos determinar el estado del caso

de prueba. En el caso del inicio de sesión por correo electrónico, el usuario iniciará
sesión correctamente o no. La condición posterior es lo que sucede como resultado
de la ejecución del paso, como ser redirigido a la bandeja de entrada del correo
electrónico.

8. Contraseña errónea

La determinación del estado de aprobado / reprobado depende de cómo se

comparan entre sí el resultado esperado y el resultado real.
Mismo resultado = Aprobado
Diferentes resultados = Falla

3.5 Definición de variables y constantes para las pruebas

Sobre las variables de prueba

Una variable de prueba es un par de nombre-valor definido por el usuario que
almacena información, y hace referencia a ella, en una prueba y entre varias
pruebas.

Uso compartido de variables entre pruebas

Una variable se declara en la sección Variables de pruebas de la prueba, pero la
variable se puede utilizar en la prueba como referencia para cualquier campo que
se pueda sustituir. Para sustituir datos de una variable de prueba, se utiliza la página
Variables de prueba de la vista Orígenes de datos de prueba. A la variable de le da
un valor predeterminado cuando se declara. El valor se puede modificar también
utilizando una sentencia Fijar variable. Las sentencias Fijar variable se crean con
los menús Añadir e Insertar del Editor de pruebas. Las variables se pueden definir
en un valor codificado o en un valor recuperado de un origen de datos, como una
agrupación de datos o una referencia que aparece antes que la sentencia Set.
Una razón habitual para compartir datos entre pruebas es realizar la correlación de
datos. Con la correlación de datos, la variable se define en una respuesta que
proviene de una solicitud en una prueba y se utiliza en las solicitudes efectuadas en
una prueba distinta. Suponga que está probando la base de datos de un empleado.
La prueba Crear empleado crea un registro de empleado y la prueba Modificar
empleado modifica el registro del empleado. Cuando se crea un nuevo registro, se
asigna un ID de registro. Se pueden utilizar variables para pasar el ID de registro de
una respuesta en la prueba Crear empleado a la prueba Modificar empleado.

Utilización de variables para acceder a las agrupaciones de datos

Puede definir variables para que compartan datos desde una agrupación de datos
en todas las pruebas. Esto se hace sustituyendo el campo del valor de una
sentencia Fijar variable desde una agrupación de datos. De este modo, la primera
prueba, que aparece en la planificación, puede definir la variable desde una
agrupación de datos y compartirla con otra prueba de la planificación.
Suponga que tiene dos pruebas que se registran en una aplicación utilizando un ID
de usuario de una agrupación de datos. El límite de un registro se mantiene incluso
si las pruebas están en un bucle y el usuario virtual las ejecuta varias veces. Al
utilizar las variables definidas por el usuario, el usuario virtual recupera un nuevo
registro cada vez a lo largo del bucle, y ambas pruebas pueden utilizar el mismo
registro.
variable desde cualquier origen de datos, por lo que dicho valor se puede compartir
también entre pruebas.

Variables de matriz

Cree una variable de matriz para añadir varios valores a una variable. Si ha creado
una solicitud HTTP secundaria, añada las vías de acceso completas de las
solicitudes en una variable de matriz que puede utilizarse con código personalizado
durante la reproducción.
• Declaración y asignación de variables de prueba
Al declarar una variable en IBM® Rational Performance Tester, puede crear un
contenedor para ella, inicializarla en una serie o un valor de agrupación de datos, y
definir su ámbito. A continuación, en la prueba, puede reasignar otro valor a la
variable.
• Inicialización de variables desde la línea de mandatos
Para inicializar las variables de prueba de un archivo XML, puede ejecutar la prueba
desde la interfaz de la línea de mandatos mediante la opción varfile.
• Inicialización de variables desde Rational Quality Manager
Si desea ejecutar una prueba IBM Rational Performance Tester desde IBM Rational
Quality Manager, puede pasar las variables de ejecución definidas en Rational
Quality Manager en la prueba Rational Performance Tester.

Prueba de una muestra

Esta característica requiere la opción Statistics Base.
El procedimiento Prueba T de una muestra prueba si la media de una única variable
difiere de una constante especificada y automatiza el cálculo del tamaño de efecto
de prueba t.

Ejemplos
Un investigador desea comprobar si la puntuación media del coeficiente intelectual
de un grupo de alumnos difiere de 100. O bien, un fabricante de copos de cereales
puede tomar una muestra de envases de la línea de producción y comprobar si el
peso medio de las muestras difiere de 1 kg con un nivel de confianza al 95%.

Estadísticos
Para cada variable de prueba: media, desviación estándar, error estándar de la
media, y la estimación del tamaño de efecto para la prueba t. La diferencia promedio
entre cada valor de los datos y el valor de contraste hipotetizado, una prueba t que
contrasta que esta diferencia es 0 y un intervalo de confianza para la diferencia
promedio (para el que puede especificarse el nivel de confianza).
Conclusión.
Al desarrollar un nuevo software o sistema de información, la primera etapa de
pruebas a considerar es la etapa de pruebas unitarias. En la cual como
mencionamos anteriormente, se encuentran presentes las pruebas de caja negra y
de caja blanca en las cuales, en una se realiza un análisis de los datos de entrada
y de salida y en otro se analiza el proceso interno del sistema para evaluar las
inconsistencias que pueda estar presentando el sistema, para así llegar a una
corrección de estos y proseguir con la nueva fase del proceso de desarrollo del
sistema. Podemos destacar que las pruebas unitarias son una forma de probar el
correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada
uno de los módulos funcione correctamente por separado.
Bibliografía.
Adán, V. G. (2019, 3 abril). Detallando un plan de pruebas. Qalovers. Recuperado 13 de

mayo de 2022, de https://www.qalovers.com/2019/01/detallando-un-plan-de-

pruebas.html

Andrade, A. (2021, 10 septiembre). Cómo desarrollar un plan de pruebas sólido pero

simple. Alexander Andrade. Recuperado 13 de mayo de 2022, de

https://alexanderandrade.net/blog-de-ingenieria-de-software/calidad-de-

software/como-desarrollar-un-plan-de-pruebas-solido-pero-simple/#.Yn6-

SOjMK3A

Desarrollo de casos de prueba. (s. f.). © Copyright IBM Corp. 2008, 2015. Recuperado 13

de mayo de 2022, de https://www.ibm.com/docs/es/elm/6.0.1?topic=suites-

developing-test-cases

Fernandez, C. (2017, 28 septiembre). Concepto de constante y variable en matemáticas.

Smartick. Recuperado 13 de mayo de 2022, de

https://www.smartick.es/blog/matematicas/problemas/constante-variable-

matematicas/

Software Testing Bureau. (2021, 21 octubre). Crear un buen Plan de Pruebas.

https://www.softwaretestingbureau.com/crear-un-buen-plan-de-pruebas/

Software Testing: Cinco Pasos Para Elaborar El Plan De Pruebas. (2021, 11 marzo).

Trans Ti. https://trans-ti.com/2021/03/11/software-testing-cinco-pasos-para-

elaborar-el-plan-de-pruebas/