¿Los evaluadores tienen que mirar el código fuente?

¿Qué tan necesario es para los evaluadores hacer pruebas de caja blanca además de las pruebas de caja negra? Como desarrollador, considero valioso que una persona con mentalidad de control de calidad revise mi código y busque puntos débiles, pero también parece que si un probador no técnico es lo suficientemente exhaustivo y metódico, puede cubrir bien la aplicación.

Las pruebas de recuadro blanco pueden revelar casos de prueba importantes que no serían obvios mientras se mira solo la aplicación desde la perspectiva del usuario, pero las pruebas de recuadro negro exclusivamente pueden llevar menos tiempo y aumenta significativamente la cantidad de personas que son capaces de hacer el trabajo . Además, el desarrollador debe realizar una cantidad no trivial de pruebas de caja blanca antes de que llegue al probador, ¿estoy en lo cierto?

Las pruebas de caja blanca y caja negra son dos habilidades diferentes: alguien experto en una no necesariamente es experto en la otra.

Gran parte de lo que hace QA será la prueba de caja negra, asegurándose de que el sistema funcione "como se anuncia" y, en este sentido, no necesitan saber cómo funciona el sistema para hacer un buen trabajo. De hecho, el conocimiento del código puede llevarlos a las mismas trampas que atrapan al desarrollador incauto haciendo sus propias pruebas. Es mucho mejor que no tengan ideas preconcebidas sobre cómo el desarrollador piensa que se supone que el sistema debe funcionar.

Eso no quiere decir que no debería haber pruebas de caja blanca, que es (en parte) lo que es la prueba de unidad de desarrollador. Un buen conjunto de pruebas unitarias debería probar entradas válidas, entradas inválidas y entradas de caso límite. Sin embargo, no creo que siempre sea necesario que QA haga esto, aunque no sea por otra razón que es realmente responsabilidad del desarrollador.

Sin embargo, como SnOfus señala en sus comentarios, una buena prueba de caja blanca puede ser extremadamente útil.

He tenido buena suerte en mi equipo con las revisiones del código de prueba. Los probadores tienden a mirar el código de la misma manera que a las aplicaciones: se preguntan "de qué manera este código no funcionaría", y a menudo encuentran problemas que los programadores no encuentran durante la revisión del código.

Para una respuesta más larga, escribí este artículo .

Absolutamente

Como dije en respuesta a @ChrisF: QA está ahí para garantizar que el código de producción funcione siempre . Sin ser exhaustivo, eso significa saber qué plataformas se esperan, cuál será el estado de la máquina implementada, cuáles son los requisitos de rendimiento y estar seguros de que cada línea tendrá éxito.

IME, un buen equipo de control de calidad escribirá, leerá y revisará más código que el equipo de desarrollo.

Si sus equipos de funciones y los equipos (principales) de corrección de errores no tienen un desarrollador de control de calidad que trabaje para diseñar la API, el flujo de trabajo, la seguridad y todos los demás aspectos de la función / corrección, entonces realmente se está perdiendo una fortaleza que su departamento de control de calidad puede aportar a su producto mientras se está desarrollando .

No es necesario en absoluto. En lugar de que una persona con mentalidad de control de calidad revise su código, le recomiendo que un desarrollador revise su código. Además, si está escribiendo pruebas unitarias a medida que desarrolla su código, que una persona con mentalidad de control de calidad revise su código no es el mejor uso del tiempo del control de calidad.

La persona de control de calidad no debe centrarse en CÓMO se escribió el código, sino en QUÉ hace el código.

La persona de control de calidad no debe centrarse en las pruebas funcionales y aprovechar los requisitos para realizar esas pruebas. Al final, las pruebas unitarias y un probador funcional de control de calidad que haga pruebas de caja negra serán el mejor uso de todos.