Esa es la pregunta que lanzé en el sitio Software Quality Assurance and Testing de StackExchange.com en cuyas respuestas pude ver que existe cierto desacuerdo entre la comunidad de testers sobre ese tema y si bien yo tengo una idea clara al respecto, lo que en verdad quería conocer eran las argumentaciones de aquellos que piensan que sí deberían arreglar defectos (algunos defectos) y aquellos que piensan que no deberían para así hacer una síntesis.

No obstante, al poco tiempo otro usuario inicia otro hilo en el que pregunta cuales son las principales responsabilidades de un tester en las que expone una pequeña lista de responsabilidades:

1) Analyzing the Requirements from the client
2) Participating in preparing Test Plans
3) Preparing Test Scenarios,test cases
4) Defect Tracking
5) Preparing Suggestion Documents to improve the quality of the application
6) Communication with the Test Lead / Test Manager
7) Conducting Review Meetings within the Team

Hay tantas cosas con las que no estoy de acuerdo con lo que leo en ese foro que voy a dejar plasmado aquí mi pensamiento. Para comenzar tengo que decir que para mi, la responsabilidad de todos los miembros de un equipo es exactamente la misma: contribuir tanto como sea posible al éxito del proyecto. Entonces, si bien las actividades, especialidades y orientaciones pueden ser distintas, la responsabilidad es la misma.

Ahora bien, si aceptamos esto como válido deberíamos entonces definir qué es un proyecto exitoso y qué no lo es. Para todos aquellos medio entrado en años (de profesión) como yo de seguro les sonará el cuentito llamado OTOBOS que dice que un proyecto exitoso es un proyecto “on time, on budget, on scope” y la verdad es que en los tiempos del los modelos predictivos, en los que el SDLC era por lo general en cascada, mantener al proyecto a lo largo del tiempo on time, on budget y on scope era cosa de magos, se creía que la clave estaba en el *control*. Pues bien, puede que me equivoque pero voy a darles *mi* definición de lo que es un proyecto exitoso:

“Un proyecto exitoso es aquel que nos otorga un alto retorno sobre la inversión a la vez que nos permite crear una relación de confianza con el cliente”

La segunda parte de esta definición habla de la satisfacción del cliente, y puesto que lo que este recibe no es otra cosa que software, deberíamos aclarar qué es un software exitoso para el cliente. Veamos, nuestros clientes no nos encargan el desarrollo de una solución porque no se les ocurran mejores cosas en que despilfarrar el dinero, sino que lo invierten en una herramienta que les permita cumplir con sus metas de negocio. Ya sea optimizando o agilizando la gestión de la compañia, diferenciandose de la competencia, fidelizando clientes, brindando nuevos servicios online o alguna otra ventaja, las empresas *invierten* en software y esperan un retorno de esa inversión. Entonces:

“Un software exitoso (para el cliente) es aquel que le permite cumplir con sus metas de negocios y por tal, le otorga el esperado retorno sobre la inversión”

Y es que de eso se trata y siempre se ha tratado, de dinero. Por lo tanto, la responsabilidad de *todos los miembros del equipo* (sí, testers incluidos) es contribuir a este éxito. Y para esto hace falta mucho más que control y responsabilidades estrictas y predeterminadas.

Continuará…

El buen desarrollador, además de poseer conocimientos y experiencia superiores debe estar infectado por una pasión altamente contagiosa, de esa manera, tarde o temprano el equipo completo se verá contagiado en mayor o menor medida. Esto no es tan inusual, muchas veces nos encontramos con personas que se convierten en referentes no solo de sus equipos sino que también de otros equipos de la misma empresa y todos se benefician de sus conocimientos y su dedicación, especialmente la de enseñar, compartir conocimientos y experiencias… esas cosas que no se encuentran en los libros.

La mayor contribución de estos desarrolladores no suele plasmarse tanto en su código sino en la capacidad de hacer de otros, mejores desarrolladores. Y es que como la experiencia no se adquiere de los libros sino de los errores (no solo propios), es este tipo de desarrolladores el que puede salvar a los menos experimentados de cometerlos. Por último, y para ampliar el punto anterior, otra cualidad necesaria para lograr esto es el conocimiento profundo de la história del software, sus personalidades, sus aportes, sus pensamientos, sus aciertos y errores.

