Testing del sistema de escrutinio de la Corte Electoral

Hemos tenido la oportunidad de participar en parte del proceso de pruebas funcionales y de performance del sistema de Escrutinio de la Corte Electoral que se utilizó el pasado 26 de octubre y 30 de noviembre en las Elecciones Nacionales.

Ha significado un nuevo desafío para el equipo del CES. Por una parte, ponernos en contexto sobre un tema que siendo de conocimiento común a toda la población, hay muchas partes del proceso de una instancia de escrutinio que tuvimos que analizar con mayor cuidado. Por otra parte, implica probar el sistema que registra el escrutinio de las Elecciones Nacionales ¡una responsabilidad importantísima y con mucha visibilidad!; en otras palabras, un proyecto sumamente interesante.

Pruebas funcionales

Luego de elaborar el plan de pruebas y realizar el inventario con las funcionalidades, lo discutimos con el equipo de desarrollo de UTE (responsable de la implementación). Para definir la estrategia de las pruebas analizamos los riesgos y el impacto de cada una de las funcionalidades. Para el ingreso de datos y los diferentes cálculos utilizamos testing planificado y para otras funcionalidades de menor prioridad, utilizamos testing exploratorio y documentamos diferentes sesiones según las misiones previamente definidas. Todas estas actividades fueron documentadas debidamente en una plataforma específica quedando a disposición del equipo de desarrollo y testing para futuras consultas.

Pruebas de performance

Para definir las pruebas de performance a ejecutar sobre el sistema se realizó un análisis de la realidad y se seleccionaron las transacciones más utilizadas, así como también la cantidad de usuarios que utilizarían el sistema en base a información histórica de las pasadas elecciones. Por otra parte, se estudió la infraestructura del sistema en lo que respecta a hardware y software (por ejemplo: servidores de aplicación y motores de base de datos) con el objetivo de tener los diferentes componentes controlados y conocer las causas de los eventuales problemas que surgieran.

En base a toda la información recopilada y luego de priorizar las transacciones, se simularon escenarios de prueba correspondientes al 50% y 100% de la carga esperada, en la hora pico de ingresos ponderando por departamento, es decir, se analizó el contexto particular de cada departamento (partidos políticos, listas, votantes, circuitos habilitados, puntos de acceso al sistema habilitados, etc.).

Durante las pruebas se brindó información que permitió mejorar el sistema y corregir los problemas detectados.

Testing si o testing no

En muchos clientes que estuve trabajando, escuche la siguiente frase “hacemos testing si o no”. Desde mi punto de vista esta claro, “si, hacemos el testing” pero para mi sorpresa escuchaba “NO hacemos el testing”. Los motivos sobraban, entre los que se escuchaba más habitualmente:

  • es una funcionalidad muy sencilla y es imposible que el desarrollador se equivoque, o
  • no hay tiempo para probarlo en testing lo liberamos a producción porque es urgente,
  • no es necesario porque el cambio es menor.

 

Este es el punto en donde nosotros los “testers” tenemos que hacer hincapié. Incorporar tareas de testing en un proyecto, le da un valor agregado.  Detectar los errores en etapas tempranas, es mucho más beneficioso que detectarlo al final. Participación en las reuniones de relevamiento de requerimientos.

Todos estos puntos ayudan a mejoran la calidad de un producto, por eso cada vez que nos encontremos frente a una situación similar.

 

Curso online “Puertas abiertas al testing” gratis

Para todos aquellos que quieran conocer de qué trata esta apasionante disciplina o conocer cómo el CES concibe esta profesión se publicó Puertas abiertas al testing.

Es un curso que presenta una introducción general sobre el testing y sobre diferentes tipos de pruebas.  Está disponible en la plataforma de capacitación del CES, abierto a todo el mundo.

Los cursos de la Carrera de Testing del CES utilizan la plataforma de la misma forma incorporando además foros, chats, videoconferencias, ejercicios teóricos y con especial énfasis, ejercicios prácticos.

Esperamos que lo recorran y lo disfruten.

¿Cómo empezar con la automatización de pruebas funcionales?

En una entrada anterior del blog hablamos sobre cuándo conviene emprender la automatización de pruebas funcionales. En este post veremos ideas relativas a cómo emprender ese camino.

