Todos los desarrolladores han sentido la frustración de recibir reportes de errores. ¿Por qué no descubrieron esos errores antes? ¿Qué paso con las pruebas unitarias y de integración? La respuesta a estas preguntas puede estar en  los siguientes aspectos:

 

1. Los usuarios ejecutaron código que no fue probado.
2. El orden de la secuencia de comandos ejecutados fue diferente a lo probado.
3. El usuario ingreso una serie de datos no validados.
4. El sistema está instalado en un ambiente donde no fue probado.

 

Plan de pruebas y Tester

 

Para crear un plan de pruebas efectivo se deben considerar múltiples aspectos relacionados con el sistema que se está probando. Por ejemplo funcionalidades, ingreso de de datos, ambiente de ejecución, etc.

 

Por eso, un Tester de profesional debe tener Skills en múltiples áreas para poder diseñar un plan de pruebas efectivo.

 

El proceso de pruebas, al igual que las fases de desarrollo de RUP, tiene 4 fases. Estas fases son:

 

1. Modelar el ambiente del sistema.

La primera tarea del Tester es simular como el sistema se relaciona con su ambiente. Para esto se deben identificar todas las interfaces del sistema y los datos que pasan por las mismas.

 

Existen 4 tipos de interfaces en los sistemas:

 

·         Interfaces Humanas.

·         Interfaces de software (API)

·         Interfaces de Archivos (Datos)

·         Interfaces de comunicaciones (Redes y Device)

 

El siguiente paso que el Tester debe hacer es encontrar las acciones que el usuario puede realizar y que harían que el software deje de comportarse de manera consistente. Por ejemplo:

 

·         ¿Qué pasa si un cliente cambia los mismos registros que otro en el mismo tiempo? Esto es manejo de la concurrencia.

·         ¿Qué pasa si se baja el sistema en medio de una transacción?

·         ¿Qué pasa si dos sesiones del sistema acceden a la misma API?

·         Etc….

 

Dentro de las consideraciones que debe tener en mente un Tester se encuentran la forma en que se elogien los valores de las variables de entrada y la secuencia cómo ellas son ingresadas.

 

En la selección de las variables existe un método llamado BOUNDARY VALUE PARTITIONING. Básicamente es para buscar los valores esperados y las condiciones de borde de cada variable. Además de lo anterior se debe considerar la entrada concurrente de datos y la correcta aislamiento entre cada sesión que está manipulando los valores de las variables.

 

La segunda consideración tiene que ver con el orden en que se ingresan las variables. Tres técnicas son usadas para apoyar la definición del orden de ingreso de los datos. La más común es usar diagramas de estados (UML) para modelar el ingreso de datos y el estado en que el sistema debe quedar en cada movimiento.

 

Otra técnica es la que nos brindan las herramientas basadas en la teoría del lenguaje. Por ejemplo expresiones regulares y gramaticales. Un ejemplo de esto sería:

 

Filemenu.Open filename* (ClickOpen | ClickCancel)

 

Por último, las más desconocidas y complejas son las técnicas estocásticas y de algoritmos genéticos. Estos modelos combinan los valores a ingresar y su secuencia para producir palabras y oraciones Sintacticamente correctas.

 

2. Elegir los escenarios de pruebas.

 

Muchos modelos de dominio y grupos de variables representan un infinito número de escenarios de pruebas, cada uno con sus costos y plazos de pruebas. Siendo realistas, en un proyecto de software los presupuestos son limitados por lo que debemos discriminar en que escenarios se probaran y cuales no.

 

¿Cuál es el criterio que se debe usar? Existen muchas respuestas para esta pregunta, siendo la más común entre los Tester el uso del criterio de Cobertura.  Este criterio dice que por lo menos una vez cada línea del código y las entradas del sistema han sido probadas. Esto es el criterio mínimo esperable para las pruebas de un sistema antes de ser entregado.

 

Si desarrollamos la idea de la cobertura del código, nos damos cuenta que esto es muy complejo porque además de considerar que todo el código haya sido ejecutado al menos una vez, caemos en el tema de las rutas de ejecución. Una ruta de ejecución es la secuencia en que las líneas de código son ejecutadas. Las rutas de ejecución para el mismo código pueden llegara a ser infinitas.

 

Para acotar estas infinitas posibilidades el Tester busca los escenarios más comunes de ejecución, lo típico que un usuario ejecutaría.

 

Existen tres criterios reconocidos para elegir las rutas de ejecución a ser probadas. El primer criterio es el que pone foco en la cobertura de las estructuras de control. La idea es que las pruebas hagan que la ruta de ejecución pase por todas las opciones que abren las estructuras de control. Por ejemplo IF, que en ambos casos se prueben.

 

