archivo

Archivos Mensuales: mayo 2011

El concepto de testing de caja gris es simple, se basa en la realización de testing de caja negra basado en casos de prueba realizados por personas que conocen el programa por dentro. Se entiende que de esta forma las pruebas realizadas son más efectivas porque se conocen las partes del código que pueden resultar más conflictivas: por su complejidad, por su acoplamiento con otras clases, etc…

Por regla general cuando nos encontramos que el equipo de desarrollo diseña casos de prueba se centra en aspectos funcionales sin tener en cuenta cómo se ha desarrollado la aplicación, algo que resulta curioso ya que se tiene conocimiento suficiente para poder diseñar este tipo de pruebas. ¿Por qué sucede esto? Pues porque no se le da la importancia que se merece al testing y luego pasa lo que pasa y se entregan los productos en el estado en que se entregan.

Parece que todo lo ajeno a la construcción es accesorio, prescindible o incluso una pérdida de tiempo. Yo no entiendo el desarrollo de software sin la realización de un testing acorde a las características del proyecto, como tampoco lo entiendo sin una documentación en función de lo que se necesite.

Ver también: Testing de caja blanca.

Esta estrategia de testing se centra en la verificación de las funcionalidades de la aplicación: Datos que entran, resultados que se obtienen, interacción con los actores, funcionamiento de la interfaz de usuario y en general todo aquello que suponga estudiar el correcto comportamiento que se espera del sistema.

Por tanto la diferencia fundamental respecto al testing de caja blanca es que en este caso no se trabaja con el código fuente sino con el programa, no importa en este caso cómo se consigue la funcionalidad de un módulo sino que el mismo responda de la manera en que debería según las especificaciones del sistema.

No se trata de elegir una estrategia u otra, sino de elegir para cada proyecto lo que más convenga. Probablemente lo más acertado sea aplicar técnicas de ambos mundos, aunque lo más normal suele ser que se apliquen técnicas de caja negra con técnicas de caja blanca que suponen menos esfuerzo (o ninguno) como el análisis estático de código. Al final siempre será cuestión de disciplina, analizar coste y beneficio y la apuesta por una metodología o forma concreta de trabajar.

Ver también: Testing de caja gris.

Comenta James Marcus Bach que (traducción libre): “Nuestras ideas básicas sobre qué prácticas son mejores o peores están fuertemente influidas por aquellas personas que percibimos que saben cómo desarrollar software”.

No solo nuestra experiencia y formación orientan nuestra forma de trabajar y de afrontar los proyectos de desarrollo de software, también nuestra observación, nuestra capacidad de asimilar las prácticas que le funcionan a otras personas (tal vez no siempre, pero que sí pueden ser efectivas).

¿Elegimos referencias? Sí, ¿absolutas? tal vez no. En cualquier caso, cerrar los ojos y no aprender todo los que los demás (compañeros, clientes, proveedores) pueden ofrecernos supone ponernos obstáculos a nosotros mismos, si no hemos acertado siempre tendremos la posibilidad de rectificar en un futuro, tal vez haya supuesto un error para el presente, pero una experiencia favorable para el futuro.

La documentación en un proyecto de desarrollo de software son piedras que vas guardando en la mochila hasta que te cansas y las vuelves a dejar poco a poco en el suelo.

Cuando se decide qué documentación debe llevar un proyecto hay que analizar la utilidad final que se le va a dar, ¿va a servir exclusivamente para guiar este desarrollo?, ¿se va a utilizar en siguientes iteraciones del producto?, ¿se va a actualizar o simplemente se va a tomar como elementos de consulta?.

Si se decide que acompañe al proyecto a lo largo de su ciclo de vida (incluyendo sus mantenimientos) hay que saber que mantener esas piedras en la mochila va a requerir un esfuerzo y que cuanto más crezca el sistema más se va a necesitar. Está claro que siempre puedes tirar alguna piedra o decidirte por tirarlas todas pero cuando lo hagas lo mismo estás tirando muchas horas de trabajo que no han cumplido su propósito y que no has invertido en hacer un sistema mejor.

