Testing funcional 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 les voy a contar sobre el proyecto de pruebas mencionado en el post anterior por Matías Nassi, 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

Metodología de pruebas de Performance del CES

Desde hace unos años venimos utilizando una metodología propia para llevar adelante proyectos de pruebas de performance que nos ha dado muy buenos resultados.

Hemos tenido el agrado de escribir varias publicaciones al respecto y presentarlas en diferentes eventos (Expo QA 2008SEPGLA 2008)  recibiendo un muy buen feedback.

La metodología es lo suficientemente amplia para abarcar varios tipos de proyectos pero a su vez da una guía muy útil a la hora de abordar estos temas.

En este post me gustaría comentar brevemente las diferentes estapas de la metodología y cuál es el objetivo de cada una.

Etapas de pruebas de performance

Etapa inicial

Se busca entender el contexto en el cual surge el proyecto y los objetivos que se persiguen. Se busca también, dimensionar el proyecto de testing de performance, acotando su alcance. Se requieren en general pruebas de concepto para analizar que herramientas se adecuan mejor al contexto y al sistema que se tiene que probar. Al finalizar esta etapa tenemos que tener una idea clara del esfuerzo necesario para llevar adelante el proyecto,  perfiles de gente se a involucrar, los recursos  materiales se van a necesitar, etc.

Etapa de Relevamiento

Es una de las etapas fundamentales del proyecto. Se busca definir un modelo que simule de la manera más adecuada posible la realidad a la cual se va a enfrentar el sistema. En esta etapa debemos integrar personas con distintos perfiles (usuarios, analistas funcionales, desarrolladores, administradores, etc.) para definir qué transacciones se incluirán, cuántos usuarios virtuales se ejecutarán, cada cuánto tiempo, cómo se simularan otros sistemas, etc. Se deben tener en cuenta todos estos factores para reproducir las condiciones bajo las cuales se quiere estudiar el sistema.

También se deben detallar otros aspectos importantes como ser: la infraestructura que se utilizará para las pruebas, como se monitorizará la misma, los datos a utilizar en las pruebas, etc.

Etapa de Automatización

En general en las pruebas de performance debemos programar para simular el modelo definido en la etapa anterior. Este modelo en general incluye la necesidad de ejecutar funcionalidades con alta concurrencia. Para poder lograr esto, en general, las herramientas trabajan a nivel de protocolo. Para protocolos abiertos y ampliamente difundidos como HTTP existe una variedad importante de herramientas gratuitas y pagas, pero para protocolos propietarios es más complicado encontrar herramientas gratuitas (tal como comentamos en un post anterior).

Al finalizar esta etapa se contará con todos los artefactos de prueba necesarios para recrear el modelo definido.

Etapa de Armado de la Infraestructura definitiva

Luego que se ha dedicado mucho esfuerzo definiendo y programando la automatización, es hora de dejar el ambiente de pruebas listo para comenzar las ejecuciones. Esta etapa en general ocurre luego de la etapa de automatización debido a que por lo general los servidores a utilizar en las pruebas tienen un costo alto y se intenta minimizar el uso de los mismos. Las etapas anteriores se pueden realizar con un ambiente similar al que se va a utilizar en las pruebas.

Al finalizar esta etapa se tiene toda la infraestructura lista para la ejecución, eso incluye la monitorización (tanto de los servidores como de las generadoras de carga), procesos de backup/restore en caso de que sean necesarios, etc.

Etapa de Ejecución

En esta etapa se comienza a obtener los resultados. Generalmente las ejecuciones las comenzamos con las llamadas líneas bases (baselines) las cuales consisten en ejecutar cada transacción sin concurrencia ninguna (con la totalidad de los recursos disponibles) para obtener el mejor tiempo posible de cada una. Estos tiempos nos servirán luego como puntos de comparación. Al comenzar las pruebas se recomienda asignar un porcentaje de carga bajo (por ejemplo un 20% de la carga que se desea soportar), si todo funciona según lo esperado subir al 40%, y así hasta llegar al 100% o 200% si se desea. La razón fundamental para tomar esta estrategia es encontrar con un nivel de complejidad menor los problemas más gruesos, atacarlos y luego pasar al siguiente escalón. Si se ejecutaría de primera el escenario objetivo puede pasar que ocurran varios problemas al mismo tiempo, agregando complejidad  al análisis de los mismos.

Luego de varias iteraciones de ejecución, reportes y correcciones (lógica, configuración, re-diseño, etc.) se llega a una versión del sistema que cumple con los desafíos planteados, o no se llega y se aprende sobre los puntos en los cuáles se debe mejorar.

Es muy importante tener en cuenta que durante esta etapa el objetivo es mejorar el sistema y por este motivo se deben involucrar tanto los testers como los desarrolladores, los expertos en el DBMS, en el sistema operativo, en el balanceador de carga, en el servidor web, en el storage, etc, etc.

Etapa de Finalización

Luego que se terminan las ejecuciones es aconsejable hacer un informe final en el cual se cuente  el desarrollo del proyecto, qué mejoras se hicieron qué sugerencias quedan por implementar para mejorar la performance, etc. También es aconsejable hacer una evaluación postmortem en la cual se vean los puntos a mejorar y ajustar para el próximo proyecto.

