Probar nuevamente

En mi último post en Proyectos Beta escribí unas sugerencias para mejorar el trabajo de QA (y creo, muchas de ellas se aplican realmente a cualquier trabajo), en este post voy a comentar un poco de mi vivencia como tester y coordinador de pruebas.

Muyyyy loco…

Me suelo poner muy loco cuando encuentro los mismos errores en un sistema que estoy testeando.
No me malinterpreten, me encanta encontrar errores. Cuanto más errores encontrados… mejor! Creo que es uno de nuestro objetivo como equipos de QA. Tampoco quiero significar que me guste (o disfrute) que el software tenga errores. Por favor, no piensen mal.
Siento que como tester (y/o como parte de un equipo de QA) tenemos la misión de contribuir al proyecto, encontrando errores que si se nos pasaran por alto, los podría encontrar el cliente, impactando esto en la imagen y la credibilidad de la empresa desarrolladora, generando retrasos por retrabajo, etc.
En definitiva siento que ayudamos al desarrollador a mejorar el producto. Y pienso (o deseo) que aquel que considere al producto de software, un poco como «suyo” va a sentir cierta gratitud con nuestra contribución.

Y… ¿Cómo es eso?

Y entonces… ¿Cómo es eso que «me pongo loco»?… Pues así es, me indigno cuando encuentro otra vez LOS MISMOS errores. (Tranquilos que no lo exteriorizo de ninguna manera molesta o «peligrosa». A lo sumo hago un descargo en un post 😀 ).
Años pasaron desde que se comenzó a desarrollar (y a probar) software y ya sabemos que es altamente probable, que un sistema salga con errores (o altísimamente improbable que no los tenga). Pero sería muy importante y muy «sabio» que como equipo de desarrollo «capitalicemos» los errores que son encontrados y reportados por un equipo de QA.
Estimados desarrolladores. Líderes de proyectos… ¡Por Dios! No nos hagan reportar otra vez los mismos errores! ¡Ustedes lo pueden evitar! De lo contrario nosotros y ustedes.. TODOS… perdemos tiempo (y alguien pierde dinero). Nos aburrimos como QA… y tenemos la sensación que no nos dan importancia..Y aunque debe ser muy cómodo reparar el mismo error en diferentes parte del código (porque lo hicieron antes) no creo que los haga sentir muy productivos.
Y para ilustrar mejor el tema, aquí van….

algunos ejemplos:

Si ves que reporto muchos errores de ortografía en una versión del programa. ¡Pedile por favor a tu equipo que instalen un corrector! Para la próxima versión de prueba no se deberían reportar más errores de ese tipo (así de tontos).
Si ves que te reporto un error (o dos) de ordenamiento incorrecto en una grilla del sistema (ABM), revisá que en todas las grillas no pase más. No te limites a corregir el error reportado. No esperes que el equipo de QA te reporte el mismo error en todas las grillas de datos para corregirlo.
Hay como estos, muchos más ejemplos.

Te paso un par de tips

¿Y cómo puede el equipo de desarrollo sistematizar ese proceso? ¿Cómo se puede aprovechar lo que reporta QA, no sólo para arreglarlo sino para que no vuelva a suceder?… Dos cositas: «Guía de desarrollo» y «comunicación a todo el equipo».
Es extremadamente útil la creación de una guía de desarrollo colaborativa con los puntos que el equipo debe tener en cuenta para desarrollar de manera “homogénea” (evitando por ejemplo, que los mismos controles en diferentes formularios muestren un comportamiento diferente). Esta guía deberá ir creciendo (con participación de desarrollo y QA) a medida que surjan las incidencias.
Y otra cosa importante es una buena comunicación a TODOS los miembros del equipo de desarrollo para que conozcan y utilicen esta guía.
Esas son dos actividades (con un costo mínimo en esfuerzo y tiempo) que pueden ahorrar al proyecto una gran cantidad de tiempo, dinero y frustraciones.
Pongamos por favor foco como equipo en meter nuevas funcionalidades y no en «parchar errores» (y menos aún si son repetidos).

Quisiera saber qué piensan los desarrolladores y testers sobre esta idea… Pueden dejar sus comentarios al pie de la nota.
En un próximo post voy a escribir un ejemplo de guía de desarrollo (lo más estándar posible), y verán que cuestiones tan ‘obvias’ no lo son tanto.

¡Feliz codificación y hasta la próxima!


Comments

    1. Excelente pregunta. Considero que alguien debería estar encargado y responsable del diseño del producto (Un analista o arquitecto de software o el «product owner»). A él hay que acudir para ‘refinar’ las historias de usuarios cuando hay diferencias de criterios o si la historia es ambigua. Esa es una forma de unificar criterios con el desarrollador.
      Otra podría ser reportando una «mejora» que consideres representa tu criterio. Las mejoras pueden ser analizadas (también por la persona, o grupo de personas, que decide como ‘crece o cambia’ el producto) y podrá ser aceptada o rechazada.
      Muchas gracias por comentar!

Responder a Jaqueline Probst Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *