Unidad 2B

Unidad 2
Desarrollo y ejecución de casos de prueba

I.- Introducción o motivación inicial
¡Bienvenidos estudiantes!
Junto con saludar los invito a revisar la segunda unidad del módulo de Taller de Testing y
Calidad de Software, donde a través de este documento conoceremos herramientas y
caso de prueba, aplicando las distintas pruebas de sistemas.
Los aprendizajes esperados para esta unidad son:
 Caracterizan el concepto de prueba de sistema y su importancia dentro del

proceso de desarrollo de software.
 Relacionan la aplicación de diferentes tipos de pruebas de sistema, a la mejora en
la calidad de un software.
 Crean planes de pruebas de sistema para proyectos de desarrollo de software.
 Ejecutan pruebas funcionales y no funcionales para corregir errores en un
proyecto de software.
II.-Listado de Contenidos de la unidad
 Concepto de pruebas de sistema.

- Tipos de pruebas.
- Definición: (Pruebas estáticas, dinámicas, manuales, automáticas, funcionales y no
funcionales).
- Herramientas para realización de pruebas de sistema existentes en el mercado.
- Importancia y función de las pruebas de sistema.
 Crecimiento de uso de un software.

 Antecedentes históricos del surgimiento de las pruebas de sistema.
 Pruebas estáticas y dinámicas.
 Pruebas de compatibilidad.
 Pruebas de regresión.
 Pruebas de integración.
- Tipos de pruebas según su ejecución (manuales y automáticas).
- Enfoques de pruebas de sistema (caja negra, caja blanca o testing aleatorio).
- Niveles de pruebas (unitarias, modulares, integración, sistema e integración).
 Concepto de plan de pruebas de sistema.

- Importancia de un plan e pruebas. Objetivos
- Análisis de planes de pruebas. Estructura
- Diseño de planes de prueba. Requerimientos.
- Implementación de planes e pruebas.
 Conceptos de pruebas funcionales y no funcionales.

- Tipos de pruebas funcionales:
o Pruebas de humo
o Pruebas de regresión
o Pruebas de aceptación
o Alpha testing
o Beta testing.
- Tipos de pruebas no funcionales:
o Pruebas de seguridad
o Pruebas de usabilidad
o Pruebas de rendimiento
o Pruebas de escalabilidad
o Pruebas de mantenibilidad
o Pruebas de inestabilidad
o Pruebas de portabilidad
- Aplicación de pruebas funcionales.
- Aplicación de pruebas no funcionales.
Instituto Profesional AIEP. Educación Online 2016

III.-Desarrollo de temas de la unidad
Tema 1.
 Principios Fundamentales del Proceso de Pruebas

En el proceso de Ingeniería de Software, existen, dependiendo la metodología de desarrollo
utilizada (SCRUM, RUP, etc.), una serie de etapas claramente identificadas en el proceso, tales
como: análisis diseño, implementación, pruebas, etc. Sin embargo, por algunas razones que no
vale la pena discutir en este apartado, es la etapa correspondiente al proceso de pruebas de un
producto, a la que las empresas desarrolladoras menos tiempo de planeación asignan y a la
que menos recursos comprometen en sus respectivos planes de trabajo. En muchos casos incluso,
las fábricas de software, suelen acudir a una mala práctica en donde involucran personal de
desarrollo, para ejecutar actividades de pruebas, sin tener en cuenta que estas personas, debido
al rol que asumen dentro del proceso, de manera involuntaria protegerán el estado de su
producto, muchas veces minimizando la criticidad de los fallos encontrados, sesgando de esta
manera el grado real de calidad del producto.
Por esta y muchas razones más, es altamente aconsejable, que esta etapa de pruebas sea
ejecutada por un equipo ajeno a los procesos de desarrollo o en el mejor de los casos por un
tercero especializado en el aseguramiento de la calidad del software.
5 Principios fundamentales, para los equipos o personas que incursionan en metodologías de

pruebas.
1. Las pruebas exhaustivas no son viables: para proyectos cuyo número de casos de
uso o historias de usuario desarrolladas sea considerable, se requeriría de
una inversión muy alta en cuanto a tiempo y recursos necesarios para cubrir pruebas
sobre todas las funcionalidades del sistema; por esta razón, es conveniente realizar
un análisis de riesgos de todas las funcionalidades del aplicativo y determinar en este
punto cuales serán objeto de prueba y cuáles no. Naturalmente, ninguna funcionalidad
que haga parte del ciclo de negocio del aplicativo debe quedar por fuera de esta revisión.
Por otra parte, es necesario evitar para el caso de funcionalidades complejas, escribir (n)
casos de prueba, que cubran todas las posibles combinaciones de entrada y salida que
puede llegar a tener las funcionalidades. Diseñar casos de prueba bajo estas condiciones,
solo es justificable cuando la funcionalidad objeto de prueba tiene una complejidad
trivial. Por las razones ya mencionadas, es altamente sugerirle diseñar y ejecutar pruebas
de muestra, las cuales sean elegidas bajo criterios de experiencia y/o aleatoriedad.
2. El proceso no puede demostrar la ausencia de defectos: independientemente de la

rigurosidad con la que se haya planeado el proceso de pruebas de un producto, nunca
será posible garantizar al ejecutar este proceso, la ausencia total de defectos de un

producto en su paso a producción, debido entre otras cosas, al principio no. 1, en el cual
no se permite escribir y ejecutar casos de prueba de manera exhaustiva. Por lo anterior,
un proceso de pruebas planeado, puede garantizar una reducción significativa de los
posibles fallos y/o defectos del software, pero nunca podrá garantizar que el software no
fallará en su ambiente de producción.
3. Inicio temprano de pruebas: es típico ver como algunas firmas de desarrollo, ven el
proceso de pruebas como una serie de actividades que se dan de manera aislada y solo
hasta el momento en el que se tiene una reléase de pruebas del producto, el equipo de
pruebas se incorpora a ejecutar las respectivas actividades; aunque sea válido, lo
recomendable es que las actividades de pruebas se ejecuten de manera paralela con cada
una de las etapas del proceso. Las actividades de un proceso de pruebas, deben ser
incorporadas incluso desde el mismo momento en el que se ejecutan las etapas
de análisis y diseño, por esta razón, documentos de especificación y de diseño, deben ser
sometidos a revisiones, lo que ayudará a detectar problemas en la lógica del negocio
mucho antes de que se escriba una sola línea de código. En conclusión, cuanto más
temprano se detecte un defecto bien sea sobre los entregables de especificación y diseño
o sobre el producto, menos costoso será para el equipo del proyecto dar solución a
dichos incidentes.
4. Las pruebas no garantizan la calidad del Software: si bien las pruebas del Software
ayudan a mejorar la calidad de un producto, esto no es totalmente garantizable, si estas
actividades no son incorporadas desde etapas tempranas del proyecto. Este nivel de
calidad no será garantizado, entre otros aspectos, porque existe la posibilidad de que
algunas funcionalidades del software pueden no suplir las necesidades y
expectativas de los usuarios finales a los cuales va dirigido el desarrollo, así el
comportamiento del software sea correcto y responda fielmente a lo que fue
especificado. Una buena práctica que ayuda a mitigar el riesgo de que el usuario final no
esté satisfecho con el producto, es involucrarlo desde instancias tempranas en el
proceso y tener en cuenta sus apreciaciones para generar una retroalimentación a
tiempo.
5. Ejecución de pruebas bajo diferentes condiciones: en un plan de pruebas, siempre existe

un apartado relacionado con la estrategia a utilizar por parte del equipo de pruebas, en
este ítem, se define entre otros aspectos, el número de ciclos de prueba que se
ejecutarán sobre las funcionalidades del negocio. La idea consiste, en que por cada ciclo
de prueba ejecutado, se generen diferentes tipos de condiciones, basados
principalmente en la variabilidad de los datos de entrada y set de datos utilizados. No es
conveniente, ejecutar en cada ciclo, los casos de prueba basados en los mismos datos del
ciclo anterior, dado que con seguridad, se obtendrán los mismos resultados. En
conclusión, ejecutar ciclos bajo diferentes tipos de condiciones, permitirá identificar
posibles fallos en el sistema, que antes no eran fácilmente reproducibles.

Metodología de Pruebas
Los procesos de aseguramiento de calidad de un producto de software suelen dividirse en lo que
respecta a su componente analítico en pruebas estáticas y dinámicas. La diferencia fundamental
entre estos tipos de pruebas, radica en que las pruebas estáticas se centran en evaluar la calidad
con la que se está generando la documentación del proyecto, por medio de revisiones periódicas,
mientras que las pruebas dinámicas, requieren de la ejecución del software con el fin de medir el
nivel de calidad con la que este fue codificado y el nivel de cumplimiento en relación con la
especificación del sistema.
Realizar pruebas dinámicas a un producto de software, suele en la mayoría de los casos

confundirse con una simple actividad de ejecución de pruebas y reporte de incidencias, sin
embargo, para productos de complejidad media en adelante, lo recomendable es implementar de
manera formal una metodología de pruebas que se ajuste y acople uniformemente con la
metodología de desarrollo seleccionada por la firma desarrolladora.
Para procesos de desarrollo basados en la metodología RUP o métodos tradicionales,

implementar una metodología de pruebas es totalmente viable, teniendo en cuenta que estas
metodologías están orientadas a la documentación y a la formalización de todas las actividades
ejecutadas. Si por el contrario, la firma desarrolladora guía su proceso bajo lineamientos basados
en metodologías ágiles, será necesario reevaluar la conveniencia de ejecutar todas las actividades
que implica un proceso de pruebas formal, lo que en la mayoría de los casos, conlleva a reducir
al mínimo las actividades relacionadas con un proceso de pruebas, circunstancia que
naturalmente puede desencadenar en la liberación de productos con bajos niveles de calidad.
Un proceso de pruebas formal, está compuesto, cuando menos por las siguientes 5 típicas etapas:
1. Planeación de pruebas.
2. Diseño de pruebas.
3. implementación de pruebas.
4. Evaluación de criterios de salida.
5. Cierre del proceso.
1. Planeación de Pruebas: Es la etapa en donde se ejecutan las primeras actividades

correspondientes al proceso de pruebas y tiene como resultado un entregable denominado
plan de pruebas el cual debe estar conformado en cuando menos por aspectos tales como:
1.1. Alcance de la prueba: determina que funcionalidades del producto y/o software serán
probadas durante el transcurso de la prueba. Este listado de funcionalidades a probar se
extrae con base a un análisis de riesgos realizado de manera previa, que tienen en cuenta
variables tales como el impacto que podría ocasionar la falla de una funcionalidad y la
probabilidad de falla de una funcionalidad. Producto de este análisis, se cuenta con
información adicional que permite determinar además del alcance detallado del proceso

de pruebas, la prioridad con la que las funcionalidades deben probarse y la profundidad
de las pruebas.
1.2. Tipos de Prueba: en este punto se debe determinar qué tipos de pruebas requeriría el
producto. No todos los productos de software requieren la aplicación de todos los tipos
de pruebas que existen, por esta razón, es estrictamente necesario que el líder de
pruebas se plantee preguntas que le permitan determinar qué tipos de prueba son
aplicables al proyecto en evaluación. Los posibles tipos de prueba a aplicar son: pruebas
de stress, pruebas de rendimiento, pruebas de carga, pruebas funcionales, pruebas de
usabilidad, pruebas de regresión, entre otros.
1.3. Estrategia de Pruebas: teniendo en cuenta que no es viable probar con base a todas las
posibles combinaciones de datos, es necesario determinar a través de un análisis de
riesgos sobre que funcionalidades debemos centrar nuestra atención. Adicionalmente,
una buena estrategia de pruebas debe indicar los niveles de pruebas (ciclos) que
aplicaremos y la intensidad o profundidad a aplicar para cada nivel de pruebas definido.
En este punto también es importante definir los criterios de entrada y salida para
cada ciclo de pruebas a ejecutar.
1.4. Criterios de Salida: entre las partes involucradas en el proceso, se define de manera
formal, bajo qué condiciones se puede considerar que una actividad de pruebas fue
finalizada. Los criterios de salida se deben definir para cada nivel de pruebas a ejecutar.
Algunos ejemplos de criterios de salida que pueden ser utilizados son: porcentaje de
funcionalidades de alto riesgo probadas con éxito, número defectos críticos y/o mayores
aceptados, etc.
1.5. Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se debe incluir una
estimación de tiempos, los roles y/o recursos que harán parte del proceso, la
preparación del entorno de pruebas, cronograma base, etc.
2. Diseño de Pruebas: una vez elaborado y aprobado el plan de pruebas, el equipo de trabajo
debe iniciar el análisis de toda la documentación existente con respecto al sistema, con el
objeto de iniciar el diseño de los casos de prueba. Los entregables claves para iniciar este
diseño pueden ser: casos de uso, historias de usuario, arquitectura del sistema, diseños,
manuales de usuario (si existen), manuales técnicos (si existen). El diseño de los casos, debe
considerar la elaboración de casos positivos y negativos. Los casos de prueba negativos
permiten validar cómo se comporta el sistema ante situaciones atípicas y permite verificar la
robustez del sistema, atributo que constituye uno de los requerimientos no funcionales
indispensable para cualquier software. Por último, es necesario definir cuáles son los datos
de prueba necesarios para la ejecución de los casos de prueba diseñados.
3. Implementación y Ejecución de Pruebas: la ejecución de pruebas debe iniciar con la creación

de los datos de prueba necesarios para ejecutar los casos de prueba diseñados. La ejecución

de estos casos, puede realizarse de manera manual o automatizada; en cualquiera de los
casos, cuando se detecte un fallo en el sistema, este debe ser documentado y registrado en
una herramienta que permita gestionar los defectos (Bug Tracker). Una vez el defecto ha
sido corregido por la firma desarrolladora en su respectivo proceso de depuración, es
necesario realizar un re-test que permita confirmar que el defecto fue solucionado de manera
exitosa. Por último, es indispensable ejecutar un ciclo de regresión que nos permita
garantizar, que los defectos corregidos en el proceso de depuración de la firma, no hayan
desencadenado otros tipos de defectos en el sistema.
4. Evaluación de Criterios de Salida: los criterios de salida son necesarios para determinar si es
posible dar por finalizado un ciclo de pruebas. Para esto, es conveniente definir una serie de
métricas que permitirán al finalizar un proceso de pruebas, comparar los resultados obtenidos
contra las métricas definidas, sí los resultados obtenidos no superan la métricas definidas, no
es posible continuar con el siguiente ciclo de pruebas.
Existen varios tipos de criterios de salida dentro de los cuales se pueden mencionar:
cubrimiento de funcionalidades en general, cubrimiento de funcionalidades críticas para el
sistema, Número de defectos críticos y mayores detectados, etc. También es importante
aclarar que el proceso de pruebas puede ser suspendido y/o paralizado, debido entre otros, a
aspectos relacionados con el presupuesto y la calidad mínima del sistema requerida para el
inicio formal de pruebas.
5. Cierre del proceso: durante este periodo de cierre el cual históricamente se ha comprobado
que se le destina muy poco tiempo en la planeación, se deben cerrar las incidencias
reportadas, se debe verificar si los entregables planeados han sido entregados y aprobados,
se deben finalizar y aprobar los documentos de soporte de prueba, analizar las lecciones
aprendidas para aplicar en futuros proyectos, etc.
Concepto de pruebas de sistema.

Es la última fase del desarrollo de Sistemas. Es el proceso instalar equipos o Software nuevo,
como resultado de un análisis y diseño previo como resultado de la sustitución o mejoramiento de
la forma de llevar a cabo un proceso automatizado.
Al Implantar un Sistema de Información lo primero que debemos hacer es asegurarnos que el

Sistema sea operacional o sea que funcione de acuerdo a los requerimientos del análisis y
permitir que los usuarios puedan operarlo.
Existen varios enfoques de Implementación:
• Es darle responsabilidad a los grupos.

