¿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

¿Los informáticos necesitamos cábalas para reproducir incidentes?

Ayer casi sin quererlo me encontré rodeada de fanáticos “hinchas” futboleros, al principio todo lo que decían carecía de sentido para mí. Al pasar los minutos, mi actitud hacia lo que escuchaba cambió y comencé a sorprenderme.  Algo que realmente no deja de sorprenderme son las cábalas, la creencia popular supone que existe una fuerza más allá de lo natural relacionada con una o varias acciones que provocan que suceda algo.

En el deporte y en este caso en el fútbol, ocurre que si queremos un resultado igual al anterior debemos repetir exactamente la secuencia de acciones que hicimos antes y durante el partido anterior.  Fue ahí cuando comprendí que estos hinchas no hacen más que intentar generar un contexto igual al anterior para generar un resultado igual al anterior.

Algo similar ocurre cuando probando software encontramos un incidente, para lograr reproducirlo debemos generar un contexto igual para obtener nuevamente el incidente.

Así cuando estamos probando un software debemos prestar atención a todo el ambiente y las acciones que ejecutamos para saber exactamente cómo reproducir una situación. Pero cuidado hinchas y testers de software olvidar tan sólo una de estas acciones puede significar la perdida de la copa Libertadores!

María Elisa Presto

Especialización en testeo de portales

En los últimos años se ha incrementado el uso de portales en Internet, sitios web que ofrecen al usuario acceso a recursos y servicios relacionados. A modo de ejemplo se encuentran links, buscadores, foros de discusión, documentos, aplicaciones, e-commerce, entre otros.

La disciplina de pruebas de performance intenta modelar el uso que los usuarios de una aplicación le dan a la misma a fin de detectar posibles cuellos de botella, aislarlos e intentar, con un equipo de expertos en la infraestructura y la aplicación, realizar cambios hasta encontrar la mejor configuración.

En el CES realizamos a diario pruebas de performance sobre distintos tipos de aplicaciones, con más o menos capas y distintas tecnologías. Contamos con una metodología la cual ha sido reconocida a nivel internacional. Si bien cada sistema tiene sus particularidades, las ideas generales para realizar un buen modelado de la realidad son similares.

En este artículo voy a centrarme en aspectos comunes para realizar pruebas de performance en portales. La principal particularidad se encuentra en la etapa de relevamiento, aquí a diferencia de otras aplicaciones, podrán estar integradas varias aplicaciones con lo cual se hace necesario identificarlas y, en base a ellas, seleccionar las herramientas a incluir para realizar la automatización. Luego, por cada una de estas aplicaciones, habrá que realizar las actividades que proponemos en nuestra metodología (Relevamiento, Automatización, Armado de la Infraestructura definitiva y Ejecución). Finalmente se deberá ejecutar una prueba en conjunto con todas las aplicaciones que brinda el portal, a fin de modelar su verdadero uso.

Una simplicidad que se da a diferencia de sistemas transaccionales es lo relacionado a la generación de datos. Ya que salvo excepciones, a priori no se consumen los datos utilizados para las pruebas. Lo cual al realizar varias pruebas complica el proceso, ya que la ejecución y posterior comparación queda ligada a la posibilidad de volver a un estado conocido el estado de la aplicación (incluyendo todos los componentes de la infraestructura, ej.: bases de datos).

Lo que más difiere últimamente entre portales y otro tipo de aplicaciones es lo relativo a facilidades que se le brinda al usuario.Ejemplos de esto son el “single sign on” y lastecnologías que apuntan a mejorar la percepción del usuario, como ser Ajax, Silverlight, flash, entre otras…que se dan más desde el lado del cliente. Todo esto habrá que considerarlo y ver la forma de emularlo a fin de lograr una carga similar a la que el portal estará recibiendo una vez en producción.

Lo otro que cambia, es el modelado del tráfico y del comportamiento de los usuarios. No es lo mismo a un sistema en donde el usuario tiene que usarlo y finalizar una tarea. Un portal es diferente. Por ejemplo, se tiene abandono de los usuarios (usuarios que abandonan el portal a la mitad de algo y no terminan transacciones), usuarios que buscan algo y no lo encuentran…

