Un plan de pruebas tiene que cumplir una serie de premisas o pautas para estar completo o al menos, que pueda definirse como “master”, por así decirlo.
Lo primer que debemos de pensar es: ¿que tenemos que probar?
Depende de lo que tengamos que probar, acondicionaremos nuestros casos de prueba hacía una cosa u otra. Por ejemplo, no es lo mismo, probar algo de back, que de front, o probar un CRM. Cada aplicativo es diferente y en base a lo que se quiera probar, debemos adaptar el plan y darle un enfoque u otro o, incluso, darle una profundidad más o menos clara.
Una vez que hemos pensado eso, debemos de enfocarnos en: ¿cuando hay que probarlo?
Cuando tenemos tiempos de entrega definidos, sabremos a que enfrentarnos y que tipo de casos podemos realizar, si más profundos o no o si, en algunos casos, si el tiempo aprieta, incluso solo hacer un listado a modo de checklist, que nos paute las pruebas pero no dediquemos un gran esfuerzo a escribir, con detalle todo. En eso está la cuestión, en el detalle, no solo que queramos, sino que nos de tiempo a realizar.
Esas dos preguntas, ocasionan una tercera: ¿donde lo vamos a probar?
Es esencial, ya que podemos centrarnos en un navegador, en varios, en dispositivos o en algún sistema especial. Esto nos marcará los tiempos de ejecución y nos dará, a grandes rasgos, la dedicación y esfuerzo que debemos de introducir en ellos.
Si tenemos claras, al menos, estas tres cuestiones, podemos comenzar a realizar una planificación coherente y que nos dará los tiempos necesarios para adecuarnos al proceso de desarrollo que tengamos en un determinado proyecto.
Independientemente de las anteriores cuestiones, nos debemos de plantear, también, ¿quien lo va a probar?
Lo ideal es que los casos de prueba los pudiera ejecutar cualquier persona, en cualquier momento, independientemente del equipo, si está o no en ese proyecto o si se dedica a probar o no, pero muchas veces, los tiempos aprietan y no es posible dar todo el detalle que quisiéramos.
Si lo vamos a probar desde un área de Calidad, los casos de prueba estarán escritos de una manera en concreto, centrándose en las pruebas a realizar y quizá no tengan que tener tanto detalle, ya que, lo más probable es que una persona que se dedique a probar, realice más de lo que se puede llegar a aplicar en el caso y puede completarlo adecuadamente.
Si, en cambio, lo que queremos es que se pruebe desde otras áreas, nos tenemos que enfocar en escribir detenidamente los pasos y describir cada acción con el máximo detalle, sabiendo que si no tenemos el negocio en la cabeza, podemos ejecutar una batería de pruebas, sin problema.
Después de hacer esto, lo ideal sería que un equipo de producto, nos pudiera validar los casos realizados, ayudándonos a saber si, efectivamente, el plan que hemos realizado cubre toda la funcionalidad a probar o existe alguna casuística que no hubiésemos tenido en cuenta, detectándola en ese momento y, posteriormente, cubriéndola con un caso de prueba.
0 Comentarios