Cuando comenzamos un proyecto de cero o incluso, si entramos cuando el proyecto ya está avanzado, tenemos muchas dudas e incertidumbre de lo que nos vamos a encontrar, que organización tendrá, que metodología, forma de trabajo...Una solución a todos estos males es la la realización de un procedimiento de testing para ese proyecto.
Un procedimiento siempre nos ayudará a encontrar una forma de trabajo acorde al mismo, una ayuda de lo que tenemos y de lo que podemos hacer, de lo que hasta ahora se ha logrado y lo que podemos aportar nosotros, mejorando el trabajo o ayudando para que sea mejor.
Este tipo de documentos se pueden crear a nivel personal para ver a que nos enfrentamos, ya que, habitualmente, donde entremos, tendremos a un responsable directo que se encargará de velar por estos problemas, aunque en algunos casos, siempre se le puede presentar para ayudarle y mejorar la vida a nuestros compañeros y a nosotros mismos.
En ambos casos, este aporte nos ayudará siempre a ir un poco más lejos y a valorar lo que tenemos hasta la fecha y lo que no, para poder ponerlo en práctica.
El primer punto que tenemos que tener en cuenta es como está actualmente el proyecto, que puntos fuertes tiene, que puntos flacos y que es lo que se está realizando ahora mismo. Una valoración propia de lo que se ve en tu día a día.
El segundo punto siempre tiene que ir dirigido a la linea que tiene que seguir el proyecto en el futuro, que medidas se pueden tomar para mejorar, que medidas hay que reforzar y en que hay que seguir igual porque está funcionando (a veces, todo funciona, no penséis mal). Este punto será decisivo ya que es donde vamos a poner todo nuestro esfuerzo para que algo que no funcione cambie de rumbo y pueda ir del todo bien. Siempre tenemos que valorarlo desde nuestro punto de vista y mirar alrededor, no todo puede estar concentrado en nosotros mismos.
Una vez realizado este primer análisis de la manera actual de trabajo y las mejoras a futuro, podemos comenzar con una metodología de trabajo dentro del programa que utilicemos para hacer nuestras pruebas, por ejemplo:
Si estamos utilizando un gestor de pruebas, como Zephyr, XRay, Testlink o ALM, una manera de organizarse es crear un árbol de carpetas de pruebas donde organizar los casos de prueba de manera correcta, organización por variantes, por módulos, por funcionalidades...existen infinitas posibilidades.
Una buena manera de organizarse, aparte del programa que utilicemos, es una nomenclatura en los defectos, que sea clara y concreta y que de un vistazo podamos detectar de donde es el defecto, que variante o módulo es y en que entorno. Un ejemplo podría ser:
[ENTORNO/EQUIPO] - [VARIANTE/MÓDULO/FUNCIONALIDAD] - [TÍTULO CLARO Y CONCISO]
El entorno lo pongo, ya que en algunos casos, se prueba en dos entornos, uno para pruebas exploratorias y otro de preproducción, pero no llega a ser necesario en muchos casos. También se puede definir el equipo, que puede ser de testing o de aceptación (todo funciona en base a la forma y manera de trabajar).
Estas ideas son solo un caso básico de lo que podemos llegar a realizar, pero puede ser el primer el primer paso para lograr una mejor y eficiente organización de nuestro trabajo y en algunos casos el de nuestros compañeros o equipo.
0 Comentarios