Fin del taller de prueba automatizada

El jueves pasado tuvimos el quinto y último encuentro del taller de prueba automatizada que dictamos junto con Pablo Tobia en FIUBA. El taller era abierto y gratuito pero con inscripción previa. Justamente al ser totalmente gratuito implicaba cierto riesgo en lo que hace a la planificación, pues es común que mucha gente se inscriba y luego no asista. Para mitigar esto, pedimos a todos los interesados que para confirmar su vacante resolvieran un pequeño ejercicio de programación.

Inicialmente tuvimos unas 40 personas que manifestaron interés en participar del taller cuando aún no estaba definido el horario. Una vez que definimos el horario le informamos a estas ~40 personas y les pedimos que resolvieran el ejercicio para completar su inscripción. Sólo 12 de los 40 lo hicieron. Y aún así, de esos 12 solo 10 participaron del taller.

El taller consistió en 5 encuentros de  ~3 horas. Como guía del taller utilizamos los cuadrantes de testing de Marrick con lo cual el contenido quedó organizado de la siguiente forma:

  • Encuentro #1: conceptos básicos de testing y presentación del enfoque de los cuadrantes
  • Encuentro #2:
    • foco en el cuadrante #1 (support programming & technology facing),
    • test automation manifest
    • xUnit test patterns
    • Test doubles
    • Coverage
  • Encuentro #3 y #4:
    • foco en el cuadrante #2 (support programming & business facing)
    • tipos de herramientas para automatización de pruebas
    • arquitectura de las herramientas de automatización de pruebas
    • testing de aplicaciones tipo enterprise
    • SeleniumIDE, Cucumber, Fitnesse
    • Phantom, Slimer and CasperJS
    • Watir & PageObjects
  • Encuentro #5:
    • foco en los cuadrantes #3 y #4 (test que critican el producto)
    • Stress testing, JMeter
    • AB testing
    • Calidad del software más allá del testing
    • Testing en distintos tipos de proceso de desarrollo
    • El rol de tester

Tanto docentes como alumnos quedamos muy contentos con el taller y concluimos que perfectamente podria ser una materia de las carreras de informática de FIUBA (en realidad es posible que también aplique a otras carreras pero sabemos que en FIUBA estos temas no estan cubiertos por ninguna materia en la actualidad). En caso querer convertir este taller en un materia (o en un curso más amplio) deberíamos agregar temas talles como: planificación de la prueba, definición y administración de casos de prueba, herramientas de soporte, Testlink, modelos de calidad, etc.

Finalmente quiero agradecer a todos los que participaron este experimento para mi ha sido un gran placer el tiempo compartido.

Sobre las carreras de informática en FIUBA

La Facultad de Ingeniería de la Universidad de Buenos ofrece dos carreras en el área de informática: Ingeniería en Informática y Licenciatura en sistemas. Como docente de dicha casa de estudio suelo recibir consultas del tipo:

“Me gustaría trabajar en XYZ, ¿me conviene hacer la licenciatura o la ingeniería?”

Luego de haber respondido esta pregunta N veces, decidí tomarme unos minutos para grabar los siguientes dos videos. Espero les resulten útiles.

 

 

Curso: Aprendiendo a programar con Python

Durante el segundo cuatrimestre de este año voy estar dictando este curso de introducción a la programación. El mismo surge de una iniciativa conjunta del FIUBA y el programa EmplearTec.

Tanto la currícula como en enfoque de enseñanza del curso están basados en el curso de Algoritmos y Programación 1 (FIUBA) de Rosita Wachenchauzer, del cual fui parte hace algunos años. Esto implica que quienes tomen el curso deberán asistir a dos clases semanales de 3 horas cada una y deberán dedicar otras tantas horas para estudio extra clase.

Los interesados pueden encontrar más información y detalles de la inscripción en la página de FIUBA.

Reflexiones sobre docencia universitaria

En 2009 participé como docente del curso experimental de Algoritmos y Programación 1 a cargo de Rosita Wachenchauzer en FIUBA. Esa experiencia me hizo un click y me llevó a replantearme varias cuestiones respecto de la forma de organizar las clases. Quiero en este artículo enfocarme en una de las cuestiones que generó ese click.