Podemos distinguir 2 etapas en el proceso:

  1. Desarrollo de la plataforma de automatización
  2. Desarrollo de las pruebas automatizadas

Desarrollo de la plataforma de automatización

El desarrollo de la plataforma de automatización es el puntapié inicial en la automatización de pruebas para un producto puntual. En primera instancia es vital conocer los requerimientos necesarios para las pruebas. Por ejemplo, verificaciones con lectura de bases de datos o si hay reportes en pdf que las pruebas deben leer y comparar.

Luego que sabemos lo que necesitamos buscamos herramientas o la combinación de estas para satisfacer las necesidades. En el ejemplo anterior (lectura en bases de datos y pdf’s) podemos combinar un framework de pruebas unitarias como JUnit o TestNG con librerías de automatización a nivel de interfaz gráfica, librerías para conexión a bases de datos, librerías para manejo de pdf, entre otras.

Una vez seleccionadas las herramientas es necesario integrarlas y hacer una prueba de concepto de la plataforma.

El siguiente paso es desarrollar las funciones o módulos básicos para que las pruebas sean composición de estas. Por ejemplo, crear las funciones: Login, CrearInstancia, VerificarCreación, ModificarInstancia, VerificarModificación, Logout.

Las pruebas serán combinaciones de estas funciones con diferentes datos. Por ejemplo:

  • Login (usuario1)
  • CrearInstancia (instancia1)
  • VerificaciónCreación (instancia1)
  • Logout
  • Login (usuario2)
  • ModificarInstancia (instancia1)
  • VerificarModificación (instancia1)
  • Logout

Por supuesto, en el desarrollo de las pruebas se continuará creando nuevos módulos y funciones a medida que surjan las necesidades.

Desarrollo de las pruebas automatizadas

Como en un proyecto de desarrollo de software (que de hecho lo es), comenzamos con ciclos de diseño, implementación, verificación y validación de pruebas. Es importante marcar ciclos cortos de manera que se puedan mostrar resultados rápidamente.

Un esfuerzo no despreciable es el dedicado a la configuración del entorno de datos necesario para los scripts. Pronto publicaremos una entrada relativa a eso.

El diseño de las pruebas es fundamental para encontrar elementos  comunes y reutilizables que se puedan consolidar en funciones  para el uso de varios scripts. De esta manera aumentamos la  productividad porque se crearán nuevos scripts más rápido,  reutilizando funciones. De la misma forma se aumenta la  mantenibilidad ya que ante cambios en las interfaces de la  aplicación (tanto GUI como API) los cambios se realizan  únicamente en las funciones y no en cada script.

Para la implementación, en este esquema de trabajo, las herramientas Record and Playback pasan a un segundo plano ya que directamente se codifica las pruebas pudiendo utilizar  scripts similares como plantillas. La grabación de un script no tiene sentido ya que este se construye a partir de la composición de funciones y no una nueva serie de acciones.

En cuanto a la etapa de prueba de los scripts, cabe destacar que la  verificación se refiere a la prueba de los scripts en el ambiente en donde se desarrollan. La validación es deseable que se haga en un nuevo ambiente para probar así que los datos requeridos para la ejecución están bien documentados y configurados.

Resumen

Esperamos con este post haber dado un pantallazo a alto nivel de cómo se puede arrancar con un proyecto de automatización de pruebas funcionales.

En resumen, se desarrolla una plataforma que establece las bases para un desarrollo sustentable de scripts, facilitando la creación de nuevos y el mantenimiento de los actuales.

Hasta la próxima.

Mauricio Farías

¿Automatizamos las pruebas funcionales?

En general, en el ambiente del software se conocen los beneficios de disponer de pruebas automatizadas. Sin embargo, es menos común entender los costos que esto implica. No están claras las características de la inversión asociada.

El desafío es decidir cuándo y cómo invertir en automatización de pruebas para conseguir un proyecto exitoso (proyecto de automatización). Para esto es vital analizar el contexto, o sea, el producto, el proyecto de desarrollo y la empresa (desarrolladora o consumidora de software).

Para aquellos que aún no han automatizado pruebas funcionales en su ámbito de trabajo, a continuación se presentan ideas que pueden ayudar a evaluar cuándo empezar.