• Uso de diferentes estrategias para el entrenamiento de los usuarios.
• El Analista de Sistemas necesita ponderar la situación y proponer un plan de conversión que sea

adecuado para la organización
• El Analista necesita formular medidas de desempeño con las cuales evaluar a los Usuarios.
• Debe Convertir físicamente el sistema de información antiguo, al nuevo modificado
En la preparación de la Implantación, aunque el Sistema esté bien diseñado y desarrollado

correctamente su éxito dependerá de su implantación y ejecución por lo que es importante
capacitar al usuario con respecto a su uso y mantenimiento.
Niveles de Prueba del Software

En un proceso de pruebas formal, suelen confundirse con mucha facilidad, los niveles de pruebas
con los tipos de prueba, y a pesar de que se encuentren íntimamente relacionadas, tienen
connotaciones diferentes en el proceso. Para entender un poco más, vamos a partir del hecho de
que las pruebas pueden ejecutarse en cualquier punto del proceso de desarrollo de software, y
es aquí donde los niveles de prueba nos permiten entender con claridad los diferentes puntos o
etapas en donde pueden ejecutarse ciertos tipos de prueba. Por lo anterior, es común que
algunas personas se refieran a los niveles de pruebas o intenten clasificarlos como: pruebas de
desarrollador, pruebas funcionales y pruebas de usuario final. Sin embargo, la terminología
apropiada para referirse a los diferentes niveles corresponde a la siguientes cuatro (4)
clasificaciones que son: pruebas unitarias, pruebas de integración, pruebas de sistema y pruebas
de aceptación. En cada uno de estos niveles de prueba, se podrán ejecutar diferentes tipos de
prueba tales como: pruebas funcionales, no funcionales, de arquitectura y asociadas el cambio de
los productos.
A continuación una breve descripción de cada nivel de prueba:
1. Pruebas Unitarias o de Componente: este tipo de pruebas son ejecutadas normalmente por
el equipo de desarrollo, básicamente consisten en la ejecución de actividades que le permitan
verificar al desarrollador que los componentes unitarios están codificados bajo condiciones de
robustez, esto es, soportando el ingreso de datos erróneos o inesperados y demostrando así
la capacidad de tratar errores de manera controlada. Adicionalmente, Las pruebas sobre
componentes unitarios, suelen denominarse pruebas de módulos o pruebas de clases,
siendo la convención definida por el lenguaje de programación la que influye en el término a
utilizar. Por último, es importante que toda la funcionalidad de cada componente unitario
sea cubierta, por al menos, dos casos de prueba, los cuales deben centrarse en probar al
menos una funcionalidad positiva y una negativa.

2. Pruebas de Integración: este tipo de pruebas son ejecutas por el equipo de desarrollo y
consisten en la comprobación de que elementos del software que interactúan entre sí,
funcionan de manera correcta.

3. Pruebas de Sistema: este tipo de pruebas deben ser ejecutadas idealmente por un equipo de
pruebas ajeno al equipo de desarrollo, una buena práctica en este punto corresponde a la
tercerización de esta responsabilidad. La obligación de este equipo, consiste en la ejecución
de actividades de prueba en donde se 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 de pruebas, deben cubrir los aspectos funcionales
y no funcionales del sistema. Para el diseño de los casos de prueba en este nivel, el equipo
debe utilizar como bases de prueba entregables tales como: requerimientos iniciales, casos de
uso, historias de usuario, diseños, manuales técnicos y de usuario final, etc. Por último, es
importante que los tipos de pruebas ejecutados en este nivel se desplieguen en un ambiente
de pruebas / ambiente de pre-producción cuya infraestructura y arquitectura sea similar al
ambiente de producción, evitando en todos los casos utilizar el ambiente real del cliente,
debido principalmente, a que pueda ocasionar fallos en los servidores, lo que ocasionaría
indisponibilidad en otros servicios alojados en este ambiente.

4. Pruebas de Aceptación: Independientemente de que se haya tercerizado el proceso de
pruebas y así la firma responsable de estas actividades haya emitido un certificado de calidad
sobre el sistema objeto de prueba, es indispensable, que el cliente designe a personal que
haga parte de los procesos de negocio para la ejecución de pruebas de aceptación, es incluso
recomendable, que los usuarios finales que participen en este proceso, sean independientes
al personal que apoyó el proceso de desarrollo. Cuando las pruebas de aceptación son
ejecutadas en instalaciones o ambientes proporcionados por la firma desarrolladora se les
denominan pruebas Alpha, cuando son ejecutadas desde la infraestructura del cliente se les
denomina pruebas Beta. En los casos en que las pruebas de aceptación del producto se hayan
ejecutado en el ambiente del proveedor, el aplicativo no podrá salir a producción, sin que se
hayan ejecutados las respectivas pruebas Beta en el ambiente del cliente, de lo anterior es
importante concluir, que las pruebas Alpha son opcionales, pero las pruebas Beta son
obligatorias.
Tipos de Pruebas
» PRUEBAS UNITARIAS
Prueba Unitaria
Objetivo de la Prueba: Se focaliza en ejecutar cada módulo (o unidad mínima a ser probada, ej.
= una clase) lo que 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.

Descripción de la Prueba: Particionar los módulos en pruebas en unidades lógicas fáciles de
probar.
 Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).
 Para esto los casos de prueba deben diseñarse de forma tal que se recorran todos los
caminos de ejecución posibles dentro del código bajo prueba; por lo tanto el diseñador debe
construirlos con acceso al código fuente de la unidad a probar.
 Los aspectos a considerar son los siguientes: Rutinas de excepción, Rutinas de error, Manejo
de parámetros, Validaciones, Valores válidos, Valores límites, Rangos, Mensajes posibles.
Técnica: Comparar el resultado esperado con el resultado obtenido.

 Si existen errores, reportarlos.
Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas.

 Todos los defectos que se identificaron han sido tenidos en cuenta.
Consideraciones Especiales: Para la elaboración de pruebas unitarias en java se puede utilizar el

JUNIT y CACTUS.
» PRUEBAS DE INTEGRACIÓN
Prueba de Integración
Objetivo de la Prueba: Identificar errores introducidos por la combinación de programas

probados unitariamente. Determina cómo la base de datos de prueba será cargada. Verificar
que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan
correctamente. Verificar que las especificaciones de diseño sean alcanzadas. Determina el
enfoque para avanzar desde un nivel de integración de las componentes al siguiente.
Descripción de la Prueba: Describe cómo verificar que las interfaces entre las componentes de
software funcionan correctamente.
 Determina cómo la base de datos de prueba será cargada.
 Determina el enfoque para avanzar desde un nivel de integración de las componentes al
siguiente.
 Decide qué acciones tomar cuando se descubren problemas.
Por cada Caso de Prueba ejecutado: Comparar el resultado esperado con el resultado obtenido.
Técnica: Utilizar la técnica top-down. Se empieza con los módulos de nivel superior, y se verifica
que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con los
parámetros correctos.
Utilizar la técnica down-top. Se empieza con los módulos de nivel inferior, y se verifica que los

módulos de nivel inferior llaman a los de nivel superior de manera correcta, con los parámetros
correctos.
Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas. Todos los defectos
que se identificaron han sido tenidos en cuenta.
Consideraciones Especiales: Ninguna
Prueba de Regresión
Objetivo de la Prueba: Determinar si los cambios recientes en una parte de la aplicación tienen
efecto adverso en otras partes.
Descripción de la Prueba: En esta prueba se vuelve a probar el sistema a la luz de los cambios
realizados durante el debugging, mantenimiento o desarrollo de la nueva versión del sistema
buscando efectos adversos en otras partes.
Técnica: La prueba de regresión es una nueva corrida de casos de prueba previos.

 Se requiere de políticas para ser creada la prueba de regresión y decidir qué casos de prueba
incluir, para probar eficientemente.
 La prueba de regresión es un buen candidato para automatización. Desde que estas pruebas
se repiten una y otra vez, las herramientas para minimizar el esfuerzo del trabajo son útiles.
 La prueba de viejas funcionalidades es más importante que la de nuevas funcionalidades.
 Aquellos casos de uso (y los casos de prueba asociados) que descubren defectos
tempranamente deben ser incluidos en la prueba de regresión.

 Todos los defectos que se identificaron han sido tenidos en cuenta.
Pruebas de Humo (Smoke Testing o Ad Hoc)
Objetivo de la Prueba: Los objetivos son los siguientes:
 Detectar los errores en realeases tempranos y de manera fácil

 Probar el sistema constantemente
 Garantizar poco esfuerzo en la integración final del sistema
 Asegurar los resultados de las pruebas unitarias
 Se reducen los riesgos y a baja calidad.

Descripción de la Prueba: Toma éste nombre debido a que su objetivo es 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 tarde en el ciclo de
desarrollo está 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.
Técnica:
1. Realizar una integración de todo el sistema cada cierto periodo (se recomienda un día,
máximo una semana)
2. Realizar los casos de prueba asignados a los casos de uso finalizados ese día más los
realizados en días anteriores
3. Buscar eficientemente errores

· Todos los defectos que se identificaron han sido tenidos en cuenta.
Consideraciones Especiales: Cuando se encuentre un error en el release correspondiente al

periodo elegido para hacer las integraciones del sistema, se detiene el desarrollo hasta que el
error es corregido. Este tipo de pruebas es útil en la programación extrema (extremme
programming) y de sistemas complejos.
Es útil el uso de programas de prueba automáticas que se encarguen de probar os casos de
prueba ya ejecutados en realeases anteriores.
PRUEBAS DEL SISTEMA
Pruebas del Sistema
Objetivo de la Prueba: Asegurar la apropiada navegación dentro del sistema, ingreso de datos,
procesamiento y recuperación.
Descripción de la Prueba: Las pruebas del sistema deben enfocarse en requisitos que puedan
ser tomados directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas
pruebas es verificar el ingreso, procesamiento y recuperación apropiado de datos, y la
implementación apropiada de las reglas de negocios. Este tipo de pruebas se basan en técnicas
de caja negra, esto es, verificar el sistema (y sus procesos internos), la interacción con las
aplicaciones que lo usan vía GUI y analizar las salidas o resultados.
En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen, desempeño, etc.)
asegurarán que la aplicación alcanzará sus objetivos de negocio.

La prueba de Sistema incluye:
- Prueba funcionalidad
- Prueba de Usabilidad
- Prueba de Performance
- Prueba de Documentación y Procedimientos
- Prueba de Seguridad y Controles
- Prueba de Volumen
- Prueba de Esfuerzo (Stress)
- Prueba de recuperación
- Prueba de múltiples sitios
Para sistemas web se recomienda especialmente realizar mínimo el siguiente grupo de pruebas
de sistema:
Humo.
Usabilidad
Performance
Funcionalidad
Para capitalizar el trabajo hasta ahora completado, los casos de prueba de las pruebas previas
realizadas pueden frecuentemente ser reorganizados y rehusados durante la prueba de sistema.
No obstante, deben ser desarrollados casos de prueba adicionales para aquellos aspectos del
sistema, tales como documentación, procedimientos y desempeño que no han sido probados
durante la prueba unitaria y de integración.
La prueba de sistema es compleja porque intenta validar un número de características al mismo

tiempo, a diferencia de otras pruebas que sólo se centran en uno o dos aspectos del sistema al
mismo tiempo.
Técnica: Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos,
para verificar que:
 Los resultados esperados ocurren cuando se utiliza un dato válido.

 Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se
utiliza un dato inválido.
 Cada regla de negocios es aplicada adecuadamente.

Consideraciones Especiales: Identifique o describa aquellos aspectos (internos o externos) que

impactan la implementación y ejecución de las pruebas del Sistema

Pruebas de Desempeño
Objetivo de la Prueba: Validar el tiempo de respuesta para las transacciones o funciones de

negocios bajo las siguientes dos condiciones:
 Volumen normal anticipado

 Volumen máximo anticipado.
Descripción de la Prueba: Las pruebas de desempeño miden tiempos de respuesta, índices de

procesamiento de transacciones y otros requisitos sensibles al tiempo. El objetivo de las pruebas
de desempeño es verificar y validar los requisitos de desempeño que se han especificado (en
este caso, el desempeño ofrecido por el proponente).
Las pruebas de desempeño usualmente se ejecutan varias veces, utilizando en cada una, carga
diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar a la esperada
en el sistema. Una segunda prueba debe hacerse utilizando una carga máxima.
Adicionalmente, las pruebas de desempeño pueden ser utilizadas para perfilar y refinar el
desempeño del sistema como una función de condiciones tales como carga o configuraciones de
hardware
Las principales actividades son:

- Comparar el desempeño del sistema actual con los requisitos,
- Poner a punto el sistema para mejorar las métricas de desempeño y proyectar la
capacidad futura de carga del sistema.
Los objetivos de nivel de servicio definidos deben guiar la prueba de performance. Algunas
características que afectan el desempeño son:
- Errores lógicos
- Procesamiento ineficiente
- Diseño pobre: muchas interfaces, instrucciones y entradas/salidas.
- Cuellos de botella en discos, CPU ó canales de entrada/salida
- Salidas del sistema
- Tiempos de respuesta
- Capacidad de almacenamiento
- Tasa de entrada/salida de datos
- Número de transacciones que pueden ser manejadas simultáneamente.
Las pruebas de desempeño utilizan las técnicas de caja blanca y caja negra.
Técnica: Utilice los procedimientos de prueba desarrollados para las pruebas del modelo del negocio
(Pruebas del Sistema).

 Modifique archivos de datos (para incrementar el número de transacciones) o los scripts para
incrementar el número de veces que ocurre cada transacción.
 Los scripts deben ser ejecutados en una máquina y deben ser repetidos con múltiples clientes
(virtuales o actuales). (Ver consideraciones especiales).
Criterio de Completitud: Un Usuario / Una Transacción. Se completaron las pruebas sin ninguna falla y
dentro del tiempo esperado o requerido por transacción.
 Múltiples transacciones, múltiples usuarios. Se completaron las pruebas de los scripts sin ninguna
falla y dentro del tiempo esperado.
Consideraciones Especiales: Unas pruebas de desempeño integrales incluyen tener una carga en
background en el servidor. Hay varios métodos que pueden ser utilizados para hacer ésto:
 Transacciones dirigidas directamente al servidor, usualmente en forma de sentencias SQL. ·
 Creación de usuarios virtuales para simular muchos clientes (usualmente varios cientos). Se
utilizan herramientas de Emulación de Terminales Remotas para obtener esta carga. Esta
técnica también puede ser utilizada para cargar de tráfico la red.
 Use múltiples clientes físicos, cada uno corriendo los scripts de prueba.
 Las pruebas de desempeño deben ser ejecutadas en una máquina dedicada o en un tiempo
dedicado. Esto permite control total y medidas precisas.
 La Base de datos utilizada para pruebas de desempeño debe ser de un tamaño real o
proporcionalmente más grande que la diseñada.
Pruebas de Carga
Objetivo de la Prueba: Verificar el tiempo de respuesta del sistema para transacciones o casos
de uso de negocios, bajo diferentes condiciones de carga.
Descripción de la Prueba: Las pruebas de carga miden la capacidad del sistema para continuar
funcionando apropiadamente bajo diferentes condiciones de carga.
La meta de las pruebas de carga es determinar y asegurar que el sistema funciona
apropiadamente aún más allá de la carga de trabajo máxima esperada. Adicionalmente, las
pruebas de carga evalúan las características de desempeño (tiempos de respuesta, tasas de
transacciones y otros aspectos sensibles al tiempo).
Técnica: Use los scripts desarrolladas para Pruebas del Negocio.

Modifique archivos de datos (para incrementar el número de transacciones o veces que cada
transacción ocurre).

