Desarrollador de soluciones y probador de soluciones

Ambos, pero en un nivel diferente. El desarrollador debe comprender las características básicas de la arquitectura para poder entregar un software que funcione, se desempeñe y se escale. El probador necesita saber más sobre cómo está configurado el sistema para poder resolver posibles problemas de implementación y configuración.

Es muy importante que ambas entidades comprendan la arquitectura de programación, ya que será útil al informar los errores o al buscar los errores o fallas en el software. Si el probador no entiende la arquitectura de programación, no sabrá todas las dimensiones para probar.

Vamos a empezar desde el principio.
Los objetivos finales del desarrollador y el probador son opuestos:

• El desarrollador trabaja para demostrar que la aplicación funciona como se esperaba;
• El probador trabaja para probar que la aplicación no funciona como se esperaba;

" Como se esperaba " significa literalmente que la aplicación funciona exactamente como se especifica en los requisitos.

Sin embargo, los requisitos no se pueden codificar ni probar directamente. Para ello, se crean dos artefactos:

• Especificaciones de Diseño (DS), que contienen la Arquitectura de la solución;
• Casos de prueba (TC), que contienen detalles de secuencias de uso individuales;

El desarrollador implementa el DS escribiendo el código.
El probador prueba el código de acuerdo con TC.

Como ves, solo el desarrollador tiene necesidad directa de estar profundamente familiarizado con la Arquitectura .
Sin embargo, si el evaluador también está familiarizado con él, tendrá una buena oportunidad para encontrar problemas específicos del diseño que, de otro modo, serían difíciles de detectar.

Lectura adicional: Modelo V