EVALUACION Y MEJOR PARA EL

DESARROLLO DE SOFTWARE

Ing. Roydeli Domínguez Aguilar

(UnidadII. Pruebas de software.)

RESULTADO DE APRENDIZAJE

Equipo #4

ALUMNOS:

DAVID ORLANDO SUAREZ DIAZ. (092310921)

NOEMI SOLORZANO ESTRADA. (092311134)

BRITNEY ANGELLY RODRIGUEZ DIAZ. (092310908)

CARLOS EDUARDO RESENDEZ HERNANDEZ. (092310859)

LUCERO ALONDRA GARCIA RODRIGUEZ. (092311103)

JIMENEZ RUIZ DELMAR DEL ROSALIO. (092311045)

CUATRIMESTRE Y GRUPO

4 “A”

CARRERA:

TSU EN DESARROLLO DE SOFTWARE MULTIPLATAFORMA

FECHA:

01– 10 – 2024
Contenido
INTRODUCCION..................................................................................................................1

CASO DE PRUEBAS............................................................................................................2

DATOS DE PRUEBA............................................................................................................7

REPORTES DE DEFECTO................................................................................................11

VERSIONAMIENTO............................................................................................................14

CONCLUSION....................................................................................................................17

Referencias.........................................................................................................................18
 INTRODUCCION

Un plan de pruebas de software es un documento que describe los pasos a llevar a cabo
y el enfoque de las pruebas en un proyecto de desarrollo de software.

El plan de prueba tiene como objetivo orientar el esfuerzo de pruebas, identificando y

detallando as pruebas mas importantes, para que el equipo de QA pueda enfocarse en su
ejecución y pueda responder de forma adecuada a los cambios que tiene el proyecto.

El plan de pruebas está constituido por 4 Puntos esenciales (caso de prueba, datos de
prueba, reportes de defecto, versionamiento). Los cuales cumplen un papel diferente pero
no menos importante ya que cada uno tiene los componentes específicos apartados que
lleva la documentación de una aplicación web o un servicio web en línea.

El caso de prueba es el conjunto de condiciones o variables bajo las cuales un evaluador

determina si un sistema cumple con los requisitos especificados. Estas condiciones
aseguran que el software cumple con los requisitos de funcionalidad y de comunicación.

Los datos de prueba son la información utilizada durante la ejecución de casos de prueba
para verificar el comportamiento y la funcionalidad de un sistema o aplicación. Consta de
3 tipos de datos los cuales verifican que los datos a ingresar sean leídos correctamente.

Los reportes de defecto son los documentos o registros que describen fallos, errores o
problemas encontrados en un software durante el proceso de prueba. Este punto es muy
importante ya que se revisa las versiones del software que sean cambiado, buscando así
las fallas o incompatibilidad con las diferentes interfaces o sistemas.

Por otra parte, el versionamiento es el proceso de asignar números o etiquetas a

diferentes versiones de software o documento a lo largo de su desarrollo, es decir se
enumeran o se parchan los diferentes tipos de cambio que se realizan en el software.

En este documento mostraremos algunos ejemplos de venta para que sea de manera
mas practica y concisa de entender.
 CASO DE PRUEBAS

Un caso de prueba es una secuencia de ejecución detallada que nos ayuda a validar
paso a paso una funcionalidad o un requerimiento sobre un sistema, y
podremos comprobar si el resultado obtenido coincide con el resultado esperado. En el
caso de no coincidir, esta secuencia de pasos nos ayuda a encontrar el error y corregirlo.

Los usos de las pruebas de software, no solo actúan como medida de corrección, sino
también de prevención de errores. Entre más temprana sea la etapa de detección de
defectos, menores serán los costos asociados a su reparación.

Las pruebas unitarias, por ejemplo, se encargan de

detectar errores en pequeñas unidades de código antes
de su integración al sistema. De esta manera se puede
identificar con precisión el origen del fallo y evitar que
afecte al resto del software en etapas posteriores.

Esto quiere decir que las pruebas de software son un

