Ciclos de validación personalizados por proyecto

A la hora de tener un ciclo de pruebas adecuado en un proyecto, es necesario que tengamos en cuenta lo siguiente:

  • Tipos de validaciones: tenemos que tener muy claras las validaciones que vamos a realizar, tanto si son manuales o automáticas o si, por ejemplo, van a ser más exploratorias o técnicas. Esto reducirá tiempos, agravios y positivizará el trabajo entre todos.
  • Tiempos de validación: también tenemos que tener muy claro cuales serán los tiempos que emplearemos en la validación ya que si es insuficiente, la garantía no estará adecuadamente ajustada.
  • Ajustar esfuerzos: hay que pivotar entre los momentos de desarrollo y los de pruebas, y saber cuando invertir esfuerzos, sobre todo a la hora de realizar entregas a tiempo o validaciones ajustadas para que las personas de desarrollo tengan tiempo para arreglar lo reportado, al igual que nosotros necesitamos tiempo para validar.

No en todos los proyectos se deben de ajustar los ciclos de validación de la misma manera y sobre todo, debemos de ser conscientes de que jamas debe de entregarse nada sin ser validado de nuevo, sin tener los test de integración ejecutados y en verde y sobre todo, no tenemos que ser “tacaños” con las jornadas de pruebas, siempre es poco, eso lo dice mi experiencia.

En muchas ocasiones, pecamos de utilizar siempre la misma técnica de pruebas para diferentes proyectos, pero esto es un error de lo más común. Cada proyecto es un mundo y hay que ajustar las pruebas que vamos a realizar. También depende mucho de la metodología que utilicemos.

En base a la rapidez y el detalle del desarrollo, podemos adecuar las pruebas y aumentar o disminuir los porcentajes de tipos de pruebas, según el tipo y modo de hacerlas. Si el proyecto tiene grandes cambios y no hay módulos cerrados, las entregas son cortas y rápidas, debemos de tener un porcentaje mayor de pruebas manuales exploratorias que encontrarán defectos de manera rápida y sencilla. En cambio, si tenemos unas entregas mayores, más acotadas y con tiempo suficiente, debemos de potenciar la automatización y robotización de los procesos encontrados y ejecutarlos antes de que la build despliegue al entorno de producción.

Otra buena práctica y muy necesaria, es el adecuarnos a las necesidades que tenga el cliente y sobre todo, apoyarnos en la realización de sus pruebas de usuario, creando una buena documentación. En este mundillo, la mejor, evidentemente, son los casos de prueba. Ya lo hemos visto en otras ocasiones.

Si hablamos de tiempos y momentos de validación no se nos puede escapar ningún detalle, consensuando cada punto de control con la persona responsable del desarrollo y con la del diseño. Las entregas de cada responsable deben de ser lo más ajustadas a los tiempos marcados y añadir el esfuerzo que consideremos para no pasarnos de fecha, ya que todo lo que venga después, comenzará con retraso y empezarán las prisas y los agobios. Si trabajamos en equipo, debemos de asegurarnos de que todo el mundo está cómodo y estemos poniendo nuestro granito de arena a que su día a día sea mejor. Muchas veces, pecamos de egoísmo y nos comemos el tiempo del resto por nuestra comodidad o incluso, por no saber levantar la mano a tiempo para solicitar ayuda y cerrar las cosas como debemos.

Si queremos obtener un ciclo de pruebas adecuado y que nos genere confianza no debemos de dejar de realizar una serie de validaciones, una tras otra, y de la misma manera. Generando reportes e informes que nos aporten una visibilidad del estado de las cosas que vamos a entregar o poner en producción.


Los ciclos de pruebas adecuados siempre nos van a aportar tranquilidad y sobre todo confianza en lo que entregamos.

No hay comentarios:

Publicar un comentario