Criterio de Completitud: Múltiples transacciones, múltiples usuarios. Se completaron las
pruebas de los scripts sin ninguna falla y dentro del tiempo esperado.
Consideraciones Especiales: Las pruebas de carga deben ser ejecutadas en una máquina
dedicada o en un tiempo dedicado. Esto permite control total y medidas precisas. ·
La Base de datos utilizada para pruebas de desempeño debe ser de un tamaño real o
proporcionalmente más grande que la diseñada.
Pruebas de Stress
Objetivo de la Prueba: Verificar que el sistema funciona apropiadamente y sin errores, bajo
estas condiciones de stress:
 Memoria baja o no disponible en el servidor.
 Máximo número de clientes conectados o simulados (actuales o físicamente posibles)
 Múltiples usuarios desempeñando la misma transacción con los mismos datos.
 El peor caso de volumen de transacciones (ver pruebas de desempeño).
NOTAS: La meta de las pruebas de stress también es identificar y documentar las condiciones
bajo las cuales el sistema FALLA.
Descripción de la Prueba: Las pruebas de stress se proponen encontrar errores debidos a

recursos bajos o completitud de recursos. Poca memoria o espacio en disco puede revelar
defectos en el sistema que no son aparentes bajo condiciones normales. Otros defectos pueden
resultar de incluir recursos compartidos, como bloqueos de base de datos o ancho de banda de
la red. Las pruebas de stress identifican la carga máxima que el sistema puede manejar.
El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones que
sobrecargan sus recursos. No debe confundirse con las pruebas de volumen: un esfuerzo grande
es un pico de volumen de datos que se presenta en un corto período de tiempo.
Puesto que la prueba de esfuerzo involucra un elemento de tiempo, no resulta aplicable a
muchos programas, por ejemplo a un compilador o a una rutina de pagos.
Es aplicable, sin embargo, a programas que trabajan bajo cargas variables, interactivas, de
tiempo real y de control de proceso.
Aunque muchas pruebas de esfuerzo representan condiciones que el programa encontrará
realmente durante su utilización, muchas otras serán en verdad situaciones que nunca ocurrirán
en la realidad. Esto no implica, sin embargo, que estas pruebas no sean útiles.
Si se detectan errores durante estas condiciones “imposibles”, la prueba es valiosa porque es de
esperar que los mismos errores puedan presentarse en situaciones reales, algo menos
exigentes.
Técnica: Use los scripts utilizados en las pruebas de desempeño.
Para probar recursos limitados, las pruebas se deben correr en un servidor con configuración

reducida (o limitada).
Para las pruebas de stress restantes, deben utilizarse múltiples clientes, ya sea corriendo los
mismos scripts o scripts complementarios para producir el peor caso de volumen de
transacciones.
Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas y excedidas sin que el
sistema falle. (O si las condiciones en que el sistema falle ocurren por fuera de las condiciones
especificadas).
Consideraciones Especiales: Producir stress en la red puede requerir herramientas de red para
sobrecargarla de tráfico.
El espacio en disco utilizado para el sistema debe ser reducido temporalmente para limitar el
espacio disponible para el crecimiento de la Base de datos.
Sincronización de varios clientes accediendo simultáneamente los mismos registros.
Pruebas de Volumen
Objetivo de la Prueba: Verificar que la aplicación funciona adecuadamente bajo los siguientes
escenarios de volumen:
 Máximo (actual o físicamente posible) número de clientes conectados (o simulados),
todos ejecutando la misma función (peor caso de desempeño) por un período
extendido.
 Máximo tamaño de base de datos (actual o escalado) y múltiples consultas ejecutadas
simultáneamente
Descripción de la Prueba: Las pruebas de volumen hacen referencia a grandes cantidades de
datos para determinar los límites en que se causa que el Sistema falle. También identifican la
carga máxima o volumen que el sistema puede manejar en un período dado. Por ejemplo, si el
sistema está procesando un conjunto de registros de Base de datos para generar un reporte,
una prueba de volumen podría usar una Base de datos de prueba grande y verificar que el
sistema se comporta normalmente y produce el reporte correctamente.
El objetivo de esta prueba es someter al sistema a grandes volúmenes de datos para determinar
si el mismo puede manejar el volumen de datos especificado en sus requisitos.
Algunos ejemplos de escenarios de prueba de volúmenes:
 Un compilador puede ser alimentado por un programa para compilar que sea absurdamente
grande.
 Un editor de nexos puede recibir un programa que contenga miles de módulos.
 Un simulador de circuito electrónico puede recibir un circuito diseñado con miles de
componentes.
Puesto que obviamente, la prueba de volumen es una prueba costosa, tanto en tiempo de
máquina como en personal, se debe tratar de no exceder los límites. Sin embargo, todo

programa debería ser expuesto, al menos, a algunas pruebas de volumen.
Técnica: Utilice los scripts diseñados para las pruebas de desempeño.

 Deben usarse múltiples clientes, ya sea corriendo las mismas pruebas o pruebas
complementarias para producir el peor caso de volumen (ver pruebas de stress) por un
período extendido.
 Se utiliza un tamaño máximo de Base de datos. (actual, escalado o con datos
representativos) y múltiples clientes para correr consultas simultáneamente para períodos
extendidos.
Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas y los límites
especificados en el sistema se han conseguido o excedido sin que el sistema falle.
Consideraciones Especiales: ¿Qué período de tiempo debería considerarse como aceptable para
condiciones de volumen alto?
Pruebas de Recuperación y Tolerancia a fallas
Objetivo de la Prueba: Verificar que los procesos de recuperación (manual o automática)

restauran apropiadamente la Base de datos, aplicaciones y sistemas, y los llevan a un estado
conocido o deseado. Los siguientes tipos de condiciones deben incluirse en la prueba:
 Interrupción de electricidad en el cliente.
 Interrupción de electricidad en el servidor
 Interrupción en la comunicación hacia el servidor (caídas de red)
 Interrupción en la comunicación con los controladores de disco.
 Ciclos incompletos (procesos de consultas interrumpidos, procesos de sincronización de
datos interrumpidos)
 Llaves o apuntadores de base de datos inválidos
 Elementos corruptos o inválidos en la base de datos.
Descripción de la Prueba: Estas pruebas aseguran que una aplicación o sistema se recupere de
una variedad de anomalías de hardware, software o red con pérdidas de datos o fallas de
integridad.
Las pruebas de tolerancia a fallas aseguran que, para aquellos sistemas que deben mantenerse
corriendo, cuando una condición de falla ocurre, los sistemas alternos o de respaldo pueden
tomar control del sistema sin pérdida de datos o transacciones.
Las pruebas de recuperación son contrarias a las pruebas en que la aplicación o sistema es
expuesto a condiciones extremas (o condiciones simuladas), tales como fallas en dispositivos en
entrada/salida o llaves o apuntadores inválidos de base de datos. Los procesos de recuperación
se invocan y la aplicación es monitoreada y/o inspeccionada para verificar que estos
mecanismos se han ejecutado en forma apropiada.
El objetivo de esta prueba es determinar la habilidad del sistema para recuperarse de una falla

de hardware o software. Esta prueba evalúa las características de contingencia construidas en el
sistema para procesar interrupciones y para volver a puntos específicos en el ciclo de
procesamiento del sistema. La recuperación debe ser considerada en el proceso de diseño.
Errores de programación o de datos pueden ser incorporados ex profeso en un sistema para
determinar si se puede recuperar de ellos. Las fallas de equipo (por ejemplo errores de paridad
en memoria, errores en dispositivos de entrada/salida) pueden ser simuladas.
Técnica: Se deben utilizar las pruebas creadas para la Funcionalidad del sistema y Procesos de
Negocios para crear una serie de transacciones. Una vez se alcanza el punto inicial de las
pruebas de recuperación, se deben realizar o simular las siguientes acciones:
 Interrupción de electricidad en el cliente.
 Interrupción de electricidad en el servidor: simular o iniciar procedimientos de pérdida
de energía para el servidor.
 Interrupción de la comunicación en la red. (desconectar físicamente los cables o apagar
los hubs o routers)
 Interrupción de la comunicación con los controladores de disco: simular o eliminar
físicamente la comunicación con uno o más controladores o dispositivos.
Una vez se realizan estas acciones, se deben ejecutar series de transacciones, y luego, una vez
alcanzado el segundo punto de pruebas, se deben invocar los procedimientos de recuperación.
Las pruebas para ciclos incompletos utilizan la misma técnica que se describe arriba, excepto
que los procesos de Base de datos deban ser abortados o terminados prematuramente.
Las pruebas para estas condiciones requieren que se llegue a un estado conocido previamente
en la Base de datos. Algunos campos, apuntadores y llaves deben ser modificados
manualmente, valiéndose de las herramientas que ofrezca la SSPD. Las transacciones
adicionales deben ser ejecutadas utilizando las pruebas para Funcionalidad de la aplicación y
para Procesos de Negocios.
Criterio de Completitud: En todos los casos mencionados, la Base de datos, aplicación y otros
sistemas deben retornar a un estado conocido y deseado, una vez se completan los
procedimientos de recuperación. Este estado podría incluir que el daño de datos se limite
solamente a los campos, llaves o apuntadores que se sabe que fueron alterados, y reportes
indicando los procesos o transacciones que no fueron completadas debido a las interrupciones
producidas.
Consideraciones Especiales: Las pruebas de recuperación pueden llegar a ser molestas. Los
procedimientos para desconectar cables o simular pérdida de electricidad pueden ser poco
factibles o deseables. Podrían llegar a requerirse métodos alternativos, como herramientas de
diagnóstico.
 Se requiere la participación de personal de la red, administradores de la base de datos y
del sistema.
 Estas pruebas deben ser ejecutadas en horas no laborables o en máquinas aisladas.

Prueba de Múltiples Sitios
Objetivo de la Prueba: Detectar fallas en configuraciones y comunicaciones de datos entre

múltiples sitios.
Descripción de la Prueba: El propósito de esta prueba es evaluar el correcto funcionamiento del

sistema o subsistema en múltiples instalaciones.
Técnica: Realizar casos de prueba que verifiquen mínimo lo siguiente:

1) Consistencia de las opciones de configuración para el sistema a través de los sitios
2) Empaquetamiento del sistema para múltiples instalaciones
3) Sincronización de datos entre sitios
4) Comunicación de datos entre sistemas en diferentes sitios
5) Rompimiento de funciones de sistema a través de los sitios.
6) Consistencia de controles y seguridad a través de los sitios

 Todos los defectos que se identificaron han sido tenidos en cuenta.
Prueba de Compatibilidad y Conversión
Objetivo de la Prueba: Buscar problemas de compatibilidad y conversión en los sistemas.
Descripción de la Prueba: El propósito es demostrar que los objetivos de compatibilidad no han

sido logrados y que los procedimientos de conversión no funcionan.
La mayoría de los programas que se desarrollan no son completamente nuevos; con frecuencia
son reemplazos de partes deficientes, ya sea de sistemas de procesamiento de datos, o sistemas
manuales.
Como tales, los programas tienen a menudo objetivos específicos con respecto a su
compatibilidad y a sus procedimientos de conversión con el sistema existente.
Técnica: Desarrollar casos de prueba que permitan detectar deficiencias con:
 Compatibilidad entre programas

 Conversión de datos


Pruebas de Integridad de Datos y Base de Datos
Objetivo de la Prueba: Asegurar que los métodos de acceso y procesos funcionan

adecuadamente y sin ocasionar corrupción de datos.
Descripción de la Prueba: La Base de datos y los procesos de Base de datos deben ser probados
como sistemas separados del proyecto. Estos sistemas deberían ser probados sin usar interfaces
de usuario (como las interfaces de datos). Se necesita realizar investigación adicional en el
DBMS para identificar las herramientas y técnicas que podrían existir para soportar las pruebas
identificadas más adelante.
Técnica: Invoque cada método de acceso y proceso de la Base de datos, utilizando en cada uno
datos válidos e inválidos.
Analice la Base de datos, para asegurar que los datos han sido grabados apropiadamente, que
todos los eventos de Base de datos se ejecutaron en forma correcta y revise los datos
retornados en diferentes consultas.
Criterio de Completitud: Todos los métodos de acceso y procesos de la Base de datos funcionan
como fueron diseñados y sin corrupción de datos
Consideraciones Especiales: Las pruebas pueden requerir un ambiente de DBMS o

controladores para ingresar o modificar datos directamente en la Base de datos.
: Se debe utilizar un conjunto pequeño de datos para incrementar la visibilidad de cualquier

evento anormal o inesperado.
Los procesos pueden ser invocados manualmente.
Pruebas de Seguridad y Control de Acceso
Objetivo de la Prueba: Nivel de seguridad de la aplicación: Verifica que un actor solo pueda
acceder a las funciones y datos que su usuario tiene permitido.
Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso al sistema y a la
aplicación están habilitados para accederla.
Descripción de la Prueba: Las pruebas de seguridad y control de acceso se centran en dos áreas

claves de seguridad:
 Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios y
 Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.
Las pruebas de seguridad de la aplicación garantizan que, con base en la seguridad deseada, los
usuarios están restringidos a funciones específicas o su acceso está limitado únicamente a los
datos que están autorizado a acceder. Por ejemplo, cada usuario puede estar autorizado a crear
nuevas cuentas, pero sólo los administradores pueden borrarlas. Si existe seguridad a nivel de
datos, la prueba garantiza que un usuario “típico” 1 puede ver toda la información de clientes,
incluyendo datos financieros; sin embargo, el usuario 2 solamente puede ver los datos
institucionales del mismo cliente.
Las pruebas de seguridad del sistema garantizan que solamente aquellos usuarios autorizados a
acceder al sistema son capaces de ejecutar las funciones del sistema a través de los mecanismos
apropiados.
Debido a la creciente preocupación de la sociedad por la privacidad de la información, muchos

programas tienen objetivos específicos de seguridad.
El objetivo de esta prueba es evaluar el funcionamiento correcto de los controles de seguridad

del sistema para asegurar la integridad y confidencialidad de los datos. El foco principal es
probar la vulnerabilidad del sistema frente a accesos o manipulaciones no autorizadas. Una
manera de encontrar esos casos de prueba es estudiar problemas conocidos de seguridad en
sistemas similares y tratar de mostrar la existencia de problemas parecidos en el sistema que se
examina.
Algunas consideraciones de prueba son:
 Controles de acceso físico

 Acceso a estructuras de datos específicas a través de los programas de aplicación.
 Seguridad en sitios remotos
 Existencia de datos confidenciales en reportes y pantallas
 Controles manuales, incluyendo aquellos para autorización y aprobación, formularios,
documentación numerada, transmisión de datos, balances y conversión de datos.
 Controles automáticos, incluyendo aquellos para edición de datos, chequeo de
máquinas, errores del operador, acceso a datos elementales y archivos, acceso a
funciones, auditoría, entre otros.
Técnica: Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las funciones y datos

a los que se debe autorizar.
 Crear pruebas para cada tipo de usuario y verificar cada permiso, creando transacciones
específicas para cada tipo de usuario.
 Modificar tipos de usuarios y volver a ejecutar las pruebas. En cada caso, verificar si los datos
o funciones adicionales quedan correctamente permitidos o denegados.
 Acceso al sistema (ver consideraciones especiales)
Criterio de Completitud: Para cada tipo de usuario conocido, las funciones y datos apropiados y
todas las transacciones funcionan como se esperaba.
Consideraciones Especiales: El acceso al sistema debe ser revisado y discutido con los
administradores de la red y/o del sistema. Esta prueba puede no ser requerida como tal, sino
como una función de los administradores de red o del sistema.
Pruebas Estáticas, Dinámicas, Manuales, Automáticas,

Funcionales y No Funcionales.
Pruebas estáticas:
Pruebas estáticas son pruebas de un componente o sistema a nivel de especificación o
implementación sin ejecutar el software, por ejemplo revisiones o análisis estático de código.
Se basan en el examen manual y en el análisis automatizado del código o de cualquier otra