El segundo criterio es DATAFLOW, esto es que todas las estructuras de datos sean iniciadas y usadas.

 

Por último, el criterio menos usado, en mi opinión, es FAULT SEEDING. La idea de está técnica es sembrar errores intencionalmente en el código los cuales son encontrados con los casos de pruebas, idealmente se encuentran también los errores originales.

 

Respecto a los criterios de selección de casos de pruebas para las entradas de datos son simplemente la cobertura de todas las entradas de datos del sistema y la técnica llamada DISCRIMINATION CRITERION, que consiste en probar aleatoriamente hasta llegar a cubrir las entradas posibles del sistema.

 

3. Ejecutar y evaluar los escenarios de pruebas.

 

Después de tener definidos los escenarios de pruebas viene la labor de ejecutar lo que se definió. Hacer esto de manera manual es un trabajo arduo y puede generar nuevos errores.  Existen herramientas que ayudan al Tester a obtener información interna  del sistema para mejorar sus pruebas.

 

La evaluación del escenario de pruebas basado en las salidas del sistema no es fácil de automatizar. La evaluación pasa por el Tester que compara los valores esperados versus lo que realmente obtuvo. Para está sencilla tarea se asume que las especificaciones, valores esperados, son correctos. Actualmente esta evaluación es hecha por el Oráculo Humana, llamado Tester.

 

Dos aproximaciones para evaluar las pruebas

 

Existen dos opciones para ejecutar las pruebas:

 

·         Formalismo: poco usado en la práctica porque requiere especificaciones formales de buena calidad. En las especificaciones pueden haber errores, que serían traspasados al sistema.

 

·         Código embebido: Es software incrustado en el sistema que toma medidas de estados de objetos, valores de variables y datos internos. Esto ayuda al Tester porque entrega información desde el interior del sistema y no sólo de las salidas de pantalla.

 

Existen otro tipo de pruebas basadas en código embebido. Está segundo tipo de pruebas es mucho más sofisticado y son código de pruebas del código del sistema. Está técnica se llama SELF-TESTING PROGRAMS.

 

Pruebas de Regresión

 

En un equipo serio de desarrollo, una vez que el Tester ha reportado errores encontrados en el sistema, estos son asignados a los desarrolladores que correspondan para que los reparen. Los desarrolladores después de esto generan una nueva versión del sistema.

 

En ese momento se debe resolver la pregunta ¿Qué es lo que debo volver a probar? La respuesta a la pregunta no es trivial porque cada reparación de un error puede tener cuatro consecuencias posibles:

 

·         Sólo repara el problema reportado.

·         Falla en resolver el problema reportado.

·         Resuelve el problema, pero genera otras fallas.

·         No resuelve el problema y además genera otras fallas.

 

Lo razonable sería volver a probar todo para así hacerse cargo de todas las opciones que el FIX (código reparado) puede provocar. Esto es, cómo siempre, económicamente inviable para el proyecto de software.

 

Estas pruebas realizadas sucesivamente en cada versión del sistema se llaman pruebas de Regresión.

 

Además de tener que resolver que probar para validar el FIX, ocurre frecuentemente que en cada nueva versión del sistema se incorpora funcionalidades nuevas que deben ser probadas también. Muchas veces el Tester privilegia las pruebas sobre las nuevas funcionalidades en vez de hacer pruebas de regresión, esto es malo pero consistente con el criterio de cobertura expuesto en la fase de diseño de las pruebas.

 

4. Medir el progreso de las pruebas.

 

Cuando uno juega el rol de Tester, el Project Manager siempre debe estarnos preguntando ¿Cómo vamos con las pruebas? No siempre tenemos una respuesta fundamentada para entregarle. Básicamente tenemos el número de veces que hemos probado, los casos, las fallas, etc. Es decir contamos eventos, pero esto no nos asegura que estemos avanzando hacia el objetivo del proyecto.

 

Para tener una idea del avance de las pruebas debemos preocuparnos de verificar la completitud estructural y funcional. Para poder comprobar los aspectos estructurales podemos formularnos las siguientes preguntas:

 

·         ¿Hemos probado los errores de programación comunes?

·         ¿Hemos ejercitado todo el código fuente?

·         ¿Hemos forzado todos los datos internos para que sean inicializados y usados?

·         ¿Hemos encontrado todos los errores sembrados?

 

Para la completitud estructural por su parte son:

 

·         ¿Hemos pasado a través de las formas en que el sistema puede fallar? ¿Hemos realizado todos los Test que lo validan?