mecanismo eficaz en la prevención y reducción de riesgos, al tener como función principal
la identificación de problemas potenciales antes de afectar negativamente la funcionalidad
del software o el cumplimiento de los requisitos.

Los pasos que seguiremos para documentar un caso de pruebas:

1. Identificación del Caso de Prueba

 ID del Caso de Prueba: este es un identificador único del caso de prueba se usa
para facilitar el seguimiento,
 Título: es un nombre claro y descriptivo que describa el propósito del caso de
prueba.

2. Descripción

Detalla lo que se está probando y el objetivo del caso de prueba.

 Propósito: Explica brevemente qué se va a probar y por qué es importante.

 Alcance: Define los límites de la prueba y qué se incluye o excluye.

3. Precondiciones

Las precondiciones son los requisitos o condiciones que deben cumplirse antes de
ejecutar un caso de prueba. Pueden incluir el estado del sistema, datos específicos
necesarios, o configuraciones previas. Estas aseguran que la prueba se realice en un
entorno adecuado y que los resultados sean válidos.

 Requisitos Previos: Detalla cualquier configuración o estado necesario antes de

ejecutar la prueba (por ejemplo, datos de entrada, acceso al sistema).

4. Datos de Entradas

Los datos de entrada son los valores o información que se utilizan durante la ejecución de
un caso de prueba, pueden incluir parámetros, formularios, archivos o cualquier tipo de
datos que el sistema necesita para llevar a cabo la operación que se está probando. Son
esenciales para evaluar si el sistema responde correctamente bajo diferentes condiciones.

 Datos de Prueba: Especifica qué datos se utilizarán, incluyendo formatos, valores

y condiciones. Estos datos son información necesaria para llevar a cabo la prueba.

5. Pasos a seguir para la Ejecución

Son instrucciones detalladas sobre cómo realizar la prueba.

 Instrucciones: Enumera los pasos detallados que el tester debe seguir para
realizar la prueba. Deben ser claros y fáciles de seguir.

6. Resultados Esperados

Estos son resultados que se esperan obtener al finalizar el caso de pruebas

 Resultados: Describe lo que se espera ver después de ejecutar la prueba. Esto

puede incluir mensajes en pantalla, cambios en la base de datos, etc.

7. Resultados reales

Se refiere al comportamiento o resultado observado después de ejecutar los pasos del

caso de prueba. Es la respuesta efectiva del sistema a las acciones realizadas durante la
prueba.

 Resultados: resultados obtenidos después de ejecutar la prueba.

8. Postcondiciones

Las postcondiciones son las condiciones o estados que deben verificarse después de
ejecutar un caso de prueba. Estas describen cómo debería quedar el sistema una vez
finalizada la prueba, incluyendo cambios en datos, estados de aplicación o resultados
generados. Ayudan a determinar si la prueba fue exitosa y si se cumplieron los resultados
esperados.

 Estado Final: Describe cómo debería quedar el sistema después de ejecutar la

prueba (cambios en el sistema, estado de datos).

9. Notas Adicionales

Son comentarios adicionales como errores o consideraciones especiales.

 Observaciones: Incluye cualquier información relevante que pueda ayudar en la

ejecución o comprensión de la prueba.

10. Historial de Cambios

Este historial es un registro que documenta todas las modificaciones realizadas a un caso
de prueba a lo largo del tiempo. Incluye información como la fecha de cada cambio, quién
lo realizó y una breve descripción de lo que se actualizó. Esto ayuda a mantener la
trazabilidad y a comprender la evolución del caso de prueba.

 Versiones: Registra las modificaciones realizadas al caso de prueba, junto con

fechas y responsables.

11. Responsables

Es la persona asignada para realizar la prueba

 Persona: Debe ser una persona que tenga conocimiento sobre el proceso de
ejecución y pueda resolver los posibles problemas que se presenten.

12. Fecha de ejecución

Fecha que proporciona un contexto temporal sobre cuándo se llevó a cabo la prueba.
Esto es útil para el seguimiento de versiones, identificar problemas en un momento
específico y facilitar la gestión del ciclo de vida de las pruebas.

13. Comparación

Después de ejecutar el caso de prueba, se compara el resultado real con el resultado

