Mucho se ha escrito y discutido ya sobre la relación entre los tester y los desarrolladores en diversos proyectos y metodologías de trabajo.

Hace tiempo existía un documento de requisitos, de este documento se derivaba el diseño, del diseño el código, del código los casos de prueba, etc. Había una clara separación entre desarrolladores y testers, ambos perfiles incluso se ubicaban en lugares diferentes dentro de la empresa, separados físicamente.

Un tester y un desarrollador trabajando en el mismo proyecto tenían dos estilos de vida totalmente diferentes. Los desarrolladores creaban el software de cero solo para ser señalado por un tester en los puntos donde no funcionaba. Por otro lado los tester esperaban y esperaban hasta que los desarrolladores les daban el software para probar, que por lo general, se rompía en el momento de ejecutarlo.

Otro elemento que causaba fricción entre las partes eran los espacios de tiempo. Un tester solo podía trabajar si tenía un producto acabado. Mientras se realizaban las pruebas pertinentes, el equipo de desarrollo empezaba nuevas funcionalidades para mantener la productividad, entonces cuando un tester encontraba un defecto los desarrolladores acusaban al tester de hacerles perder el tiempo de desarrollo en la corrección de defectos.

Toda esta tensión entre ambos equipos va en contra del objetivo de negocio de tener un producto acabado y de calidad.

Con la llegada de las metodologías ágiles estos problemas han quedado atrás. La solución es pensar en un solo equipo y no en varias partes. Pequeños equipos donde el cliente, developers y testers se sientan en la misma mesa o trabajan en la misma sala.

Cuando todo el equipo está cerca se empieza a hacer algo que se había olvidado, comunicar. Las barreras del lenguaje desaparecen y ambas partes tienen las mismas expectativas en cuanto a lo que funciona y a lo que aún no está resuelto.

Lo que más ayuda es que ambas partes trabajan en la misma iteración, por tanto, en un mismo sprint (ciclo de trabajo), una funcionalidad es desarrollada, probada, y los defectos encontrados son corregidos. Los tester tienen influencia en el desarrollo detectando errores en fases tempranas del desarrollo y decidiendo que hacer con ellos. Por otro lado, los desarrolladores también tienen una ventaja, los errores detectados y solucionados en el mismo sprint de desarrollo no son «errores reales».

Cuando el tester prueba desarrollos que los programadores están haciendo en ese mismo momento, su feedback ayuda mucho a que el trabajo del programador sea mucho más eficiente. El feedback lo  debe dar lo más rápido posible desde que el programador acaba de desarrollar la funcionalidad, incluso durante su desarrollo, piensa que si un desarrollador acaba hoy una tarea y mañana tiene el feedback lo tendrá fresco y todo será mucho más fácil para todas las partes.