Automatización de pruebas de software.

Las pruebas automatizadas constituyen una necesidad casi absoluta en los proyectos que impliquen la creación y desarrollo de software, estas incluyen una amplia gama de beneficios que no están disponibles para las pruebas manuales.

En la actualidad existe una gran variedad de herramientas para realizar pruebas automatizadas. Estas proporcionan una ventaja evidente partiendo de tiempo y conservación de los recursos, sin comprometer la calidad del procedimiento de prueba, la exactitud de los informes finales y la eficiencia del proceso de pruebas, son efectivas y económicamente factibles. El uso de las mismas permite tener más comodidad en la elaboración de los errores y fallos que se producen antes de que el producto de software es liberado, o en momentos en que hay una necesidad de proporcionar asistencia al cliente para resolver los defectos encontrados.

Las pruebas automatizadas han mejorado enormemente el proceso básico de perfeccionamiento de aplicaciones web y sus beneficios se encuentran disponibles para desarrolladores. A continuación se citan algunas de sus ventajas:

• Confiables: Las pruebas realizan con exactitud diversas operaciones cada vez que se ejecutan, de tal modo que evita posibles errores humanos.
• Recursivas: Evidencian cómo el software reacciona bajo diferentes condiciones, cuando se está probando una misma operación repetidamente.
• Programables: Permiten programar pruebas sofisticadas que pongan en evidencia la robustez del software que se pruebe.
• Abarcadoras: Facilitan la construcción de un ambiente de pruebas que cubra cada característica del software.
• Reutilizables: Permite reutilizar pruebas en diversas versiones.
• Factibles: Se pueden ejecutar más pruebas en menos tiempo y el número de los recursos se reduce.
• Rápidas: Su ejecución es perceptiblemente más rápida.
• Flexibles: Las pruebas deben ser fáciles de entender, de modificar y de extender.

Las pruebas automatizadas se ejecutan mediante el empleo de herramientas que facilitan las tareas de un probador de software.

lgunas pruebas de software tales como las pruebas de regresión intensivas de bajo nivel pueden ser laboriosas y consumir mucho tiempo para su ejecución si se realizan manualmente. Adicionalmente, una aproximación manual puede no ser efectiva para encontrar ciertos tipos de defectos, mientras que las pruebas automatizadas ofrecen una alternativa que lo permite. Una vez que una prueba ha sido automatizada, ésta puede ejecutarse repetitiva y rápidamente en particular con productos de software que tienen ciclos de mantenimiento largo, ya que incluso cambios relativamente menores en la vida de una aplicación pueden inducir fallos en funcionalidades que anteriormente operaban de manera correcta. Existen dos aproximaciones a las pruebas automatizadas:

• Pruebas manejadas por el código: Se prueban las interfaces públicas de las clases, módulos o bibliotecas con una variedad amplia de argumentos de entrada y se valida que los resultados de obtenidos sean los esperados.
• Pruebas de Interfaz de Usuario: Un marco de pruebas genera un conjunto de eventos de la interface de usuario, tales como teclear, hacer click con el ratón e interactuar de otras formas con el software y se observan los cambios resultantes en la interface de usuario, validando que el comportamiento observable del programa sea el correcto.

La elección misma entre automatización y ejecución manual de pruebas, los componentes cuya prueba será automatizada, las herramientas de automatización y otros elementos son críticos en el éxito de las pruebas, y por lo regular deben provenir de una elección conjunta de los equipos de desarrollo, control de calidad y administración. Un ejemplo de mala elección para automatizar, sería escoger componentes cuyas características son inestables o su proceso de desarrollo implica cambios continuos.

En el desarrollo contemporáneo de software existe una tendencia creciente a usar Frameworks como los denominados XUnit (por ejemplo JUnit y NUnit) que permiten la ejecución de pruebas unitarias para determinar cuándo varias secciones del código se comportan como es esperado en circunstancias específicas. Los casos de prueba describen las pruebas que han de ejecutarse sobre el programa para verificar que éste se ejecuta tal y como se espera. La automatización de pruebas es una característica clave del desarrollo ágil de software en donde se le conoce como "desarrollo guiado por pruebas". En ellas, las pruebas unitarias se escriben antes que el código que genera la funcionalidad. Sólo cuando el código pasa exitosamente las pruebas se considera completo. Cuando hay cambios, el programador descubre inmediatamente cualquier defecto que rompa los casos de prueba lo cual baja el costo de la reparación. Dos inconvenientes de este estilo de trabajo son:

1. Algunas veces se "desperdicia" la capacidad del programador escribiendo las pruebas unitarias. El entrecomillado se debe precisamente que asegurar la calidad del producto no es desperdicio alguno.
2. Normalmente se prueban los requerimientos básicos o el flujo normal del caso de uso en vez de todos los flujos alternativos, dado que extender las pruebas más allá de la prueba base eleva el costo del producto. En algunas ocasiones los flujos alternativos son probados por un equipo de pruebas más o menos independiente del equipo de desarrollo.

Muchas herramientas de automatización de pruebas proveen características para grabar y reproducir acciones del usuario para posteriormente ejecutarlas un número indefinido de veces, comparando resultados obtenidos con resultados esperados. La ventaja de ésta aproximación a la automatización es que requiere de menos desarrollo de software, sin embargo el confiar en éstas características del software lo hace menos confiable en la medida que muchas veces dependen de la etiqueta o posición del elemento de interfaz, y, al cambiar, el caso de prueba debe ser adaptado al cambio o probablemente fallar. Una variante de estas pruebas es la prueba de sistemas basados en la web en las que la herramienta de prueba ejecuta acciones sobre el navegador e interpreta el HTML resultante. Una variación más es la automatización sin scripts, que no usa grabación y reproducción de acciones sino que construye un modelo de la Aplicación Bajo Prueba (AUT en sus siglas en inglés, ABP) que permite a la persona que prueba ("tester") que cree pruebas simplemente editando parámetros y condiciones.

Data-driven testing

Una vez teniendo el script para prueba automatizada, con poco esfuerzo más podemos obtener mucho más beneficio de esta misma nave. En este caso, podemos parametrizar la prueba y hacer que cada valor ingresado en cada campo sea tomado de un data pool (fuente de datos de prueba, tal como una tabla o archivo), y así estar probando distintos escenarios.

 Nuestros datos de prueba necesitan pueden ser una tabla con las siguientes columnas, que corresponden a los campos de la forma de registro de cliente: First_Name, Last_Name, Country_Name, City_Name, Address, Balance.

 Entonces tendremos un datapool con estas columnas. Luego podremos pensar distintas combinaciones de valores para probar. Por ejemplo, valores nulos, o valores muy grandes, strings muy largos, balances negativos, etcétera. Así, la misma prueba la puedo ejecutar con todas las combinaciones de datos que se me ocurran con tan solo ingresar los valores en una tabla. Esta ejecución la puedo hacer cada vez que se necesite, obteniendo información sobre el estado de la aplicación en forma casi inmediata.

 Si esta prueba la tuviera que ejecutar en forma manual con cada dato de prueba interesante, me llevaría más tiempo que ejecutarla automáticamente. O sea, los beneficios de este caso de prueba automatizado se ven directamente en este ciclo de pruebas, y no recién en el siguiente ciclo de pruebas de regresión. Son beneficios a corto plazo, con lo cual, visto de esta forma, es muy conveniente comenzar a automatizar.

 De acuerdo a lo que cuenta Cem Kaner en uno de sus artículos automatizar una prueba lleva entre 3 y 10 veces más que ejecutarla en forma manual (este artículo es de 1997, pero es aún vigente, o en tal caso, el costo es menor). Incluso, si en los siguientes ciclos de prueba tenemos cierto costo de mantenimiento de estos casos de prueba, imaginemos que también de 10 veces más que el costo de ejecución manual, también obtendremos beneficios si ejecutamos 11 veces la prueba de regresión.

Pruebas de validación

Pruebas de validación

 

La validación se logra cuando el software funciona de acuerdo a las expectativas del cliente.

La validación seconsigue mediante una serie de pruebas de la caja negra que demuestran la conformidad con los requisitos. Si aparecen deficiencias, hay que negociar con el cliente un método para resolverlas.

La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el software de manera natural, con el encargado de desarrollo "mirando por encima del hombro" del usuario" y registrando errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entrono controlado.