esperado:

Si el resultado real coincide con el resultado esperado: El caso de prueba se considera

exitoso.

Si hay discrepancias: Se clasifica como fallido y se documentan los detalles para

investigar la causa.

Consejos Adicionales

 Claridad: se recomienda usar un lenguaje simple y directo.

 Consistencia: tratar de mantener un formato uniforme en todos los casos de
prueba.

Revisiones: Hacer que otras personas revisen los casos de prueba para asegurar la
precisión y claridad.
 DATOS DE PRUEBA

Los datos de prueba son conjuntos de información utilizados para verificar el correcto
funcionamiento de un sistema, software o aplicación. Estos datos se emplean en las fases
de desarrollo y prueba de software para simular diversas situaciones y comportamientos
que podrían ocurrir en el uso real.

Características de los datos de prueba:

Realistas: Deben reflejar situaciones que podrían suceder en el entorno real.

Diversos: Deben incluir casos normales, extremos, y de error para cubrir un amplio
espectro de posibles comportamientos.

Predefinidos: Son definidos antes de que se realicen las pruebas para asegurar que el
software responda correctamente en escenarios planificados.

Tipos de datos de prueba:

 Datos válidos: Información que cumple con los requisitos establecidos y que
debería ser aceptada por el sistema.

Ejemplo: Un número de teléfono en formato correcto.

 Datos inválidos: Información que no cumple con los requisitos y debería ser
rechazada.

Ejemplo: Un correo electrónico sin el símbolo "@".

  Datos límite: Información que se encuentra en los límites aceptables (mínimo y
máximo).

Ejemplo: Un campo de edad donde el mínimo permitido es 16 y el máximo 100.

 Datos vacíos o nulos: Situaciones donde no se proporciona información o es

nula.

Ejemplo: Un campo obligatorio que está vacíos.

Ejemplo de datos de prueba para la gestión de pedidos en línea (PMCH). Los campos a
ingresar son: nombre del cliente, número de tarjeta de crédito, dirección de envío, y
cantidad de productos.

Campos esperados:

 Nombre del cliente: Solo se permiten letras y espacios cantidad no mayor a 30

letras

 Número de tarjeta de crédito: 16 dígitos numéricos.

 Dirección de envío: Combinación de letras, números y símbolos, solo se permiten

no mayor a 6 caracteres.

 Cantidad de productos: solo número enteros positivos de una escala de 1-100

Ejemplo de datos de prueba reales:

Datos válidos (el sistema debería aceptar):

  Nombre del cliente: Britney Rodríguez

 Número de tarjeta de crédito: 1234567891012345

 Dirección de envío: AV Villaflores calle 123

 Cantidad de productos: 6

Datos inválidos (el sistema debería rechazar):

 Nombre del cliente: BRI 2 ( es rechazado ya que contiene un número y el

nombre es muy corto)

 Número de tarjeta de crédito: 12345abc12345678 (incluye letras)

 Dirección de envío: 123 (demasiado corta)

 Cantidad de productos: 0 (valor fuera del rango permitido)

Datos límite (el sistema debería aceptar):

  Nombre del cliente: Ana (nombre con longitud mínima aceptable)

 Número de tarjeta de crédito: 1111222233334444 (exactamente 16 dígitos)

 Dirección de envío: Av. P (longitud mínima de 5 caracteres)

 Cantidad de productos: 1 (mínimo permitido)

Datos vacíos o nulos (el sistema debería pedir correcciones):

 Nombre del cliente: (vacío)

 Número de tarjeta de crédito: (vacío)

 Dirección de envío: (vacío)

 Cantidad de productos: (vacío)

Resultados esperados

Los criterios de pedidos están en correcto funcionamiento realizando las restricciones

determinadas para el pedido.
Resultados Reales

Las normas de pedidos funcionan correctamente sin que se encuentre alguna falla.

REPORTES DE DEFECTO

Un reporte de defectos (también conocido como informe de errores o bug report) es un

documento o registro utilizado en el desarrollo de software para informar y rastrear un
error o falla en el sistema. El objetivo del reporte es proporcionar a los desarrolladores la
información necesaria para identificar, analizar y corregir el problema.

Contenido típico de un reporte de defectos:

ID del defecto: Un identificador único para el defecto.

Título o resumen: Una breve descripción del problema.

Descripción: Detalles sobre el comportamiento defectuoso, incluyendo lo que se

esperaba y lo que realmente ocurrió.

Pasos para reproducir: Instrucciones claras sobre cómo reproducir el error, incluyendo
las acciones específicas realizadas antes de que ocurriera.

Resultado esperado: Qué debería haber pasado si el sistema funcionara correctamente.

Resultado real: Lo que realmente ocurrió cuando el defecto se manifestó.

Severidad: El impacto del defecto en el sistema (por ejemplo, crítico, mayor, menor).

Prioridad: La urgencia con la que debe corregirse el defecto (por ejemplo, alta, media,
baja).

Entorno de pruebas: Información sobre el entorno donde se detectó el defecto (versión

de software, sistema operativo, navegador, etc.).

Archivos adjuntos: Imágenes, capturas de pantalla, registros, o cualquier evidencia

adicional que ayude a comprender el problema.

Fecha de creación: La fecha en que se reportó el defecto.

Asignado a: Persona o equipo responsable de corregir el defecto.

Estado del defecto: Indica si el defecto está nuevo, en revisión, en corrección, corregido,

 Ejemplo

ID 001 Fecha 01/10/2024 Prioridad alta Severidad Mayor

Titulo El botón “Añadir al carrito” no funciona en la página detalles del producto
Descripción Cuando un usuario intenta añadir un producto al carrito desde la pagina de
detalles, no ocurre ninguna acción y el producto no se agrega al carrito
Pasos a seguir para el defecto
1.- Acceder a la tienda en línea desde un navegador

2.- Navegar a cualquier página de detalles de un producto

3.- Navegar a cualquier página de detalles de un producto

4.- Hacer click en el botón “añadir al carrito”

Archivos
adjuntos

Resultado El producto debería añadirse al carrito y mostrarse una confirmación o

esperado notificación.
Resultado No se añade el producto al carrito y no hay ninguna notificación o cambio
real visible.
Entorno de - Sistema operativo Windows 11
- Navegador Google Chrome 93.0.4577.63
prueba
- Versión de la tienda 2.1.0

Asignado a Equipo de desarrollo web (Delmar Rosalio, Carlos Eduardo, David Orlando,
Noemi, Britney Angelly, Lucero Alondra)
Estado de Abierto
defecto
 VERSIONAMIENTO

El versionado de software es una práctica común en la industria del desarrollo de

software. Se utiliza para mantener un registro de los cambios realizados en una aplicación
de software a lo largo del tiempo. Cada vez que se realiza un cambio en el software, se
crea una nueva versión de este. Cada versión se identifica con un número de versión
único que permite a los desarrolladores y usuarios rastrear los cambios y saber
exactamente qué versión están utilizando.

El proceso de versionado de software implica el uso de herramientas de control de

versiones para ayudar a los desarrolladores a mantener un registro de los cambios
realizados en el código fuente de una aplicación.

El versionado de software es importante porque permite a los desarrolladores mantener

un registro de los cambios realizados en un programa de software. Esto puede ser útil en
varias situaciones, como cuando se necesita solucionar un problema en una versión
anterior de un programa. También puede ser útil cuando se desea agregar nuevas
funciones a una aplicación existente.

El versionado de software también ayuda a garantizar que los usuarios estén usando la
versión más actualizada y segura de una aplicación. Si se descubre una vulnerabilidad de
seguridad en una versión anterior de un programa de software, los desarrolladores
pueden solucionar el problema y lanzar una nueva versión que incluya la corrección. Los
usuarios pueden entonces actualizar sus versiones para asegurarse de que están
protegidos contra la vulnerabilidad.

Nomenclatura o Estándar

Existen distintos tipos de versiones y en algunas aplicaciones utilizan diferentes

nomenclaturas para realizar el versionamiento, para cuestiones de desarrollo se definen 3
tipos de cambios en estándar
  Major: cambio drástico, este cambio no es compatible con versiones inferiores.

 Minor: cambio que añade características nuevas al desarrollo y/o modifica

