Instituto Politécnico Nacional

Unidad Profesional Interdisciplinaria De Ingeniería y Ciencias Sociales y Administrativas

UPIICSA

Proceso Básico de la Aplicación de Pruebas

Gallegos Pérez Erick

Ingeniería de Pruebas

5NM70

GARCIA RODRIGUEZ JOSE LUIS

Objetivo:
En este ensayo, discutiré el tema del Proceso Básico de la Aplicación de Pruebas. Estaré
explorando los diferentes aspectos de este tema y brindando mi propia perspectiva al
respecto. Espero arrojar algo de luz nueva sobre este tema y proporcionar una perspectiva
diferente para el lector. Conocer acerca del tema relacionado con el Proceso Básico de la
Aplicación de Pruebas
, el cual se dio a la tarea de indagar de manera directa, con respecto a los puntos señalados
se espera conservar un 80% por ciento de la información recabada

Misión:
El proceso de prueba de software es una parte crucial de la garantía de calidad para
cualquier proyecto de desarrollo de software. Al probar exhaustivamente la funcionalidad del
nuevo software antes de su lanzamiento, las empresas pueden evitar el proceso costoso y
lento de corregir errores después del hecho. por lo que se quiere ofrecer información
confiable referente a los temas de Proceso Básico de la Aplicación de Pruebas, expuestos
en este texto, para su correcta difusión y fácil acceso, para lograr así proporcionar un amplio
aprendizaje

Visión:
El proceso de prueba de software es una parte importante del desarrollo de software de alta
calidad. Al tomarse el tiempo para probar exhaustivamente el nuevo software antes de su
lanzamiento, las empresas pueden evitar el proceso costoso y lento de corregir errores
después del hecho.
Encontrar fuentes de información confiable y sostenibles para lograr mantener a los grupos
de interés informados de manera correcta y continua acerca los temas tratados
Contenido:

El proceso de prueba de software generalmente comienza con el equipo de desarrollo

escribiendo casos de prueba, que luego ejecuta el equipo de prueba. Los casos de prueba
deben cubrir toda la funcionalidad del software y deben diseñarse para detectar posibles
errores. Una vez que se hayan ejecutado todos los casos de prueba, el equipo de pruebas
informará sus hallazgos al equipo de desarrollo.

Luego, el equipo de desarrollo corregirá cualquier error que se haya encontrado y el equipo
de prueba volverá a ejecutar los casos de prueba para verificar que las correcciones
funcionen según lo previsto. Una vez que el software pasa todos los casos de prueba, está
listo para su lanzamiento.

Proceso de pruebas de calidad de Software

Las pruebas de calidad en un software ERP son todos los procesos cuya ejecución permite
conocer su calidad, así como los posibles fallos que puedan existir a corto, medio o largo
plazo. Cuando se realizan pruebas a un software de gestión empresarial, es posible
predecir su comportamiento durante la implementación, su grado de manejabilidad y su
interfaz gráfica.

Existen diferentes formas de realizar pruebas de calidad, están dadas por el contexto que
representa cada uno de los clientes en particular, es decir, no existe un plan de pruebas que
sirva para todos los escenarios, pues puede ser que una prueba para un software ERP en
concreto es perfecto, pero en otro puede ser perjudicial.

TIPOS DE PRUEBAS DE CALIDAD DE SOFTWARE

Todas las pruebas de este tipo varían, sin embargo, su finalidad sigue siendo la misma y es
verificar y aprobar todo el software de una empresa, ya sea un ERP para empresas
instaladoras o para empresas distribuidoras. Algunas pruebas de calidad se explican a
continuación:

● PRUEBAS DE FUNCIONAMIENTO: Dentro de esta categoría es posible encontrar

tres subgrupos, los cuales se clasifican, según sus objetivos, en:

● Testing de función: Enfocada en conseguir informes sobre la aptitud de las

funciones, los métodos y los servicios que componen el ERP.
● Testing de seguridad: Ideada para comprobar la seguridad de los datos que
maneja el ERP para Pymes, es decir, los datos de la empresa.
● Testing de volumen: Dirigida a medir la velocidad del ERP para procesar
grandes cantidades de información en la base de datos, bien sea en entrada
o en salida.
● PRUEBAS DE USABILIDAD: La finalidad de éstas es comprobar la relación del
usuario con el software de gestión empresarial, prestando especial atención a la
interfaz, la experiencia del usuario, asistentes de ayuda integrados, interactividad,
entre otras cosas.