La literatura, en general, dice que hay que basarse en logs de navegación de portales similares o anteriores para poder determinar un escenario de uso lo más real posible.Este tipo de informaciónno siempre está disponible con lo cual muchas veces se estima en base entrevistas la simulación del uso del portal a generar. Asimismo, se intenta tipificar usuarios además de transacciones (lo que generalmente se tipifica), ya que para una misma transacción hay gente que puede llegar a utilizarla de manera diferente. A modo de ejemplo si la transacción fuese “consultar horarios de trámites” algunos usuarios tal vez solo consulten esos horarios y los impriman y otros de allí pasen a solicitar un número para realizar un trámite.

En conclusión, dado que los usuarios tienen un comportamiento diferente y son potencialmente diferentes para cada ejecución de la transacción (no es como en un sistema transaccional en donde se loguea una vez y nada más) es que la forma de modelar la realidad se basa en el comportamiento que los usuarios le dan al sistema más que en las funcionalidades.

Gustavo Guimerans

La aventura de enseñar testing

Desde un pequeño país que como decía el escritor argentino Jorge Luis Borges, pone mucho tesón en diferenciarse… y que tiene algunas curiosidades… surge esta idea singular: lanzar una carrera de testing.

¡La carrera de testing propuesta por el Centro de Ensayos de Software se inicia el 2 de mayo!

Es sin duda un punto de partida, quizás uno de los más ambiciosos que el CES, con su vocación de abordar problemas inéditos, se ha planteado en su relativamente corta trayectoria.

Pero también es un punto de llegada, un jalón fundamental en esta exploración que hemos emprendido juntos, la de conocer para testear y testear para conocer, como mencionamos tantas veces.  Enseñar y aprender testing, de eso se trata.

Comenzamos dando una asignatura opcional en la carrera de Ingeniería en Computación de  la Facultad de Ingeniería, Universidad de la República.  Incorporamos posteriormente nuevos temas para transmitir y transferir la experiencia del CES suministrando servicios de testing funcional, de performance y de automatización del testing funcional en diferentes industrias.

Ampliamos los cursos al ámbito de la Comisión de Posgrados y Actualización Profesional, y preparamos cursos comerciales, para informáticos y usuarios calificados. Fue la etapa de difusión del testing.

¡Más práctica!… fue el clamor unánime, y consideramos que era imprescindible ofrecer un “Ciclo de testing en la práctica” y así lo hicimos.

Luego nos preguntamos cómo podríamos contribuir mejor a difundir una cultura de testing, a impregnar de testing las actividades de construcción o adquisición de software. Lanzamos entonces el  curso “Testing para desarrolladores” que ya hemos impartido en varias instancias en Uruguay y México.

Cada uno de estos hitos constituyó un nuevo desafío, nuevas interrogantes y generó el esfuerzo por dar más y mejores respuestas.

¿Cómo continuar profesionalizando el testing? ¿Cómo demostrar cuán creativo e interesante es el testing? ¿Cómo demostrar el retorno de la inversión en testing? ¿Cómo dar continuidad al aprendizaje? ¿Cómo profundizar en conocimiento, experiencia y especialización? ¿Cómo explicar mejor y evaluar lo aprendido? ¿Cómo garantizar que lo aprendido puede ser aplicado en la realidad, en aplicaciones de gran porte, en infraestructuras complejas? Muchas veces, a mí personalmente, las dudas me impidieron avanzar. Pero mis compañeros del CES, los que comparten conmigo la labor cotidiana, me impulsaron, inspiraron y trabajaron para que este nuevo hito, sea a la vez un punto de llegada y de partida…

Tendremos seguramente muchos aciertos y también errores que esperamos superar juntos. Pero estamos convencidos que esta carrera ayudará a quienes se desempeñan como testers de software y a quienes quieren “probar” nuevos horizontes, a profesionalizarse y ser reconocidos por el valor que aportan al compromiso compartido por la calidad y la excelencia.

Mónica Wodzislawski

