Automatizando pruebas de IBM BPM

Una vez más un amigo que me tiene mucha confianza me invitó a proyecto desafiante: automatizar pruebas de una aplicación generada con una tecnología propietaria “IBM Business Automation Workflow” (IBM BPM).

Muy a grandes rasgos esta herramienta permite automatizar procesos de negocio utilizando una herramienta case que permite integrar (entre otras cosas) servicios (soap & rest) y componentes Java. Una vez que se ha generado el flujo, se genera un paquete (.ear) que se despliega en un servidor de aplicaciones Webphere y listo, está disponible para los usuarios. Hay que mencionar que la propia herramienta de desarrollo de IBM provee ciertas funcionalidades para realizar pruebas, pero en el contexto de esta iniciativa hemos decido ir por un enfoque basado en herramientas de uso general, aunque no descartamos hacer algunos experimentos con estas funcionalidades de prueba.

Luego de un par de sesiones de trabajo hemos identificado 3 tipos de pruebas:

  1. Pruebas end-to-end usando Selenium Web-Driver, esto eso: las prueba es un script que utilizando un nagevador emula el comportamiento del usuario
  2. Pruebas de servicio, realizadas con SoapUI y que consumen los servios SOAP que están por detrás de las pantallas
  3. Pruebas unitarias de los componentes Java codeadas con JUnit.

Decidimos empezar por (2) porque parecía ser un win rápido y efectivamente lo fue. No encontramos mayores complicaciones en hacer estas pruebas.

A continuación empezamos a trabajar en (3) y como sospechamos la cuestión se tornó más difícil porque el código de los componentes Java que se invoca desde la herramienta case (un eclipse customizado) tiene dependencias a bibliotecas de IBM que no están disponibles en repositorios públicos. Para hacer estas pruebas también debimos “mavenizar” los proyectos de cara a poder correr las pruebas en el servidor de itegración continua.

Finalmente, nos queda pendiente probar la estrategia (1) personalmente no me inquieta mucho pues al fin y al cabo las pruebas de UI son algo en lo que no suelo confiar mucho por su costo de mantenimiento y su fragilidad. En dos semanas les cuento que tal nos fue con esto último.

Preparando MeMo2, 2019-2c

Luego un muy buen primer cuatrimestre tenemos la vara más alta para este segundo. A partir del feedback obtenido en las encuestas y las retros con alumnos y con el equipo docente tenemos en mente lo siguiente:

  1. Creemos que la dinámica general de la materia funciona muy bien, con lo cual la mantendremos y solo haremos pequeños ajustes en cuestiones puntuales.
  2. A pesar de que algunos ya confirmaron que no podrán, continuaremos con ex-alumnos en el equipo docente (se están sumando 4 nuevos colaboradores). Esto, además de ayudarnos con la carga de trabajo, también nos permite tener una mirada distinta dentro del equipo docente. Al mismo tiempo es un manera de formar futuros docentes.
  3. Mantendremos el stack de herramientas de soporte (eso es: Google Groups, Canvas Campus y GitLab) e intentaremos incorporar el uso de Kahoot.
  4. También mantendremos el stack de desarrollo con Ruby/Sinatra/Padrino, aunque actualizaremos a Ruby 2.5.1
  5. Renovaremos los ejercicios y el TP final, aunque muy posiblemente mantendremos el JobVacancy como TP1
  6. Vamos a realizar algunos ajustes en la dinámica de los ejercicios de programación individuales y en su corrección. Queremos que las correcciones y el feedback sean más uniformes. Para esto último tenemos que trabajar internamente para generar más guías y rubricas para las correcciones y también vamos a intentar implementar un mecanismo de revisión de correcciones entre los docentes.

Como para cerrar quiero destacar algunos puntos relevantes para quienes planeen cursar este segundo cuatrimestre de 2019:

  • La asistencia a clase es obligatoria y por ende la controlamos
  • La materia es intensa, require de una dedicación constante a lo largo de todo el cuatrimestre lo cual implica unas 8 horas semanales de trabajo extra-clase.
  • Si bien no tenemos el tradicional mecanismo de evaluaciones parciales en papel, el sistema de evaluación que utilizamos genera menos tensiones de parte de los alumnos, pero al mismo tiempo requiere mayor disciplina y dedicación.
  • Las clases comienzan 19.00 (puntual)
  • La primera clase será el Jueves 22/8, ¡no falten! la primera clase siempre es muy importante para setear expectativas)

Ingeniería de Software 2019 @ UNTreF

Este cuatrimestre será la primera vez que dictemos la materia en el contexto del nuevo plan de estudios. Esto implica ciertos cambios a nivel contenido respecto de lo que veníamos dando en años anteriores. Estos cambios tienen más que ver con cambios generales a nivel del plan de estudios que con cambios en el contenido particular de nuestra materia.

Más allá de los cambios de contenido, planeamos mantener la modalidad de cursada, eso es:

  1. Modalidad de aula invertida
  2. Como consecuencia del punto anterior hay una constante carga de trabajo fuera del aula (~6 horas semanales)
  3. Trabajo y evaluación constante a lo largo de toda la cursada

