Sistemas que usan periféricos especiales

Muchos sistemas utilizan o se comunican con periféricos o dispositivos no estándares, como puede ser una puerta automática, una barrera, una impresora de billetes de metro o tren, etc.

En general, es difícil disponer de estos elementos en el entorno de pruebas, especialmente el interno (pruebas alfa, en las instalaciones del desarrollador, de verificación, como queramos llamarlas) ya sea por su tamaño, coste, disponibilidad en el tiempo o pertenecer a otra compañía.

Si no hemos tenido en cuenta esta circunstancia al realizar nuestra estrategia de pruebas (y por tanto, en el planteamiento general del proyecto) nos encontraremos con que el número de pruebas que podemos hacer antes de entregar nuestro producto está limitado por esta causa, y además en elementos cuyo fallo puede suponer un impacto importante en la calidad percibida por el cliente.

Una táctica para solventar este inconveniente es que cualquier implementación de comunicaciones con dichos dispositivos tenga un modo "de prueba" o "test", de tal forma que cuando el sistema está en este modo, la comunicación con el dispositivo es sustiuida por un metodo posible en el entorno de pruebas definido, como puede ser un fichero o impresora.

Este modo "test" debe cumplir con algunas características que nos permitan asegurar que su uso no desvirtua la prueba:

• Debe contruirse de forma que su activación o desactivación no implique la modificación y/o recompilación de código: mediante un valor en un fichero de configuración, entrada de registro, etc
• Para la interpretación/ generación del mensaje, debe ejecutarse el mismo código en el modo "test" que en el modo "en producción".

Ya que esta estrategia implica que el equipo de desarrollo tenga en cuenta en su trabajo las necesidades de pruebas (algo no muy habitual), es necesario conseguir que estas decisiones se tomen lo antes posible en el proyecto, y en el nivel de decisión adecuado que garantice que no se dejaran en el olvido cuando las presiones de tiempo lleguen.

Esta tactica puede extrapolarse a cualquier comunicación que nuestro sistema tenga que realizar con otro sistema del que no dispondremos en nuestro entorno de pruebas, aplicando como siempre el criterio de coste/riesgo correspondiente.