Control de Calidad de tus Tareas

Revisa los deberes. Esas tres palabras nos introdujeron a todos al fascinante mundo del control de calidad. Desgraciadamente no solemos progresar mucho más que ir y dar una vista rápida a lo hecho. ¿Resultados? Desde errores ortográficos grandes y pequeños hasta acabar diciendo lo contrario de lo que queríamos decir.

Llevo unos meses aprendiendo Ruby on Rails, un lenguaje de programación. En estas navidades me introdujeron al concepto del Desarrollo Guiado por Pruebas¹, que consiste en establecer primero una prueba que debe superar una aplicación, ver donde falla y hacer las mínimas correcciones posibles para que pase la prueba. El ciclo se va repitiendo las veces necesarios hasta que la aplicación haga bien todo lo que se supone debe hacer.

Pues bien, en Hacker News² me tropiezo con un artículo de Tony Osbourn³ en el que sugiere que este mismo esquema puede aplicarse a un artículo de un blog. Primero escribimos en forma de requisitos, las pruebas que el artículo debe pasar, después escribir el mínimo necesario para pasar dichas pruebas. Una vez, estemos seguros que nuestro artículo, “aprueba”, podemos pasar a una edición más profunda.

Ejemplo

Por ejemplo, para este mismo artículo, podría haber establecido las siguientes tres pruebas:

1. Este post debe introducir al diseño basado en pruebas
2. Este post debe expandir el post original de Tony Osburn a otras materias además del blog
3. Este post debe programarse para 30/1/2014

Hasta este momento, supongo que he cubierto la primera prueba y, me tendréis que creer, que también he preparado la tercera. Queda la segunda, que paso a explorar a continuación. Esto va a quedar un tanto raro, pero en fin, ahí va…

Más allá de los blogs

Como podrás ver, esta forma de trabajar tiene aplicación más allá de los blogs. En primer lugar a cualquier pieza escrita, desde una manual a un libro de texto y desde un artículo a una novela. También, ¿por qué no?, a un texto jurídico, incluso una sentencia: “Esta Sentencia deberá considerar todas las piezas de prueba presentada… etc” e ir revisando punto por punto. En general, puede aplicarse a cualquier cosa que no se caiga, estropee o muera mientras la vamos haciendo. En otras palabras diseñar una casa así, está bien. Irla construyendo y ver si se cae o no, pues no tanto.

Aquí os dejo la idea.

Notas

1. Tienes más detalles en este artículo de wikipedia
2. Hacker News de ycombinator
3. A case for writing unit tests for your blog posts