La prueba beta se lleva a cabo en uno o más lugares de clientes por los usuarios finales del software. A diferencia de la prueba alfa, el encargado de desarrollo, normalmente, no está presente. 
La prueba beta es una aplicación "en vivo" del software en un entrono que no puede ser controlado por el equipo de desarrollo. El cliente registra todos los problemas (reales o imaginarios) que encuentra y los informa a intervalos regulares. 
Como resultado, el equipo de desarrollo lleva a cabo modificaciones y así prepara una versión del producto para toda la base de clientes.

Técnica de Análisis de Valor Límite - Pruebas de Caja Negra

Esta técnica complementa a la de partición equivalente.

En lugar de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la elección de casos de prueba "en los bordes" de la clase. 

En vez de centrarse solamente en las condiciones de entrada, el AVL deriva casos de prueba también para el campo de salida.

1. Si una condición de entrada especifica un rango delimitado por los valores a y b, se deben diseñar casos de prueba para los valores a y b y para valores justo por debajo y justo por encima de a y b, respectivamente.

2. Si una condición de entrada especifica un número de valores, se deben desarrollar casos de prueba que ejerciten los valores máximo y mínimo. 

También se deben probar los valores justo por debajo del máximo y del mínimo.

3. Aplicar las directrices 1 y 2 a las condiciones de salida. 

Por ejemplo, supongamos que se requiere una tabla como salida deun programa, entonces se deben diseñar casos de prueba que creen un informe de salida que produzca el máximo ( y el mínimo) número permitido de entradas en la tabla.
 

4. Si las estructuras de datos internas tienen límites preestablecidos(por ejemplo, un arreglo de 100 entradas) hay que asegurarse de diseñar un caso de prueba que ejercite la estructura de datos en sus límites.

Técnica de Particion Equivalente - Pruebas de Caja Negra

Una partición equivalente es una técnica de prueba de Caja Negra que divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.
El diseño de estos casos de prueba para la partición equivalente se basa en la evaluación de las clases de equivalencia.

El diseño de casos de prueba para la partición equivalente se basa en una evaluación de las clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada.

Regularmente, una condición de entrada es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica.

Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices: Si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.

Si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.

Si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de él.

Si una entrada es booleana, hay 2 clases: si o no.

Los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases.

Aplicando estas directrices se ejecutan casos de pruebas para cada elemento de datos del campo de entrada a desarrollar. Los casos se seleccionan de forma que ejerciten el mayor número de atributos de cada clase de equivalencia a la vez.

Para aplicar esta técnica de prueba se tienen en cuenta los siguientes pasos:

• Primero se deben identificar las clases de equivalencia lo cual se hace tomandocada condición de entrada y aplicándole las directrices antes expuestas.

Para definir las clases de equivalencia hace falta tener en cuenta un conjunto de reglas: Si una condición de entrada especifica un rango, entonces se confeccionan una clase de equivalencia válida y 2 inválidas. Si una condición de entrada especifica la cantidad de valores, identificar una clase de equivalencia válida y dos inválidas.
Si una condición de entrada especifica un conjunto de valores de entrada y existen razones para creer que el programa trata en forma diferente a cada uno de ellos, identificar una clase válida para cada uno de ellos y una clase inválida.
Si una condición de entrada especifica una situación de tipo “debe ser”, identificar una clase válida y una inválida.
Si existe una razón para creer que el programa no trata de forma idéntica ciertos elementos pertenecientes a una clase, dividirla en clases de equivalencia menores.

• Luego de tener las clases válidas e inválidas definidas, se procede a definir los casos de pruebas, pero para ello antes se debe haber asignado un identificador único a cada clase de equivalencia.

• Luego entonces se pueden definir los casos teniendo en cuenta lo siguiente:

1. Escribir un nuevo caso de cubra tantas clases de equivalencia válidas no cubiertas como sea posible hasta que todas las clases de equivalencia hayan sido cubiertas por casos de prueba.
2. Escribir un nuevo caso de prueba que cubra una y solo una clase de equivalencia inválida hasta que todas las clases de equivalencias inválidas hayan sido cubiertas por casos de pruebas.

Con la aplicación de esa técnica se obtiene un conjunto de pruebas que reduce el número de casos de pruebas y nos dicen algo sobre la presencia o ausencia de errores. A menudo se plantea que las pruebas a los software nunca terminan, simplemente se transfiere del desarrollador al cliente. Cada vez que el cliente usa el programa está llevando a cabo una prueba.