documentación del proyecto sin ejecutar el código. Se utilizan para probar los productos de
trabajo del software, incluyendo el código. Pueden realizar antes de ejecutar las pruebas
dinámicas. Los defectos detectados durante las revisiones al principio del ciclo de vida suelen ser
menos costosos de corregir que los detectados durante las pruebas. Se complementan con las
técnicas dinámicas, ya que cada una permite encontrar distintos tipos de defectos de una manera
eficiente y efectiva.

Objetivos básicos
 Encontrar defectos del producto, en el punto más temprano posible del ciclo de
desarrollo.
 Asegurar que las partes apropiadas llegan a un acuerdo técnico, sobre el producto.
 Verificar que el producto cumple con los criterios predefinidos.
 Completar formalmente una tarea técnica.
 Proveer datos del producto y del proceso de revisión.
Beneficios secundarios
 Asegurar que los participantes están técnicamente al tanto del producto.
 Ayudar a formar un equipo técnico eficiente.
 Ayudar a utilizar los mejores talentos de la organización.
 Proveer a los participantes del sentido de pertenencia y compromiso.
 Ayudar a los participantes a desarrollar sus habilidades como revisores.
Los tipos de pruebas dependen de que se busca y como se analiza el producto, entre ellos están:
 Revisiones informales.
 Inspecciones o Revisiones Técnicas Formales - RTF ´
 Walkthroughs
 Auditorias
Pruebas Dinámicas:
Las pruebas dinámicas son aquellas pruebas que no se pueden ejecutar hasta el momento
en que esté disponible una versión ejecutable del software.
Sin embargo, la preparación de las pruebas dinámicas puede empezar mucho antes, con el
fin de poder comenzar con su ejecución nada más recibir la primera versión ejecutable del
software.
Tipos de pruebas dinámicas
Pruebas de unidad; Verifican programas o módulos individuales. Son ejecutadas, típicamente, en

ambientes aislados o especiales. Generalmente son ejecutadas por la misma persona que
programó el módulo o programa. Son los tests que suele detectar la mayor cantidad de bugs.

Pruebas de integración: Verifican las interfaces entre partes de un sistema (módulos,
componentes o subsistemas). La integración pueden ser total (Big Bang) o gradual: Top-Down: Se
necesitan “stubs” para simular módulos inferiores. Bottom-Up: Se necesitan “drivers” para
simular módulos superiores.
Pruebas de sistema: Verifican el sistema global contra sus objetivos iniciales. Además, se debería
testear, entre otros: Volumen (Load). Instalabilidad. Operabilidad. Seguridad. Performance
(Stress).
Pruebas de aceptación: Validan el sistema contra los requerimientos del usuario. Aunque no
siempre, son ejecutadas, típicamente, en el ambiente real del usuario. Los casos de prueba son
generalmente especificados y ejecutados por los mismos usuarios.
Pruebas de regresión: Su nombre se debe a que se contrapone con las demás pruebas dinámicas,
que son progresivas (testeo de nuevas funciones y características). Son la ejecución de un
subconjunto de casos de prueba, previamente ejecutados, para asegurar que los cambios a un
programa o sistema no lo degradan. Uno de los desafíos es la selección de los casos de prueba
que se deben volver a ejecutar. Es el test más común en la etapa de mantenimiento de un
sistema. Las pruebas de regresión son siempre una parte integrante de las pruebas dinámicas
progresivas.
¿Pruebas Manuales o Automáticas?

Esta es una de esas típicas preguntas que se plantea casi todo aquel a quien le ha tocado
dirigir el desarrollo o el control de calidad de un producto software. Cuando uno se lo plantea por
primera vez, así, a priori, la idea de sustituir horas de pruebas manuales por pruebas automáticas
suena perfecta. Pulsar “un botón” y lanzar automáticamente las pruebas. Pero cuando se le da
unas cuantas vueltas al tema, se empiezan a ver algunos problemillas y aparecen las dudas.
Por experiencia conozco varios proyectos de automatización de pruebas que terminaron en

auténticos desastres. Recuerdo especialmente un caso en que el equipo de automatización de
pruebas trabajaba de forma totalmente independiente al equipo de desarrollo, y ambos equipos
trabajaban además sin tener por detrás un buen sistema y estrategia de gestión de la
configuración, lo que hacía que los scripts de pruebas estuvieran constantemente
desactualizados, con lo que el supuesto ahorro de la automatización se iba en el mantenimiento
de los scripts de pruebas. La automatización de pruebas supone al fin y al cabo generar más
código, el de las pruebas, que hay que mantener.

Sobre el qué, cuándo y dónde automatizar hay mucho escrito, pero la idea de los
cuadrantes que aparecen en el libro Agile Testing, es la mejor ya que clasifica los diferentes tipos
de pruebas y las estrategias recomendadas para las mismas:
 Cuadrante 1. Pruebas unitarias y de componentes, que normalmente se recomienda

automatizar.
 Cuadrante 2. Pruebas que pueden realizarse de manera automática o manual, y que suelen
ser las pruebas funcionales, simulaciones, prototipos, etc.
 Cuadrante 3. Pruebas manuales, que suelen ser las de usabilidad, aceptación, de exploración
y alpha/beta testing.
 Cuadrante 4. Herramientas que se hacen con herramientas, como son las de rendimiento y
carga.
Todo esto da para mucho hablar. En temas como que además muchas veces los esfuerzos de
automatización se ven frustrados por productos cuya arquitectura hace imposible automatizar las
pruebas.
Pruebas Funcionales y no funcionales:

Se entiende como las Funcionalidades del Sistema cómo “lo que el sistema hace”. Las
Funcionalidades pueden estar descritas en las especificaciones de requerimientos,
especificaciones funcionales, casos de uso e inclusive no estar documentadas.
Los casos de prueba se definen a partir de estas funciones o características, así como su
interoperabilidad entre sistemas.
Consideran el comportamiento externo del sistema por lo que se consideran pruebas de caja
negra. Además de las pruebas sobre los módulos y funciones, pueden realizarse pruebas en áreas
especializadas como Pruebas de Seguridad y Pruebas de Interoperabilidad.
Su objetivo es probar los requerimientos no funcionales, incluyendo (sin limitarse a)

pruebas de: Desempeño, Carga, Estrés, Usabilidad, Mantenibilidad, Confiabilidad y Portabilidad.
Los requerimientos no funcionales representan “cómo funciona el sistema” (en contraposición
con las funcionalidades que definen “lo que el sistema hace”).
Las características no funcionales del software, se pueden medir de diversas maneras, por
ejemplo por medio de tiempos de respuesta en el caso de pruebas de desempeño.
Pueden hacer referencias a modelos de calidad, como por ejemplo ISO 9126. Consideran el
“comportamiento externo” del sistema, en la mayoría de los casos son pruebas de caja negra.
Herramientas para realización de pruebas de sistema

Existentes en el mercado.
En este artículo presentamos el listado de herramientas Open Source más populares para la
calidad de software (Testing), las cuales se dividen en las siguientes categorías.
» Herramientas de gestión de pruebas
» Herramientas para pruebas funcionales
» Herramientas para pruebas no funcionales
» Herramienta para la gestión de defectos
Herramienta de Gestión de Pruebas

» TestLink:

Es una herramienta web de código abierto (Open Source) la cual permite crear y gestionar casos
de prueba, organizar planes de ejecución, definir usuarios que pueden interactuar con el proyecto
, registrar resultados y permite visualizar distintos reportes, si bien la interfaz es algo amarga
pero funcionalmente cumple en función de la necesidad.
Página web: http://www.testlink.org/
Herramienta para pruebas funcionales

» Selenium:
Es un framework de código abierto (Open Source) el cual permite realizar pruebas
automatizadas sobre plataformas web, la escritura de script se apoya en objetos, este framework
cuenta con 2 proyectos un IDE que se instala en Mozilla que permite grabar y reproducir y el otro
se basa en librerías que están disponible en diferentes leguajes de programación PYTHON, RUBY,
JAVA y C#.
Página web: http://www.seleniumhq.org/

» Cucumber:
Es un framework de código abierto (Open Source) el cual permite automatizar pruebas sobre
plataformas web, la escritura de script se apoya en BDD (Behavior Driven Development), este
framework dispone de librerías en los siguientes lenguajes PYTHON, RUBY, JAVA y C#.
Página web: https://cucumber.io/

Herramienta para pruebas no funcionales
» Jmeter:
Es una herramienta de escritorio de código libre construida en java, la cual permite realizar
pruebas de stress y performance, trabaja sobre los siguientes protocolos: HTTP, HTTPS, SOAP,
JDBC, LDAP, JMS, Mail (POP3 y IMAP).
Página web: http://jmeter.apache.org/
» Sonarqube:
Es una herramienta cliente servidor de código libre, la cual permite realizar pruebas de inspección
de código, cuenta con plugins gratuitos y otros de pago, trabaja sobre los principales lenguajes de
programación, por otro lado cuenta con plugins para realizar la su integración con diversos
sistemas.
Página web: https://www.sonarqube.org/

Herramienta para la gestión de defecto
» Mantis:
Es una herramienta de código libre, la cual permite el seguimiento de problemas e incidencias, la
herramienta permite registrar incidentes y generar un flujo de trabajo para la resolución de los
mismos, cuenta con reportes y gráficos, notificaciones por correo electrónico y lo más importante
permite adjuntar documentos para evidenciar los incidentes
Página web: https://www.mantisbt.org/

» Bugzilla:
Es una herramienta de código libre, la cual permite el seguimiento de incidencias, la herramienta
permite registrar incidentes y enviarlos al equipo de desarrollo para su resolución, cuenta con
reportes y gráficos, notificaciones por correo electrónico y lo más importante permite adjuntar
documentos para evidenciar los incidentes
Página web: https://www.bugzilla.org/
Importancia y función de las pruebas de sistema

Los Productos Software, sistemas y/o aplicaciones son creadas, desarrolladas e
implementadas por seres humanos y por ende en cualquiera de sus etapas de creación se puede
presentar una equivocación, al generarse esa “Equivocación” se puede conllevar a un defecto en
el software, por ejemplo mala digitación, distracción al codificar, mala elaboración de un
documento entre otras. Si no se ha identificado ese defecto y el software o la aplicación se
ejecuta, hay un alto riesgo de que la aplicación no haga lo que debería hacer o el objeto para lo
cual fue creada, es decir se genera un fallo o desperfecto, lo que podría generar una catástrofe, es
importante conocer que los fallos también se pueden presentar por situaciones del entorno,
como la radiación, descarga eléctrica, contaminación, inundaciones, Húmeda, Fuego, etc.
Los Ingenieros de sistemas entonces deben estar en la capacidad de conocer y aplicar las
diferentes normas, procesos y procedimientos para garantizar la calidad de los productos
software, aplicando las pruebas de calidad de software necesarias para que con ellas se pueda
ayudar a reducir los riesgos en las aplicaciones, logrando que se identifiquen los defectos antes de
que se ejecuten, así de forma proactiva tomar decisiones que permitan hacer las actividades
necesarias para mejorar las condiciones del software y ofertar un producto que satisfaga las
necesidades del cliente.

Crecimiento de uso de un software.
La industria del software es considerada un sector de clase mundial que representa una
oportunidad de fomento de la competitividad y crecimiento económico e industrial. La
importancia de esta industria a nivel económico radica en el respaldo de la operatividad y
estabilidad que otorga a otros sectores industriales importantes de la economía nacional. No
obstante, la evidencia empírica revela limitaciones de crecimiento que deben ser superadas para
lograr las metas propuestas para el sector.
La economía digital de Europa se está construyendo sobre la industria del software, el

crecimiento está siendo continuado y se prevé conseguir los 290 mil millones de euros para el año
2020.
Estas previsiones han sido realizadas por la Comisión Europea en su Estudio “The Economic
and Social Impact of Software and Services on Competitiveness and Innovation”.
Aun siendo la cifra bastante elevada, no parece complicado su cumplimiento puesto que en
2009 ya se consiguió la friolera de 229 mil millones de euros gracias al software a medida y el
crecimiento no ha parado desde entonces, incrementándose interanualmente. Por otra parte los
softwares de videojuegos y servicios tic de aplicaciones aunque tienen una continúa evolución,
dicha evolución es mucho más lenta e incluso puede que en términos de infraestructura los
servicios de Ti disminuyan levemente.
En el año 2015 los gastos totales destinados a desarrollo de software llegó a 53,3 mil millones de
euros con un crecimiento de 1,8% anualmente.
¿Qué se espera en los próximos años?
La tendencia que se esperan en los próximos años, son el big Data, la movilidad, la colaboración
social, el internet of thing y los programas open source.
Tema 2.
Antecedentes históricos del surgimiento

De las pruebas de sistema.
“La ingeniería de software es una disciplina que integra métodos, herramientas y

procedimientos para el desarrollo de software de computadora.” Desde la década del sesenta ha
existido un movimiento tendiente a cambiar la programación de computadores de un estado
artesanal a una disciplina similar a la ingeniería. El campo de la ingeniería de software surgió con el

objetivo de introducir una técnica disciplinada al desarrollo de software.
Fritz Bauer estableció una de las primeras definiciones de ingeniería de software en 1969:
“Ingeniería de Software es el establecimiento y uso de principios robustos de ingeniería, orientados
a obtener software que sea fiable y funcione de manera eficiente sobre máquinas reales”. Los
puntos claves de esta definición pueden observarse en todas las disciplinas de ingeniería: principios
robustos y productos económicos y confiables.
La ingeniería de software, al igual que otras ingenierías, debe trabajar con elementos
gerenciales y humanos, además de los elementos técnicos propios. Sin embargo, a diferencia de las
otras ingenierías, su producto, el software, es inmaterial. El desarrollo de software no puede, por
tanto, ser manejado y controlado como otros procesos para productos físicos.
El desarrollo de software es una actividad compleja por naturaleza. La complejidad del
desarrollo de software se ve agravada por el constante y acelerado avance tecnológico de la
industria electrónica. Cada día los fabricantes son capaces de producir máquinas más económicas y
poderosas. Esto posibilita desarrollar actualmente aplicaciones que no podrían realizarse cinco o
diez años atrás.
Las necesidades del usuario son, cada vez, más complejas. El software, en sí mismo, es cada
vez más complejo. El proceso de desarrollo de software es, en definitiva, cada vez más complejo
La ingeniería de software surgió de una serie de investigaciones en la década de los 60. Las
primeras investigaciones al respecto buscaban hallar mejores mecanismos para escribir programas.
Trabajos posteriores, como el análisis y diseño estructurado, comenzaron a presentar un
visión más amplia del proceso. La disciplina se ha enriquecido con muchas investigaciones y avances
tecnológicos desde esa época.
La ingeniería de software, durante toda su vida, ha estado “marcada” por tres enfoques o
paradigmas principales :
- Los métodos orientados a procesos
- Los métodos orientados a la información
- Los métodos orientados a objetos
Normalmente, el testing está considerado como parte del Ciclo de Vida de Desarrollo de
cualquier aplicación (Requisitos, análisis & diseño, implementación, testing y deployment), pero el
testing, a su vez, tiene su propio ciclo de vida. Dependiendo de la organización, este ciclo puede
tener más o menos fases, a continuación veremos A grandes rasgo las fases que son siempre
comunes, podemos decir que el ciclo de vida del Software Testing incluye las siguientes fases:

1. Planificación
7. Producción 2. Análisis
Ciclo de vida
del Software
6. Pruebas Testing
Finales e
Implementació 3. Diseño
n
5. Ciclos 4. Ejecución
¿En qué fase del ciclo de vida deben comenzar las pruebas?
Lo antes posible. Si dividimos el ciclo de desarrollo en cuatro etapas: Inicio, Elaboración,
Construcción y Transición…el equipo de Quality Assurance debería comenzar sus labores entre la
fase de Inicio y Elaboración. Es recomendable que al menos el responsable del equipo de calidad
asista a las reuniones de toma de requisitos.
1. Planificación de las pruebas (Fase de definición del Producto):
La fase de planificación de pruebas significa redactar el Test Plan ó Plan de Pruebas. El Test Plan es
un documento a alto nivel que describe las estrategias a seguir durante el desarrollo de las pruebas.
Contenidos de un Test Plan :
+ Alcance de las pruebas.

