"Cuándo los programadores y tester colaboran".

Consejos de programación para #programadores.

-----------------------------------------------------------------------

LIBRO: 97 COSAS QUE TODO PROGRAMADOR NECESITA SABER.

POR: KEVLIN HENNEY.

-----------------------------------------------------------------------

91° "CUÁNDO LOS PROGRAMADORES Y TESTER COLABORAN":

Algo mágico sucede cuando los evaluadores y programadores comienzan a colaborar. Se dedica menos tiempo a enviar errores de un lado a otro a través del sistema de seguimiento de defectos. Se pierde menos tiempo tratando de descubrir si algo es realmente un error o una característica nueva, y se dedica más tiempo a desarrollar buenas funciones de software para satisfacer las expectativas del cliente. Hay muchas oportunidades para iniciar la colaboración incluso, antes de que comience la codificación.

Los evaluadores pueden ayudar a los clientes a escribir y automatizar pruebas de aceptación utilizando el lenguaje de su dominio con herramientas como Fit (Framework for Integrated Test).

Cuando éstas pruebas se realizan a los programadores antes de que comience la codificación, el equipo está practicando el desarrollo impulsado por pruebas de aceptación (ATDD). Los programadores escriben los dispositivos para ejecutar las pruebas y luego codifican para hacer que las pruebas pasen.

Éstas pruebas luego pasan a formar parte del conjunto de regresión. Cuando esta colaboración ocurre, las pruebas funcionales se completan temprano, dando tiempo para exploraciones y pruebas en condiciones extremas o mediante flujos de trabajo del panorama más amplio.

Podemos ir un paso más allá. Como tester, puedo realizar la mayoría de mis pruebas e ideas antes de que los programadores comiencen a codificar una nueva característica. Cuando les pregunto a los programadores si tienen alguna sugerencia, casi siempre me dan la información que me ayuda a tener una mejor cobertura de prueba o me ayuda a evitar pasar mucho tiempo en pruebas innecesarias. Muchas veces hemos evitado defectos porque las pruebas aclaran muchas de las ideas iniciales. Por ejemplo, en un proyecto yo estaba activado, las pruebas de ajuste que realicé a los programadores mostraron los resultados esperados de una consulta para responder a una búsqueda con comodines. El programador tenía toda la intención de codificar sólo búsquedas completas de palabras. Pudimos hablar con el cliente y determinar la interpretación correcta antes de comenzar la codificación. Al colaborar, evitamos el defecto, lo que nos ahorró a ambos mucho tiempo perdido.

Los programadores pueden colaborar con los evaluadores para crear una automatización exitosa cómo buena. Entienden buenas prácticas de codificación y pueden ayudar a los evaluadores a configurar una Suite robusta de automatización de pruebas que funciona para todo el equipo. A menudo, he visto que los proyectos de automatización de pruebas fracasan porque las pruebas están mal diseñadas. Las pruebas intentan probar demasiado, o los evaluadores no han entendido lo suficiente sobre la tecnología como para poder mantener las pruebas independientes. Los tester tsuelen ser el cuello de botella, por lo que tiene sentido que los programadores trabajen con ellos en tareas como la automatización. Trabajar con los evaluadores para comprender qué se puede probar tempranamente, tal vez al proporcionar una herramienta simple, brindará a los programadores otro ciclo de retroalimentación que los ayudará a entregar un mejor código a largo plazo.

Cuando los evaluadores dejan de pensar que su único trabajo es romper el software y encontrar errores en el código de los programadores, los programadores dejan de pensar que los probadores “salen a por ellos” y están más abiertos a la colaboración. Cuando los programadores empizan a darse cuenta de que son responsables de incorporar calidad a su código, la capacidad de prueba del código es un subproducto natural y el equipo puede automatizar más de las pruebas de regresión juntas. Comienza la magia del trabajo en equipo exitoso.

-Janet Gregory-