Esperamos les sea útil esta información y pueda contribuir en la mejora de la performance de sus sistemas.

Matías Reina

Contratando a un tester

Una de las problemáticas actuales en la industria de software de Uruguay es la rotación de personal, las empresas invierten una y otra vez en que las personas dominen tecnologías, dominios de aplicación y herramientas. Estos cambios se dan con desarrolladores, analistas y testers, entre otros.

Si bien en Uruguay se le está dando más importancia al testing de software en las universidades, centros de capacitación y en las empresas,  hay que tener en cuenta que el testing es una disciplina que aun está en pañales. Por lo que usualmente quienes hace tiempo testean son quienes están desempeñando tareas relacionadas al liderazgo de proyectos de testing.

Las empresas, deciden buscar en el mercado local personas dedicadas a realizar actividades de testing  ya sea porque se quiere mejorar la calidad de los productos o porque necesitan reemplazar a alguien que abandonó la empresa.  No es tan sencillo conseguir un buen tester y tenemos que ser cuidadosos en el proceso de selección y en el período de adaptación del nuevo integrante a la empresa.

Primero tenemos que pensar cómo concebir al testing, para luego bajar a tierra las ideas considerando el contexto de la organización para que nos ayude a decidir a quienes necesitamos, y con qué perfiles.

Una de las definiciones que más nos gusta es aquella que define al testing como una investigación técnica de un producto bajo prueba con el fin de brindar información sobre la calidad de un producto (James Bach). Esta definición, ni ninguna otra que veamos, nos indica quiénes, cuándo o cómo hacer esta investigación, ya que depende del contexto, del producto, del proyecto, etc., pero nos indica mínimas habilidades a considerar. Por ejemplo podemos requerir las características generales de un investigador (como que sea organizado y genere conocimiento original y relevante, entre otras).

Me gustaría compartir un artículo que leí: “The Art of Recruiting” del ex-evangelizador Apple Guy Kawasaki,en el que se detallan 10 consejos a tener en cuenta cuando se contrata personal para trabajar en una empresa.  Uno de los consejos es “Contrata gente infectada.” Indica que típicamente las organizaciones buscan gente con background educativo y profesional “correctos”. Estoy de acuerdo con Kawasaki, en que hay que agregarle una tercera cualidad, la pasión: ¿El candidato está infectado de pasión por tu producto? Porque no importa toda la educación y la experiencia profesional del mundo si el candidato no consigue apasionarse.

Este consejo sirve para contratar personas para cualquier rol, pero en testing es un factor fundamental. El testing no es una actividad sistemática, se necesita creatividad para imaginar posibles problemas y el pragmatismo para implementar y simular ambientes y situaciones para ejecutar pruebas y ver cómo se comporta nuestro software. La idea es detectar defectos y fallas antes que el usuario final las detecte, hay que conocer las características del software y también a los futuros usuarios.

Tenemos que preguntarnos qué valor le da al negocio un tester que conozca de conceptos, estrategias y técnicas de testing, pero que siempre utilice los mismos checklist, corra pruebas de regresión sin agregar nuevos casos cada vez y/o que evalúe el cubrimiento de las pruebas en extensión y no en profundidad.

Cuando estamos evaluando a una persona para desempeñar el rol de tester, tenemos que verificar cuales son los conceptos que maneja del testing.

Hay que evitar que los futuros testers tengan ideas equivocadas sobre la disciplina de testing. También hay que intentar no transmitir estas ideas y si ya son parte del posible nuevo miembro, tendremos que considerar esfuerzo para cambiárselas y hacer que no sólo se apasione por el/los productos, sino también por el testing.

Cuidado cuando se considere que:

  • algunos mitos son verdades, por ejemplo
    • Cualquiera puede testear
    • Es malo desarrollando, ponlo a testear
    • Los testers son malos desarrollando
    • Para testear es mejor no ser informático
    • Sólo los informáticos son buenos testers
    • El tester es el custodio de la calidad
  • no hay posibilidades de crecimiento, o que la participación del tester nunca será importante en la empresa
  • puede ser reemplazado por otro tester y que no se verá la diferencia
  • los resultados no serán utilizados para mejorar la calidad del producto
  • se subestiman los resultados de las pruebas

Un punto relevante en este tema son las especializaciones en testing existentes. Para pensar los títulos y diplomas para Testers como requisito para la contratación, tenemos que saber qué significa tenerlos. 

En la actualidad se imparten algunos cursos de testing para empresas de la industria y asignaturas específicas en carreras relacionadas al desarrollo de software.  No hay una capacitación en testing que considere la capacitación académica con las posibles  especializaciones. Las certificaciones más conocidas están orientadas a evaluar que se conozca una terminología común, las problemáticas frecuentes de las pruebas y algunas técnicas de diseño de pruebas. No se evalúa la práctica, experiencia ni habilidades necesarias para hacer investigación de los productos bajo prueba.

