1.

Tema:
Tipos de pruebas de software.
2. Introducción
Siempre existen errores en nuestro entorno, ya sea en el desarrollo de software o en la
usabilidad que le damos a un software o página web, lo que conducirá a una mala experiencia
por parte del usuario; lo mismo puede causar nuestro software desarrollado a los usuarios que lo
usen, por lo tanto, es de vital importancia realizar las pruebas necesarias para tener un buen
producto o software.
Las pruebas de software nos ayudan a explorar, comprender y conocer el servicio o producto
que estamos desarrollando de una manera en la cual podemos reducir la cantidad de errores y
así evitar que estos sean mostrados al usuario. Para esto, podemos realizar distintos tipos de
pruebas.
A continuación, se listará cada tipo de prueba de software, se dará una definición de lo que es
cada una de estas y finalmente, se concluirá sobre este tema y los aspectos importantes.
3. Desarrollo:
3.1. PRUEBAS DEL SISTEMA[ CITATION Ian05 \l 12298 ][ CITATION Gui12 \l 12298 ].
Implican integrar dos o más componentes que implementan funciones del sistema o
características y a continuación se prueba este sistema integrado. En un proceso de desarrollo
interactivo, las pruebas del sistema se ocupan de probar un incremento que va a ser entregado
al cliente; en un proceso en cascada, las pruebas del sistema se ocupan de probar el sistema
completo.
Se enfocan en requisitos que son tomados directamente de la documentación como casos de
uso, reglas y funciones; para verificar el ingreso, procesamiento y recuperación apropiado de
datos. Esta prueba es muy compleja ya que intenta validar varias características al mismo
tiempo, a diferencia de otras que solo se centran en una o dos características del sistema al
mismo tiempo.

Existen dos fases distintas de pruebas del sistema:

1. Pruebas de integración: los equipos de pruebas tienen acceso al código fuente del
sistema. Cuando se descubre un problema, el equipo de integración intenta encontrar la
fuente del problema e identificar los componentes que tienen que ser depurados. Las
pruebas de integración se ocupan principalmente de encontrar defectos en el sistema.
Implica construir este a partir de sus componentes y probar el sistema resultante para
encontrar problemas que pueden surgir debido a la integración de los componentes. Los
componentes que se integran pueden ser componentes comerciales, componentes
reutilizables que han sido adaptados a un sistema particular o componentes nuevos
desarrollados.
Para muchos sistemas grandes, es probable que se usen los tres tipos de componentes. Las
pruebas de integración comprueban que estos componentes realmente funcionan juntos,
son llamados correctamente y transfieren los datos correctos en el tiempo preciso.

2. Pruebas de entregas: en las que se prueba una versión del sistema que podría ser
entregada a los usuarios. Aquí, el equipo de pruebas se ocupa de validar que el sistema
satisface sus requerimientos y con asegurar que el sistema es confiable. Las pruebas de
entrega son normalmente pruebas de caja negra en las que el equipo de pruebas se ocupa
 simplemente de demostrar si el sistema funciona o no correctamente. Los problemas son
comunicados al equipo de desarrollo cuyo trabajo es depurar el programa. Cuando el
cliente se implica en las pruebas de entregas, éstas menudo se denominan pruebas de
aceptación. Si la entrega es lo suficientemente buena, el cliente te puede entonces aceptarla
para su uso.
Fundamentalmente, se puede pensar en las pruebas de integración como las pruebas de
sistemas incompletos compuestos por grupos de componentes del sistema. Las pruebas de
entrega consisten en probar la entrega del sistema que pretende proporcionar a los clientes.
Naturalmente, estas se solapan, en especial cuando se utiliza el desarrollo incremental y el
sistema para entregar está incompleto.
Son el proceso de probar una entrega del sistema que será distribuido a los clientes. El
principal objetivo de este proceso es incrementar la confianza del suministrador en que el
sistema satisface sus requerimientos. Si es así, éste puede entregarse como un producto o
ser entregado al cliente. Para demostrar que el sistema satisface sus requerimientos, tiene
que mostrarse que éste entrega la funcionalidad específica, rendimiento y confiabilidad, y
que no falla durante su uso normal.
3. Pruebas de rendimiento: una vez integrado el sistema completamente, es posible probar
las propiedades emergentes del sistema tales como el rendimiento y fiabilidad. Las pruebas
de rendimiento tienen que diseñarse para asegurar que el sistema pueda procesar su carga
esperada. Esto normalmente implica planificar una serie de pruebas en las que la carga se
va incrementando regularmente hasta que el rendimiento del sistema se hace inaceptable.