El tester diplomático: siendo parte del equipo

Al tester le toca en muchas oportunidades la fastidiosa tarea de ser (en el mejor de los casos) un inspector de calidad, y en ocasiones un verdugo (la peor pesadilla) de los desarrolladores.

Las actividades de verificación traen consigo la necesidad de reportar los errores, que por más que nos desvivamos en decir que son “del producto”, y que sostengamos nuestra eterna bandera de que “se evalúan productos y no las personas”, al fin y al cabo, esto recae sobre algún desarrollador.

En tiempos donde la presión y los plazos son ambiciosos (comúnmente, en proyectos de desarrollo de software suele ser todo el tiempo, ¿verdad?), esto se puede transformar en  confrontaciones o generar climas ásperos de trabajo.

Escenarios de trabajo del testing independiente

El testing independiente puede desenvolverse en varios escenarios. En general, podríamos categorizarlos en estos cuatro principales:

  1. Proyectos cortos dentro del laboratorio de testing independiente
  2. Proyectos permanentes o de larga duración dentro del laboratorio de testing independiente
  3. Proyectos cortos en permanencia con el cliente
  4. Proyectos permanentes, o de larga duración con permanencia en el cliente

Para dar una definición más acertada, deberíamos precisar los términos “cortos” o “permanentes”. Para el caso práctico, tomaremos como ejemplo de proyectos cortos aquellos que van desde dos o tres semanas, hasta dos o tres meses de duración máxima. Proyectos de larga duración, suelen consumir períodos mayores, y muchas veces, sin una fecha de finalización definida.

La premisa de una institución de testing como CES, es lograr ejecutar el mejor conjunto de pruebas dado el contexto, aportando información de valor a los interesados, como resultado de la aplicación de ingeniería de software y de testing (muchas veces en conocimiento, metodología e incluso en análisis con refinamiento o construcción de requerimientos).

Si bien, nuestro trabajo es encontrar los incidentes, cazar bugs… es diferente la actitud que debemos tomar dependiendo del contexto, y de ello dependerá su impacto y muchas veces nuestras relaciones interpersonales a futuro.

Para el propósito de este artículo, los escenarios 1 y 2 son casi análogos, dado que la interacción con el cliente suele ser menos frecuente, y en reuniones planificadas.

Los escenarios más delicados son el 3 y 4, siendo este último el más sensible y el foco de este artículo. Esto se debe a que la interacción con múltiples actores, el dinamismo, y el ritmo cambiante pueden ser el hábitat natural de estos testers.

Actitudes en relaciones interpersonales

En estas circunstancias, nos ha dado mucho resultado hacer foco en las siguientes actitudes:

  • Proactividad
  • Involucramiento con el equipo
  • Involucramiento con el producto y actitud ante el hallazgo de incidentes
  • Comunicación efectiva
  • Aprendizaje continuo y valor agregado

Proactividad

Este término todos los conocemos. Se trata de tener una actitud activa hacia las tareas del proyecto. Buscar la información y las soluciones, construirlas a partir de las múltiples visiones de los actores involucrados. Interactuar con las personas indicadas, respetando siempre los tiempos del otro, y considerando que en situaciones de alta presión, las personas son muy celosas de su tiempo disponible, por este motivo, la consulta de información tiene que ser certera y esquemática, apoyada en un análisis previo de los temas a tratar. Cuando no es posible llegar, o se han acumulado muchas dudas respecto a determinada situación, o se obtienen opiniones muy desencontradas, será necesario tener una instancia de reunión; pero este debería ser siempre uno de los últimos recursos. La proactividad implica buscar las soluciones, optimizando nuestro tiempo y el tiempo de los demás.

Involucramiento con el equipo.

Es importante sentirse miembro del equipo, y tratar de realmente serlo, haciendo que el resto de las personas nos perciban como tal. La interacción persona a persona, el preferir la comunicación verbal al correo electrónico, valorar los aportes de los diferentes expertos explícitamente y comunicar pequeños o grandes logros, retribuyendo a las personas involucradas con un comentario positivo, son algunas de las actitudes que pueden ayudar a lograrlo. Por supuesto que involucrarse en actividades sociales es altamente positivo (reuniones extra laborales, participación grupal en comidas, actividades deportivas), generar propuestas, y tener la iniciativa. La experiencia indica que las opiniones negativas hacia una persona tienden a desaparecer cuando se comparten actividades sociales de este estilo con compañeros de trabajo.

