Iniciado por
Drumpi
Swapd0: No, el manual definitivo no lo tiene que hacer el desarrollador. Al desarrollador se le da un documento con características que se deben implementar, pero este debe devolver un documento indicando la organización del código, los bloques funcionales, etc... y entre todo eso, cómo funciona la interfaz o cómo está implementada. Pero no es un manual como los que leemos, sino un documento hecho de forma rápida, que lo entienda un ingeniero o alguien familiarizado con los ordenadores. Es más, debería ser simplemente una corrección del manual de características con los cambios que se han hecho por problemas del diseño o cosas que no se han tenido en cuenta.
Quieras o no, el desarrollador debe hacer más que programar. Es un peñazo, pero debe DOCUMENTARLO TODO, y eso debería incluir un mínimo manual de uso, porque es el último que realiza cambios a la interfaz.
Splinter: no te equivoques, que yo he dicho que he tenido que hacer los scripts del análisis antes de ejecutarlos, a mi no me los daba nadie.
Los "test case" sí que me los pasaban ya hechos, pero teníamos gente que se dedicaba exclusivamente a ello, no nos venían hechos desde el cliente. Pero claro, si el test case te dice "generar un documento" ¿tú que haces? A mi no me daban un manual de uso (sólo es de despliegue). Así que iba y buscaba el típico botón de la hoja de papel blanca con la esquina doblaba, lo pulsaba y a esperar lo mejor. Generalmente funcionaba, pero luego te decías "¿y lo hará a través de archivo->nuevo...?", lo probabas y fallaba... y eso deberían considerarse dos test case diferentes.
O peor aun: ambos métodos te funcionaban, pero luego cogías, editabas el documento y te dices "¿y si le doy ahora para generar un segundo documento?". Le dabas al botón y ¡CRASH! ¿Qué haces? ¿pones fallo al generar el documento? ¿lo pones en la edición? Al final tenía que añadir otro test case, darlo como fallo crítico y mandarlo de vuelta... Bueno, no, tenía que realizar el resto de pruebas y después mandarlo de vuelta.
El chequeo manual es más efectivo en la localización de errores, pero mucho más lento, y por tanto, costoso. Pero todo lo que implica QA se hace en el grupo de QA, test cases incluidos, y si no hay una documentación del producto mínima, no puedes hacer nada. Yo no puedo probar un Hadooken si no me han escrito en alguna parte que se ejecuta con la combinación de botones tal, y eso es un manual de uso que viene de parte del desarrollo, pero no necesito un artwork de Ryu con flechitas de colores.
Marcadores