Aplicando el diseño de casos de pruebas al software en cuestión se puede conseguir una prueba más completa y descubrir y corregir el mayor número de errores antes de que comiencen las “pruebas del cliente”. 

Como ejemplo, consideremos los datos contenidos en una aplicación de automatización bancaria. Este software acepta datos en la siguiente forma:
Código de área: En blanco ó un número de 3 dígitos
Prefijo: Número de 3 dígitos que no comience por 0 ó 1
Sufijo: Número de 4 dígitos
Contraseña: Vvalor alfanumérico de 6 dígitos
Ordenes: "Comprobar", "Depositar","Pagar factura", etc.

Las condiciones de entrada relacionadas con cada elemento de la aplicación bancaria se pueden especificar como:
Código de área: Condición de entrada lógica - el código de área puede estar o no presente
Condición de entrada rango - valores definidos entre 200 y 999
Prefijo: Condición de entrada rango - valor especificado > 200
Sufijo: Condición de entrada valor- longitud de 4 dígitos
Contraseña: Condición de entrada lógica - la palabra clave puede estar o no presente
Condición de entrada valor - cadena de seis caracteres
Orden: Condición de entrada conjunto, contenida en las órdenes listadas anteriormente.

Los casos de prueba se seleccionan de manera que se ejercite el mayor número de atributos de cada clase de equivalencia a la vez.

Técnica de Prueba de bucles - Pruebas de Caja Blanca

Los bucles son la piedra angular de la mayoría de los algoritmos implementados en software. La prueba de bucles es una técnica de prueba de caja blanca que centra su punto de atención en la validez de las construcciones de bucles.
 

A) Bucles simples: Se les debe aplicar el siguiente conjunto de pruebas, donde n es el número máximo de pasos permitidos para el bucle:
1. Pasar por alto totalmente el bucle
2. Pasar una sola vez por el bucle
3. Pasar dos veces por el bucle
4. Hacer m pasos por el bucle con m < n
5. Hacer n-1, n y n+1 pasos por el bucle

B) Bucles anidados
1. Comenzar por el bucle más interior. Establecer los demás bucles en sus valores mínimos.
 

2. Llevar a cabo las pruebas de bucles simples para el bucle más interior, mientras se mantienen los parámetros de iteración.

Por ejemplo. Contadores de bucles, de los bucles externos en sus valores mínimos. Añadir otras pruebas para valores fuera de rango o excluídos.
 

3. Progresar hacia fuera, llevando a cabos pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mínimos y los demás bucles anidados en sus valores "típicos".
 

4. Continuar hasta que se hayan probado todos los bucles.

C) Bucles concatenados: Se pueden probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto (si el contador del bucle 1 se usa como valor inicial del bucle 2 entonces los bucles no son independientes)

D) Bucles no estructurados: Esta clase de bucles se deben rediseñar para que se ajusten a las construcciones de la programación estructurada.

Técnica de Prueba de condiciones - Pruebas de Caja Blanca

La prueba de condiciones es un método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el módulo de un programa. Se basa en el criterio de que si un conjunto de pruebas de un programa P es efectivo para detectar errores en las condiciones que se encuentran en P, es probable que el conjunto de pruebas sea también efctivo para detectar otros errores en el programa P.

Para una expresión relacional de la forma:

E1 <operador relacional> E2

se requieren tres pruebas: el valor de E1 mayor, menor o igual que el de E2. La prueba que haga el valor de E1 mayor o menor que el de E2 debe hacer que la diferencia entre estos dos valores sea lo más pequeña posible.

Si la expresión es de la forma B1 & B2 donde B1 y B2 son variables lógicas, esta se cubre para B1 verdadero y B2 falso, B1 falso y B2 verdadero y ambos B1 y B2 verdadero.

Pruebas de Caja Blanca

La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del software puede obtener casos de prueba que:

1. Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
3. Ejecuten todos los bucles en sus límites operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su validez.

Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más importantes que se le aplican a los software, logrando como resultado que disminuya en un gran porciento el número de errores existentes en los sistemas y por ende una mayor calidad y confiabilidad.

Técnica de Camino básico

La prueba del camino básico es una técnica de prueba de la Caja Blanca propuesta por Tom McCabe.

Esta técnica permite obtener una medida de la complejidad lógica de un diseño y usar esta medida como guía para la definición de un conjunto básico.

La idea es derivar casos de prueba a partir de un conjunto dado de caminos independientes por los cuales puede circular el flujo de control. Para obtener dicho conjunto de caminos independientes se construye el Grafo de Flujo asociado y se calcula su complejidad ciclomática. Los pasos que se siguen para aplicar esta técnica son:

1. A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.
2. Se calcula la complejidad ciclomática del grafo.
3. Se determina un conjunto básico de caminos independientes.
4. Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico.

Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.

Técnica de Notación de Grafo de Flujo

Para aplicar la técnica del camino básico se debe introducir una sencilla notación para la representación del flujo de control, el cual puede representarse por un Grafo de Flujo. Cada nodo del grafo corresponde a una o más sentencias de código fuente. Todo segmento de código de cualquier programa se puede traducir a un Grafo de Flujo. Para construir el grafo se debe tener en cuenta la notación para las instrucciones. Un Grafo de Flujo está formado por 3 componentes fundamentales que ayudan a su elaboración, comprensión y nos brinda información para confirmar que el trabajo se está haciendo adecuadamente.

Los componentes son:

Nodo

Cada círculo representado se denomina nodo del Grafo de Flujo, el cual representa una o más secuencias procedimentales. Un solo nodo puede corresponder a una secuencia de procesos o a una sentencia de decisión. Puede ser también que hallan nodos que no se asocien, se utilizan principalmente al inicio y final del grafo.

Aristas

Las flechas del grafo se denominan aristas y representan el flujo de control, son análogas a las representadas en un diagrama de flujo. Una arista debe terminar en un nodo, incluso aunque el nodo no represente ninguna sentencia procedimental.

Regiones

Las regiones son las áreas delimitadas por las aristas y nodos. También se incluye el área exterior del grafo, contando como una región más. Las regiones se enumeran. La cantidad de regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un programa.

Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo. Cuando en un diseño se encuentran condiciones compuestas (uno o más operadores AND, NAND, NOR lógicos en una sentencia condicional), la generación del grafo de flujo se hace un poco más complicada.

Técnica Complejidad Ciclomática

La complejidad ciclomática es una métrica de software extremadamente útil pues proporciona una medición cuantitativa de la complejidad lógica de un programa. El valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condición. El camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente.

Herramientas para pruebas de Software

Actualmente el número de herramientas para pruebas de software disponibles, tanto en el mercado como de manera gratuita (herramientas de código abierto), es muy amplio.
En el siguiente listado verás las más importantes.
Tenemos las siguientes categorías según sean herramientas open source (gratuítas) o herramientas comerciales (de pago).

1. Herramientas de gestión de pruebas
2. Herramientas para pruebas funcionales
3. Herramientas para pruebas de carga y rendimiento.

Herramientas Open Source:
1) Herramientas de gestión de pruebas

• Bugzilla Testopia
• FitNesse
• qaManager
• qaBook
• RTH (open source)
• Salome-tmf
• Squash TM
• Test Environment Toolkit
• TestLink
• Testitool
• XQual Studio
• Radi-testdir
• Data Generator

2) Herramientas para pruebas funcionales

• Selenium
• Soapui
• Watir (Pruebas de aplicaciones web en Ruby)
• WatiN (Pruebas de aplicaciones web en .Net)
• Capedit
• Canoo WebTest
• Solex
• Imprimatur
• SAMIE
• ITP
• WET
• WebInject

3) Herramientas para pruebas de carga y rendimiento

• FunkLoad
• FWPTT load testing
• loadUI
• jmeter

Herramientas comerciales:
1) Herramientas de gestión de pruebas

• HP Quality Center/ALM 
• QA Complete 
• qaBook
• T-Plan Professional
• SMARTS 
• QAS.Test Case Studio 
• PractiTest 
• SpiraTest 
• TestLog
• ApTest Manager 
• Zephyr

2) Herramientas para pruebas funcionales

• QuickTest Pro 
• Rational Robot 
• Sahi 
• SoapTest 
• Test Complete 
• QA Wizard 
• Squish 
• vTest 
• Internet Macros 

3) Herramientas para pruebas de carga  y rendimiento