Las pruebas de rendimiento implican estresar el sistema realizando demandas que están
fuera de los límites del diseño de software. Las pruebas de estrés van realizando pruebas
acercándose a la máxima carga del diseño del sistema hasta que el sistema falla. Este tipo
de pruebas tiene dos funciones:
1. Prueba el comportamiento de fallo de ejecución del sistema. Pueden aparecer
circunstancias a través de una combinación no esperada de eventos en donde la carga
sobre el sistema supere la máxima carga anticipada. Las pruebas de estrés verifican que
las sobrecargas en el sistema provocan fallos ligeros en lugar de colapsarlo bajo su
carga.
2. Sobrecargan el sistema y pueden provocar que se manifiesten defectos que
normalmente no serían descubiertos. Aunque se puede argumentar que estos defectos
es improbable que causen fallos de funcionamiento en un uso normal, puede haber
combinaciones inusuales de circunstancias normales que las pruebas de estrés pueden
reproducir.
3. Las pruebas de estrés se encargan de verificar que el sistema funciona apropiadamente
y sin errores.
4. Se propone encontrar errores debidos a recursos bajos o completitud de recursos.
4. Pruebas de desempeño.
Validan el tiempo de respuesta para las transacciones
Miden tiempos de respuesta, índices de procesamiento de transacciones y otros requisitos
sensibles al tiempo.
5. Pruebas de carga
Validar el tiempo de respuesta para las transacciones
Mide tiempos de respuesta, índices de procesamiento de transacciones y otros requisitos
sensibles al tiempo.
6. Pruebas de volumen
Verificar el tamaño de la Base de Datos, si el equipo es suficiente, etc.
 Hacen referencia grandes cantidades de datos para determinar los límites en que se causa
que el sistema falle.
Deben usarse múltiples clientes, ya sea corriendo las mismas pruebas o pruebas
complementarias para producir el peor caso de volumen.
7. Pruebas de recuperación y tolerancia a fallas
Verificar que los procesos de recuperación (manual o automática) restauran
apropiadamente la Base de Datos.
Estas pruebas aseguran que una aplicación o sistema se recupere de una variedad de
anomalías de hardware, software o rede con pérdidas de datos o fallos de seguridad.
8. Pruebas en múltiples sitios
Detectar fallas en configuraciones y comunicaciones de datos entre múltiples sitios.
El propósito de esta prueba es evaluar el correcto funcionamiento del sistema en múltiples
instalaciones.
9. Pruebas de compatibilidad y conversión
Buscar problemas de compatibilidad y conversión en los sistemas, el propósito es
demostrar que los objetivos de compatibilidad no han sido logrados que los
procedimientos de conversión no funcionan.
Compatibilidad entre programas y conversión de datos.
10. pruebas de integridad de datos y base de datos
Asegurar que lo métodos de acceso y procesos funcionan adecuadamente y sin ocasionar
corrupción de datos.
La Base de Datos y procesos de deben ser probados como sistemas separados del proyecto

3.2. PRUEBAS DE COMPONENTES[ CITATION Gui12 \l 12298 ][ CITATION Ian05 \l

12298 ].
Se denominan también pruebas de unidad, son el proceso de probar los componentes
individuales en el sistema. Éste es un proceso de pruebas de defectos, por lo que su objetivo es
encontrar defectos en estos componentes.
Existen diferentes tipos de componentes que pueden probarse en esta etapa:
1. Funciones individuales o métodos dentro de un objeto.
2. Clases de objetos que tienen varios atributos y métodos.
3. Componentes compuestos formados por diferentes objetos o funciones. Estos componentes
compuestos tienen una interfaz definida que se utiliza para acceder a su funcionalidad.
3.3. PRUEBAS DE VALIDACIÓN DE SOFTWARE A LA MEDIDA[ CITATION Gui12 \l
12298 ].
1. Pruebas de GUI
La navegación, objetos de la ventana y características como menús, medidas, gráficos,
posiciones, sirven para verificar la prueba de interfaz con el usuario mediante la
iteración con el software.
Pruebas de crear, modificar cada ventana para verificar la adecuada navegación,
comparando con similares al mercado.
2. Pruebas de ciclo de negocio
Estas deberán emular a través del tiempo todas las actividades a ejecutarse;
identificando un periodo y suponiendo las transacciones y actividades que podrían
ocurrir durante dicho periodo.
3. Pruebas de configuración
Se pretende verificar como opera el sistema en diferentes configuraciones tanto de
software como de hardware. Dado que las especificaciones de entorno de trabajo,
equipos de red, servidores pueden variar; incluso pueden tener diferentes versiones de
 software instaladas (SO).

4. Pruebas de estilo y aceptación