+ Comienzo y fin (planificación)
+ Estrategias (Black Box, White Box, etc.)
+ Niveles de Pruebas (Integration testing, Regression testing, etc.)
+ Limitaciones

+ Riesgos
+ Revisiones y entregables.
+Técnicas de Pruebas (Boundary Value Analysis, Equivalence Partitioning, etc.)
Herramientas para realizar las pruebas (Automáticas, carga, integración co
+ Reporting (How would bugs be reported)
+ Hitos
+ Métricas
+ Recursos y planes de formación
+ Tareas y responsabilidades
Estas son sólo algunos de los contenidos de un Plan de pruebas aunque muchas veces varía
dependiendo de la empresa. Hay algunas plantillas interesantes en internet, como la de la IEEE.
2.Análisis de pruebas (Fase de Documentación)
La fase de análisis es una extensión de la fase del planificación. Mientras que la fase de planificación
es a más alto nivel, la fase de análisis es donde se comienza a documentar los planes detallados. Se
comienza a analizar los casos de prueba:
 Revisión de los Inputs: Se consideran, el documento de especificación de requisito y otros

documentos de planificación del proyecto…mientras, el plan de pruebas se rompe en
pequeñas partes que serán los futuros casos de prueba.
 Formatos: Generalmente en esta fase se crea una matriz de validación basada en los
requisitos. Estas matrices nos ayudarán a la hora de ejecutar los test cases. También,
usando alguna de las herramientas de planificación de proyectos que hay en el mercado
(phpcollab, MS project, gantt…) creamos la planificación de las pruebas basándonos en cada
uno de los hitos del plan de proyecto. Las métricas a utilizar, también se diseñan en esta
fase.
 Test Cases: ó casos de prueba. Siguiendo la matriz de validación y otros documentos de

entrada (inputs), se escriben los test cases. Comenzamos también a vincular los requisitos
con cada test case.
 Automatización: Mientras se crean test cases, se identifican los casos que deben ser
automatizados. También se identifican las áreas para las pruebas de rendimineto, de carga y
de stress.
 Plan de Regresión: Los ciclos de pruebas, es decir, número de veces que se probará de
nuevo la aplicación para verificar que los defectos encontrados no han introducido nuevos
errores.
3. Diseño de pruebas:

Tenemos que darnos cuenta que el ciclo de vida de pruebas transcurre en paralelo al de desarrollo.
Así, una vez que hayamos llegado a esta fase (el equipo de desarrollo probablemente habrá
comenzado a escribir las primeras líneas de código) comenzaremos el diseño.
Durante esta fase todos los planes, test cases, etc… de la fase de análisis son revisados y finalizados.
Nuevos test cases puden ser añadidos y se realiza el documento de gestión de riesgos. También es
el momento para hacer los scripts de pruebas automaticas (nuevos ó updates de los ya existentes).
Finalmente, los informes de pruebas, especialmente los informes sobre pruebas unitarias.
4. Ejecución de las pruebas:
En este momento el equipo de desarrollo tiene una versión estable y lista para testear. Lo más
recomendable es hacer un test de cualificación de la versión (qualification testing) para evaluar que
la aplicación es lo suficientemente estable para comenzar la ejecución de las pruebas. De nada sirve
comenzar una ronda de test si al cabo de cinco golpes de ratón la aplicación rompe. Tiene que tener
un mínimo de estabilidad.
Una vez terminado el “Qualification”, los ingenieros de pruebas ya pueden comenzar a ejecutar el
plan de test. Así como los test automáticos (si los hubiera), unit testing, revisiones de código,
performance….etc.
Para llevar el seguimiento de la ejecución de los test cases podemos utilizar alguna de las
herramientas comerciales que hay en el mercado ó utlizar una matriz de excel donde iremos
apuntado nuestros PASSED o FAILED (OK or NOT).
5. Ciclo de pruebas (Regresión):
En este momento del ciclo al menos alguna ronda de test ya se habrá ejecutado y algunos issues se
habrán reportado. Una vez que el equipo de desarrollo ha arreglado los defectos, la segunda ronda
de pruebas comienza. Esta nueva ronda de pruebas podría solamente centrarse en las áreas ó
funcionalidades que han sido arregladas. Pero también podría ser regresión testing, donde la
aplicación es testeada nuevamente para verificar su correcto funcionamiento y que el arreglo de los
defectos no ha afectado otras partes del código.
Pruebas —> Reporte de Defectos —> Arreglo de Defectos (y mejoras) —> Nueva ronda de Pruebas
Aquí es donde pruebas automáticas pueden ser de gran ayuda para repetir el mismo test case una y
otra vez.
Durante esta fase es importante revisar el documento de requisitos (CRD) y el Project Plan por si
han habido modificaciones.

 Pruebas de compatibilidad.
La prueba de compatibilidad es uno de los varios tipos de pruebas de software realizadas en

un sistema que se construye sobre la base de ciertos criterios y que tiene que realizar una
funcionalidad específica en una instalación ya existente medio ambiente. La compatibilidad de un
sistema de aplicación en desarrollo, por ejemplo, otros sistemas y aplicaciones, el sistema operativo
de red, decidir muchas cosas, como el uso del sistema en el medio ambiente, la demanda del
sistema, etc. Muchas veces, los usuarios prefieren no optar por una aplicación sólo porque no es
compatible con cualquier otro sistema, red, hardware o sistema operativo que ya están utilizando.
Esto lleva a una situación en la que los esfuerzos de desarrollo adoptadas por los desarrolladores de
llegar a ser en vano.
¿Cuál es la prueba de compatibilidad

La prueba de compatibilidad es un tipo de prueba utilizado para garantizar la compatibilidad del
sistema o sitio web construido con varios otros objetos, tales como otros navegadores web,
plataformas de hardware, los usuarios (en caso de que si es tipo muy específico de requisitos, como
por ejemplo un usuario que habla y sólo puede leer un idioma en particular), sistemas operativos,
etc. Este tipo de pruebas ayudan a determinar qué tan bien un sistema lleva a cabo en un ambiente
particular, que incluye hardware, red, sistema operativo y otro software, etc.
La prueba de compatibilidad se puede automatizar mediante las herramientas de automatización o

se puede realizar de forma manual y es una parte de las pruebas de software no funciona.
Los desarrolladores en general, toman en cuenta la observación para la evaluación de los siguientes
elementos en un entorno de computación (entorno en el que se prueba el sistema de nuevo como
aplicación y que tiene una configuración similar a la del entorno real en el que se supone que el
sistema necesita adaptarse y empezar a trabajar.
 Hardware: Evaluación del desempeño de la aplicación como sitio web en una plataforma de
hardware determinado. Por ejemplo: Si un juego es compatible con todas las plataformas ha
sido desarrollado y está siendo probado para la compatibilidad de hardware, el desarrollador
puede optar por probar varias combinaciones de conjuntos de chips (como Intel, Macintosh
GForce), las placas madre, etc.
 Navegador: Evaluación del desempeño del sistema o sitio web en un determinado tipo de
navegador. Por ejemplo: Una página web es la prueba de compatibilidad con navegadores como
Internet Explorer, Firefox, etc. (por lo general las pruebas de compatibilidad del navegador
también es visto como una prueba de la experiencia del usuario, ya que se relaciona con la
experiencia del usuario de la aplicación, mientras que la utilice en diferentes navegadores).
 Red: Evaluación del desempeño del sistema o sitio web en la red con distintos parámetros como
el ancho de banda, la variación en la capacidad y la velocidad de funcionamiento del hardware
subyacente, etc., que se configura para replicar el entorno operativo actual.

 Periféricos: Evaluación del desempeño del sistema en relación con los diferentes sistemas o
dispositivos periféricos conectados directamente través de la red. Por ejemplo: impresoras,
máquinas de fax, líneas telefónicas, etc.
 Compatibilidad entre versiones: Evaluación del desempeño del sistema en relación con sus
propios predecesor y/o sucesor versiones (la compatibilidad hacia atrás y adelante). Por
ejemplo: Windows 98 fue desarrollado con compatibilidad con versiones anteriores para
Windows 95, etc.
 Software: Evaluación del desempeño del sistema en relación con otro software. Por ejemplo:
Compatibilidad de software con herramientas de funcionamiento de la red, servidores web,
mensajería de herramientas, etc.
 Sistema Operativo: Evaluación del rendimiento de sistema en relación con el sistema operativo
subyacente en el que se usará.
 Bases de datos: Muchas aplicaciones y sistemas operan sobre bases de datos. Las pruebas de
compatibilidad de base de datos se utiliza para evaluar un rendimiento de la aplicación en
relación a la base de datos que va a interactuar.
¿Qué tan útil es?
La prueba de compatibilidad puede ayudar a los desarrolladores a entender los criterios que
su sistema necesita para lograr y cumplir, con el fin de ser aceptado por los usuarios previstos que
ya están utilizando otros sistemas operativos, redes, software y hardware, etc. También ayuda a los
usuarios para saber qué sistema mejor se ajuste en la configuración actual que está utilizando.
El uso más importante de las pruebas de compatibilidad es como se ha mencionado

anteriormente: para asegurar su funcionamiento en un entorno informático en el que se supone
que operan. Esto ayuda a averiguar los cambios necesarios o modificaciones o adiciones necesarias
para que el sistema sea compatible con el entorno informático.
Objetivo de la Prueba: Buscar problemas de compatibilidad y conversión en los sistemas.
Descripción de la Prueba: El propósito es demostrar que los objetivos de compatibilidad no han

sido logrados y que los procedimientos de conversión no funcionan.
La mayoría de los programas que se desarrollan no son completamente nuevos; con frecuencia
son reemplazos de partes deficientes, ya sea de sistemas de procesamiento de datos, o sistemas
manuales.
Como tales, los programas tienen a menudo objetivos específicos con respecto a su
compatibilidad y a sus procedimientos de conversión con el sistema existente.
Técnica: Desarrollar casos de prueba que permitan detectar deficiencias con:

· Compatibilidad entre programas
· Conversión de datos

Todos los defectos que se identificaron han sido tenidos en cuenta.
 Pruebas de Regresión:
La regresión consiste en la repetición selectiva de pruebas para detectar fallos introducidos
durante la modificación de un sistema o componente de un sistema. Se efectuarán para comprobar
que los cambios no han originado efectos adversos no intencionados o que se siguen cumpliendo
los requisitos especificados.
En las pruebas de regresión hay que:
 Probar íntegramente los módulos que se han cambiado.
 Decidir las pruebas a efectuar para los módulos que no han cambiado y que han sido afectados
por los cambios producidos.
Este tipo de pruebas ha de realizarse, tanto durante el desarrollo cuando se produzcan cambios en
el software, como durante el mantenimiento.
Descripción de la Prueba: En esta prueba se vuelve a probar el sistema a la luz de los cambios
realizados durante el debugging, mantenimiento o desarrollo de la nueva versión del sistema
buscando efectos adversos en otras partes.
Técnica: La prueba de regresión es una nueva corrida de casos de prueba previos.

Se requiere de políticas para ser creada la prueba de regresión y decidir qué casos de prueba
incluir, para probar eficientemente.
La prueba de regresión es un buen candidato para automatización. Desde que estas pruebas
se repiten una y otra vez, las herramientas para minimizar el esfuerzo del trabajo son útiles. La
prueba de viejas funcionalidades es más importante que la de nuevas funcionalidades. Aquellos
casos de uso (y los casos de prueba asociados) que descubren defectos tempranamente deben ser
incluidos en la prueba de regresión.

Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas. Todos los defectos
que se identificaron han sido tenidos en cuenta.

 Pruebas de Integración:
Aun cuando los módulos de un programa funcionen bien por separado es necesario probarlos
conjuntamente: un módulo puede tener un efecto adverso o inadvertido sobre otro módulo; las
subsunciones, cuando se combinan, pueden no producir la función principal deseada; la imprecisión
aceptada individuamente puede crecer hasta niveles inaceptables al combinar los módulos; los
datos pueden perderse o malinterpretarse entre interfaces, etc.
Por lo tanto, es necesario probar el software ensamblando todos los módulos probados
previamente. Éste es el objetivo de la pruebas de integración.
A menudo hay una tendencia a intentar una integración no incremental; es decir, a combinar todos
los módulos y probar todo el programa en su conjunto. El resultado puede ser un poco caótico con
un gran conjunto de fallos y la consiguiente dificultad para identificar el módulo (o módulos) que los
provocó.
En contra, se puede aplicar la integración incremental en la que el programa se prueba en pequeñas
porciones en las que los fallos son más fáciles de detectar. Existen dos tipos de integración
incremental, la denominada ascendente y descendente. Veamos los pasos a seguir para cada caso:
Integración incremental ascendente:
1) Se combinan los módulos de bajo nivel en grupos que realicen una subfunción específica
2) Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y
salida de los casos de prueba.
3) Se prueba el grupo
4) Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la
estructura del programa.
La Figura 7 muestra este proceso. Concretamente, se forman los grupos 1, 2 y 3 de módulos

relacionados, y cada uno de estos grupos se prueba con el controlador C1, C2 y C3 respectivamente.
Seguidamente, los grupos 1 y 2 son subordinados de Ma, luego se eliminan los controladores
correspondientes y se prueban los grupos directamente con Ma. Análogamente se procede con el
grupo 3 eliminando el controlador C3 y probando el grupo directamente con Mb.
Tanto Ma y Mb se integran finalmente con el módulo Mc y así sucesivamente.

Integración incremental descendente:
1) Se usa el módulo de control principal como controlador de la prueba, creando resguardos

(módulos que simulan el funcionamiento de los módulos que utiliza el que está probando)
para todos los módulos directamente subordinados al módulo de control principal.
2) Dependiendo del enfoque e integración elegido (es decir, primero-en-profundidad, o
primero-en-anchura) se van sustituyendo uno a uno los resguardos subordinados por los
módulos reales.
3) Se llevan a cabo pruebas cada vez que se integra un nuevo módulo.
4) Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el módulo real.
La Figura 8 muestra un ejemplo de integración descendiente. Supongamos que se selecciona una

integración descendiente por profundidad, y que por ejemplo se prueba M1, M2 y M4. Sería
entonces necesario preparar resguardos para M5 y M6, y para M7 y M3. Estos resguardos se han
representado en la figura como R5, R6, R7 y R4 respectivamente. Una vez realizada esta primera
prueba se sustituiría R5 por M5, seguidamente R6 por M6, y así sucesivamente hasta probar todos
los módulos.

Para la generación de casos de prueba de integración, ya sea descendente o ascendente se utilizan
técnicas de caja negra.
Testing Automatizado vs. Testing Manual
Testing Automatizado Testing Manual

Pros: Pros:
 Si se tienen que correr un juego de pruebas  Si el caso de prueba sólo se ejecuta dos veces
repetidamente, la automatización será de ante un cambio en la codificación,
muchísima ayuda. probablemente debería ser una prueba
manual antes que automatizada ya que el
 Nos permite correr las pruebas costo es mayor al beneficio.
automatizadas sobre un código que cambia
frecuentemente reduciendo el tiempo  Permite al tester ampliar más las pruebas
insumido en las pruebas de regresión. durante la ejecución del caso de prueba.
Encontrando más bugs ya que el tester puede
 Permite realizar matrices de pruebas inventar combinaciones impensadas
combinando diferentes lenguajes con mientras navega la aplicación y ante diversas
diferentes SO. situaciones.
 Permite realizar pruebas en paralelo en una o

varias máquinas.

