Desarrollo de software. Antipatrón. Testing de microscopio de fuerza atómica

Que un proyecto sea complejo y/o tenga numerosas resistencias no debe ser excusa para tratar de obtener la mayor calidad posible del software y del producto dentro del contexto en el que nos toque trabajar.

Por ese motivo, los equipos de proyecto deben establecer mecanismos para garantizar esos umbrales de calidad y la coordinación general del mismo debe armonizarlos y exigirlos siempre teniendo en cuenta el contexto y nuestras posibilidades, y también las características del sistema que se desarrolla: un sistema crítico en el que se pone en juego la integridad de las personas, del medio ambiente o la cuenta de resultados de una organización requerirá unos mecanismos de control más estrictos que otros tipos de aplicaciones (en lógica, ese sistema debería tener un presupuesto de trabajo acorde a esas características).

Meses trabajando en el proyecto, con un desgaste importante y en el que cada día es una aventura nueva. Decenas de personas trabajando, de organizaciones y departamentos distintos. Riesgos que aparecen de forma continua. Y detrás de todo una agenda que cumplir, que podremos negociar con el área usuario (o no), pero que al fin y al cabo te establece unos hitos y unos límites.

Este puede ser el día a día de gran parte de los proyectos de desarrollo de software en los que estamos trabajando, en resumen, mucha dificultad y mucho trabajo para conseguir que salga adelante de la manera más satisfactoria posible para todas las partes. Si además, tratamos de que llegar lo más próximo al límite de la calidad que nos permite tener el contexto del proyecto el esfuerzo será muchísimo mayor.

El equipo de testing no debería ser ajeno a las intrahistorias del proyecto, a la complejidad que se está teniendo en el proceso de desarrollo, si me apuráis incluso a ese sufrimiento para sacar el trabajo adelante, por ese motivo recomiendo que los testers participen activamente en los trabajos porque de esta forma su empatía con el resto del equipo le permitirá entender por qué se ha actuado de una manera o de otra.

De esta manera no solo la labor del tester es más efectiva sino que los controles de calidad tienen en cuenta todo lo que ha pasado.

Resulta demoledor para los desarrolladores cuando haciendo una presentación del estado de desarrollo del proyecto al equipo de testing, estos empiezan a fijarse en detalles sin importancia teniendo en cuenta todo lo que se ha tenido que pasar para llegar a ese momento, es como si después de haberte perdido en el bosque un día de tormenta, lo primero que te dicen cuando llegas a casa es que hay que ver que cómo es posible que se te caído un botón de la camisa.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: