Probando con Marick and Cia

 In Development

El sábado 13 de marzo la gente de agilismo.es (powered by Autentia) la volvieron a liar. Tuve la oportunidad de asistir al último “sarao” que montaron, esta vez: Probando con Marick….si, si, Brian Marick uno de esos “locos” del Manifiesto ágil.

El caso es que allí estábamos unas 40 personas disfrutando de la charla del gran Marick, muchas caras conocidas de otros “saraos” y sobre todo mucho programador suelto.

De todo lo que se contó me quedo con algunas ideas interesantes:

-“No es lo mismo un programador con 10 años de experiencia que un programador con 1 año que hace 10 veces lo mismo”….lógico!. Lo que me da que pensar: ¿Cuántos desarrolladores con 10 años de experiencia conozco? Lo normal en este pais es ir abandonando la programación según vas avanzando en tu carrera profesional, hasta definitivamente colgar el Eclipse (o netbeans, no vamos a ser racistas) y acabar con el Project y el Word. En otros paises no ocurre esto, la profesión de “programata” está mejor vista, sino ahí tenemos al genial Marick.

– Marick distingue dos tipos de bugs:

1) Los que el programador comete por un fallo en su codificación, es decir, los bugs de toda la vida.

2) Los fallos propios de haber codificado correctamente un problema pero con una solución que no era la esperada, es decir, haber entendido mal la historia de usuario inicial y haber hecho otra cosa, que funciona, pero no es lo que el usuario esperaba.

Los primeros deberían ser detectados por el TDD, de ahí obtendremos una de las ventajas de usarlo: Disminuir el número de bugs en nuestro software.

Lo segundo, me gusta porque los fallos funcionales para Marick también son bugs.

– Los test de interfaz de usuario con herramientas como Selenium no son recomendables ya que son test muy frágiles y fáciles de romper. Cuando mas débil (fácil de romper) sea un test peor estaremos haciendo TDD.

Además de todo esto realizó un juego en el que exponía cada una de las partes que componían una aplicación y de como debían interactuar unas con otras. La conclusión principal: Hay que hacer Test Unitarios de cada elemento antes de que se pongan a interactuar unos con otros (integración).

En fin, solo me queda agradeceros tanto a agilismo.es como a Autentia por brindarnos la oportunidad de compartir estos momentos y a todos los que allí estabais por compartir vuestras experiencias y conocimientos.

Nos vemos en el siguiente.

P.D.- Las fotos son cortesía de Semurat (http://www.flickr.com/photos/semurat/sets/72157623496473597/)

Recent Posts
Comments
  • Enrique Amodeo
    Responder

    Muy bueno este post, la verdad es que me hubiera gustado ir a este evento.
    Especialmente genial dos comentarios de Marick:
    * Los bugs funcionales. Sí, los analistas funcionales también cometen errores y son tan bugs como los de un programador.
    * Test de interface de usuario son frágiles.

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.