Software Engineer in Test

Uno de los libros que leí este verano fue “How Google Test Software“, el cual describe entre otras cosas la estructura de equipo y roles usada por Google. Entre los roles mencionados hay 3 que captaron principalmente mi atención.

Software Engineer, también llamado en el libro feature developer, es quien construye la funcionalidad deseada por el usuario. Escribe el código de las funcionalidad junto con sus correspondientes pruebas unitarias.

Test Engineer, también llamado en el libro user developer, es el responsable desde la perspectiva del usuario de todas aquellas cuestiones relacionadas a la calidad. Se encarga de la automatización de los escenarios del uso.

Software Engineer in Test, también llamado en el libro test developer, es el responsable de asistir al Software Engineer en la escritura de los test proveyendo herramientas y frameworks de soporte que faciliten la escritura de los mismos y permitan cumplir con las diversas cuestiones de calidad.

Por si la descripción de los roles no es clara: el software engineer es responsable de construir las  funcionalidades y probarlas, el Software Engineer in Test, lo ayuda en estas tareas proveyendo herramientas y incluso escribiendo algunos tests más grandes (no unitarios). El Test Engineer prueba las funcionalidades desde una óptica más general, viendo más el bosque (sistema como un todo) que el árbol (funcionalidades particulares).

Es este último rol, Software Engineer in Test, el que más llamó mi atención, creo que en parte por el hecho de que me gustaría contar con alguien así cuando me desempeño como Software Engineer/Feature developer.

Casualmente por esas vueltas que tiene la vida, la semana pasada empecé a trabajar en un nuevo proyecto ocupando un rol que bien podría definir como Software Engineer in Test. En el proyecto hay un conjunto de analistas que escriben/describen/especifican la funcionalidad del sistema utilizanzo lenguaje Gherkin y yo me encargo de escribir el denominado “glue code” para que esas descripciones/especificaciones pueden ejecutarse de forma automatizada. Para esto básicamente escribo código Java usando Cucumber-JVM. Dado que estoy trabajando part-time en este proyecto, aún es muy poco lo que he hecho, pero estoy muy entusiasmado.

Cierro este artículo con una de las frases que más me gustó del libro:

“Test is just another feature of the application, and SETs are the owner of the testing feature.”

 

Project Bootstrap, cómo inicio mis proyectos

Al comienzo de todo proyecto de desarrollo hay ciertas cosas que debemos tener en claro y algunas decisiones que debemos tomar respecto de las herramientas de soporte que utilizaremos. Estas cuestiones constituyen lo que suelo denominar como bootstrap del proyecto. Hace un tiempo grabé este screencast para mis alumnos de UNQ sobre este tema. Para quienes prefieran leer a escuchar, resumo brevemente lo que mencionado en el screencast.

Todo proyecto surge a partir de una visión. La visión es definida por el cliente y es básicamente el justificativo del proyecto. El cliente decide llevar adelante el proyecto para resolver un problema o para aprovechar una oportunidad. Es fundamental que todos los involucrados del proyecto conozcan la visión, por ello siempre suelo ponerla por escrito y compartirla con todos los involucrados.

Al desarrollar proyectos es común hablar de “el cliente”, un término que me resulta inapropiado, pues lo considero ambiguo. Personalmente prefiero utilizar términos más específicos. Desde mi perspectiva todo proyecto tiene un sponsor, que es aquel que brinda el apoyo político para que el proyecto se lleve adelante. En forma simplificada podemos decir que el sponsor es quien está pagando por el proyecto. Por otro lado tenemos al experto de negocio, que es quien conoce en detalle la problemática a resolver. En ocasiones puede que el sponsor sea también el experto de negocio, pero no siempre es así.

Ya en el terreno de las herramientas, hay algunas cosas básicas como:

  • un repositorio de código: git, mercurial, subversion o el que más te guste
  • una herramientas de gestión: Jira, Redmine, Trello, una hoja de cálculo o simplemente un tablero de post-its
  • un servidor de integración continua: Jenkins, TeamCity, Travis o el que gustes