Martin Fowler escribió un interesante artículo llamado TransMediaApplication en el cual explica un problema común que se presenta a la hora de desarrollar aplicaciones para distintos dispositivo. Creo que esta frase resume todo el artículo: A common mistake is to think of different apps for different delivery devices.

En mi experiencia este escenario no se presenta solo cuando se trata de aplicaciones que corren en distintos dispositivos sino que se presenta con mucha mayor frecuencia de lo que se cree. El caso es que lo que Martin Fowler describe es un caso muy particular de un problema mayor: no comprender de que se trata en parte la arquitectura.

Lo voy a explicar con un ejemplo. Imaginemos que una empresa de transporte de carga nos pide desarrollar un sistema de seguimiento de sus vehículos. Estos vehículos tienen rutas específicas por las que deben transitar y tienen además una velocidad máxima autorizada. Nuestro cliente quiere conocer la ubicación de cada uno de sus camiones y sus velocidades (entre otras miles de cosas) prácticamente en tiempo real o con una demora no mayor a 1 minuto.

Para esto, cada vehículo tiene incorporado algún tipo de dispositivo móvil con GPS (o alguna variante). Nuestro cliente quiere visualizar la posición de sus vehículos en un mapa (en principio, mapas de google) y quiere poder hacerlo desde su dispositivo móvil.

Ahora bien, si quien lee esto fuese el responsable del desarrollo de este sistema… ¿por donde comenzaría?. Muchas personas comienzan por interiorizarse sobre los distintos modelos de dispositivos móviles incorporados a los vehículos, comienzan a interiorizarse por los diferentes sistemas de coordenadas que manejan, por los distintos mecanismos de despacho de esas coordenadas, esto es, si tienen conexión a internet continua, si soportan mensajes SMS, si http, tcp o udp, por los servicios que soportan en cada uno de sus puertos, etc. Luego, continúan por estudiar las apis de google maps, los lenguajes en los que esas apis están disponibles y demás consideraciones sobre cómo trabajar con esos mapas. Por último posiblemente, querrán conocer desde que tipo de dispositivo móvil es que el cliente quiere poder consultar la información.

Todo lo anterior está mal! No quiero decir que no deba hacerse ya que tarde o temprano conocer estas cosas será muy necesario, pero está mal porque denota una falta de análisis reflexivo sobre qué es lo que se debe desarrollar y sobre qué es lo que el cliente (negocio) necesita. Veamos, en la descripción del problema existen varios elementos que debemos notar y sobre los que tenemos que reflexionar, estos son: seguimiento, rutas, posición, velocidad, vehículo, dispositivo móvil, GPS y mapa. Existen otros elementos mencionados directa o indirectamente, pero quiero focalizarme solo estos.

A estos elementos debemos agruparlos en dos categorías: esenciales y accidentales. Así, posición, ruta, velocidad y seguimiento son esenciales mientras que dispositivo móvil, GPS y mapa son accidentales. Vehículo, por su parte, es un sinsentido. Si bien por alguna razón, las descripciones de los problemas que nos proveen los clientes suelen abundar en elementos accidentales, es nuestra responsabilidad el identificarlos y catalogarlos como tales en primera instancia.

El sistema a desarrollar debe, en principio, ser totalmente independiente de consideraciones superfluas como el protocolo de comunicación por medio del cual recibirá la posición de los vehículos. Si lo hace mediante TCP, UDP, por mensajes SMS o por correo twitter no es relevante en principio. Tampoco lo es la manera en que la información será presentada, ni si los clientes corren en dispositivos móviles o en PCs de escritorio, sobre un web browser o una aplicación nativa. Todas estas cosas deberán abordarse en su momento pero es importante comprender que se debe esperar a que llegue ese momento.

¿Y mientras tanto qué? Bueno, mientras no llegue el momento de encarar los detalles debemos centrarnos en resolver el problema esencial: desarrollar el sistema de seguimiento. Esto es lo primero!

En el software como en la vida, no distinguir lo importante de lo accesorio es el camino seguro al fracaso.