Involucramiento con el producto / Actitud ante el hallazgo de incidentes

Hacernos y sentirnos parte del equipo, nos facilitará el tomar la actitud de ser parte también en la construcción de ese producto, desde el punto de vista del aporte en calidad. Por ese motivo, se debe tornar desde el foco “destructivo” del testing (intentando rápidamente quebrar el producto en cuanto a su funcionalidad y rendimiento), al foco de “despojar de errores y mejorar la calidad”. Si bien el trabajo es el mismo, y la intensidad también es la misma, este último enfoque es el más adecuado para interactuar con las personas que están construyendo un producto, sean desarrolladores, arquitectos o gerentes de tecnología, entre otros. En nuestras interacciones interpersonales se notará que nosotros de alguna manera “queremos” al producto y estamos preocupados por la presencia de incidentes en él. Nuestra retribución personal ante el hallazgo de incidentes cambia de ser cazadores voraces de los más grandes y mejores bugs, para luego de reparados mejorar la calidad del producto; sino es el encontrar incidentes, lo antes posible, antes de que los usuarios finales los encuentren, y ver el producto, también “nuestro” producto, mejorando su calidad gracias a nuestro trabajo. Y este es uno de los puntos más importantes que quiero destacar.

Comunicación efectiva

Tanto por correo electrónico, por teléfono o personalmente, tenemos que ser capaces de sintetizar la información a trasmitir, y la información que queremos obtener. Una buena técnica, para nada novedosa, es que antes de la comunicación hagamos un esquema con los puntos a tratar, nuestras dudas y lo que queremos informar. Para la comunicación con superiores, o personas que tengan que informarse de nuestros avances, obstáculos, o tomar decisiones a partir de nuestra información, es importante tener en cuenta la información esquematizada. Es común que estas personas tengan muy poco tiempo para consumir nuestra información e inclusive seguir la lógica de nuestro razonamiento. Cuando es mucha la información a transmitir, una buena técnica, es anexar un resumen,  al final del correo, resaltar las partes importantes en negrita, utilizar estilos, tabulación, tablas, y colores (no más de tres preferentemente dicen los entendidos en usabilidad y comunicación efectiva). Limitar nuestras dudas, reclamos y sugerencias a las que realmente apliquen. Seremos bien considerados si los problemas los acompañamos de soluciones, o sugerencias.

Aprendizaje continuo y valor agregado

En todos los entornos de trabajo y de todas las personas podemos aprender. Tener la mente abierta a incorporar nuevos conocimientos y estar atento a las diferentes visiones. Solemos no prestar demasiada atención a las personas que nos están transmitiendo información “repetida”, pero en cambio, una práctica bastante útil puede ser el consumir esa información, dado que la visión de esta otra persona, nos puede ayudar a consolidar el conocimiento ya adquirido, y tener nuevas herramientas cuando tengamos que trabajar, y retransmitir esa información. Nuestro saber se ve enriquecido, y además, podemos ser más críticos y compartir nuestro conocimiento, desde una perspectiva constructiva. Por ejemplo, es preferible mantener el silencio en una reunión, a exponer nuestro supuesto “conocimiento superior” al respecto del punto tratado, si este no tiene realmente un valor agregado al objetivo de la reunión.

Para finalizar 

En este artículo, se pretendió presentar brevemente algunas actitudes personales del testing independiente que pueden ser útiles en la interacción con grupos numerosos de diversos orígenes en proyectos complejos y de gran escala.

Además de favorecer al proyecto en sí, y la vida profesional, suelen generar muy buenas relaciones interpersonales, buen ambiente de trabajo e incluso algunos buenos amigos.

Christian Pla

¿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

 

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 menos usuales (caso sistema financiero 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