Adicionalmente me parece importante contar con:

  • Un ambiente de prueba/demo: este es un ambiente “neutro”, fuera de la máquina del programador, donde se instala la aplicación en cuestión de forma frecuente. Este ambiente es usado para las revisiones de iteración. De cara a mitigar riesgos, debería ser lo más similar posible al ambiente productivo
  • Projectpedia: es básicamente una wiki que concentra información del proyecto. Con información del proyecto me refiero a cosas bastante variadas que van desde información de contacto de los involucrados, hasta la visión del proyecto y la información de acceso a los distintos ambientes, etc, etc

¿y tu? ¿usas algo más?

Cliente no es un buen término

Es común al trabajar en proyectos hablar de “el cliente” como un rol. Yo mismo lo hago todo el tiempo, pero no me parece apropiado y tengo algunos argumentos al respecto.

Desde el punto de vista humano me parece muy frió: “el cliente y el proveedor”, siento que genera un división muy fuerte y que en cierto modo denota un conflicto de intereses. Personalmente me  gusta ver a mis clientes como socios, pues al fin y al cabo ambos sabemos que para lograr un proyecto realmente exitoso tenemos que lograr una situación ganar-ganar.

Desde el punto de vista técnico el término cliente me resulta ambiguo. ¿quien es el cliente? ¿es quien paga por el proyecto? ¿o es quien conoce los detalles de la problemática a resolver?  Para evitar este tipo de ambigüedades es que prefiero utilizar otros términos más específicos, sobre todo al comienzo de los proyecto para dejar bien en claro las responsabilidades de cada involucrado.

En primer lugar todo proyecto tiene un sponsor que es quien está pagando por el proyecto y que también suele representar la parte política del proyecto frente al resto de la organización.

Por otro lado tenemos al experto de negocio que es quien tiene el conocimiento de la problemática a resolver.

Finalmente tenemos al usuario que es quien utilizará la solución de software provista.

Puede que estos tres roles terminen ocupados por la misma persona o no, eso suele depender del contexto del proyecto. En mi experiencia, en organizaciones grandes es muy común que estos roles sean ocupados por distintas personas. Tomando como ejemplo el caso de la petrolera que compartí hace un tiempo, el gerente general ocupaba el rol de sponsor, el responsable de compras era el experto de negocio y los analistas del área de compras eran los usuarios.

QA no es testing

Una confusión que muy frecuentemente encuentro es el uso del término QA para referirse a cuestiones de prueba. Voy a intentar aclarar un poco esta confusión.

Existen diversas definiciones de calidad. Una de ellas es la que define calidad como ausencia de defectos. Esto nos lleva a definir qué entendemos por defecto. En términos generales podríamos decir que un defecto es una no conformidad con los requerimientos/especificaciones.

El testing es una actividad enfocada en la detección de defectos. El testing por si sólo no asegura la calidad de un producto. Decir que al testear se mejora la calidad de un producto, sería equivalente a decir que por pesarse se baja de peso. El testing brinda información sobre los defectos de un producto, del mismo modo que una balanza brinda información sobre el peso. Luego en base a esa información uno puede tomar acciones correctivas, como hacer dieta en el caso de sobrepeso, o corregir los defectos en caso que estos sean de una severidad no aceptable. En términos más formales el testing es denominado Quality Control (QC).

Ahora bien, testear para detectar defectos y luego corregirlos, es un enfoque de calidad en cierto modo reactivo. Esto nos lleva a la pregunta: ¿podremos hacer algo más proactivamente para asegurar la calidad de nuestros productos?

Si aceptamos que la calidad del producto está influenciada por el proceso de construcción del mismo, entonces podríamos tomar un enfoque de calidad más proactivo, definiendo tareas en nuestro proceso de cara a asegurar la calidad. Esto es precisamente lo que se denomina aseguramiento de calidad o simplemente QA (Quality Assurance).