No estoy en contra de la documentación en los proyectos, los seguidores más antiguos de mi blog habrán leído artículos donde expresaba mi amor (sobre todo) y también mis desencuentros con los entregables documentales. ¿Dónde me encuentro ahora? Pues en intentar ser lo más práctico posible e intentar, donde puedo y cuando puedo, porque tengo reglas que cumplir en mi organización, que la documentación que acompañe al proyecto sea la que necesita (a mi juicio) y que sea de la mayor calidad posible.

Muchos de nosotros hemos trabajado en proyectos o en tareas dentro de los mismos de las cuales teníamos serias dudas de su viabilidad y más que probablemente nuestra intuición (que no lo es tanto porque se basa en la naturaleza del trabajo a realizar, en el entorno y en nuestra experiencia) ha acertado en la mayor parte de los casos.

Siempre hay tiempo para perder dinero y tiempo porque cuando lo hacemos estamos desechando otras opciones, tal vez, con mayor probabilidad de éxito o bien le estamos dedicando menos esfuerzo a aquellas tareas en ejecución o ya ejecutadas (y que están en mantenimiento) que marcharían mejor si le dedicásemos más atención.

Hay que perder el miedo a decir que no, a comentar a tus superiores que el proyecto que quieren emprender presenta riesgos que hacen peligrar su viabilidad,, como es lógico exponiendo tus razones para ello. Después si el proyecto no va bien es a ti a quien van a pedir responsabilidades, por lo que lo mejor es que si no lo tienes claro, lo digas.

¿Qué finalmente deciden realizarlo? Pues nada, tenemos jefes y estamos en una organización, por lo que nos tocará intentar hacer el trabajo de la mejor manera posible, pero por lo menos habremos hecho lo que teníamos que hacer, advertir de manera razonada de la existencia de riesgos.

Resulta complicado acertar al detalle el porcentaje de avance de un proyecto, teniendo en cuenta la cantidad de contingencias que pueden ocurrir en el proceso de desarrollo.

Con independencia de lo anterior hay que tratar de ser lo más objetivo posible, nos podemos equivocar, pero en base a una reflexión objetiva de cómo ha discurrido el proyecto hasta ahora y qué hitos se han cerrado. Las estimaciones optimistas (sobre todo) y las pesimistas son una fuente de problemas, por ejemplo:

– Una estimación optimista da lugar a falsas expectativas, si el proyecto va de una determinada manera y estimas que el grado de avance es mayor, están dando a entender una expectativa de beneficio o una expectativa de pérdida (en el caso de que el proyecto vaya realmente mal) que después no se va a cumplir y muy probablemente tus jefes te pedirán explicaciones, además, si no se detecta la existencia de posibles problemas, difícilmente se pueden establecer medidas para intentar reconducir los trabajos.

– Una estimación pesimista puede crear en el proyecto un falso estado de alarma. Es cierto que es una forma de poder cubrirte las espaldas ya que se supone que será complicado que el proyecto vaya peor que lo que se indica, pero esto puede provocar una presión innecesaria en el proyecto que podrá impactar en la productividad, bajo presión se puede trabajar mejor durante un tiempo, pero a medio/largo plazo resulta perjudicial.

Además, si la estimación pesimista prevé unos resultados aceptables (pero que son inferiores a lo que refleja el grado de avance real del proyecto) puede provocar tanto en el gestor como en el propio equipo de proyecto una sensación de conformismo que haga que realmente la tendencia sea cumplir la previsión pesimista en lugar de conseguir los objetivos que realmente se podrían haber logrado.

Martin Fowler, firmante del manifiesto ágil, experto en refactorización, programación orientada a objetos y programación extrema, realiza en el libro “Refactoring: Improving the Design of Existing Code”, la siguiente reflexión (traducción libre): “Cuando sientas la necesidad de escribir un comentario, intenta primero refactorizar el código de manera que cualquier comentario se convierta en innecesario”.

Una de las características de la programación extrema y de las metodologías ágiles en general es la percepción de que salvo que sea absolutamente imprescindible hay que huir de los comentarios en el código, ya que la naturaleza del software es adaptativa, cambiante y al final se terminarán dejando comentarios que nada tienen que ver con la naturaleza actual del código.

Lo mejor es que el software sea autocomentado, para ello la codificación tiene que ser de calidad y ser resultado en muchos casos de varias revisiones (refactorización) para hacer la clase o el método mucho más interpretable e inteligible.