● PRUEBAS DE FIABILIDAD: Al igual que las de funcionamiento, se dividen en tres

grupos:

● Testing de integridad: Trata de valorar y calificar la resistencia a fallos que

presenta el software.
● Testing de estructura: Consiste en verificar que cada una de las partes que
componen el diseño del software ERP se encuentren conectadas a las
funciones correctas, en otras palabras, que no exista contenido huérfano en
el ERP.
● Testing de estrés: Se utiliza para evaluar el comportamiento del software
ERP en situaciones poco usuales, como por ejemplo, una sobre carga de
funciones, la saturación de la memoria, la restricción de los recursos
compartidos, etc…
● PRUEBAS DE RENDIMIENTO: Miden la relación función resultado de un ERP, éstas
se dividen en:

● Testing Benchamark: Se encarga de cuantificar el rendimiento de un nuevo

componente del ERP, comparándolo directamente con otro existente.
● Testing de contención: Ésta valora la capacidad de respuesta de un
elemento, en cuanto a sus habilidades, al momento de ser requerido por
diversos actores, un ejemplo de dicho elemento podría ser el registro de
recursos o la memoria.
● Testing de carga: Su finalidad es probar y asegurar los límites operacionales
del software de gestión empresarial, mediante la aplicación de cargas de
trabajo promedio. Por ejemplo, si se quiere hacer la prueba sobre un ERP
para una empresa de obras y servicios, es necesario indicar cuales son las
cargas habituales de trabajo de las mismas.

● PRUEBAS PARA LA CAPACIDAD DE SOPORTE: Existen dos formas de medirlo,

éstas son:

● Testing de configuración: Su principal objetivo es asegurarse que un ERP

funciona de forma correcta, sin importar la configuración que la empresa
decida aplicar, tanto a nivel de software como a nivel hardware. De igual
forma es posible aplicar esta prueba como un medidor de rendimiento del
sistema, o bien utilizarla en asociación con una prueba especializada en
dicho tema.
● Testing de instalación: Es probablemente una de las pruebas más
importantes, puesto que de ella dependerá, en gran medida, la correcta
implementación del ERP. Consiste en certificar que el software ERP se
encuentra en plena capacidad de ser instalado en condiciones extremas de
hardware o de software, como por ejemplo, problemas con la capacidad de
memoria o con la velocidad de procesamiento.
La forma más eficaz de asegurar la calidad del producto software.

Pruebas unitarias o de componentes.

El primer nivel de prueba es la prueba unitaria o de componentes, que consiste en verificar

unidades de software de forma aislada, es decir, probar el correcto funcionamiento de una
unidad de código.
En [PRE05] se indica que una unidad de código se considera como una unidad de
programa, como una función o método de una clase que se invoca desde fuera de la unidad
y que puede invocar otras unidades. Por eso es necesario probar que cada unidad funcione
por separado de las otras unidades de código.
Estas pruebas generalmente las realizan los desarrolladores, ya que es muy recomendable
conocer el código fuente del programa y, por lo general, se realizarán pruebas de caja
blanca o se analizará el código para verificar que cumple con las especificaciones del
componente.
Sin embargo, no solo se realizarán pruebas de la estructura del código, sino que también se
generarán casos de prueba funcionales para verificar el funcionamiento del componente.

POR EJEMPLO: Las pruebas unitarias se escriben para probar la funcionalidad de piezas
individuales de código, llamadas unidades. Por ejemplo, una prueba unitaria podría probar
la funcionalidad de un método en una clase. Las pruebas unitarias generalmente las
escriben los desarrolladores a medida que codifican, para probar el código a medida que se
desarrolla
Pruebas de integración.

El segundo nivel de prueba en el modelo V es la

prueba de integración. En casi toda la
documentación consultada siempre se hace la
siguiente pregunta: ¿por qué son necesarias las
pruebas de integración si ya se ha comprobado
que los componentes funcionan individualmente?
Aunque los componentes funcionan bien
individualmente, es posible que al ensamblar los
distintos componentes del sistema se presenten
errores que inicialmente no habíamos
considerado.

