Professional Documents
Culture Documents
¡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.
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.
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.
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.
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.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
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.
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.
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.
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.
» PRUEBAS DE INTEGRACIÓN
Prueba de Integración
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
Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas. Todos los defectos
que se identificaron han sido tenidos en cuenta.
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.
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
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.
- 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.
Técnica: Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos,
para verificar que:
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
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).
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).
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.
Para probar recursos limitados, las pruebas se deben correr en un servidor con configuración
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
Consideraciones Especiales: ¿Qué período de tiempo debería considerarse como aceptable para
condiciones de volumen alto?
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
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.
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
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
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.
Técnica: Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las funciones y datos
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:
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.
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.
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.
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.
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.
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#.
» 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.
» 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
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.
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.
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.
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.
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:
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.
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.
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.
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:
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.
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:
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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.
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.
» Técnicas combinatorias
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.
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
» 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
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.
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.
Otro nivel de prueba es la prueba funcional, es preparada y ejecutada por un grupo independiente
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.
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
Tema 3.
¿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.
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.
Si estás trabajando con un sistema informático nuevo, no tendrás problemas en discernir, pues
todas serán nuevas.
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.
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 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.
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.
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.
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.
Criterios de suspensión:
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.
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:
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.
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.
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
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
Para el Software Testing, los riesgos por lo general están vinculados con factores como:
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.
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
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.).
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
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.
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
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.
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.
Entradas/Salidas
Entradas
Salidas
Dimensionamiento
Para la valoración de este servicio se tienen en cuenta las siguientes actividades:
Actividad Dimensionamiento
» Pruebas de aceptación
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.
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.
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.
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.
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.
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.
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.
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.
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.