Por lo tanto al momento de contratar un nuevo tester en la empresa es importante que se planifiquen las actividades iniciales para transmitir la pasión por producto y por el testing para que la información obtenida de las pruebas le de valor negocio.

Me gusta pensar que en ocasiones es mejor un diamante bruto en mano que diamante pulido rotando. Esto significa que puede ser más productivo contratar a alguien con conocimiento en un dominio de aplicación y no tantos en testing, para irlo formando, capacitando y apasionarlo por la empresa y los productos, que contratar a alguien con certificaciones, titulaciones y/o con experiencia pero con pensamientos negativos respecto a las pruebas.

Algunos puntos a evaluar en un tester, tenga experiencia previa o no:

  • analítico, asertivo, atento, cauto, certero, claro,comprometido, conciso, creativo, crítico, curioso, deductivo, desconfiado, detallista, diplomático, explícito, buencomunicador, entre otros.
  • y otra cualidad importante es que tenga capacidad para adaptarse a los cambios

Si bien no podemos asegurar que una persona no abandone la empresa para ingresar en otra, podemos jerarquizar el testing, y darle importancia a nivel de planificación y de toma de decisiones, para que la persona vaya capacitándose en el negocio y en testing sin perder la motivación.

Básicamente el proceso de contratación consta de 3 etapas: La convocatoria, la selección dentro de los candidatos que se presentaron y la incorporación al equipo de trabajo del nuevo miembro.

Instanciar este proceso para contratar a un tester requiere que en la convocatoria detallemos las habilidades y experiencia que buscamos, pensando en el testing como actividad cognitiva. Para seleccionar al tester, además de conocer su formación tenemos que ser capaces de evaluar su capacidad por apasionarse por el testing y por nuestro producto. En base a conocer más de nuestros candidatos podremos estimar el esfuerzo para que se incorpore a nuestro equipo y obtengamos los resultados esperados.

Mariana Travieso

Pruebas de Performance en protocolos propietarios (caso ISO8583)

En el laboratorio de Ensayos de Plataformas del CES realizamos usualmente Performance Testing a aplicaciones web que ejecutan sobre el conocido protocolo abierto HTTP, para lo que utilizamos algunas herramientas, ya sean pagas o gratuitas, como ser Microsoft Visual Studio Team System, JMeter, OpenSTA, entre otras. Las pruebas de performance (a diferencia de las pruebas funcionales) necesitan manejarse a nivel de protocolo para poder ser más eficientes y simular cientos de usuarios en una sola máquina.

Pero, ¿qué sucede si queremos realizar pruebas de performance de aplicaciones que manejan protocolos distintos y quizás menos usuales que HTTP? En muchos casos, las herramientas que presentamos anteriormente pueden ser capaces de soportar directamente el protocolo, o al menos brindarnos la oportunidad de simularlo luego de algunas configuraciones adicionales. Si este no es el caso, no queda otra alternativa que entender en detalle las especificaciones del protocolo e implementar por cuenta propia módulos o herramientas que permitan establecer una comunicación, y en particular para las pruebas de performance, que permitan generar cierta carga parametrizable mediante este protocolo.

En varios proyectos del CES en el sector financiero nos hemos encontrado con un protocolo ampliamente difundido en estos entornos, este es el ISO8583. Este protocolo es utilizado para el intercambio de información financiera, principalmente por ATMs (Automatic Transaction Machine) y POS (Point of  Sale). En definitiva, cuando realizamos un retiro de un cajero automático o una compra en un local de venta utilizando nuestra tarjeta de crédito/débito, estamos estableciendo una comunicación via ISO8583 con una institución financiera, cuyo sistema de administración de tarjetas se encargará de procesar la petición recibida y enviar una respuesta indicando el resultado de la transacción. Este componente que procesa la información, típicamente se llama Switch Financiero.

Como mencionabamos previamente, debido a que ninguna de las herramientas disponibles en nuestro laboratorio fue capaz de soportar naturalmente el ISO8583, optamos por desarrollar nuestra propia herramienta generadora de carga, la cual fue desarrollada en Java. Cabe comentar de todos modos que, en el mundo open source, se pueden encontrar diversas herramientas que implementan este protocolo, permitiendo enviar mensajes mediante el mismo hacia un switch financiero (problema también abordado en el CES y que comentaremos en futuros post sobre experiencias de Testing Funcional), pero ninguna de ellas cumple el requerimiento fundamental de toda prueba de performance: permitir la generación automática de carga masiva. Luego de varios meses en los cuales debimos entender la especificación del estándar y desarrollar la aplicación acorde al mismo, junto con posteriores modificaciones de mejora logramos obtener una herramienta estable capaz de soportar hasta 200 transacciones por segundo en una única máquina de escritorio, cifra más que aceptable en un principio.

El contar con esta herramienta, y poder utilizarla en conjunto con otras para poder simular todos los puntos de entrada de un core financiero, nos ha permitido llevar adelante exitosamente múltiples proyectos en los cuales ha estado involucrado nuestro laboratorio, logrando generar la carga requerida para poder cumplir los objetivos primordiales de una prueba de performance. En posts subsecuentes estaremos describiendo en detalle cuales son estos objetivos.

Matias Nassi