El ISTQB nos dice que estas pruebas tienen

como objetivo probar las interfaces entre componentes, las interacciones con diferentes
partes de un mismo sistema, como el sistema operativo, el sistema de archivos, el hardware
y las interfaces entre diferentes sistemas.
¿En qué orden procedemos a la integración de los componentes?

Para llevar a cabo estas pruebas en el [SCH14] nos muestran las siguientes estrategias
para la prueba de integración:
• Integración descendente.
• Integración ascendente.
• Integración Ad hoc.
• Integración del esqueleto.

Integración descendente
La prueba de integración de arriba hacia abajo es un enfoque incremental para construir
una arquitectura de software. La prueba comenzará con el componente del sistema de nivel
superior que llama a otros componentes del sistema pero no a sí mismo. La integración
continúa con componentes de nivel inferior.

Integración ascendente
La prueba comienza con los componentes básicos del sistema que no requieren
componentes adicionales. Los subsistemas más grandes se ensamblan a partir de los
componentes probados.

Integración Ad-hoc

Los componentes se integraron en el orden en que se completaron. Cuando un componente

ha pasado la prueba de componentes, se ejecuta la prueba de integración para ver si
coincide con otro componente probado previamente y se ejecuta la prueba de integración.
Integración del esqueleto

La integración del esqueleto es una técnica de prueba que se puede utilizar para probar la
funcionalidad de un sistema de software. Esta técnica se utiliza para probar el sistema
integrando los diferentes módulos que componen el sistema. Esta técnica se utiliza para
probar el sistema integrando los diferentes módulos que componen el sistema. La ventaja
de usar esta técnica es que puede ayudar a identificar errores en el sistema en una etapa
temprana. Esta técnica también es útil para probar la funcionalidad del sistema.
Cuando un esqueleto o columna vertebral del sistema se ha terminado, los componentes se
integran gradualmente en él.

POR EJEMPLO: Estas pruebas pueden incluir la verificación de que el software puede
responder correctamente a los eventos básicos, como los comandos de inicio, parada y
reinicio. Además, se pueden realizar pruebas para garantizar que el software maneje
correctamente los datos básicos, como la información de posición y velocidad.

Pruebas de sistema

Una vez probados los componentes y su integración, pasamos al tercer nivel de pruebas,
donde se comprobará si el producto cumple con los requisitos especificados.
El ISTQB nos dice que las pruebas del sistema pueden incluir pruebas basadas en riesgos
y/o especificaciones de requisitos, procesos comerciales, casos de uso u otras
descripciones textuales de alto nivel o patrones de comportamiento del sistema,
interacciones con el sistema operativo y recursos del sistema.
Las pruebas del sistema deben investigar los requisitos del sistema funcional y no funcional
y las características de calidad. Para ello se aplicarán técnicas de pruebas de caja negra.
Pruebas de validación o aceptación.

Las pruebas indicadas anteriormente se encuentran bajo la responsabilidad de quien está

produciendo el programa. Las pruebas de aceptación son responsabilidad del cliente y
pueden ser la única parte de las pruebas en donde estén involucrados.
Estas pruebas se llevan a cabo antes de que el programa se ponga en funcionamiento en
real y tienen que satisfacer las expectativas del cliente.
Hay cuatro formas típicas de las pruebas de aceptación [ISTQB]:

• Pruebas de aceptación del contrato.

• Pruebas de aceptación del usuario.
• Pruebas operativas.
• Pruebas alfa y beta.

Pruebas de aceptación del contrato

Las pruebas de aceptación del contrato se basan en los criterios de aceptación previstos en
el contrato celebrado al inicio del proyecto.
Estas pruebas son muy importantes, porque la empresa encargada del desarrollo del
software podría malinterpretar los criterios de aceptación y no tener en cuenta aspectos que
el cliente tiene en cuenta. Por este motivo, el software se entrega al cliente para su prueba.
Estas pruebas son generalmente las mismas que se realizan en las pruebas del sistema,
excepto que se realizan en el entorno del cliente, una característica muy importante, ya que
pueden aparecer errores que antes no aparecían.

Pruebas de aceptación del usuario

