A la hora de abordar un proyecto de diseño de pruebas, lo primero que recibimos los consultores es la documentación. En ocasiones, extensísima. En otras, excesivamente escueta… Sea como fuere, resulta fundamental invertir el tiempo necesario en leer y releer toda la documentación -análisis funcionales, diseño técnico, requisitos…-, a fin de entender el alcance global del proyecto e ir fijando ideas, encaminadas, ya en esta primera fase, a alcanzar un diseño de pruebas a alto nivel.
Proceso del diseño de pruebas
Es más, si la documentación es muy amplia, sería muy útil ir desarrollando, a la vez que revisamos, un pequeño esquema sobre cada requisito trazado, analizando a qué funcionalidades afectaría. De esta forma, en una primera vuelta ya podríamos disponer de un borrador de los casos de uso de nuestras pruebas, es decir, un diseño a alto nivel que, sin duda, facilitará mucho la labor a la hora de completar el diseño de pruebas.
Con el diseño definitivo a alto nivel preparado, después de leer y releer la documentación, de haber separado la paja del grano y de haber consultado todas las dudas con el jefe del proyecto (es muy importante que todas las posibles dudas queden resueltas en fase de diseño, lo que nos hará ganar tiempo en el proceso de ejecución), solo quedaría desdoblar los escenarios para cubrir el abanico de clientes u otras tipologías en función del ámbito del proyecto, es decir, el espectro de pruebas.
El siguiente paso sería desarrollar los steps para nuestros casos de uso. Aquí, lo más importante es que estos steps sean claros, concisos y bien estructurados. No importa que salgan 18 pasos, lo importante es que cualquier persona ajena al proyecto, o que no sea la que lo diseñó, sea capaz de ejecutar el PP sin perderse. Hay que aclarar que el número de steps nunca es un indicativo de la dificultad de ejecución del escenario de prueba, más bien suele ser al contrario. Los TCs bien documentados/diseñados son más fáciles de ejecutar para cualquier persona.
En conclusión, los steps deben ser claros para reflejar el objetivo final del caso -el requisito a cubrir- y para detallar lo más fielmente posible todo el proceso E2E de ejecución de la prueba.
La experiencia nos dice que un buen diseño de PP nos hace ganar tiempo en ejecución, por ello, cuando abordamos un nuevo diseño, lo primero que nos debemos plantear no es diseñar para uno mismo, sino, diseñar para los demás.
Por Noelia Martín
Ingeniera QA de MTP