Contras: Contras:
 El esfuerzo inicial es mayor. La creación del  Las pruebas manuales pueden consumir
script automatizado puede ser más costoso demasiado tiempo
que la creación del caso de prueba para
ejecución manual.  Cada vez que hay un cambio en la
aplicación el tester debe correr las pruebas
 No se pueden (o puede ser muy costoso) de regresión. Ante reiterados cambios, el
automatizar referencias visuales como tester puede llegar a correr demasiadas
colores o ubicación en pantalla de objetos. veces las pruebas de regresión, reduciendo
su capacidad de encontrar errores.
Otras Consideraciones:
 Que la automatización sea costoso o no, también depende en el conocimiento que se tenga
sobre la herramienta que se utilizará.
 Siempre hay que tener en cuenta cual es el COSTO y cual el BENEFICIO de la manera que
encaremos las pruebas que vamos a realizar (manual o automatizado) teniendo en cuenta el
conocimiento de la herramienta a utilizar, conocimientos en programación, tiempo de las
pruebas, cantidad de ciclos de testing, etc.
Enfoques de pruebas de sistema

(Caja negra, caja blanca o Testing aleatorio).
Los términos caja negra y caja blanca son muy utilizados dentro de la teoría en
sistemas con respecto al tipo de perspectiva con la cual es estudiado un sistema. Estos dos
tipos de estudios dentro de un sistema son usados dependiendo de lo que exactamente deseemos
estudiar, si queremos saber cómo funciona internamente un elemento de un sistema se utiliza el
termino caja blanca. Si lo que queremos es estudiar la interacción de dicho modulo con los demás
módulos del sistema se utiliza el termino caja negra
El objetivo principal de realizar estas pruebas es el de encontrar defectos en el software,

verificando se cumple las especificaciones de diseño (Prueba de Verificación) o verificando que
cumpla los requisitos de análisis (Prueba de Validación), con esto logramos demostrar al
desarrollador y al cliente de que el software satisface sus requerimientos y saber cuáles son los
defectos del software para posteriormente corregirlos Para esto existe un modelo de los casos
de prueba que nos permitirá hacerlas correctamente, dicho modelo se presenta en la figura 1

La prueba del software es un elemento crítico para la garantía de la calidad del
software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado.
Además, esta etapa implica:
 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.
 Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores,
haciéndolo con la menor cantidad de tiempo y esfuerzo.
La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones
externas. La prueba es un proceso de ejecución de un programa con la intención de descubrir
un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no
descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta
entonces.
En nuestro caso hemos clasificado en dos ramas, pruebas de caja negra y pruebas de caja
blanca.
» Caja Negra
También conocidas como Pruebas de Comportamiento, estas pruebas se basan en la

especificación del programa o componente a ser probado para elaborar los casos de prueba. El
componente se ve como una “Caja Negra” cuyo comportamiento sólo puede ser determinado
estudiando sus entradas y las salidas obtenidas a partir de ellas. No obstante, como el estudio de

todas las posibles entradas y salidas de un programa sería impracticable se selecciona un conjunto
de ellas sobre las que se realizan las pruebas. Para seleccionar el conjunto de entradas y salidas
sobre las que trabajar, hay que tener en cuenta que en todo programa existe un conjunto de
entradas que causan un comportamiento erróneo en nuestro sistema, y como consecuencia
producen una serie de salidas que revelan la presencia de defectos. Entonces, dado que la prueba
exhaustiva es imposible, el objetivo final es pues, encontrar una serie de datos de entrada cuya
probabilidad de pertenecer al conjunto de entradas que causan dicho comportamiento erróneo sea
lo más alto posible.
Al igual que ocurría con las técnicas de Caja Blanca, para confeccionar los casos de prueba de Caja
Negra existen distintos criterios. Algunos de ellos son:
 Particiones de Equivalencia.
 Análisis de Valores Límite.
 Métodos Basados en Grafos.
 Pruebas de Comparación.
 Análisis Causa-Efecto.
Las pruebas de Caja Negra se llevan a cabo sobre la interfaz del software, y es
completamente indiferente el comportamiento interno y la estructura del programa, esto es
estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que
produce, sin tener en cuenta su funcionamiento interno.
Los casos de prueba de la caja negra pretende demostrar que:

 Las funciones del software son operativas.
 La entrada se acepta de forma adecuada.
 Se produce una salida correcta, y La integridad de la información externa se mantiene.
Se derivan conjuntos de condiciones de entrada que ejerciten completamente todos los

requerimientos funcionales del programa. La prueba de la caja negra intenta encontrar
errores de las siguientes categorías

 Funciones incorrectas o ausentes.
 Errores de interfaz.
 Errores en estructuras de datos o en accesos a bases de datos externas.
 Errores de rendimiento.
 Errores de inicialización y de terminación.
Los casos de prueba deben satisfacer los siguientes criterios:

 Reducir, en un coeficiente que es mayor que uno, el número de casos de prueba
adicionales.
 Que digan algo sobre la presencia o ausencia de clases de errores.
Ejemplos
» Caja Negra
Un chip de memoria puede considerarse una caja negra. Muchas personas utilizan chips
de memoria, e incluso los diseñan para los equipos informáticos, pero por lo general sólo los
diseñadores de chips de memoria necesitan comprender su funcionamiento interno.
Casi cualquier cosa puede ser descrita como una caja negra:
- un transistor
- un algoritmo
- un programa de computación
- un mainboard
- parlantes, etc.
Las Pruebas a Ejecutarse son:

 Prueba de unidad.- este tipo de prueba es considerada una de las primordiales ya
que los resultados obtenidos de esta repercutirá directamente en la ejecución de las
demás pruebas.
 Prueba de integración.- Este busca que el programa corra sin problemas.
 Prueba de validación.- tras la culminación de las pruebas de integración, el software
está completamente ensamblado como un paquete; se han encontrado y corregido los
errores de interfaces, y debe comenzar una serie final de pruebas del software, la prueba
de validación.
 Prueba de recuperación.- muchos sistemas basados en computadoras deben recuperarse
de los fallos y asumir el procesamiento en un tiempo previamente especificado. En
algunos casos un sistema debe ser tolerante a fallos, o sea, los fallos de
procesamiento no deben hacer que cese el funcionamiento de todo el sistema.

 Prueba de seguridad.- estas pruebas intentan verificar que los mecanismos de
protección incorporados en el sistema, lo protejan, de hecho de la penetración impropia.
Durante la prueba de seguridad, el 7 encargado de la prueba juega el papel de un
individuo que desea penetrar el sistema.
Técnicas de pruebas de caja negra

A continuación describimos las principales técnicas (o métodos) de pruebas de caja negra, tomando las definiciones
del Syllabus del ISTQB:
Partición de equivalencias
Consiste en clasificar las entradas de datos del sistema en grupos que presentan un
comportamiento similar, por lo cual serán procesados de la misma forma. Se pueden definir
particiones tanto para datos válidos como no válidos (datos que deben ser rechazados por el
sistema).
Las particiones también pueden definirse en función de las salidas de datos, valores internos,
valores relacionados antes o después de ciertos eventos, y también para los valores que reciben las
interfaces. A partir de allí se definen pruebas para cubrir todos o parte de las particiones de datos
válidos y datos inválidos.
Es aplicable a entradas de datos realizadas por personas o vía interfaces con otros sistemas.
Consiste en clasificar las entradas de datos del sistema en grupos que presentan un
comportamiento similar, por lo cual serán procesados de la misma forma. Se pueden definir
particiones tanto para datos válidos como no válidos (datos que deben ser rechazados por el
sistema).
Las particiones también pueden definirse en función de las salidas de datos, valores internos,
valores relacionados antes o después de ciertos eventos, y también para los valores que reciben las
interfaces. A partir de allí se definen pruebas para cubrir todos o parte de las particiones de datos
válidos y datos inválidos. Es aplicable a entradas de datos realizadas por personas o vía interfaces
con otros sistemas.

» Tablas de decisión
Las tablas de decisión son una herramienta útil para documentar reglas de negocio de alta
complejidad que el sistema debe cumplir. Las tablas de decisión se crean a partir del análisis de la
especificación funcional y la identificación de estas reglas de negocio.
Las condiciones de entrada y acciones se expresan a menudo en términos de verdadero o
falso. La tabla de decisión contienen las condiciones desencadenantes, que son la combinación de
valores de verdadero o falso para cada entrada de datos, así como la acción que resulta de cada
combinación.
Cada columna de la tabla corresponde con una regla de negocio que representan la
combinación de condiciones, y las acciones que resultan.
» Transición entre estados
Un sistema puede presentar diferentes comportamientos según su estado actual o eventos

previos. Este aspecto del sistema se puede representar en un diagrama de transición entre estados.
El diagrama de estados, permite al Tester visualizar los estados, transiciones, entradas de datos o
eventos que las desencadenan y las acciones que pueden resultar. Una tabla de estados, muestra
las relaciones entre los estados y las entradas de datos. Puede ayudar a identificar posibles
transacciones inválidas.
» Pruebas de Casos de Uso

Los casos de uso describen las interacciones entre actores (que pueden ser usuarios o
sistemas) que producen un resultado que agrega algún valor. A partir de estos se pueden derivar
casos de prueba. Tienen precondiciones que deben cumplirse para que estos funcionen de forma
exitosa.
Los casos de uso terminan con post-condiciones, que son resultados observables y estado del
sistema después de la ejecución. Son útiles para definir las pruebas de aceptación, en las que
participa el usuario o cliente.
» Técnicas combinatorias
El testing combinatorio es muy útil cuando las combinaciones de datos de entrada y

parámetros a partir de los cuales puede ejecutarse un sistema, son demasiados para poder
abarcarlos todos en el tiempo disponible.
Se pueden usar herramientas como los arboles de clasificación para identificar combinaciones
incompatibles entre sí que pueden excluirse.
Proporciona los medios para identificar un subconjunto de estas combinaciones que pueda
ayudar a alcanzar un nivel determinado de cobertura.
Pruebas de historias de usuario
En metodologías ágiles como por ejemplo Scrum, los requerimientos de usuario son
preparados en la forma de historias de usuario. La historia de usuario describe una funcionalidad (o
parte de ella) que puede ser desarrollara y probada en una sola iteración. La historia de usuario
describe la funcionalidad a implementar, requerimientos no funcionales y los criterios de
aceptación.
La cobertura mínima de pruebas para una historia de usuario está compuesta por los criterios
de aceptación. Por ende los casos de prueba se derivan de estos criterios de aceptación.

» Caja Blanca
A este tipo de técnicas se le conoce también como Técnicas de Caja Transparente o de Cristal.
Este método se centra en cómo diseñar los casos de prueba atendiendo al comportamiento interno
y la estructura del programa. Se examina así la lógica interna del programa sin considerar los
aspectos de rendimiento.
El objetivo de la técnica es diseñar casos de prueba para que se ejecuten, al menos una vez,
todas las sentencias del programa, y todas las condiciones tanto en su vertiente verdadera como
falsa. Como se ha indicado ya, puede ser impracticable realizar una prueba exhaustiva de todos los
caminos de un programa. Por ello se han definido distintos criterios de cobertura lógica, que
permiten decidir qué sentencias o caminos se deben examinar con los casos de prueba. Estos
criterios son:
 Cobertura de Sentencias: Se escriben casos de prueba suficientes para que cada sentencia
en el programa se ejecute, al menos, una vez.
 Cobertura de Decisión: Se escriben casos de prueba suficientes para que cada decisión en el
programa se ejecute una vez con resultado verdadero y otra con el falso.
 Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada condición
en una decisión tenga una vez resultado verdadero y otra falso.
 Cobertura Decisión/Condición: Se escriben casos de prueba suficientes para que cada
condición en una decisión tome todas las posibles salidas, al menos una vez, y cada decisión
tome todas las posibles salidas, al menos una vez.
 Cobertura de Condición Múltiple: Se escriben casos de prueba suficientes para que todas
las combinaciones posibles de resultados de cada condición se invoquen al menos una vez.
 Cobertura de Caminos: Se escriben casos de prueba suficientes para que se ejecuten todos
los caminos de un programa. Entendiendo camino como una secuencia de sentencias
encadenadas desde la entrada del programa hasta su salida.
Las Pruebas de Caja Blanca permiten examinar la estructura interna del programa. Se diseñan
casos de prueba para examinar la lógica del programa. Es un método de diseño de casos de
prueba que usa la estructura de control del diseño procedimental para derivar casos de prueba que
garanticen que:
 Se ejercitan todos los caminos independientes de cada módulo.
 Se ejercitan todas las decisiones lógicas.
 Se ejecutan todos los bucles.
 Se ejecutan las estructuras de datos internas.
Las pruebas de caja blanca se centran en los detalles procedimentales del software, por

lo que su diseño está fuertemente ligado al código fuente.
Las personas encargadas de las pruebas escogen distintos valores de entrada para examinar
cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los
valores de salida adecuados.
Al estar basadas en una implementación concreta, si ésta se modifica, por regla general las
pruebas también deberán rediseñarse.
» Caja blanca
Las principales pruebas son:
o Pruebas de flujo de control.- En estas pruebas se quiere encontrar errores en la
parte lógica del programa. Utilizando las condiciones simples (operador-relación) o con
condiciones complejas (N x [operador-relación]). Por ejemplo este encuentra errores
con los paréntesis, con variables y hasta de operaciones aritméticas.
o Pruebas de flujo de datos.- Por medio de esta herramienta se hace la selección más
adecuada del flujo de datos, para llegar a una resolución correcta. Esto para probar las
variables y definiciones en el programa.
o Pruebas de bifurcación (branch testing).- Como lo dice su título, es ligado a una
bifurcación o para bucles. Con ella podemos definir si algún bucle está correctamente
implementado y si las líneas de código donde exista una condición es la mejor opción o si
debería ser cambiada.
o Pruebas de caminos básicos.- Esta prueba lo que demuestra es el conjunto de pasos
base del programa, lo que quiere lograr es que cada sentencia de código se ejecute
mínimo una vez. Acá se usan herramientas como grafos, diagramas de flujo, la
complejidad ciclomática, entre otros.
Como se menciona anteriormente es para revisar un producto terminado, por lo tanto lo que
podemos revisar seria:
o Datos de entrada: Por ejemplo si vamos a revisar una función que solo recibe números
correspondientes a los días de la semana, tendríamos un rango de [1 - 7], lo que nos da 3

posibilidades para las pruebas.
1) No hay dato de entrada.
2) El dato de entrada es menor a 1.
3) El dato de entrada esta entre 1 y 7
4) El dato de entrada es mayor a 7.
o Funcionalidad: Este es más sencillo, ya que es probar que el código cumpla con un
requerimiento en específico, por ejemplo si es una función de suma de dos datos, que el
resultado sea la suma del mismo.
Al igual que el anterior tenemos las siguientes posibilidades.

1) La función no da el resultado correcto.
2) La función da el resultado correcto.
3) La función no recibe parámetros.
4) La función no devuelve parámetros.
Conclusiones
Como pudimos mostrar se tiene gran variedad de formas de realizar estas pruebas y todo
dependerá de la necesidad que tengamos, es decir, del problema que hayamos resuelto. Por
lo tanto para saber cuál de las dos pruebas usar deberíamos tener en cuenta con qué
recursos contamos, si tenemos el código fuente de un sistema podríamos aplicar fácilmente
las pruebas de caja blanca, por el contrario, si no nos proporcionaron los códigos y
únicamente contamos con el producto final, no nos queda otra opción más que optar por las
pruebas de caja negra.
Niveles de pruebas.
Los niveles de prueba son diferentes ángulos de verificar y validar un producto de software.
Es como el tomar una radiografía a un cuerpo humano desde diferentes lados y buscar donde hay
un problema en los huesos.
Existen diferentes niveles de prueba de Software, los principales son la Prueba unitaria que es la
que realizan los desarrolladores de software en su código o componente.
La prueba de integración que es realizada también por el desarrollador de software y consiste en