• HP LoadRunner
• LoadStorm
• NeoLoad
• WebLOAD Professional
• Forecast
• ANTS – Advanced .NET Testing System
• Webserver Stress Tool
• Load Impact

Herramientas Todo en Uno

• Test Studio – Una herramienta para pruebas de rendimiento, carga, pruebas automáticas, gestión de pruebas y test exploratorio.

Herramientas para pruebas sobre teléfonos móviles

• Testdroid-Herramienta para pruebas automatizadas para Android.

Modelo de prototipos

El modelo de prototipos o de prototipaje previo a su desarrollo debe considerar las siguientes partes fundamentales:

• La definición de los objetivos globales para el software.
• Identificar los requisitos conocidos.
• Identificar las áreas del esquema del software en donde sea necesaria una mayor definición.
  

El siguiente esquema represente el proceso que sigue este modelo:

 

Su diseño es rápido y se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida).

Ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos y ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

La clave de su éxito esta en definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:

• Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos
• Que el prototipo se descarte, o al menos en parte.
• Que después se desarrolle el software real con un enfoque hacia la calidad

Cabe resaltar que este modelo solamente es útil cuando tanto el cliente como el desarrollador conocen los objetivos y las necesidades generales para el software.

Pruebas del Software

Las pruebas funcionales - (Functional Software Testing) y las pruebas unitarias (Unit Software Testing) deben ser consideradas como temas cien por ciento técnicos, en mi experiencia como analista de pruebas o también llamado tester, he llegado a probar una buena cantidad de sistemas en varias empresas, enfocadas principalmente al sector financiero.

Para el analista de pruebas es muy importante y conveniente tener una definición funcional y técnica decente antes de iniciar el proceso de prueba, en realidad en un proceso de aseguramiento de la calidad el analista QA revisor debe validar que estos documentos son lo suficientemente claros y consistentes, una vez aprobados estos documentos podrán servir de base para que el analista de pruebas pueda preparar el plan de pruebas, el cronograma de pruebas y los casos de prueba.

Cada vez que tengo un sistema en mis manos siento que mi labor debe ser darle un valor agregado, cada error que yo pudiera encontrar significa un éxito para la calidad del sistema. Evidentemente el analista de pruebas o tester debe ser un profesional en Ing. De Sistemas o Ing. de Software, los conocimientos técnicos son valiosos en esta labor, pero no son suficientes, necesitamos también tener conocimientos del negocio, en la actualidad los sistemas más importantes son realizados para dar solución a los problemas de negocios. 

El nivel de conocimiento del tester sobre un negocio debe ser similar al del usuario que utilizará el sistema. Un tester experimentado puede llegar a tener un amplio conocimiento  de diversos negocios y le resultará sencillo adaptarse a cualquier tipo de aplicación y a cualquier tipo de plataforma: Web, C/S o Host, siendo esta última a mí parecer la más complicada.

Para conocer como funcionara el sistema y tener una visión general de lo que este hace para el negocio es necesario asimilar la documentación funcional y técnica previamente definida. Luego de asimilar estos conocimientos será más sencillo el desarrollo de los casos de prueba.

En las pruebas funcionales los casos de prueba tienen el objetivo de detectar errores, los casos de prueba deben definir los datos de entrada a utilizar, el proceso que debemos seguir en el sistema y el resultado esperado.

Una vez concluidos los casos de prueba es mas sencillo poder estimar cuanto tiempo nos tomara una primera barrida de pruebas y con esto también podremos realizar nuestro cronograma y plan de pruebas.

Los casos de prueba nos permitirán probar todas las funcionalidades del sistema, sin embargo es importante tener buen criterio a la hora de desarrollarlos.  Las combinaciones de casos de prueba podrían ser prácticamente infinitas, propongo el siguiente ejemplo:

Si pensamos hacer casos funcionales para un sistema bancario nos encontraremos con una gran combinación de variables:

Para este ejemplo solo nos centraremos en un simple retiro bancario, en donde nos encontraríamos con las siguientes variables:

¿En que tipo de cuenta haremos el cargo? Ahorros, Corriente, A Plazos
Esto nos daría al menos 3 variables o casos de prueba.

¿La cuanta tendrá saldo? Saldo = 0,  Saldo > 0, Saldo < 0
3 variables