Es una inversión

Los beneficios de la automatización se verán luego de varios ciclos de ejecución, por lo tanto la inversión tendrá que ser sostenida.

No se trata de un esfuerzo inicial y luego esperar. De nada sirve comprar la licencia de una herramienta de automatización y no invertir en la creación, mantenimiento y ejecución de las pruebas. Sería como comprar una licencia de Visual Studio 2010 y esperar que las aplicaciones estén listas. Esto es sólo el comienzo, un proyecto de automatización de pruebas es también un proyecto de desarrollo de software.

Son conocidos los casos en los que se compran “mágicas” herramientas de automatización y luego quedan olvidadas en el armario.

Si en cambio, se decide invertir en dominar una herramienta de código abierto o libre, la situación será similar. Una vez adquirida la experticia necesaria, se deberá seguir trabajando en el proceso de creación y uso de las pruebas.

Según el producto

Será necesario considerar las herramientas existentes para automatizar las pruebas según la tecnología usada, Web, GUI, Web services, protocolo de comunicación, etc. Las interfaces del producto nos dirán si automatizar las pruebas será difícil, factible, fácil, etc. La complejidad para automatizar el accionar de una interfaz y la forma de validar el resultado de una prueba nos dará información sobre el esfuerzo necesario.

El producto puede requerir trabajar en múltiples plataformas: sistemas operativos, bases de datos, navegadores, etc. Si se mantienen las interfaces para las diferentes plataformas, podemos probar con las mismas pruebas automatizadas ahorrando tiempo de desarrollo. Por ejemplo, supongamos que tenemos una aplicación que requiere ejecutar sobre plataformas de PC (Intel y Mac) y en móviles (con iOS, Android, Windows Phone), con las variantes posibles en cuanto a navegadores (IExplorer, Firefox, Chrome, Opera). Las pruebas pueden ser las mismas y simplemente ejecutarse en cada configuración.

Según el proyecto

El proyecto determina cuántas iteraciones se esperan y con qué frecuencia. También puede tratarse de un producto que no tiene un plan determinado por un proyecto, sino que el ritmo y calidad de liberación son determinadas por las exigencias del mercado. Esto nos dirá cuánto utilizaremos nuestras pruebas automatizadas.

Por ejemplo, si estamos hablando de un desarrollo con metodologías agiles, está soportado en la automatización. En el otro extremo, si esperamos pocas iteraciones le daremos menos uso a la automatización.

Hay que considerar no sólo las iteraciones en la etapa de proyecto, sino aquellas que aparecen una vez liberado el software, en el mantenimiento urgente y evolutivo. En esta etapa las pruebas automatizadas toman un valor importantísimo, para probar rápidamente liberaciones urgentes, aportando tranquilidad sobre el cubrimiento de las pruebas.

Según la empresa

Se puede afrontar el desafío de la automatización desde el inicio del proyecto de desarrollo de la aplicación o después, esto también depende de las características de las empresas.

Empresas pequeñas o nuevas quizás no lo pueden afrontar al inicio. Es posible que no tengan los recursos para destinar a la automatización.

Otras pueden afrontar el desafío, pero se pospone, llegando a un momento en el cual las versiones salen casi sin testing. Esto puede darse porque el producto es muy grande, o se liberan versiones muy frecuentemente, o tienen múltiples versiones de un producto para diferentes clientes, plataformas, etc. El testing manual no tiene la capacidad de llevar a cabo el trabajo.

Es importante analizar el entendimiento en la gerencia y en el equipo de desarrollo sobre los beneficios y trabajo detrás de la automatización. Se necesitará el apoyo y compromiso de ambas áreas para llevar adelante el proyecto.

Se tendrá que evaluar la disponibilidad de recursos humanos para destinar a la automatización. Como mencionamos, la automatización es también un proyecto de desarrollo, lo que implica que se necesita un perfil desarrollador/tester.


Cuando

El momento adecuado dependerá de todas estas variables.

Si nos adelantamos podemos encontrarnos con inmadurez en el equipo de testing, esto podría llevarnos a descuidar las pruebas manuales, que nos dan beneficios a corto plazo. Si la organización no tiene claro lo que implica la automatización, pueden aparecer expectativas no realistas, frustración y abortar el proyecto.