Hay casos en los que el cliente y el usuario final son diferentes y lo que parece válido para
un usuario final puede no parecerlo para otro. Por esta razón, las pruebas con usuarios
finales son esenciales.

Pruebas operativas

Estas pruebas son llevadas a cabo por los administradores del sistema que se va a poner
en producción. En estas pruebas se incluyen las siguientes tareas:
• Copia de
seguridad/restauración.
• Recuperación de
desastres.
• Gestión de usuarios.
• Comprobación de
vulnerabilidades de seguridad.
• Carga de datos.
• Tareas de
mantenimiento.
Pruebas alfa y beta

A menudo sucede que cuando se entrega un programa al cliente, puede ser utilizado por
diferentes usuarios finales, y la cantidad de usuarios finales es muy grande. Cuando esto
sucede, es poco práctico realizar pruebas de aceptación con cada uno de estos clientes,
para lo cual se utilizan pruebas alfa y beta, que descubrirán errores que solo encontrará el
usuario final.
Las pruebas alfa son aquellas que se ejecutan en las oficinas del desarrollador del producto
por un grupo de personas que representan al cliente final. En estas pruebas, el
desarrollador estará al lado de estos usuarios registrando errores y problemas de
usabilidad.
La prueba beta se realiza en la oficina de un cliente o en varias situaciones específicas, ya
que el usuario final puede ser varios clientes a los que se entrega el producto. En estas
pruebas, el desarrollador no está presente. Estos clientes registran todos los problemas
derivados del uso de este producto que luego se enviarán al desarrollador.

POR EJEMPLO: La prueba alfa es un tipo de prueba de software donde los usuarios
prueban una aplicación de software en sus primeras etapas de desarrollo. La prueba beta
es un tipo de prueba de software donde los usuarios prueban una aplicación de software
después de que se haya lanzado al público.
Conclusión

No existe un único proceso de prueba de software "básico", ya que los pasos específicos
involucrados en la prueba de cualquier aplicación de software dada variarán según la
naturaleza del proyecto, el software en sí y el equipo que realiza la prueba. Sin embargo,
hay algunos elementos comunes que suelen estar involucrados en la mayoría de los
procesos de prueba de software. Estos incluyen la creación de planes y casos de prueba, la
ejecución de pruebas y el análisis de resultados.

El primer paso en cualquier proceso de prueba de software es crear un plan de prueba. Este
documento describe los objetivos del proceso de prueba, las pruebas específicas que se
realizarán y los criterios que se utilizarán para determinar si el software funciona
correctamente. El plan de prueba también especificará quién será responsable de realizar
cada prueba y cuándo se ejecutarán las pruebas.

Una vez finalizado el plan de prueba, el siguiente paso es crear casos de prueba. Los casos
de prueba son escenarios específicos que se utilizarán para probar el software. Cada caso
de prueba debe estar diseñado para probar una funcionalidad específica del software. Una
vez creados los casos de prueba, se deben ejecutar. Por lo general, esto implica ejecutar el
software en diversas condiciones e ingresar diferentes datos para ver cómo responde el
software.

Una vez ejecutadas las pruebas, se deben analizar los resultados. Esto implica observar los
datos recopilados durante las pruebas y determinar si el software pasó o falló. Si el software
falló en alguna de las pruebas, el equipo deberá investigar la causa de la falla y determinar
cómo solucionarlo. Una vez que el software funciona correctamente, se completa el proceso
de prueba.

Bibliografías

MICROTECH. (n.d.). Proceso de pruebas de calidad de Software. Www.microtech.es.

Retrieved August 31, 2022, from
https://www.microtech.es/blog/proceso-de-pruebas-de-calidad-de-software

Pruebas de Software. (n.d.). ITI.

https://www.iti.es/servicios/calidad-de-software/pruebas-de-software/

Politécnica, U., Madrid, D., Manuel, J., & Peño, S. (2015). ESCUELA TÉCNICA SUPERIOR
DE INGENIERÍA Y SISTEMAS DE TELECOMUNICACIÓN Pruebas de Software.
Fundamentos y Técnicas.
https://oa.upm.es/40012/1/PFC_JOSE_MANUEL_SANCHEZ_PENO_3.pdf
‌