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

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