martes, 30 de septiembre de 2014

La sutileza del testing

En muchas ocasiones al integrarnos a un equipo de trabajo y presentarnos como testers del proyecto se nos puede llegar a ver como los verdugos que vienen a destruir el trabajo de desarrolladores o que se intenta evidenciar los errores en el código, sin embargo, es necesario que hagamos notar que somos parte del equipo y no buscamos evidenciar nada ni a nadie, solo buscamos elevar lo más posible la calidad del producto con el apoyo de los demás integrantes del equipo

Para realizar el reporte de resultado de las pruebas nos vemos en la necesidad de reportar los issues o defectos y que por más que mencionemos que son “del producto” terminan siendo identificados con el nombre de algún desarrollador a cargo.

Esto se intensifica si nos encontramos trabajando en outsourcing, asignados a un equipo probablemente con cliente, en donde muchas veces se nos ve como los extraños del grupo que solo vienen a criticar el trabajo. Por eso es importante tener una actitud que ayude a la integración con el equipo logrando así un impacto positivo a futuro ya que dará lugar a un buen desempeño y una buena prestación del servicio al cliente.

A continuación se listan y definen algunas características y actitudes que pueden ayudarnos y facilitar el trato con el cliente y con los equipos que conformen el proyecto.

Proactividad

De la misma manera en que nosotros estamos buscando la solución a alguna duda o problema en el que nos encontramos, se encuentran los demás integrantes del proyecto; por tanto debemos buscar la forma de aminorar tiempo y esfuerzo en la resolución de los mismos: investigando, pidiendo ayuda, realizando preguntas concretas a otros integrantes del equipo, etc.

Nunca debemos quedarnos sentados esperando a que alguien venga y nos de la solución a nuestras dudas, eso probablemente no sucederá, nos tomará una mayor cantidad de tiempo y nos hará ver perezosos y desinteresados.

Integración con el equipo

Debemos lograr sentirnos dentro del equipo de trabajo y que el resto de los miembros nos identifiquen como parte de él. Podríamos intentar buscar a las personas para tratar alguna duda o revisión de algún issue de forma presencial y no solo por correo, generar propuestas, y tener la iniciativa. Además no hace daño un poco de interacción extra laboral con los compañeros; como salir a comer, participar en fiestas de cumpleaños, algún after, etc.

Conocer el producto.

Hacernos y sentirnos parte del equipo, nos facilitará ser parte también en la construcción de ese producto y esto es un gran aporte a la calidad del mismo. Por ese motivo, se debe tornar desde el foco “destructivo” del testing (intentando rápidamente quebrar el producto en cuanto a su funcionalidad y rendimiento), al foco de “despojar de errores y mejorar la calidad”. Si bien el trabajo es el mismo, y la intensidad también es la misma, este último enfoque es el más adecuado para interactuar con las personas que están construyendo un producto, sean desarrolladores, arquitectos o gerentes de tecnología, entre otros. En nuestras interacciones interpersonales se notará que nosotros de alguna manera “queremos” al producto y estamos preocupados por la presencia de incidentes en él. Nuestra retribución personal ante el hallazgo de incidentes cambia de ser cazadores voraces de los más grandes y mejores bugs, para luego de reparados mejorar la calidad del producto; sino es el encontrar incidentes, lo antes posible, antes de que los usuarios finales los encuentren, y ver el producto, también “nuestro” producto, mejorando su calidad gracias a nuestro trabajo. Y este es uno de los puntos más importantes que quiero destacar.

Comunicación efectiva

No importando el medio de comunicación (correo electrónico, por teléfono o personalmente), debemos ser claros y concisos en los que deseamos dar a conocer. Una buena práctica es resumir la información en forma de esquema y de ser necesaria alguna explicación extra o dar a notar algún dato importante deberíamos resaltar las partes en negrita, utilizar estilos, tabulación, tablas, y colores (sin crear un arcoíris).

No olvidar que le descripción de los defectos o issues encontrados debe ser clara, proveer los pasos a seguir para la reproducción de los mismos; si es necesario mencionar características especiales que pueden forzar la reproducción del mismo (S.O, versión de explorador, datos e insumos utilizados, etc) y adjuntar evidencias del issue con el mayor detalle posible.

Por último no debemos olvidar cuidar que en los estatus se mantengan actualizados los issues, riesgos, limitantes que aún faltan por atender, los que ya han sido cerrados; e indicar la prioridad de los mismos.

Espero que lo anterior les sea de utilidad J