viernes, enero 22, 2010

10 motivos para amar el test ágil

Recientemente, Kay Johansen hizo la pregunta "¿Por qué te gusta probar ágil?". Las respuestas varian desde desde las más serias a las más relajadas.
  • Tener la oportunidad realmente de impactar en la calidad y no sólo documentarla! (Juan Overbaugh) - cuando los defectos son corregidos de inmediato en lugar de ponerlos en una pila de defectos.
  • No más pruebas manuales de los scripts! En cambio, los scripts serán ejecutados automáticamente, proporcionando más tiempo para que el tester realice las pruebas de exploración.
  • Los desarrolladores realmente gustan de esto! - Localizar los problemas antes de la final de la interacción cuando el código está fresco en la mente de los desarrolladores, les ayuda a encontrar el problema.
  • Ahora puede comprobar los recursos antes de que sean escritos! (Kay y Philip) - El tester puede evitar problemas al iniciar la prueba antes que los recursos se definan.
  • Los resultados de las pruebas automatizadas se pueden ver muchas veces al día, proporcionando una rápida retroalimentación después de cualquier cambio.
  • El ambiente está muy orientado al equipo (Juan Overbaugh) - Cada miembro del equipo se preocupa de terminar las pruebas y no sólo el código (Lisa Crispin).
  • El tester puede ocasionalmente ajustar el defecto (Lisa Crispin) - Cada miembro del equipo se siente más cómodo ya que la prueba está automatizada.
  • Ofrece la oportunidad de revisar constantemente las prácticas de pruebas (Adam Knight) - En lugar de simplemente repetir lo que se ha hecho anteriormente, las prácticas son constante revisadas. En el caso de Adam las pruebas que acostumbraban tomar 5 días para ejecutarse manualmente se han reducido ahora a 30 minutos.
  • He pasado mucho menos tiempo en depuración (Adrian Howard) - tengo el feedback prácticamente al mismo tiempo que se ha cometido un error, por lo tanto, suele ser trivial localizar y corregir.
  • Siempre existe tiempo para probar porque la prueba se realiza primero - Josué Barbosa dos Santos contó la historia de trabajar en una oficina del gobierno en Brasil, donde la práctica era probar al final del proyecto. El desarrollo siempre estaba atrasado en el calendario del proyecto y terminaba siendo liberado a los usuarios sin pruebas. Con la introducción de TDD y ATDD las pruebas se ejecutaban mientras que el software era desarrollado.

El número uno para Kay de los motivos de amar la prueba ágil: es que puedo escuchar gente diciendo "este es el mejor proyecto que he trabajado en mi vida!"

Fuente: DosIdeas

5 consejos para construir software sin defectos

Lamentablemente, en algunas organizaciones todavía se considera al testing como la última etapa del proceso de desarrollo. Los desarrolladores entonces cruzan los dedos para programar todo lo más perfecto posible, de manera que la etapa de testing sea una formalidad donde a lo sumo se encuentren errores menores. Por suerte ya hace un tiempo que nos estamos alejando de esta utopía ridícula y vamos avanzando hacia un concepto en donde el testing es una parte integrada al proceso de desarrollo.

El artículo How to write good tests nos deja 5 consejos para aprovechar al máximo este nuevo enfoque.

  1. El código de test es tan importante como el código productivo. Uno de los problemas más comunes al empezar con TDD es que el código de test no es limpio ni tan prolijo como el productivo, de manera que eventualmente cuesta mucho mantenerlo. Para evitar este escenario es importante que el código de test sea tan prolijo como el productivo.
  2. Probar lo más posible, lo antes posible, lo más seguido posible. Es importante no avanzar en el código productivo hasta tener una prueba que verifique que el código escrito funcione como esperamos. Este enfoque logrará que nuestro sistema tenga menos defectos, y además nos dará mayor seguridad a futuro para implementar cambios.
  3. Probar en distintos niveles. No hay que ahogarnos con pruebas de integración que son muy dificil de escribir y lentas para ejecutar (y que, de última, no llegan a cubrir todos los elementos de la aplicación). El mejor enfoque es usar pruebas en distintos niveles. Por ejemplo:
    • Pruebas unitarias, que comprueban los componentes de forma aislada al resto.
    • Pruebas de aceptación, que son creadas por el Dueño del Producto y representan la funcionalidad mínima que tiene que tener la aplicación para poder aceptarse desde la perspectiva del negocio.
    • Pruebas de integración, que no son identificadas por el Dueño del Producto pero las desarrolla QA o el equipo de desarrollo como complemento.
    • Pruebas de interfaz de usuario. Son lentas y además cambian mucho, por lo que hay que mantenerlas separadas del resto de las pruebas.
  4. Integración continua. Las pruebas tienen que ser una parte fundamental e integral del proceso de desarrollo, que ocurren en cada instante del proceso. Todos son responsables por las pruebas, desde el desarrollador hasta QA y el Dueño del Producto. Las herramientas de integración continua nos ayudan enormemente a llevar adelante este desafio.
  5. Usar herramientas y frameworks de testing. No hay que reinventar la rueda, ni trabajar como en la edad de piedra. Tenemos muchas herramientas y frameworks de software libre que nos permiten implementar una estrategia seria de testing.
    • Fitnesse, una herramienta para crear pruebas de aceptación, de forma que personas no-técnicas puedan escribir sus propios escenarios.
    • xUnit, un framework para desarrollar pruebas unitarias, que se integra con todos los IDE de desarrollo en distintos lenguajes de programación.
    • Bugzilla, una herramienta para reportar bugs y hacer su seguimiento.
    • Selenium, una herramienta para crear pruebas automatizadas de interfaces de usuario web.
    • Hudson, una herramienta de integración continua que se usa para asegurar que el código siempre esté funcionando correctamente y pase todas las pruebas.
Fuente: DosIdeas