Según nos indica el sistema de inscripción, tendremos unos 10 alumnos, un excelente número para poder establecer un ambiente de confianza entre los alumnos y los docentes.

Las clases serán los días miércoles, de 18 a 22 horas (inicio puntual) en el aula 307 de la sede Caseros 1.

Optimizando el pipeline de deployment

Esta semana empezamos a trabajar con @CodeRaguet y Maxi Cruz en la tarea de optimizar el pipeline de deployment. Actualmente tenemos un pipeline de deployment que hace lo siguiente:

  1. Ante cada cambio en el repositorio obtiene el código
  2. Compila y corre las pruebas unitarias
  3. Despliega a un ambiente que “de integración”
  4. Corre las pruebas de aceptación
  5. Publica los artefactos
  6. Publica los pactos (pact)
  7. Despliega a un ambiente “de demo” donde la aplicación queda disponible para pruebas manuales

La ejecución de este pipeline insume actualmente ~45 minutos y el ~85 % de ese tiempo de ejecución lo consume el paso 4: la ejecución de los tests de aceptación.

Este pipeline representa la primera parte del camino hacia producción y se ejecuta varias veces al día ya que el equipo hace trunk-based development (todos trabajan en master). A continuación de este pipeline hay otro que se dispara manualmente que cubre los ambientes de tests y producción.

Un detalle no menor de esta situación es que si no hacemos nada esta situación va a empeorar gradualmente porque el producto está en constante evolución y todo el tiempo se van a agregando nuevos tests.

El desafió que enfrentamos es reducir el tiempo que insume este pipeline y por ende el tiempo que insume la ejecución de las pruebas aceptación. La estrategia que vamos a intentar implementar es: segmentar los tests de aceptación por grupos de funcionalidades y luego ejecutar cada grupo en paralelo.

En una semana les cuento como nos fue.

Cierre MeMo2 2019-1

Se fue un cuatrimestre más y es momento de análisis. Comencemos por los fríos números:

  • 32 inscriptos (34 formalmente pero 2 nunca asistieron a clase)
  • 3 abandonos antes de la sexta semana
  • 23 alumnos completaron la materia con promoción
  • 5 alumnos pendientes de final
  • 19 tareas individuales (11 cuestionarios y 5 ejercicios de programación)
  • 2 TPs grupales
  • 1 visita de la industria
  • Evaluación general de la materia: 8.9 (según encuesta interna)
  • Opinión general de la materia: 4.6 (según encuesta del departamento)
  • Claridad de los docentes (según encuesta interna): 4.8 / 5
  • Conocimiento de los docentes (según encuesta interna): 4.9 / 5
  • Dinámica de clases (según encuesta interna): 4.5 / 5
  • Materiales de estudio (según encuesta interna): 4.3 / 5
  • Dedicación promedio extra clase (según encuesta interna): 8 hs. semanales

Por otro, más allá de los números la sensación es muy positiva. Basado en el feedback recibido tanto en las encuestas como en las retrospectivas creo este resultado es consecuencia de 3 puntos destacados:

  • Un cambio de orden en los temas de la materia poniendo más foco inicialmente en cuestiones de programación. Esto a mi parecer facilitó en entendimiento de los temas de proceso y el desarrollo de los TP grupales.
  • La incorporación de ex-alumnos al equipo docente. Si bien una ex-alumna había colaborado en algunas cuestiones el cuatrimestre anterior, esta vez con contamos con varios ex-alumnos que colaboraron a lo largo del todo el cuatrimestre.
  • La temática del TP final que incluyó el desarrollo de un Bot de Telegram. Creo que esto generó cierta motivación entre los alumnos.

No están en la foto los ex-alumnos que participaron como colaboradores: Jessica, Josefina, Anarella, Facundo, Pablo y Martín.

Experimento consultorio

Experimento consultorio

Hace un tiempo me contactó un directivo de una organización para que ayudara a mejorar cuestiones de calidad en sus equipos. Pero a mi parecer los equipos no estaban tan interesados en mejorar esos aspectos que me planteaba el directivo. Me pasó varias veces que luego de haber acordado reunirme con un equipo, me cancelaron a último momento. Es así que luego de un par de actividades (algunas de ellas fallidas) acordamos comenzar esta semana con un nuevo experimento: el consultorio.

La idea es simple: yo voy a estar recurrentemente una tarde por semana en las oficinas de este cliente para atender consultas de sus equipos. Esas horas recurrentes son take or pay, o sea: se cobran haya o no consultas. Esto pone “cierta carga” del lado del cliente en generar consultas/actividades para que esas horas efectivamente se utilicen. Por mi parte, este esquema me permite planificar mi tiempo sin correr el riesgo de “perder horas” por cancelaciones de último momento.

Si este esquema funciona ese espacio de consulta debería disparar acciones concretas dentro de cada equipo. Si la cuestión no puede resolverse en el tiempo de consulta entonces agendariamos sesiones adicionales.

Sinceramente no estoy muy convencido esto vaya a funcionar pero bueno, es un experimento, sino al cabo de un par de semanas no funciona, se ajusta o se cancela.