Tales from the Scrum: TDD en todo

Hace un tiempo escribía sobre

Tales from the Scrum: Terminando la tarea

donde hace hincapié en verificar cada tarea, e introducía algo a discutir en otro post: el concepto de “hecho”, que tiene que estar claro en el equipo y en el dueño de producto.

Hoy quiero comentar sobre algo similar, que podemos hacer en cada tarea: aplicar ideas de Test-Driven Development. No hace falta que Ud. haya aplicado TDD: una disciplina que puede usarse en XP. Lo que quería adoptar de ahí, es, ante una tarea a realizar: escribir primero el test. Esto, a cualquier tarea. ¿A qué apunto?

Veámoslo con un ejemplo. Supongamos que tenemos que migrar una base de datos contable, de un tipo de base datos (digamos Oracle), a SQL Server. Una tarea delicada. No queremos que se pierdan datos. Entonces, antes de comenzar la tarea, vamos escribiendo cuál sería el test, la prueba, a pasar luego de la tarea, para considerarla bien terminada. Podría ser:

- Hacemos select count(*) de la tabla de plan de cuentas en Oracle

- Comparamos esa cantidad con el select count de plan de cuentas en SQL Server

- Hacemos un sum de debe y haber, en Oracle

- Comparamos con el sum de debe y haber en la nueva base de SQL Server

- Tomamos el mayor de la cuenta X (que tiene pocos movimientos) en Oracle y los comparamos con los movimientos del nuevo SQL Server

- Hacemos lo mismo para el mayor de la cuenta Y (la de mayor cantidad de movimientos)

- …

- …

Hasta podemos escribir un programa que haga estas comprobaciones, aunque no siempre es necesario o posible.

La cuestión es comenzar la tarea con un fin en mente: qué tiene que pasar al final para que podamos decir la tarea está bien completa y hecha.

Y esto, hacerlo ANTES de comenzar la tarea. El tener en claro hacia dónde queremos llegar, cuál es escenario final que queremos tener al terminar la tarea.

Lo mismo hacemos con cualquier tarea, ya sea del sprint, o particular nuestra. Si una de las tareas es instalar un servidor Apache, con PHP y MySql, entonces, el test podría ser:

- Escribimos http://localhost en nuestro navegador y aparece la página inicial

- Este servidor viene con phpmyadmin instalado, vamos a ese enlace, y vemos la página de la base MySql local

- Vemos en la lista de base de datos instalada, las iniciales de MySql

- Creamos una base con tal y tal parámetro

- En esa base creamos una tabla con tales y tales características

- …

- Subimos un archivo desde nuestro disco a una aplicación de galería de fotos que ya vino instalada (acá podemos verificar permisos de escritura)

- Repetimos estas pruebas desde otra máquina, llegando al servidor via http://<nombredeservidor>

(este último punto nos servirá para comprobar los permisos y protecciones que puede tener el servidor para los usuarios finales)

Tal vez para Uds. pueda parecer trivial todo esto. Yo quisiera recibir ahora un peso, por cada vez que vi que una tarea como la de arriba, fue considerada terminada solamente con instalar el servidor. O solamente poniendo http://localhost. O por cada vez que una migración de base de datos se dio por buena con simplemente que no de error en el traspaso de datos.

El escribir el test (en un programa, en un papel, en un email) también sirve para que cualquiera en el equipo pueda encarar más fácilmente la etapa de verificación, y para cuando alguna vez haya que repetir esa tarea. Es una especie de checklist de lo que tiene que quedar bien, en “verde” para que consideremos que lo que hicimos quedó bien terminado. Hay otras cuestiones a tener en cuenta, pero el test de cada tarea debería ser lo básico a cumplir.

Como todo en el Sprint, se puede ir refinando este documento, si descubrimos que sería conveniente tener en cuenta alguna otra cosa en la verificación de una tarea. Y el test también sirve para que podamos estimar el tiempo de verificar el trabajo hecho.

Gracias a @gabrielsz que fue el primero que me hizo ver estos temas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 2752, 3463. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>