validar las conexiones e integración entre dos o más componentes (códigos) de software, estos dos
niveles de prueba son realizados a través de la técnica de caja blanca.
Otro nivel de prueba es la prueba funcional, es preparada y ejecutada por un grupo independiente

al desarrollador, y consiste en validar el apego funcional del software contra los requerimientos
especificados por el usuario, esta es ejecutada utilizando la técnica de caja negra.
Otro nivel de prueba es la prueba de usuario o UAT, y es realizada por el usuario final del producto
de software con el propósito de validar si el producto de software hace o se comporta
funcionalmente como lo especifico en sus requerimientos iniciales.
Existen otros niveles de prueba y técnicas para desarrollarlas
 Niveles de pruebas unitarias.
Probar código nunca tuvo tanta importancia en el ciclo de desarrollo de una aplicación hasta hace
algunos años, donde se ha desatado una revolución en los procesos de desarrollo, apareciendo
nuevas y ágiles forma de construcción, donde ejecutar pruebas pasó
de ser un proceso tedioso a ser un forma de trabajo integrada y productiva en los nuevos procesos d
e desarrollo.
A pesar de existir diferentes tipos y tácnicas de pruebas, en este articulo hablaremos del uso de
Pruebas Unitarias, pues de todo el

conjunto de pruebas, es considerada la más importante para garantizar un proyecto exitoso, por
tanto debe ser introducida como una actividad más en el desarrollo.
Que son las pruebas unitarias

Son pruebas dirigidas a probar clases java aisladamente y están relacionadas con el código y la
responsabilidad de cada clase y sus fragmentos de código más criticos
Porque Realizar Pruebas Unitarias
 Asegura calidad del código entregado. Es la mejor forma de detectar errores

tempranamente en el desarrollo. No obstante, esto no asegura detectar todos los errores, por
tanto prueba de integración y aceptación siguen siendo necesarias.
 Ayuda a definir los requerimientos y responsabilidades de cada método en cada clase

probada.
 Constituye una buena forma de ejecutar pruebas de concepto. Cuando es necesario

hacer pruebas de conceptos sin integrar usar pruebas unitarias se convierte en un método
efectivo.
 Permite hacer refactoring tempranamente en el código. No es necesario todo un ciclo de

integración para hacer refactoring en la aplicación, basta con ver como se comporta un caso
de prueba para hacer refactoring unitario sobre la clase que estamos probando en cuestión.

 Permite incluso hacer pruebas de estress tempranamente en el código. Por ejemplo un
método que realize una consulta SQL que exceda los tiempos de aceptación es posible
optimizarla antes de integrar con la aplicacíón.
 Permite encontrar errores o bugs tempranamente en el desarrollo. Y está demostrado

que mientras más temprano se corrigan los errores, menos costará corregirlos.
Tema 3.
Plan de Pruebas de Sistema.
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.
¿Te solicitaron elaborar un plan de pruebas de software para tu próximo proyecto o iniciativa?,
pues entonces es recomendable que definas un método para hacerlo y que luego puedas
afinarlo por medio de la mejora continua.
Aquí te compartimos un método para documentar las diferentes secciones del plan de pruebas
de software, incluyendo el alcance, estrategia de pruebas, tipos de pruebas de software a incluir,
criterios de aceptación, requisitos de infraestructura, requisitos de personal y la planificación.
Los 10 pasos para elaborar un plan de pruebas de software.
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.

Además de las preguntas específicas de cada requisito, es importante hacer preguntas del
alcance general, por ejemplo:
¿Es un sistema nuevo o existente?

¿Cuáles funcionalidades existentes están siendo modificadas?
¿Cuáles son los requisitos no funcionales? Entre otras.
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 requisito y desarrollo, debes identificar e incluir en el plan de pruebas de software
la lista de las funcionalidades (Características) totalmente nuevas.
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. (International Software Testing
Qualifications Board)
Pruebas funcionales
Se determinan los conjuntos de pruebas a realizar, correspondiente con cada

funcionalidad nueva o existente que se esté modificando.
Se tienen distintos tipos de pruebas funcionales, por ejemplo, las pruebas de sistema (o
pruebas integradas de sistemas), que se realizan después que el equipo de desarrollo ha
integrado los componentes de distintas capas.
Las pruebas funcionales son definidas por el ISTQB como pruebas basadas en
especificación. Son diseñadas usando técnicas de diseño de pruebas de caja negra.
> Pruebas de caja negra según el ISTQB
> Pruebas de caja negra: Ejemplos
Entre las pruebas funcionales, también están las pruebas de aceptación, en las cuales el equipo
de calidad e inclusive personas del área de negocio o cliente del proyecto verifican el
funcionamiento del sistema o funcionalidad.
Pruebas no funcionales
Se define un conjunto de pruebas no funcionales para cada requisito de este tipo. Aquí se
pueden incluir pruebas sobre el desempeño, tiempo de respuesta, mantenibilidad, Pruebas de
seguridad de software, entre otros aspectos, según la clasificación de requisitos no
funcionales que se tenga para el proyecto.
Pruebas de caja blanca: Según la estructura y arquitectura del software que se esté
desarrollando.
Pruebas de regresión: Se definen sobre las funcionalidades modificadas en sus componentes

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

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 borde será muy difícil, y podría comprometer los
plazos del proyecto, pero asegura la calidad del producto.
Por otra parte, puede ser que la intención sea realizar un Soft Launch, o un mínimo producto
viable, en ese caso se podría definir como criterio de aceptación el 100% de los casos de prueba
principales y 20% de casos de prueba no principales.
Una vez logradas las condiciones, se darán por aceptadas las pruebas y el desarrollo de
software.
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 se procede con la reanudación.
Criterios de suspensión:
Las condiciones van a depender de los acuerdos de nivel de servicio internos de la

organización y también de los acuerdos establecidos en cada proyecto individual.
Por ejemplo, si se tiene un equipo de pruebas que comparte su esfuerzo entre varios proyectos,
se puede definir un criterio de suspensión exigente, un determinado porcentaje de casos fallidos
que resulten en incidencias. Si la condición se cumple, se detienen las pruebas y se dedica el
personal a otras actividades.
Por otra parte si se tiene un equipo de pruebas con personal dedicado, el criterio de suspensión
puede ser poco exigente, por ejemplo solo ocurriendo si se bloquean por incidencia todos los
casos de prueba.
6.- Identificar los entornos (ambientes) requeridos
Posteriormente se definen y documentan las características de los entornos de Hardware

y Software necesarios para realizar la ejecución de las pruebas de software.
Esta información se obtiene a partir del equipo de desarrollo y de los arquitectos de

software, quienes pueden suministrar los requisitos mínimos y óptimos para la operación del
sistema.
Como mejor práctica, el ambiente de pruebas de software debería ser lo más similar posible al
ambiente de producción, sin embargo, no siempre es posible debido a limitaciones de recursos
(financieros). En estos casos debe estudiarse cuales son los requisitos que aseguran un mínimo
de confiabilidad de estas pruebas respecto al entorno de producción.
Además en esta sección del plan de pruebas, también se definen los requisitos de sistemas
operativos, software y herramientas de las estaciones de trabajo de los Testers.
Si el alcance del proyecto incluye pruebas de aplicaciones (Apps) para móviles, es necesario
definir los emuladores y teléfonos inteligentes, con sus respectivos requisitos.
También deben definirse los requisitos de hardware y software para los siguientes componentes:
Herramienta de gestión de calidad de software.
Herramientas para automatización de pruebas.
Herramientas de BDD, TDD y Testing de Web Services.
7.- Determinar necesidades de personal y entrenamiento
Debe completarse previamente la estimación del esfuerzo de pruebas a partir del diseño
de casos de prueba.
Si aún no se cuenta con la estimación, se puede comenzar por definir los tipos de perfiles
de habilidades y conocimientos en Software Testing que se necesitan.
Para ello se puede buscar la respuesta a las siguientes preguntas:
¿Qué conocimientos de procesos de negocio se necesitan?
¿Qué sistemas se están probando y quienes tienen experiencia en su funcionamiento?
¿Se necesitan conocimientos específicos en pruebas de requisitos no funcionales? Por ejemplo

para pruebas de desempeño o estrés.
¿Cuál herramientas de gestión de calidad de software se va a utilizar?
¿Se necesitan conocimientos en herramientas técnicas como Lenguajes de

programación o herramientas de pruebas de webservices?
¿Se necesitan conocimientos en herramientas de pruebas automatizadas?

Requisitos de entrenamiento
Por ejemplo: Transferencia de conocimientos en el sistema y su operación con el área de

negocio.
Formación en metodologías de pruebas de software.
Entrenamiento en tipos de pruebas especializados (desempeño, estrés, arquitectura, caja

blanca).
Formación en automatización de pruebas de software.
8.- Establecer la metodología y procedimientos de prueba
La metodología de pruebas de software dependerá de la que se esté utilizando para la gestión

del proyecto.
Si se está utilizando una metodología predictiva, las pruebas de software comenzaran con la
estimación del esfuerzo de pruebas, diseño y luego la ejecución de las pruebas. Si se están
utilizando metodologías ágiles de desarrollo de software, debe estar alineada con el manifiesto
ágil.
9.- Elaborar la planificación de las pruebas
La planificación de las pruebas abarca:
 Matriz de responsabilidades
Puede usarse una Matriz RACI o Matriz RAM como plantilla. Esta se define con perfiles genéricos
o inclusive con el equipo de trabajo si ya se conoce cuál es el que será asignado.
Las tareas del plan de pruebas deben estar alineadas con las habilidades y conocimientos de
cada persona.
 Cronograma
Elaborado a partir de la estimación de las actividades de Software Testing realizada por el

equipo. Para elaborar un cronograma real, es importante definir actividades críticas como por
ejemplo los tiempos de instalación de versiones en los entornos de pruebas, pruebas de
validación de ambientes antes de comenzar a hacer las pruebas y las iteraciones por incidencias,
que es el tiempo invertido en volver a probar los casos de prueba fallidos.
 Premisas
Son las condiciones que deben cumplirse para que el cronograma sea realizable, estas se
determinan a partir de la documentación de entornos y de los requisitos de personal. Por

ejemplo disponibilidad de ciertos entornos, disponibilidad de personal con algún conocimiento
técnico específico, la metodología que se va a utilizar, premias que deben cumplirse para poder
aplicarla, entre otros.
10.- Identificar los riesgos y definir planes de respuesta
La gestión de riesgos en pruebas es muy similar a la gestión de riesgos en proyectos de la

que hemos escrito en artículos como Las 5 preguntas y respuestas sobre la identificación de
riesgos, así como el artículo sobre Cómo hacer seguimiento de los riesgos del proyecto.
Para el Software Testing, los riesgos por lo general están vinculados con factores como:
 Posibles dificultades en la disponibilidad de entornos.

 Pruebas que dependen de factores externos al proyecto y la organización.
 Disponibilidad de personal con conocimientos especializados en alguna herramienta, o en la
funcionalidad especifica que se está desarrollando.
 Dependencias con otros proyectos.
 Posibilidad que alguna premisa no se cumpla.
Para identificar los riesgos es necesario enumerar cada una de estas dependencias y por medio
de mesas de trabajo y tormentas de ideas pensar en las posibilidades de que algo salga mal (u
oportunidades para que salga bien).
Luego de la identificación, es necesario también definir planes de respuesta, los cuales deben
ser específicos para cada situación particular y riesgo.
Importancia de un plan de pruebas. Objetivos: Los objetivos principales de realizar una

prueba son: Detectar un error. Tener un buen caso de prueba, es decir que tenga más
probabilidad de mostrar un error no descubierto antes. Descubrir un error no descubierto antes
(éxito de la prueba).
Estructura fijada en el estándar

1. Identificador único del documento
2. Introducción y resumen de elementos y características a probar
3. Elementos software a probar
4. Características a probar
5. Características que no se probarán
6. Enfoque general de la prueba
7. Criterios de paso/fallo para cada elemento

8. Criterios de suspensión y requisitos de reanudación
9. Documentos a entregar
10. Actividades de preparación y ejecución de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organización y realización de las pruebas
13. Necesidades de personal y formación
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
16. Aprobaciones y firmas con nombre y puesto desempeñado
- Diseño de planes de prueba. Requerimientos.
- Implementación de planes e pruebas.
Tema 4. “Conceptos de pruebas funcionales y no funcionales”
En primer lugar tenemos las Pruebas Software Funcionales. Típicamente encontraremos el

comportamiento del sistema, subsistema o componente software descrito en especificaciones de
requisitos o casos de uso, aunque también puede no estar documentado (“que funcione como el
sistema al que sustituye”). Es decir, con las funciones establecemos “lo que el sistema hace”.
Estas pruebas se definen a partir de funciones o características (como decimos, bien descritas en
documentos o bien interpretadas por los probadores) y su interoperabilidad con sistemas
específicos, pudiendo ejecutarse en todos los niveles de pruebas (componentes, integración,
sistema, etc.).
Se consideran Pruebas de Caja Negra (“black-box testing”) puesto que valoramos el

comportamiento externo del sistema. Las Pruebas de Seguridad o las Pruebas de
Interoperabilidad entre sistemas o componentes son casos especializados de las pruebas
funcionales.
En segundo lugar figuran las Pruebas Software no Funcionales que incluyen las pruebas
de: Rendimiento, Carga, Estrés, Usabilidad, Mantenibilidad, Fiabilidad o Portabilidad, entre
otras. Por tanto se centran en características del software que establecen “cómo trabaja el

sistema“.
Estas pruebas también pueden ejecutarse en todos los niveles de pruebas. Las características no
funcionales del software se pueden medir de diversas maneras, por ejemplo, por medio de
tiempos de respuesta en el caso de pruebas de rendimiento o por número máximo de sesiones en
pruebas de estrés.
Puesto que las Pruebas software no Funcionales normalmente consideran el comportamiento

externo del sistema, en la mayoría de los casos se utilizan técnicas de Pruebas de Caja Negra.
Tipos de pruebas funcionales:
1. Pruebas de Humo (Smoke Testing o Ad Hoc)
Objetivo de la Prueba: Los objetivos son los siguientes:
 Detectar los errores en realeases tempranos y de manera fácil Probar el sistema

constantemente Garantizar poco esfuerzo en la integración final del sistema
 Asegurar los resultados de las pruebas unitarias Se reducen los riesgos y a baja calidad.

Descripción de la Prueba: Toma éste nombre debido a que su objetivo es 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 tarde en el ciclo de
desarrollo está 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.
Técnica:
1) Realizar una integración de todo el sistema cada cierto periodo (se recomienda un día,
máximo una semana)
2) Realizar los casos de prueba asignados a los casos de uso finalizados ese día más los
realizados en días anteriores
3) Buscar eficientemente errores
Todos los defectos que se identificaron han sido tenidos en cuenta.
Consideraciones Especiales: Cuando se encuentre un error en el release correspondiente al

periodo elegido para hacer las integraciones del sistema, se detiene el desarrollo hasta que el
error es corregido.
Este tipo de pruebas es útil en la programación extrema (extremme programming) y de

sistemas complejos.
Es útil el uso de programas de prueba automáticas que se encarguen de probar os casos de

