Documentos de Académico
Documentos de Profesional
Documentos de Cultura
7. Glosario
8. Referencias bibliográficas
Control de cambios
Créditos
Creative Commons
En tal sentido, se revisarán las estrategias de prueba de software, las pruebas a aplicar en aplicaciones
convencionales, para software orientado a objetos y software orientado a sistemas web.
2. Mapa conceptual
Fuente: SENA
Las aplicaciones (o software en general), son propensas a tener fallos, pues sus procesos son
diseñados e implementados por el ser humano y la presencia de estos errores puede contribuir al
fracaso de cualquier proyecto e impactar de forma negativa a la empresa.
En tal sentido, al interior del proceso de control de la calidad, se hace necesario aplicar pruebas de
software, que garanticen la satisfacción del cliente. Y estas deben ser consideradas como un conjunto
de actividades insertas dentro del mismo desarrollo y construcción del software.
La prueba de software corresponde a un tema más amplio, que usualmente se conoce como verificación
y validación (V&V). La verificación, comprende el conjunto de tareas que garantizan que el software
implemente correctamente una función específica.
Según Pressman (2010) “La validación, es un conjunto diferente de tareas que aseguran que el software
en construcción, siga los requerimientos del cliente” (p. 380). De acuerdo al modelo utilizado en la
construcción del software, se aplican determinados tipos de pruebas, las cuales se pueden aplicar en
cualquier momento del proceso de análisis, diseño, desarrollo e implementación.
3.1. Propósitos
Pressman (2010) comenta que “La aplicación de pruebas de software se realiza para descubrir errores
que se cometieron de manera inadvertida en el proceso de diseño y construcción” (p.381). Según la
enciclopedia web EcuRed (2012), los objetivos de las pruebas de software son:
“Detectar defectos en el software; verificar la integración adecuada de los componentes; verificar que todos
los requisitos se han implementado correctamente; identificar y asegurar que los defectos encontrados se han
corregido antes de entregar el software al cliente y diseñar casos de prueba que sistemáticamente saquen a
la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo”.
3.2. Metodología
La prueba de software debe comenzar de lo pequeño hacia lo grande. Para Pressman (2010),
Las primeras etapas de prueba se enfocan sobre un solo componente, o un pequeño grupo de componentes
relacionados y se aplican para descubrir errores en los datos y en la lógica de procesamiento por componente.
Después estos deben integrarse hasta que se construya el sistema completo. La prueba de software es un
conjunto de actividades que pueden planearse por adelantado y realizarse de manera sistemática. Por esta
razón, durante el proceso de desarrollo debe definirse una plantilla de prueba, que integre en un conjunto de
pasos con métodos y técnicas específicos (p. 383).
• Alcance de la prueba: determina el listado de funcionalidades del producto y/o software que serán
probados durante el transcurso de la prueba.
• Estrategia de pruebas: determinar a través de un análisis de riesgos qué pruebas se deben tener
en cuenta para ser aplicadas.
• Criterios de salida: entre los integrantes del grupo, se definen las condiciones a considerar después
de que la actividad de pruebas fue finalizada.
• Otros aspectos: tener en cuenta estimación de tiempos, los roles y/o recursos que harán parte del
proceso, la preparación del entorno de pruebas, cronograma base, entre otros.
Luego de que se elabore y realice la aprobación del Plan de Pruebas, los integrantes del equipo de
trabajo deberán dar inicio al análisis de toda la documentación existente con respecto al sistema,
como por ejemplo casos de uso, arquitectura del sistema, diseños, manuales de usuario, historias de
usuario, manuales técnicos, entre otros.
Esta se deberá dar con la creación de los datos de prueba que sean necesarios para poder ejecutar
los casos diseñados.
Esta etapa es necesaria para poder determinar la factibilidad de dar por finalizado un ciclo de pruebas.
Para poder lograr esto, es conveniente comparar los resultados frente a las métricas definidas. Si
estas pruebas no son superadas, no es posible continuar con la siguiente etapa.
En esta etapa se deberán cerrar las incidencias reportadas. Se verificará si los entregables planeados
han sido aprobados; se terminan y aprueban los documentos de soporte de la prueba y se analizan las
lecciones aprendidas para aplicar a futuros proyectos.
El proceso de pruebas de software, en el ciclo de vida del software, busca generar mayor confianza
en el cumplimiento de los requerimientos funcionales y no funcionales. Para Mayorga y Arce (2013),
se hace necesaria la implementación de mecanismos que permitan garantizar la calidad del software,
estos se denominan modelos de pruebas de software. Existen varios tipos de esquemas.
Tabla 1.
Modelos de pruebas de software
Modelo Características
Fuente: SENA
Para cumplir con un procedimiento de pruebas de software, se deberán definir estándares y establecer
procedimientos mediante los cuales, se pueda comparar lo alcanzado durante cada una de las fases.
Durante muchos años, se confió en el análisis, diseño e inteligencia del programador cuando se trataba
de construir un software. Actualmente existen modernas técnicas de diseño que ayudan a reducir
el número de errores iniciales que son inherentes al código. De igual modo, diferentes métodos de
prueba comienzan a agruparse en estrategias.
Existen dos maneras de probar el software. La primera consiste en esperar hasta que el sistema esté
completamente construido y aplicar pruebas sobre el sistema total, con la esperanza de encontrar
errores. Este tipo de estrategia, no es la más adecuada.
Desde una mirada procedimental, las pruebas de software en la Ingeniería del Software, son
generalmente un conjunto de cuatro pasos, que se articulan de forma secuencial.
Para Pressman (2010), “Las pruebas se focalizan inicialmente en cada componente de manera
individual, lo que garantiza que funcionen adecuadamente como unidad. De ahí el nombre de prueba
de unidad”. A continuación, en la prueba de integración, los componentes deben ensamblarse o
integrarse para formar el sistema del software completo. Se abordan los conflictos asociados con los
problemas duales de verificación y construcción de programas.
Durante la integración, se usan más las técnicas de diseño de casos de prueba que se enfocan en
entradas y salidas, aunque también pueden usarse técnicas que ejercitan rutas de programa específicas
para asegurar la cobertura de las principales rutas de control.
Finalmente, se aplica la prueba del sistema, la cual verifica que todos los elementos se mezclan de
manera adecuada, lográndose el funcionamiento y rendimiento global del sistema.
En las pruebas de unidad o unitarias, se evalúa el funcionamiento individual de cada módulo, escribiendo
casos de prueba para cada funcionalidad o método en el módulo, de forma que se determine la
integridad del mismo (Mayorga & Arce, 2013, p.32).
Se focaliza en ejecutar cada módulo o unidad mínima a ser probada, (Ejemplo: Una clase). Esta
situación provee un mejor modo de manejar la integración de las unidades en componentes mayores.
Busca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo lógico es
válido.
Según Mayorga y Arce (2013), esta prueba permite la verificación de las unidades de un software,
sean estas un componente o un módulo. La ventaja de esta prueba consiste en verificar la lógica del
procesamiento interno que sea aplicable a varios componentes de un programa al tiempo.
Las pruebas de integración pretenden verificar que el conjunto de los módulos de un sistema funciona
adecuadamente (Mayorga y Arce, 2013).
Es una técnica sistemática de integración incremental, para construir la arquitectura del software,
mientras se aplican las pruebas para descubrir errores asociados con la interfaz. Su objetivo es
tomar componentes a los que se aplicó una prueba de unidad y construir una estructura de programa
que determine el diseño.
No obstante, en algunos casos la prueba de integración “se utiliza para intentar una integración
que no sea incremental; enfoque llamado big bang, el cual, combina todos los componentes por
anticipado y se prueba todo el programa como un todo” (Mayorga & Arce, 2013, p. 32).
Las pruebas de integración incremental son lo contrario al enfoque Big Bang. El programa se
construye y prueba en pequeños incrementos, donde los errores son más fáciles de aislar y corregir;
las interfaces tienen más posibilidades de probarse por completo; y puede aplicarse un enfoque de
prueba sistemático.
La principal dificultad de esta prueba es localizar los errores. Se aplica de tal manera que los módulos
se integran jerárquicamente hacia abajo, comenzando con el módulo de control principal (M1) según
la figura 4. Los módulos subordinados al módulo de control principal se incorporan en la estructura,
primero en profundidad o primero en anchura.
10
Para lograr esta integración, es necesario añadir componentes desde una configuración mínima y
probar después de añadir uno a uno el cambio generado en el funcionamiento del sistema cada vez
que ocurre un incremento (Mayorga y Arce, 2013).
Mc
Ma Mb
D1 D2 D3
Grupo 3
Grupo 2
Grupo 1
11
Su propósito se focaliza en probar el sistema constantemente buscando que saque “humo” o falle.
En algunos proyectos, este tipo de prueba va junto con las pruebas funcionales. Permite detectar
problemas que por lo regular no son detectados en las pruebas normales. Algunas veces, si las
pruebas ocurren en etapas tardías, esta será una forma de garantizar el buen desarrollo. Las pruebas
de humo no son exhaustivas, pero van de extremo a extremo de la aplicación (Abad, 2005).
Abad (2005), comenta que deberá presentarse un listado de pruebas de validación a aplicaciones a
sistemas a la medida, las cuales están orientadas a la validación del funcionamiento de software a
la medida del modelo de negocio.
Asegura que el sistema funciona de acuerdo con el modelo de negocios, emulando todos los eventos
en función del tiempo.
Por medio de esta prueba se verifica la interacción del usuario con el software. El objetivo será
asegurar que la interfaz presente una adecuada navegación por medio de diferentes funcionalidades.
Además, permite asegurar que los objetos de la interfaz que se van a adoptar, se encuentren dentro
de estándares de la industria.
Con este tipo de pruebas se puede verificar la operación del sistema en diferentes configuraciones de
hardware y software. Las especificaciones para las estaciones de trabajo, equipos de red y servidores,
pueden presentar variaciones en la mayoría de los ambientes de producción.
12
Comprueba que la aplicación sigue los estándares de estilo propios del cliente, tales como el formato
de las ventanas, colores corporativos, tipos de letra, entre otros.
Esta prueba está destinada a confirmar que el producto está listo para el uso operativo. Suele ser
un subconjunto de las pruebas de sistema y se ejecuta antes de que la aplicación se instale dentro
de un ambiente de producción. Su ejecución se realiza por parte del cliente, o por un especialista de
la aplicación.
Está orientada a determinar si el sistema satisface los criterios de aceptación, validando los requisitos
que han sido levantados para el desarrollo, incluyendo la documentación y los procesos de negocio.
Basado en esta prueba, el cliente determina si acepta o rechaza el sistema.
Está orientada a verificar y validar que el sistema se instale apropiadamente en cada computador de
cliente, bajo estas condiciones:
● Instalaciones nuevas, nuevas máquinas a las que nunca se les ha instalado el sistema.
13
Su objeto está orientado a determinar la usabilidad del sistema. En tal sentido, busca medir qué tan
fácil el usuario podrá usar y entender la aplicación, tratando de identificar las áreas de diseño que
dificultan el uso del sistema por parte del usuario.
Esta prueba está orientada a ejecutar el sistema en un ambiente real para encontrar errores y validar
el producto contra sus especificaciones originales. En tal sentido, determina las pruebas de sistema
que serán corridas para validar el sistema en producción.
Las pruebas de validación a aplicaciones genéricas están orientadas a la validación del funcionamiento
del software genérico de acuerdo con los requerimientos funcionales del cliente.
La verificación en la prueba Alfa, involucra la ejecución por partes o de todo del sistema en ambientes
simulados, con el fin de encontrar errores. La retroalimentación produce cambios en el software para
resolver los errores y fallas que se descubren.
Está orientada para que un grupo de usuarios finales, por un tiempo determinado, utilice y realice la
validación del software en un ambiente real.
Según Zapata (2013), “Este tipo de prueba debe ser ejecutada idealmente por un equipo de pruebas
ajeno al equipo de desarrollo” (p.43). La obligación de este equipo, consiste en la ejecución de
actividades de prueba, con las que debe verificar que la funcionalidad total de un sistema fue
implementada, de acuerdo a los documentos de especificación definidos en el proyecto.
Los casos de prueba a diseñar en este nivel, cubren aspectos funcionales y no funcionales del
sistema. Para su diseño, el equipo debe utilizar bases de prueba entregables como: requerimientos
iniciales, casos de uso, historias de usuario, diseños, manuales técnicos y de usuario final, entre
otros.
14
Es una prueba del sistema que fuerza al software a fallar en varias formas y que verifica que la
recuperación se realice de manera adecuada. Si la recuperación es automática (realizada por el
sistema en sí), se evalúa el reinicio, los mecanismos de puntos de verificación, la recuperación
de datos y la reanudación para correcciones. Si la recuperación requiere intervención humana, se
evalúa el tiempo medio de reparación (TMR) para determinar si está dentro de límites aceptables
(Pressman, 2010).
También llamadas pruebas de resistencia (stress). Se diseñan para enfrentar los programas a
situaciones anormales, para evaluar el tiempo transcurrido antes de que falle o los recursos que utiliza
antes de bloquearse.
Evalúa el rendimiento del sistema bajo condiciones normales, cuando los componentes del software
se encuentran totalmente integrados, teniendo en cuenta todos los elementos del sistema y así poder
juzgar su verdadero desempeño ante diversas situaciones, condiciones y contextos (Mayorga & Arce,
2013).
El objetivo de esta estrategia de prueba es encontrar el mayor número posible de errores con una
cantidad manejable de esfuerzo aplicado durante un lapso realista.
No obstante, las operaciones (métodos) dentro de la clase son las unidades comprobables más
pequeñas.
15
Existen dos estrategias diferentes para la prueba de integración de los sistemas OO. La primera, la
prueba basada en Hebra o Hilo, integra el conjunto de clases requeridas para responder a una entrada
o evento para el sistema. Cada hilo se integra y prueba de manera individual.
El segundo enfoque de integración, la prueba basada en uso, comienza la construcción del sistema
al probar dichas clases (llamadas clases independientes) que usan muy pocas clases servidor (si
es que usan alguna). Después de probar las clases independientes, se prueba la siguiente capa de
clases, llamadas dependientes, que usan las clases independientes. Esta secuencia de probar capas
de clases dependientes continúa hasta que se construye todo el sistema (Pressman, 2010).
Existen otras estrategias que se aplican a la realización de pruebas para aplicaciones convencionales,
que a continuación se analizarán al detalle.
La prueba de caja blanca del software se basa en el examen cercano de los detalles de procedimiento.
Las rutas lógicas a través del software y las colaboraciones entre componentes se ponen a prueba al
revisar conjuntos específicos de condiciones y/o bucles. Existe tres tipos de pruebas de caja blanca:
- Pruebas de condición
- Pruebas de cubrimiento
- Pruebas de bucle
Permiten ejecutar al menos una vez cada sentencia, para la cual se necesitan varios casos de prueba
que permitan:
● Que cada condición se cumpla en un caso y en otro no. En general, se necesitan tantos casos como
condiciones, más uno (número ciclomático).
16
Ejemplo de estas pruebas, son la detección y notificación de errores internos en un código sin errores.
Permite cumplir o no, partes de una condición, para ello se necesitan varios casos de prueba que
permitan:
● Cada expresión simple deberá cumplirse en un caso y en otro no, siendo decisiva en el resultado.
Se utilizan para conseguir números de repeticiones especiales a través de bucles simples que permitan:
Bucles anidados
● Repetir un número medio (típico) los bucles internos, el mínimo los externos, y variar las repeticiones
del bucle intermedio ensayado.
Se refiere a las pruebas que se llevan a cabo en la interfaz del software. Una prueba de caja negra
examina algunos aspectos fundamentales de un sistema con poca preocupación por la estructura
lógica interna del software (Mayorga y Arce, 2013).
17
● Enfocarse en asegurar que la comunicación entre módulos o componentes del sistema sea acorde
a lo especificado.
7. Glosario
Pruebas de aceptación: es una estrategia que integra pruebas como: Prueba de integración
descendente, Prueba de integración ascendente, Prueba de regresión, y Prueba de humo. Está
orientada a verificar que el conjunto de los módulos de un sistema funcione adecuadamente al
mismo tiempo.
Pruebas de caja blanca: tipo de prueba orientada a evaluar los procedimientos, condiciones y
bucles propios del desarrollo de software.
Pruebas de caja negra: tipo de prueba orientada a evaluar las interfaces del software.
Pruebas de integración: es una estrategia que integra pruebas como: Prueba de integración
descendente, Prueba de integración ascendente, Prueba de regresión, y Prueba de humo. Está
orientada a verificar que el conjunto de los módulos de un sistema funcione adecuadamente en
conjunto.
Pruebas de unidad: es una estrategia que integra una prueba con el mismo nombre. Está orientada
a evaluar el funcionamiento individual de cada módulo.
Pruebas de validación a aplicaciones genéricas: es una estrategia que integra pruebas como:
Prueba alfa (para desarrolladores), y Prueba beta (para usuarios). Está orientada a la validación del
funcionamiento del software genérico de acuerdo con los requerimientos funcionales del cliente.
Pruebas de validación a sistemas a la medida: es una estrategia que integra pruebas como: Prueba
del ciclo del negocio, Prueba de GUI o interfaz, Prueba de configuración, Prueba de estilo, Prueba
de aceptación, Prueba de instalación, Prueba funcional, Prueba de documentación y procedimiento,
Prueba de usabilidad, y Prueba de campo. Está orientada a la validación del funcionamiento de
software a la medida del modelo de negocio.
18
WEBAPPS: término que se utiliza para hacer referencia a una página web, condicionada a cualquier
dispositivo móvil. Su condicionamiento se debe a la versión de HTML5 y CSS3.
8. Referencias bibliográficas
Abad Londoño, J. (2005, Julio 1). Tipos de prueba de software. [Web log post] Recuperado de
http://ing-sw.blogspot.com.co/2005/04/tipos-de-pruebas-de-software.html
Calderón Hernández, M. (2014). Modelo para pruebas de software y auditoría en entorno Microsoft.Net.
Recuperado de http://www.monografias.com/trabajos20/pruebas-de-software/pruebas-de-software2.
shtml
EcuRed - Conocimiento con todos y para todos. (s.f.). Pruebas de software. Recuperado de
https://www.ecured.cu/Pruebas_de_software
Fiestas, J. (2014, marzo 3). QA: Pruebas para asegurar la calidad del producto software. [Web log
post]. Recuperado de http://blog.elevenpaths.com/2014/09/qa-pruebas-para-asegurar-la-calidad-del.
html
Gutiérrez, J., Escalona, M., Mejias, M., & Reina, A. (2006). Modelos de pruebas para pruebas del
sistema. Recuperado de http://ceur-ws.org/Vol-227/paper07.pdf
Guzmán Cortéz, O. (s.f.). Aplicación práctica del diseño de pruebas de software a nivel de programación.
Recuperado de https://www.icesi.edu.co/revistas/index.php/sistemas_telematica/article/view/935
Martínez España, R. (Dirección). (2015). Ingeniería del software - pruebas de software [Archivo de
video] Recuperado de https://www.youtube.com/watch?v=CSgdhH5gp_U
19
Universidad Nacional de México - UNAM. (s.f.). Metodologías y procesos de análisis de software. Capítulo
2. Recuperado de http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.52.100/175/
A5%20Cap%C3%ADtulo%202.pdf?sequence=5
Control de cambios
20
21