·         ¿Hemos aplicado todas las entradas de datos?

·         ¿Hemos explorado todos los estados del sistema?

·         ¿Hemos ejecutado todos los escenarios que espero que el usuario use?

 

Estas preguntas ayudan a los Tester para poder estimar el número de fallas que quedan en el sistema por ser descubiertos y la probabilidad que estas ocurran en el ambiente productivo del sistema. Está es la medida cuantitativa que todos buscamos.

4.1. Cultura

 

La cultura es cómo un buen par de lentes, uno ve a través de ellos el mundo pero sin darse cuenta de que los tiene. El resto al vernos los nota de inmediato. Llevado al extremo de lo simple, la cultura es el contexto de obviedad, es todo el sustrato de las relaciones de los individuaos de un grupo.

 

Formalizando la definición tenemos que cultura es el conjunto de presunciones básicas que desarrolla un grupo dado, a medida que va aprendiendo a enfrentarse con sus problemas de adaptación externa e integración interna, y que han ejercido la suficiente influencia como para que puedan considerarse válidas y en consecuencia puedan enseñarse a los nuevos miembros de una organización, como el modo correcto de percibir, pensar, sentir y actuar y que estos puedan reforzarlos.

 

4.2. Antropología

La Antropología -del griego antropos (hombre, ser humano) y logos conocimiento, estudio; conocimiento del ser humano- es la ciencia social que estudia todas las dimensiones del ser humano de forma similar a la sociología, pero holísticamente. Principalmente enfocada desde la cultura y por medio del método etnográfico como exponente clásico.

 

4.3. Sociedad

La sociedad, de manera general, es el conjunto de individuos que comparten fines y conductas, y que se relacionan interactuando entre sí, cooperativamente, para constituir un grupo o una comunidad. También es una entidad poblacional o hábitat, que considera los habitantes y su entorno, todo ello interrelacionado con un proyecto común, que les da una identidad de pertenencia.

 

4.4. Cognición

 

Es la capacidad para recibir, recordar, comprender, organizar y usar la información recogida por los sentidos. Esto se refiere al pensar y todos los procesos mentales relacionados al mismo.

El objetivo de este proceso es producir documentación consistente y coherente que ayude cómo guía a la ejecución y control del proyecto. Este proceso es típicamente iterativo, por ejemplo un plan inicial tiene nombre de recursos genéricos y actividades gruesas. Cuando el plan se refina aparecen los nombres específicos de los recursos a utilizar en el proyecto y fechas de tareas mas granulares.

 

Los objetivos de usar este proceso son:

 

1. Lograr una guía para la ejecución.
2. Documentar los supuestos de la planificación.
3. Documentar las decisiones del proyecto, resguardando considerar las alternativas.
4. Facilitar las comunicaciones entre los STAKEHOLDERS.
5. Definir las revisiones claves de la administración en su contenido, extensión y tiempos.
6. Brindar una línea base para la medición del avance y control del proyecto.

Este proceso es parte del proceso global llamado Project Integration Management, que está compuesto por los sub procesos:

 

1. Project Plan Development.
2. Project Plan Execution.
3. Integrated Change Control.

 

El orden de los procesos es el dado en el listado anterior, siendo el primero el objeto de este resumen.

 

El objetivo de Project Integration Management es asegurar que los variados elementos que componen un proyecto estén apropiadamente coordinados. Esto incluye el balancear los diferentes objetivos y alternativas para satisfacer o exceder las expectativas y necesidades de los STAKEHOLDER.

Conclusiones

 

Las tecnologías de información
por si solas no son una ventaja competitiva, si no mas bien el buen uso de
estas. Dos empresas pueden tener acceso a la misma tecnología sin embargo una
puede sacarle mejor partido debido a las competencias de su personal. Está es
la clave de cómo las TI son una ventaja competitiva.

 

Las PYMES, objeto de gran parte
del análisis de este trabajo, tienen como una característica intrínseca la
escasez de presupuesto. Esto les pone una restricción importante al momento de
querer incorporar tecnología en su operación. Por esta razón es aun más
importante el punto anterior, poniendo sobre las TI el personal calificado.

 

Por último es deducible que en un
entorno cambiante, competitivo y con escasez de recursos, se hace cada vez más
importante el concepto de “agilidad empresarial”. Esto significa que las
empresas deben ser capaces para adaptarse al entorno para no desaparecer. En
este contexto las TI, deben ser capaces de acompañar el cambio organizacional
sin demandar excesivos recursos para quedar operando en las nuevas condiciones
de la compañía. De no ser así, las TI se convierten en un lastre operativo más
que en una ventaja competitiva.