Tradicionalmente las clases de Algoritmos y Programación en FIUBA se dividen en dos clases semanales: una clase teórica dictada generalmente por el profesor a cargo de la materia y una clase práctica a cargo de los docente auxiliares. En algo3 lo hacemos así. Una de las particularidades del curso de Algoritmos y Programación 1 de Rosita era (y aún hoy lo es pues el curso sigue dictandose) la organización de las clases. La materia se dicta 2 días por semana y cada día se dicta teoría y práctica. Esto permite que el alumno vea un tema en la clase teórica y a continuación lo lleve a la práctica justamente en la clase práctica. Personalmente creo que este enfoque es mejor para facilitar el aprendizaje que el enfoque tradicional.

Para los docentes esta diferencia en la organización de las clases puede tener un impacto operativo importante, sobre todo para los docentes de dedicación simple que no asisten a la universidad todos los días. Con el enfoque tradicional cada docente asiste a la universidad una sola vez por semana: el profesor asiste un día a dictar la clase teórica y los auxiliares asisten otro dia a dictar la clase práctica. El enfoque alternativo implica que todos los docentes asistan dos veces por semana a la universidad ya que cada dia se dicta teoría y práctica.

Si tomamos como verdadera la hipótesis que de que este segundo enfoque es mejor para facilitar el aprendizaje de los alumnos, nos surge entonces un dilema como docentes: ¿qué priorizar a la hora de organizar las clases: la comodidad del docente o el mejor aprendizaje del alumno?

Continuará…

Cómo enseñamos TDD

TDD es una práctica cuyo punto clave es la secuencia de pasos que se siguen para obtener la solución. En Algo3 explicamos la teoría y luego la ponemos en práctica haciendo dojos en las clases. También les damos ejercicios a los alumnos y les pedimos que los resuelven haciendo TDD, pero la realidad es no tenemos forma de asegurarnos que hayan arribado a la solución usando TDD. Hay algunas situaciones observables que pueden sugerir que la solución no fue generada utilizando TDD (por ejemplo si la solución tiene baja cobertura es muy posible que no se haya utilizado TDD o al menos no se lo haya utilizado correctamente o todo el tiempo). Al mismo tiempo todos los ejercicios de programación que resolvemos en clase procuramos hacerlo usando TDD. Finalmente evaluamos su conocimiento sobre TDD con alguna pregunta en el examen. Creo que es un enfoque bastante integral y razonable para el contexto de la materia, donde es común que tengamos más de 40 alumnos por curso. Pero es posible que haya mejores enfoque para otros contextos.

Sin ir más a lejos, yo mismo en UNQ estrené este cuatrimestre un enfoque distinto. Cabe aclarar que el contexto de UNQ es distinto, en primer lugar es una materia de ingeniería de software donde se supone que los alumnos ya vieron algo de TDD. Al mismo tiempo, la cantidad de alumnos es mucho menor, suelen ser alrededor de 10. Finalmente la dinámica de la materia es distinta: no tenemos separación explícita entre teoría y práctica y tampoco tenemos exámenes formales. Lo que hacemos (o mejor dicho lo que hemos hecho este cuatrimestre) es explicar TDD haciendo TDD, de una, explicando la teoría sobre la misma práctica. Luego les damos a los alumnos algunas katas para resolver y les pedimos que graben un screencast mientras van resolviendo la kata. Esto nos permite observar cómo los alumnos aplican la técnica paso a paso y detectar si algo no fue correctamente entendido.

Apostando a la ingeniería con estímulos de $ 25.000

La Facultad de Ingeniería de la UBA, tiene en curso un programa de estímulo a la graduación de estudiantes. Dicho programa está apuntado a aquellos estudiantes que se encuentren próximos al final de su carrera y que por una u otra razón hayan interrumpido sus estudios. El estímulo consiste en el pago de un monto de $25.000 para aquellos que efectivamente se gradúen.

Pueden encontrar más información en la página de la facultad.

Cierre de cuatrimestre en Algo3 (2013-2)

Comienzo compartiendo algunos hechos generales que personalmente me resultan de interés:

  • Consolidamos el uso de campus virtual
  • Consolidamos el uso del sistema de corrección de TPs
  • Gran parte de los grupos pudo trabajar exitosamente con servidor de integración continua
  • Curiosamente el  curso de los jueves por la tarde tuvo record de alumnos

