Caja blanca: qué cambia en el encargo

En una prueba de caja negra el evaluador ve la aplicación desde fuera: lo que responde, en qué orden y con qué errores. En caja blanca recibe además el código, y con él la explicación de por qué responde así. Esa diferencia cambia el método: ya no se adivina qué hay detrás de una ruta, se lee; y se pueden encontrar fallos que desde fuera casi nunca se ven, como una ruta que nadie enlaza o una comprobación de permisos que falta en un solo manejador.

Lo que el código no da es la prueba de que el fallo existe en el sistema que corre. Entre el repositorio y el servidor hay configuración, variables de entorno, un proxy delante y, a veces, otra versión. Por eso la lectura se combina con pruebas dirigidas: pocas, elegidas a partir de lo leído, en el entorno que la carta autoriza. Un hallazgo que solo se leyó se puede reportar, pero diciendo que no se confirmó en ejecución.

Un repositorio no es una cosa fija: cambia cada día. Si el informe dice «la función X no comprueba el dueño» y el equipo del cliente ya la cambió, nadie podrá reproducir el hallazgo ni saber si la corrección llegó antes o después. Por eso la carta de un encargo de caja blanca fija la rama y el commit exactos, y cada hallazgo cita ese mismo identificador.

La misma precisión vale para el entorno donde se confirma: si el entorno de pruebas corre otra versión, una prueba que falla no desmiente la lectura, solo dice que se probó otra cosa.

Abre el laboratorio y lee la carta.

Casi todo repositorio trae código que no es del cliente: dependencias copiadas, kits de proveedores, ejemplos. Ese código se ejecuta junto al suyo y conviene leerlo para entender cómo se usa, pero sus fallos no son del cliente: se reportan a quien lo mantiene, y analizarlo a fondo consume horas que la carta no compró. Lo mismo pasa con las pruebas automáticas y sus datos, que no llegan a producción.

El árbol del repositorio dice cuánto pesa cada parte. Compáralo con la carta antes de planear la lectura.

En la reunión de inicio el equipo de desarrollo suele ser el mejor aliado del evaluador: explica la arquitectura, confirma qué versión corre y responde dudas. A veces también ofrece atajos que la carta no cubre. El criterio es el mismo de cualquier encargo: lo que no está firmado no se hace, aunque lo ofrezca alguien del cliente con buena intención.

Lee las notas de la reunión.

Con miles de líneas de código y pocas horas, no todo se lee con la misma atención. El plan de este encargo lo dice: primero lo que recibe datos de fuera, lo que decide permisos y lo que mueve dinero o datos personales; el resto, por muestreo. En una tienda en línea eso suele significar las rutas y su middleware, la cuenta del cliente, los pedidos, el panel de administración y todo lo que habla con la pasarela de pagos.