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.

Basado en How to write good test. Top 5 considerations to build software without defects, por Alberto Gutierrez.