funcionalidad existente, este cambio sigue siendo compatible con código existente.

 Patch: solución de bugs siendo cambios retro compatibles.

También existen varios tipos de versionado de los cuales los más comunes son:

Versionado numérico:

Este implica el uso de números para identificar diferentes versiones de un programa de

software. Cada vez que se realiza un cambio, se incrementa el número de versión. Por
ejemplo, la primera versión de una aplicación puede ser la versión 1.0. La siguiente
versión podría ser la versión 1.1, y así sucesivamente.

Versionado alfabético:

Cada vez que se realiza un cambio, se asigna una letra única para identificar la nueva
versión. Por ejemplo, la primera versión de una aplicación podría ser la versión A. La
siguiente versión podría ser la versión B, y así sucesivamente.

Versionado semántico:

Utiliza tres números para identificar una versión: el número de versión principal, el número
de versión secundaria y el número de revisión. Por ejemplo, la primera versión de una
aplicación semántica podría ser la versión 1.0.0. La siguiente versión podría ser la versión
1.0.1. Y así sucesivamente.

Para garantizar un versionado de software efectivo, es importante seguir algunas mejores

prácticas, como las siguientes:
  Asignar números de versión de manera consistente y clara.
 Documentar todos los cambios realizados en el software.
 Realizar pruebas exhaustivas en cada nueva versión del software antes de
lanzarla al público.

En resumen, el versionamiento del software es una parte importante del proceso de

desarrollo de software. Permite a los desarrolladores y usuarios mantener un registro de
los cambios realizados en un programa de software y garantiza que los usuarios estén
utilizando la versión más actualizada y segura de una aplicación.

Ejemplo de versionamiento semántico

Tenemos un software el cual es sobre artículos para el hogar (P.M.C.H), se comienza con
la versión 1.0.0. cada que se realice un cambio importante, menores o correcciones de
errores se cambiara la versión.

Versión 1.0.0. primera versión estable de PMCH.

Versión 1.0.1 corrección de un error sobre el lugar de las imágenes, esto no afecta a las
funcionalidades principales.

Versión 1.1.0 se le añade una funcionalidad de compra del carrito, el software sigue
siendo compatible con las versiones anteriores.

Versión 2.0.0 se crea una opción en que los usuarios serán capaces de publicar sus
artículos a la venta cambiando así la estructura de datos que había en las versiones
anteriores.
 CONCLUSION

En el archivo anterior se mostro los pasos que se deben seguir al crear un plan de
pruebas para verificar la fiabilidad de un software, estos puntos son muy importantes para
llevar una documentación sobre los cambios y fallas que se encuentran en el sistema a
desarrollar, El plan de pruebas presentado ha sido diseñado para asegurar la calidad y el
correcto funcionamiento del software. A través de la implementación de casos de prueba
exhaustivos, se busca cubrir tanto los requisitos funcionales como no funcionales del
sistema, garantizando que cada funcionalidad se evalúe de manera sistemática y
rigurosa.

El plan de pruebas establece una base sólida para garantizar que el software no solo
cumpla con los requisitos establecidos, sino que también ofrezca una experiencia de
usuario óptima y libre de defectos.
 Referencias

cevallos, P. (26 de junio de 2024). IT-SOFTWARE. Obtenido de

https://softinnovation.site123.me/my-blog/gestores-de-versionamiento

Diaz, E. A. (16 de agosto de 2017). slideshare. Obtenido de

https://es.slideshare.net/slideshow/versionamiento-de-software/78900773

SYNTHO. (10 de abril de 2024). syntho.ai. Obtenido de https://www.syntho.ai/es/what-is-

test-data-significance-applications-and-challenges/

V/SURE. (20 de enero de 2024). visuresolutions. Obtenido de

https://visuresolutions.com/es/blog/%C2%BFQu%C3%A9-son-los-casos-de-
prueba%3F-%C2%BFC%C3%B3mo-escribir-casos-de-prueba-relacionados-con-
el-software%3F/