Entonces, siendo explícito: el aseguramiento de calidad (QA) tiene que ver con procesos, no con testing. Claro que existe cierta relación entre estas dos actividades, pero también es cierto que cada una de estas actividades requiere de distintas habilidades.

Resumiendo:

QA = Quality Assurance = Aseguramiento de calidad -> Procesos
QC = Quality Control = Control de calidad -> Testing

Webinar: Técnicas de versionado para Entrega Contínua

El próximo miércoles (mañana), voy a estar dando un webinar sobre este tema. La idea es ver los conceptos básicos de la práctica Continuous Delivery y enfocarnos en cómo manejar nuestro repositorio de código para facilitar la entrega continua. Presentaremos algunos conceptos y estrategias, y veremos como llevarlos a la práctica utilizando la herramienta Git.

En página de registración encontrarás más detalles sobre este webinar.

Durante el webinar, recibiré consultas a través de Twitter (@kleer_la & #kleerScm).

 

Cierre de cuatrimestre en UNQ, cuarta promoción

Terminó el cuatrimestre y se fue la cuarta promoción de Elementos de Ingeniería de software desde que la materia está a mi cargo. Este cuatrimestre la materia tuvo un enfoque mucho más práctico. El primer mes de clase fue más o menos igual que siempre, pero luego nos fuimos enfocando mucho más en cuestiones cercanas al código. Para ello trabajamos con Ruby+Padrino, GitHub, Travis y Heroku. Lás últimas 5 semanas los alumnos trabajaron en grupo en el desarrollo de distintas aplicaciones. La aplicaciones en sí no fueron más que una excusa para poner en práctica los temas de ingeniería abordados durante la materia: estimación, planificación, comunicación, gestión de alcance y cambios, etc, etc.

Otro cambio que tuvimos este cuatrimestre fue que usamos un sitio basado en Jekill para llevar la bitácora de clase.

Para cerrar la materia cada grupo de alumnos grabó un screencast contando el trabajo realizado, les dejo los links a los videos:

Al igual que el cuatrimestre pasado, conté con la colaboración de Natalia, una ex-alumna de la materia (¡gracias Nati!)

Algunos números frios:

  • Alumnos anotados: 10
  • Alumnos aprobados: 8 (2 alumnos abandonaron la materia en el primer mes de clase)
  • Nota final promedio: 8,25
  • Fueron un total de 28 clases
  • Tuvimos otra vez la visita de un profesional de la industria (¡gracias Emilio!)

Estoy muy contento con como salió la materia y según lo hablado en la restrospectiva, los alumnos también quedaron contentos. Una cosa en particular que me puso muy contento, es que logré mejorar la forma en que doy feedback, algo que había salido de la restrospectiva anterior.

eis2013-1

Nota: el ícono representa un alumno que estuvo ausente el día de la retrospectiva.

eis-2013-1b

Curso de Extreme Programming y tutorial de desarrollo de aplicaciones con Padrino

Desde hace un tiempo vengo trabajando con mi colegas de Kleer en la preparación de un curso de desarrollo de aplicaciones con prácticas ágiles. En cierto modo es un curso intermedio/avanzado de Extreme Programming. Durante el curso se verán temas como SCM, BDD, TDD, Mocking, Continuous Delivery, Pair programming, Design Patterns, SOLID, etc.

La idea del curso es ver estos conceptos y poner manos a la obra programando una aplicación empresarial utilizando Github, Travis, Ruby, Padrino y Heroku, entre otros. Dado que la idea es trabajar sobre los conceptos previamente mencionados, nosotros proveeremos una aplicación base sobre la cual se desarrollará el curso y sobre la que los alumnos deberán implementar nuevas funcionalidades poniendo en práctica los conceptos/prácticas en estudio.

Aprovechando el desarrollo de esta aplicación, he decido ir generando una serie de artículos y videos a modo de tutorial, para mostrar cómo encarar el desarrollo de una aplicación utilizando las mencionadas prácticas y herramientas.

Para facilitar las cuestiones de setup, estoy utilizando una máquina virtual con Linux Mint 14. Pueden descargarse la imagen base en forma totalmente gratuita desde virtualboxes.org. Esta imagen se puede ejecutar en diversas plataformas utilizando Virtual Box.

Una vez que tengan la imagen funcionando, es necesario instalar algunas cosillas, cuyo detalle pueden ver aquí.

En los próximos días comenzaré a publicar videos de 5 minutos mostrando como desarrollar la solución utilizando las mencionadas herramientas.

Continuous Delivery, una visión de alto nivel

No quiero en detalle sobre definiciones, beneficios e impedimentos relacionados a esta práctica. Creo que hay suficientes información en la web al respecto (con solo googlear el término continuous delivery encontraremos alrededor de 18.000.000 resultados).

Asumiendo que el lector ya está familiariza con las definiciones básicas, quiero compartir mi visión de esta práctica.

Un concepto central en la práctica de continuous delivery es el denominado Deployment Pipeline. El mismo modela el proceso de la organización para materializar la implementación de una idea/necesidad del negocio. Dos puntos a destacar:

  • Hablamos de organización y no de equipo, porque este proceso involucra varios sectores de la organización más allá del equipo de desarrollo.
  • Hablamos de materializar una idea/necesidad de negocio. No basta con que el software esté desarrollado, la necesidad no se resuelve con el código dentro de un repositorio o en un paquete .zip, sino con el software corriendo en un ambiente donde pueda ser utilizar por el cliente.

La primera parte de este este Deployment Pipeline debe darlo el equipo de desarrollo con la implementación de la práctica de integración continua, lo cual puede llegar a ser un interesante desafío si el equipo trabaja sobre código legacy (entiéndase legacy=sin pruebas). Aquí es importante destacar que la incorporar la práctica de integración continua va mucho más allá de poner un Build Server a monitorear el repositorio, compilar el código y ejecutar los tests.

La segunda parte del Deployment Pipeline es la que involucra a otros sectores de la organización, pues es la parte que recorre los distintos ambientes hasta llegar a producción.

 

Un caso real de conflicto entre atributos de calidad

Existe entre ciertos atributos de calidad una relación conflictiva. Un caso típico lo representan seguridad y usabilidad.

Una técnica común para implementar seguridad, es pedir al usuario el ingreso de una clave a la hora de realizar ciertas operaciones. En algunos casos, esta técnica se lleva al extremo pidiendo al usuario confirmación, re-confirmación e ingreso de clave, por operaciones que el usuario considera “triviales”. Esto suele fastidiar al usuario, el cual, con el fin de tener una mejor experiencia en el uso de la aplicación, termina desactivando las verificaciones de seguridad. Aquellos que han trabajado con Windows Vista es posible que hayan experimentado una situación de este estilo.

Esta semana viví otro caso similar: tuve que realizar unos tramites en la AFIP. Un portal tan seguro como anti-usable. Ventanas emergentes por todos lados, postback contantes, scrolls infinitos, etc, y casi nada de web 2.0. Pero más allá de esto resulta que la clave de usuario (llamada clave fiscal) tiene asociada un nivel de seguridad que habilita a realizar ciertas operaciones. En mi caso necesitaba realizar una operación que requería un nivel de seguridad de clave superior al que yo tenia. Entonces, me surgió la gran pregunta: ¿cómo hago para elevar el nivel de seguridad de mi clave? Respuesta: es un trámite personal que debe realizarse en una oficina de la AFIP, ja!

Ojo, esto no es una crítica a la AFIP, sino un ejemplo real del conflicto entre estos dos atributos de calidad: seguridad vs. usabilidad.