Ya hablando en particular del curso de los jueves por la tarde, surgieron los siguientes temas en la retrospectiva:

  • (+) Los videos explicativos
  • (+) El uso de dos lenguajes
  • (+) El uso del sistema de corrección/gestión de TPs
  • (+) El TP final
  • (-) Poco tiempo para resolver los parciales => cuestión recurrente a pesar que Carlos a intentado mejoras ya lo hablaremos en equipo
  • (-) Poca explicación sobre cómo crear elementos visuales con Java => Vamos a proveer una guía/ejemplo/video para facilitar este tema
  • (-) Que el corrector automático no corra todo el tiempo => Este un tema de infraestructura que esperamos tener resulto para el cuatrimestre próximo.

Ya en el plano personal, la experiencia con mis grupos me resulto excelente. Tuve 3 grupos que trabajaron acorde a mis expectativas, haciendo test-driven development e integración continua y cumpliendo con las fechas estipuladas. Creo que por primera vez todos los grupos a mi cargo cumplieron con la fechas estipuladas.

algo3-2013-2

La satisfacción de la inquietud

La semana pasada en el contexto del trabajo final de Algo3 dimos la clase de MVC de cara a que los alumnos puedan empezar a trabajar en la parte de vista y controlador.  A los poco días recibí un mail de un alumno de uno de mis grupos con la siguiente consulta:

Queríamos consultarle si hay alguna forma apropiada de hacer testing para la parte de vista del proyecto, ya que desde que nos pusimos a trabajar con la misma la cobertura de código del proyecto bajó notablemente.

Sinceramente la consulta me sorprendió para bien y me causó una gran satisfacción ver que un alumno tenga este tipo de inquietudes ya desde los primeros años de la carrera.

Largamos el TP Final de Algo3

Este cuatrimestre el TP fue ideado por GabiD con aportes de DiegoM y PabloM. Consiste en un juego por turnos en el que el usuario debe mover su vehículo por una ciudad llena de obstáculos de distinto tipo, intentando minimizar la cantidad de turnos utilizados y maximizando el puntaje acumulado.

Yo tengo a mi cargo 3 grupos los cuales vienen trabajando muy bien. Para facilitar las cuestiones tecnológicas y permitir que los alumnos se concentren en OO, les dimos un proyecto base de ant y un par de videos que explican cómo dar los primeros pasos con Java, Ant y Subversión. Adicionalmente me encargué de configurar un servidor de integración continua. Para esto último estamos usando el servicio gratuito que muy gentilmente nos brinda la CloudBees. Como de costumbre hemos hecho mucho énfasis en que desarrollen sus trabajos haciendo TDD y según muestran los reportes de cobertura parece que lo estan haciendo.

algo3-g1-2013-2

Cierre de Algo3, primer cuatrimestre 2013

Si bien no hicimos cambios explícitos en la dinámica de la materia, incorporamos algunas cuestiones internas que generaron impacto muy positivo.

Una de estas cuestiones fue la incorporación del sistema de corrección de TPs. Esto nos ayudo a reducir muchísimo la carga de trabajo manual al mismo tiempo que le permitió a los alumnos tener un feedback inmediato de las entregas de sus trabajos.

Por otro lado, trabajamos con más foco en la coordinación interna de las clases de los distintos cursos de práctica, reutilizando materiales y ejemplos.

Finalmente, en lo que respecta al trabajo final, tuve dos grupos a mi cargo y ya desde la primer semanal tuvimos el soporte de un servidor de integración continua. Para esto, utilice el servicio que gentilmente nos brinda en forma gratuita CloudBees. Al mismo tiempo, fue muy positivo que ambos grupos tomaron en serio el build server, rompiendo el build muy pocas veces. Todo el proceso de build lo hicimos usando Ant y consistia en compilación, ejecución de pruebas (junit), medición de cobertura (cobertura) y verificación de código (checkstyle). Otro detalle que me pareció muy positivo es que gran parte del modelo de la aplicación lo hicieron usando TDD, lo cual derivó en un porcentaje de cobertura muy bueno (superior al 80%). Algunos otro docente, también usaron esta herramienta con muy buenos resultados y por ello en la retrospectiva decidimos extenderlo a toda la cátedra para el próximo cuatrimestre.