¿Es una cuenta en Moneda Nacional MN o Moneda extranjera?
2 variables

¿Pertenece a una Persona natural PN o Persona Jurídica PJ?
2 variables

¿La cuenta es mancomunada? Si o No
2 variables

¿En que estado se encuentra la cuenta? Activa, Inactiva, Cerrada (Suponiendo que solo se manejen 3 estados).
3 variables

¿La cuenta tendrá alguna facilidad crediticia? Es decir ¿Permite sobregiros?
Si o No
2 variables

¿De que tipo será el cargo a la cuenta?

1. Transferencia entre cuenta propia
2. Transferencia a un tercero
3. Transferencia interbancaria
4. Retiro en efectivo
5. Pago de un cheque

5 variables

¿En que canal de atención se realizará esta operación?

1. En ventanilla
2. Cajero Automático – ATM
3. POS – Pago de servicio o consumo
4. Home Bankin

4 variables

Para este ejemplo tan sencillo podríamos obtener fácilmente más de 3000 casos de prueba y ni siquiera estamos enfocados a los casos que presentarán en cada pantalla. Como menús, listas, grillas, botones etc. Por este motivo debemos delimitar claramente cual es la funcionalidad que queremos probar diseñando cada caso de manera que abarque la mayor cantidad de esfuerzo posible al sistema.

Una vez que empezamos a probar nuestros casos siempre deberíamos ir un poco más allá. Muchos de los errores que he podido encontrar no estaban escritos en mis casos de prueba. 

Si en mi caso defino hacer un cargo de 1000 dólares, luego de eso podría hacer una prueba con un cargo de 1000.01 y otro de 9999.99 siempre tratando de encontrar los valores limites que provoquen un mal funcionamiento. Es interesante notar que la gran mayoría de los errores se encuentran en los valores límite. Si una pantalla se define para que no soporte un número mayor de 99999999.99 pues entonces probemos con 100000000.00 pues el sistema debería mostrarnos un mensaje indicando que el monto ingresado esta fuera del rango permitido o algo por el estilo. 

Es increíble como algunos programadores creen que no se deben probar casos para los cuales el sistema no esta preparado, bueno yo pienso totalmente lo contrario un buen sistema debe funcionar perfectamente con datos ingresados bien o mal esto diferencia a un sistema de alta calidad, se debe probar que el sistema haga lo que debe de hacer y por supuesto que no haga lo que no debe de hacer, la labor del analista de pruebas es totalmente destructiva para con el sistema, un analista tester jamás debería estar bajo las ordenes de un programador y tampoco es recomendable dejar que el programador pruebe sus propios programas, es gracioso cuando me pongo a pensar en la gran cantidad de programadores que me han pagado apuestas por su seguridad en la robustez de sus sistemas, simplemente en el fondo no quieren maltratarlos, los aman…

Otro nicho en el que se ocultan errores podrían ser los campos de ingreso de datos, aún no entiendo porque tantos programadores no colocan valores límite máximos permitidos en los campos de texto, sobre todo en los campos de párrafos o multilíneas, disfruto de esas pruebas haciendo un solo Copy de un texto mediano para luego hacer 100 veces Paste, casi me parece escuchar como se truenan los huesos de la base de datos cuando no soportan el contenido. Si realizo esa prueba la primera vez en un sistema y lo logra pasar limpio pues ese programador se ha ganado mi respeto, a pesar de ser una definición tan simple muchos la olvidan.

Las pruebas que requieran cálculos de diversos valores deberían tener pocos casos pero muy extensos y complejos, alguna vez hice pruebas para un sistema de bolsa de valores en donde se deberían calcular diversos campos calculados, cada uno de ellos mostrado en un campo o grilla, el caso debe especificar que valor se espera en cada campo y una vez ejecutado el caso constataremos que los datos que se presenten sean correctos, tanto en las pantallas como en los reportes, jamás he tenido la experiencia de encontrar un sistema nuevo sin errores en sus cálculos complejos “El sistema nunca funciona bien la primera vez”. ¡Ese es mi lema!

Por último una muy buena recomendación de pruebas es el manejo del valor cero 0 muchas veces por la complejidad de los procesos el programador olvida que este valor puede llegar a ser un divisor de otro valor y entonces: “Error Exception Faillure #afg99d7 - no valido” o algún otro mensaje horrible.