Verificar que la aplicación cumple con los estándares de estilos que el cliente solicito;
formato de ventas, letra, colores, etc.
Se realiza la prueba de aceptación, está se da antes de que el producto sea instalado o
puesto en marcha dentro del ambiente de producción, el cliente conjuntamente con el
especialista ejecuta aplicación verificando que contiene lo que pidió, satisfaciendo sus
criterios de aceptación, validando la documentación, basado en esta prueba el cliente
determina si acepta o no el sistema o producto.
5. Pruebas de instalación
Se centra en la verificación y validación de la instalación del sistema, esta tiene dos
propósitos: primero asegurar que el sistema puede ser instalado en todas las
configuraciones posibles (nuevas instalaciones, actualizaciones, instalaciones
completas o personalizadas), segundo, verificar que, una vez instalado el sistema opere
correctamente; lo que implica correr un número significativo de pruebas de
funcionabilidad.
6. Pruebas funcionales
Las pruebas Funcionales deben enfocarse en los requisitos funcionales, las pruebas
pueden estar basadas directamente en los Casos de Uso y las reglas del negocio.
Verifican la apropiada aceptación de datos, como el procesamiento, recuperación y la
implementación adecuada de las reglas del negocio.
Este tipo de pruebas están basadas en técnicas de caja negra, que es, verificar la
aplicación (y sus procesos internos) mediante la interacción con la aplicación vía GUI
y analizar la salida (resultados).
7. Pruebas de documentación y procesamiento
Evaluar la exactitud y claridad de la documentación del usuario y para determinar si el
manual de procedimientos trabajará correctamente como una parte integral del sistema.
Muchos defectos son identificados cuando un probador competente chequea
totalmente los manuales y documentación del usuario.
8. Pruebas de usabilidad
Determina cuán bien el usuario podrá usar y entender la aplicación. Identifica las áreas
de diseño que hacen al sistema de difícil uso para el usuario. La prueba de usabilidad
detecta problemas relacionados con la conveniencia y practicidad del sistema desde el
punto de vista del usuario.
3.4. PRUEBAS DE VALIDACIÓN A APLICACIONES GENÉRICAS[ CITATION
Gui12 \l 12298 ].
1. Pruebas alfa
Prueba de aceptación para detectar errores en el sistema bajo un ambiente controlado.
La verificación involucra la ejecución de partes o todo del sistema en ambientes
simulados, con el fin de encontrar errores. La retroalimentación de esta fase produce
cambios en el software para resolver los errores y fallas que se descubren antes de
poner el software en producción.

Realizar las pruebas de sistema bajo las siguientes características:

- se llevan a cabo en el lugar en donde fue desarrollado el software, en un ambiente
controlado, en el cual el desarrollador está presente.
- Se selecciona un grupo de usuarios para el alfa test y se les pide trabajen con el
sistema como parte de las pruebas.
 2. Pruebas Beta
Validación del sistema por parte del usuario, donde se realiza la prueba de aceptación,
en el cual la validación (o pruebas beta) involucra el uso del software en un ambiente
real. Se selecciona un grupo de usuarios que ponen a trabajar el sistema en un
ambiente real. Usan el sistema en sus actividades cotidianas, procesan transacciones y
producen salidas normales del sistema. Los usuarios pueden realizan pruebas a su
antojo realizando uso de la aplicación. El desarrollador no está presente. Pero los
usuarios están advertidos de que están usando un sistema que puede fallar. Se establece
un periodo de pruebas beta en el que los errores detectados no sean de carácter crítico
para el sistema.
4. Conclusión
Las pruebas de software existentes son muchas como se pudo observar, pero son de vital
importancia, muy necesarias e indispensables a la hora de desarrollar nuestro software;
permitiéndonos identificar problemas de manera prematura y así poder brindar un servicio
de calidad.

Estas pruebas, aunque se intuya que se perderá mucho tiempo en emplear una por una, es
totalmente erróneo, dado que el tiempo que le empleamos a cada prueba no se compara
con dejar todas las pruebas para el final, dado que no podremos encontrar errores según el
avance de nuestro software, lo que implica una revisión total y pérdida de tiempo, además
si no involucramos en las pruebas necesarias al cliente, no sabremos si estamos
desarrollando lo que el realmente nos pide; lo cual ocasiona otra pérdida de tiempo ya que
si el cliente no está conforme tenemos que desarrollar todo nuevamente o modificar ciertas
cosas.

Debemos tener muy claro cuando emplear cada tipo de prueba y cuándo es necesario
involucrar al cliente, no podemos involucrar al cliente en una prueba de integración ya que
él no tendría idea de lo que se trata además se sentiría confundido y posiblemente dude de
nuestro profesionalismo.
En forma general, sin restar importancia a las demás pruebas; se considera como pruebas
fundamentales a las pruebas de componentes que se basan en probar las partes del sistema,
y a las pruebas del sistema que prueban el sistema como un todo.

5. Bibliografía

[1] I. Sommerville, «Evolución del software,» de Ingeniería del software, PEARSON EDUCACIÓN,
S.A, 2005, pp. 491-504.
[2] G. Lemus, «es.slideshare.net,» 27 04 2012. [En línea]. Available:
https://es.slideshare.net/GuillermoLemus/tipos-de-pruebas-de-software.