Como se dice comúnmente, “nunca es tarde” para hacer las cosas. Pero puede pasar que otros competidores liberen más rápido, con mayor calidad, los clientes no estén conformes con la calidad, los usuarios ya no crean en la aplicación, etc. Todos estos problemas pueden afectar seriamente las ventas del producto o el éxito del proyecto.

Por lo presentado, resulta importante evaluar desde el inicio y periódicamente si estamos en el momento adecuado para arrancar con la automatización de pruebas. Se puede comenzar con una inversión pequeña aunque sostenida, tratando de no dejar pasar el tren.

En posteriores entradas al blog hablaremos de cómo encarar de mejor manera este camino.

Mauricio Farías

Testing funcional en sistemas financieros (caso de aplicaciones que se comunican mediante el protocolo ISO 8583)

Usualmente cuando hablamos de pruebas funcionales nos imaginamos una interfaz gráfica en la cual se ejecutan casos de prueba, en esta oportunidad voy a contar sobre un proyecto de pruebas funcionales del sistema financiero, complementando de esta manera un post anterior de pruebas de performance, en el cual la interfaz del sistema es un servidor “escuchando” en una ip y un puerto.

La aplicación se comunica mediante el protocolo ISO 8583 (utilizado por los ATM y POS). Este estándar es adaptado por cada organización a sus necesidades. El sistema que probamos utiliza mensajes ISO 8583 para solicitar/responder autorizaciones a transacciones bancarias.

La entrada y la salida a la funcionalidad a probar era un archivo cuyo formato se define en el estándar para transacciones financieras ISO 8583. Cada mensaje ISO8583 consta de una lista de campos, cada campo  tiene un identificador y un valor asociado, tanto para el mensaje ISO  enviado como para el mensaje ISO recibido (respuesta),  cada organización define qué campos usará y define qué valores pueden tomar.

Cómo en cualquier proyecto de pruebas fue necesario comprender el protocolo, identificar los campos relevantes, los campos adaptados por la organización y para cada tipo de transacción, qué conjunto de campos están involucrados y qué valores pueden tomar.

El problema al cual nos enfrentamos tiene un gran número de variables de entrada y de salida y estas variables a su vez tienen un gran número de valores posibles. Cada campo del mensaje es considerado una variable, por ejemplo el campo del mensaje recibido que contiene el código de respuesta (si la autorización fue aprobada o rechazada) tiene 66 posibles valores.

Se diseñaron casos de prueba utilizando las técnicas valores limites, clases de equivalencia y combinación por pares y luego se crearon manualmente algunos casos relevantes para el problema planteado. Luego de tener el diseño de casos todavía teníamos que generar  los mensajes ISO 8583, enviarlos y recibirlos.

Para enviar y recibir estos mensajes se debía invocar una funcionalidad en un servidor conocido que escucha en un puerto conocido. Debido a que no se cuenta con interfaz gráfica nos vimos obligados a implementar una herramienta (cliente) para lograr la comunicación con el servidor mencionado.

La herramienta fue llamada “ISO Test tool”. Brinda una interfaz amigable para establecer  comunicación con un servidor y enviar/recibir mensajes mediante el protocolo ISO8583, la herramienta crea y mantiene un log histórico de transacciones enviadas y recibidas para su posterior análisis.

De esta forma utilizando “ISO Test tool” cada caso de prueba se transformó manualmente en un mensaje ISO 8583 de salida y cada mensaje ISO de entrada (respuesta) se interpretó como el resultado obtenido, que luego se comparó con el resultado esperado para evaluar el caso de prueba y determinar si el mensaje de respuesta es el esperado. Cabe destacar que si bien este proceso de generación de mensajes ISO de salida y revisión de mensajes ISO de entrada se hizo manualmente, la interfaz brindada por “ISO Test tool” facilitó mucho el trabajo.

Este proyecto que en sus inicios parecía de una complejidad extrema culminó en forma exitosa, logrando testear  funcionalidades que se exponen mediante el protocolo ISO8583, gracias a “ISO Test tool” y a un adecuado diseño de casos de prueba.

María Elisa Presto