prueba ya ejecutados en realeases anteriores
Pruebas de regresión
Este servicio esta orientado fundamentalmente a conseguir un conjunto de casos de pruebas
automatizadas que sirvan para realizar pruebas de regresión en futuras entregas. Para generar las
pruebas de regresión es necesario haber ejecutado previamente los servicios de:
Generación y evolución de planes de prueba para disponer del diseño del Plan de Pruebas
Funcional, y por tanto del detalle de los casos de prueba que se van a ejecutar.
Verificación Funcional ya que debe comprobarse que el aplicativo funciona correctamente, y que
los casos de prueba han sido superados con éxito, antes de grabar las pruebas de regresión con
alguna herramienta.
Se debe observar que no en todos los casos, la automatización de las pruebas resulta ventajoso.
Por este motivo es importante que en la etapa inicial de la ejecución de este servicio se realice un
análisis del coste en la automatización de las pruebas y del coste que posteriormente va a
suponer su reutilización. En algunos casos este estudio también nos permite elegir los casos de
prueba mas ventajosos para la automatización. El conjunto de pruebas que se van a automatizar
resultará elegido teniendo en cuenta el análisis anterior y los requisitos funcionales del sistema.
Posteriormente, la ejecución del servicio continúa con la grabación de las pruebas, a través de una
herramienta elegida para este fin. Por último, las pruebas son guardadas para su posterior
utilización.
Condiciones del servicio

Acceso a la aplicación en un entorno con completa disponibilidad para poder efectuar las pruebas
requeridas.
Publicación de los entregables documentales necesarios en la herramienta de Gestión Documental.
Existencia de un Plan de Pruebas Funcional, por lo que este servicio deberá ejecutarse siempre de
forma posterior al de Generación y Evolución de Planes de Prueba.
Constancia de que el aplicativo funciona correctamente antes de proceder a la grabación de las

pruebas, por lo que este servicio deberá ejecutarse siempre de forma posterior al de Verificación
Funcional.

Equipo de Testing
Entradas/Salidas
Entradas
Documento de definición de los requisitos del sistema
Documento Plan de Pruebas Funcionales
Software desplegado en el entorno donde se van a efectuar las pruebas
Salidas
Escenarios de Regresión grabados en la herramienta de edición de test
Dimensionamiento
Para la valoración de este servicio se tienen en cuenta las siguientes actividades:
Verificación de Pruebas de Regresión.
Elaboración del informe de automatización de las pruebas
Actividad Dimensionamiento
La valoración de esta parte es

Verificación de Pruebas de Regresión
fija
Elaboración del informe de

automatización
» Pruebas de aceptación
Independientemente de que se haya tercerizado el proceso de pruebas y así la firma

responsable de estas actividades haya emitido un certificado de calidad sobre el sistema objeto
de prueba, es indispensable, que el cliente designe a personal que haga parte de los procesos de
negocio para la ejecución de pruebas de aceptación, es incluso recomendable, que los usuarios
finales que participen en este proceso, sean independientes al personal que apoyó el proceso de
desarrollo. Cuando las pruebas de aceptación son ejecutadas en instalaciones o ambientes
proporcionados por la firma desarrolladora se les denominan pruebas Alpha, cuando son
ejecutadas desde la infraestructura del cliente se les denomina pruebas Beta. En los casos en que
las pruebas de aceptación del producto se hayan ejecutado en el ambiente del proveedor, el
aplicativo no podrá salir a producción, sin que se hayan ejecutados las respectivas pruebas Beta

en el ambiente del cliente, de lo anterior es importante concluir, que las pruebas Alpha son
opcionales, pero las pruebas Beta son obligatorias .
» Alpha testing- Beta testing.
Cuando se construye software a medida para un cliente, se lleva a cabo una serie
de pruebas de aceptación para permitir que el cliente valide todos los requisitos. La mayoría de
los desarrolladores de productos de software llevan a cabo un proceso denominado pruebas alfa
y beta para descubrir errores que parezca que sólo el usuario final puede descubrir.
 Prueba alfa: se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de
forma natural con el desarrollador como observador del usuario y registrando los errores
y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado.
Prueba beta: se llevan a cabo por los usuarios finales del software en los lugares de trabajo
de los clientes. A diferencia de la prueba alfa, el desarrollador no está presente normalmente. Así,
la prueba beta es una aplicación en vivo del software en un entorno que no puede ser controlado
por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta
e informa a intervalos regulares al desarrollador.
Tipos de pruebas No funcionales:

10 tipos de pruebas no funcionales
Las pruebas no funcionales se enfocan en validar un sistema o aplicación por medio de

sus requerimientos no funcionales, es decir, la forma en que el sistema funciona y no por medio
de comportamientos específicos.
Las características no funcionales de un sistema o aplicación con frecuencia se cuantifican en

escalas variables, como por ejemplo los tiempos de respuesta en pruebas de desempeño.
El ISTQB establece que la omisión de las pruebas no funcionales puede ocasionar problemas de
calidad potencialmente catastróficos luego de la salida a producción, sin embargo, estos tipos de
pruebas son costosos, por lo que deben evaluarse los riesgos antes de comprometer los recursos
del proyecto.
A continuación te presentamos una lista no limitativa de 10 tipos de pruebas no funcionales que

puedes incluir en tu plan de pruebas de software.

1. - Pruebas de carga: Las pruebas de carga consisten en simular demanda sobre una aplicación
de software y medir el resultado. Estas pruebas se realizan bajo demanda esperada y también en
condiciones de sobrecarga (picos en la demanda). Para ejecutar estas pruebas, se requiere del uso
de herramientas que simulen la carga, como por ejemplo SoapUI.
Las pruebas de carga ayudan a identificar la máxima capacidad operativa de una aplicación, así
como en el identificar cuellos de botella y las causas de posible degradación del desempeño.
Cuando la carga de prueba se eleva por encima de los parámetros esperados, a estas pruebas se
les conoce como pruebas de estrés.
2. - Pruebas de estrés: Son pruebas de carga que se realizan con demandas mayores a la
capacidad operativa, con frecuencia hasta llegar al punto de ruptura.
Este tipo de prueba de software se utiliza para determinar la estabilidad de un sistema o

aplicación, con especial atención en la disponibilidad y manejo de errores cuando se enfrenta a la
sobrecarga.
Al igual que para las pruebas de carga, se requieren de herramientas que simulen la demanda,
SoapUI es una de estas herramientas que permite simular peticiones para servidores de
aplicaciones web. Con las pruebas de estrés se pueden identificar los puntos de ruptura, límites
para uso seguro de la aplicación, confirmar las especificaciones de diseño, identificar las formas
en que el sistema falla, entre otros aspectos.
3. - Pruebas de volumen: Las pruebas de volumen consisten en validar el funcionamiento de la

aplicación con ciertos volúmenes de datos. Por ejemplo, si se quiere ver el comportamiento de
una aplicación con un tamaño de base de datos específico, se expande el tamaño de base de
datos a dichos parámetros y luego e realizan consultas, procesos o funcionalidades de la
aplicación, midiendo su desempeño.
El sujeto de pruebas no está limitado a bases de datos, también se puede usar por ejemplo para
medir el desempeño de una interfaz cuando el archivo de interfaz (un archivo de texto, xml, etc.)
supera cierto tamaño.
El objetivo es ver si dado ciertos volúmenes de datos la aplicación funciona con normalidad,
cuales son los límites máximos de volúmenes de datos para la operación e identificar condiciones
de falla.
4. - Pruebas de configuración: En lugar de probar el desempeño de una aplicación desde la

perspectiva de la carga, las pruebas de configuración se usan para validar que efectos en el
desempeño tienen ciertos cambios en la configuración.
Un ejemplo típico de esta situación es experimentar con diferentes métodos de balanceo de

cargas y ver la respuesta de la aplicación a niveles similares de sobrecarga.

Otro ejemplo es verificar si el sistema es capaz de funcionar adecuadamente en diferentes
versiones o configuraciones de entornos de hardware y software, como pueden ser diversos
navegadores de internet, versiones de navegadores, entre otros.
5. - Pruebas de usabilidad: En las pruebas de usabilidad, los testers de software se enfocan en

validar que tan fácil de usar es una determinada aplicación. Las características evaluadas en la
usabilidad incluyen:
 Facilidad de aprendizaje: Que tan fácil es para los usuarios realizar funciones básicas la
primera vez que utilizan la aplicación.
 Eficiencia: Que tan rápido los usuarios experimentados pueden realizar sus tareas.
 Memorización: Que tan fácil de memorizar es el uso de la aplicación, esto es, cuando un
usuario pasa mucho tiempo sin usar la aplicación, puede recordar lo suficiente para usarla con
efectividad la próxima vez, o tiene que empezar a aprender de nuevo.
 Errores: Cuantos errores atribuibles al diseño comete el usuario, que tan severos son y que
tan fácil es recuperarse de los mismos.
 Satisfacción: Que tanto le gusta (o desagrada) al usuario utilizar el sistema.
6. - Pruebas de seguridad: Consiste en probar los atributos o características de seguridad del

sistema, si es un sistema seguro o no, si puede ser vulnerado, si existe control de acceso por
medio de cuentas de usuario, si pueden ser vulnerados estos accesos.
Las pruebas de seguridad también sirven para validar si el equipo de desarrollo de software ha
seguido prácticas de seguridad recomendadas en su programación. Entre las características de
seguridad de un sistema, están la confidencialidad, integridad, autenticación, autorización y la
disponibilidad.
7. - Pruebas de resistencia: Las pruebas de resistencia implican someter a un Sistema o aplicación

a una carga determinada durante un período de tiempo, para determinar cómo se comporta
luego de un uso prolongado.
Un sistema informático puede comportarse de forma normal durante las primeras horas, sin
embargo, luego de cierto tiempo, problemas como fugas de memoria suelen ocasionar fallas.
Estos defectos en el desarrollo de software no pueden identificarse bajo pruebas funcionales

normales, por lo que es conveniente involucrar pruebas de resistencia entre los tipos de pruebas
de software.
8. - Pruebas de escalabilidad: Las pruebas de escalabilidad consisten en verificar la capacidad de

una aplicación de escalar cualquiera de sus características no funcionales, como por ejemplo la
carga que soporta, número de transacciones, volúmenes de datos, entre otros.

Al diseñar casos de prueba de escalabilidad, es recomendable considerarlos en bloques
incrementales, dada la dificultad de predecir la carga real que tendrá una aplicación luego de
implementada en producción.
Probar en bloques incrementales significa por ejemplo primero probar con niveles de demanda
bajos, luego incrementar a niveles de demanda medios y finalmente probar con altos niveles de
carga. De esta manera se puede determinar que también escala la aplicación y los problemas que
comienzan a surgir en distintos niveles.
Para que los resultados sean confiables, los ambientes de prueba y su configuración deben
mantenerse constantes.
9. - Pruebas de recuperación: Las pruebas de recuperación se realizan para verificar que tan
rápido y que tan bien se recupera una aplicación luego de experimentar un falló de hardware o
software.
Por lo tanto, para realizar pruebas de recuperación se requiere forzar la falla y luego verificar si la
recuperación ocurre adecuadamente.
Por ejemplo, cuando una aplicación esté funcionando desconectar el cable de red, o en
una aplicación móvil interrumpir la conexión con la red Wi-Fi o con la operadora, para luego
restablecer la conexión.
10. - Pruebas de mantenibilidad: Básicamente consisten en evaluar que tan fácil es realizar el
mantenimiento de un sistema o aplicación. Esto significa que tan fácil es analizar, cambiar y
probar estos cambios.
Para realizar esta prueba deben evaluarse la forma en que está implementada la aplicación,
siguiendo buenas prácticas de ingeniería de software. Es decir, que se estén siguiendo los
patrones recomendados de ingeniería de software y que no se estén introduciendo
inadvertidamente anti patrones, esto es, que no se estén cometiendo errores comunes de
programación.

IV.-Resumen de la unidad

V.- Bibliografía de la unidad
 Piattini (2007) (Cap 10) Piattini (2007). (Cap. 10)

 Sommerville (2005). (Capítulo 22 y 23)
 Jacobson, , , , g, ( ) I., Booch, G., and Rumbaugh, J. (2000): El Proceso Unificado de Desarrollo.
Addison-Wesley. (Capítulo 11)
 Pressman, R. (2005): Ingeniería del Software: Un Enfoque Práctico. 6º Edición. McGraw
Edición. McGraw-Hill. (Capítulos 13 y 14) Hill. (Capítulos 13 y 14)
 Pfleeger (2002). (Caps. 7, 8 y 9)
 IEEE Computer Society (2004). SWEBOK - Guide to the Software E i i B d f K l d 2004 (C ít l 4 5)
Engineering Body of Knowledge, 2004. (Capítulos 4 y 5) http://www.swebok.org/

Unidad 2B

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Unidad 2B

Diunggah oleh

Hak Cipta:

Format Tersedia

Unidad 2

Desarrollo y ejecución de casos de prueba

Los aprendizajes esperados para esta unidad son:

 Caracterizan el concepto de prueba de sistema y su importancia dentro del

II.-Listado de Contenidos de la unidad

 Concepto de pruebas de sistema.

 Crecimiento de uso de un software.

 Concepto de plan de pruebas de sistema.

 Conceptos de pruebas funcionales y no funcionales.

Instituto Profesional AIEP. Educación Online 2016

 Principios Fundamentales del Proceso de Pruebas

5 Principios fundamentales, para los equipos o personas que incursionan en metodologías de

2. El proceso no puede demostrar la ausencia de defectos: independientemente de la

Instituto Profesional AIEP. Educación Online 2016

5. Ejecución de pruebas bajo diferentes condiciones: en un plan de pruebas, siempre existe

Instituto Profesional AIEP. Educación Online 2016

Realizar pruebas dinámicas a un producto de software, suele en la mayoría de los casos

Para procesos de desarrollo basados en la metodología RUP o métodos tradicionales,

1. Planeación de Pruebas: Es la etapa en donde se ejecutan las primeras actividades

Instituto Profesional AIEP. Educación Online 2016

3. Implementación y Ejecución de Pruebas: la ejecución de pruebas debe iniciar con la creación

Instituto Profesional AIEP. Educación Online 2016

Concepto de pruebas de sistema.

Al Implantar un Sistema de Información lo primero que debemos hacer es asegurarnos que el

Existen varios enfoques de Implementación:

• Es darle responsabilidad a los grupos.

Instituto Profesional AIEP. Educación Online 2016

En la preparación de la Implantación, aunque el Sistema esté bien diseñado y desarrollado

Niveles de Prueba del Software

A continuación una breve descripción de cada nivel de prueba:

Instituto Profesional AIEP. Educación Online 2016

Instituto Profesional AIEP. Educación Online 2016

Instituto Profesional AIEP. Educación Online 2016

Instituto Profesional AIEP. Educación Online 2016

Técnica: Comparar el resultado esperado con el resultado obtenido.

Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas.

Consideraciones Especiales: Para la elaboración de pruebas unitarias en java se puede utilizar el

Objetivo de la Prueba: Identificar errores introducidos por la combinación de programas

Instituto Profesional AIEP. Educación Online 2016

Consideraciones Especiales: Ninguna

Técnica: La prueba de regresión es una nueva corrida de casos de prueba previos.

Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas.

Consideraciones Especiales: Ninguna

Pruebas de Humo (Smoke Testing o Ad Hoc)

Objetivo de la Prueba: Los objetivos son los siguientes:

 Detectar los errores en realeases tempranos y de manera fácil

Instituto Profesional AIEP. Educación Online 2016

Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas.

Consideraciones Especiales: Cuando se encuentre un error en el release correspondiente al

PRUEBAS DEL SISTEMA

Pruebas del Sistema

Instituto Profesional AIEP. Educación Online 2016

La prueba de sistema es compleja porque intenta validar un número de características al mismo

 Los resultados esperados ocurren cuando se utiliza un dato válido.

Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas.

Consideraciones Especiales: Identifique o describa aquellos aspectos (internos o externos) que

Instituto Profesional AIEP. Educación Online 2016

Objetivo de la Prueba: Validar el tiempo de respuesta para las transacciones o funciones de

 Volumen normal anticipado

Descripción de la Prueba: Las pruebas de desempeño miden tiempos de respuesta, índices de

Las principales actividades son:

Instituto Profesional AIEP. Educación Online 2016

Técnica: Use los scripts desarrolladas para Pruebas del Negocio.

Instituto Profesional AIEP. Educación Online 2016