Recientemente he estado retomando mi cuenta de instagram y note con asombro que aún existen ideas erradas de lo que un ingeniero de pruebas y sobre el aporte que puede hacer al equipo. Y desde entonces he estado pensando en la importancia de proveer información de valor para el equipo como encargado principal de la calidad del producto.
No me mal interpretes, de nuevo sigo defendiendo la idea que la calidad de un producto es tarea de todo el equipo y no solo del grupo de pruebas de software.
Entonces digamos que todos los Ingenieros de prueba tenemos cómo misión fundamental encontrar los errores de aplicaciones y de esta manera demostrar su presencia dentro del software.
Otro punto importante es recordar que nuestro trabajo no es demostrar la ausencia de errores, sino la presencia de ellos, porque como principio de pruebas entendemos que el software sin errores es una falacia. Y qué cosa más tediosa es trabajar con un desarrollador que no lo entiende y se escuda en que hacer código es una tarea de mucho trabajo que un ingeniero de pruebas no puede entender. No debes entender de códigos para esperar una aplicación con la menor cantidad de fallas posibles, pero de nuevo, debe haber apropiación y compromiso con cada línea que se genera de código para pensar en un producto de calidad.
Pero que ocurre cuando en medio de tus pruebas, encuentras un error y debes reportarlo, es alli donde comienza un trabajo muy importante de tu rol como ingeniero de pruebas, recuerda que tu no eres lla persona que terminará decidiendo cual o que cosa se va a reparar, pero si serás la persona encargada de pasar información de valor para el resto del equipo.
Quiero partir hoy desde la premisa que eres lo que escribes y lo que reportas, y que es por ello que ello que debes tomarte el tiempo de hacer de tus reportes una herramienta de poder, y presentar a cada equipo la información más pertinente para cada proyecto.
Sin querer entrar en la “definición de hecho” o “el camino feliz” de cada funcionalidad, lo que si quiero compartir contigo son algunos consejos que te pueden ayudar a crear un reporte de errores de valor, no solo para el equipo de desarrollo, sino para todos los involucrados en el proyecto y producto que estas probando.
Y en mi experiencia te puedo asegurar que mucha gente lee y confía en tu reporte de error, así que debes tomarte ell tiempo de hacerlo informativo y entendible. De esta forma te aseguras de proveer valor a la compañía.
Teniendo en mente que tus reportes sirven para muchos propósitos dentro del equipo, y que si estas leyendo este articulo, muy probablemente sepas que tus reportes deben tener un titulo, un autor, unos pasos para replicarlos, la version probada y probablemente el servidor donde probaste dicha funcionalidad, lo que voy a enumerarte son ocho factores generales que debes tener en cuenta cuando estes redactando tu reporte y las razones por las que debes hacerlo:
Se específico sobre el problema encontrado y las funcionalidad que afectan
Esto alerta a los demás sobre los defectos, y ayudan a los programadores para reconocer los problemas.
Incluye información de versiones y plataformas donde le hayas probado:
Pues los reportes alertan a las personas de los problemas en especificaciones y posiblemente en la documentación de tus pruebas, de los documentos de los usuarios o en herramientas de desarrollo.
Usa un lenguaje natural y evita tecnicismos:
Pues tus reportes proveen información de fondo para los escritores técnicos quienes están desarrollando soluciones para posibles problemas de la aplicación y su propia página web.
Añade una descripción del problema:
Pues de esta manera también puedes evidenciar posibles problemas que se puedan enfrentar el entrenamiento de uso con el usuario.
Incluye información de fechas de reporte del error o si es lago que tiene mucho tiempo en espera de ser reparado:
Pues esta información es clave para el departamento de ventas sobre posibles problemas que pueda encontrar el usuario por errores que fueron medianamente reparados, o que no han sido aún reparados del todo.
Clasifica tus reportes y agrúpalos según la funcionalidad:
Esto provee información a los gerentes sobre el estado y la calidad del producto que esta bajo desarrollo.
Asegúrate que sean leídos por mas personas de tu equipo y que su contenido sea legible y digerible:
Pues de esta forma puedes proveen con la información de tus reportes un punto de partida para sugerir arreglos y mejoras en el comienzo de cada sprint.
Si bien es altamente probable que tengas muy marcada la idea que tu trabajo es solo revisado por el grupo de desarrolladores, te aseguro que al pasar del tiempo muchas decisiones vendrán de esos reportes y la manera de hacerlos mas poderosos es entendiendo que siempre es un trabajo informativo para terceros y que probablemente muchas personas tomen tu trabajo como punto de inicio para conocer y dominar el producto.
Y si bien tu tarea principal es encontrar errores, tu rol dentro del equipo es fomentar la calidad del producto y del proceso de creación de la aplicación, así que domínala y vuélvete un experto en su manejo.
Déjame tu opinion de este articulo y compártelo con otros ingenieros de desarrollo y de pruebas si te ha gustado.
También puedes acceder a mis cursos en los siguientes link:
También puedes suscribirte a mi canal de youtube, si aun no te has suscrito y ayudarme a seguir conectado contigo. Nos vemos en un próximo artículo.
