archivo

Archivos diarios: mayo 27, 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.