Muchas veces la gente de QA y de Testing juegan al poli malo y mediante metricas, numeros y KPIs “echamos la bronca” (en sentido figurativo) a la gente de desarrollo por realizar más las cosas. Somos especialistas en obtener numeros del Sonar y indicar a la gente de desarrollo que tiene mucho codigo duplicado, que no cumple las reglas del Checkstyle o que no ha documentado suficientemente bien el código.

Nos encanta dar consejos de como deberían programar para ser más efectivos y sacar un software de mejor calidad, nos encanta recomendar algunas buenas prácticas que hemos leido o hemos visto que han funcionado en otros proyectos y por supuesto nos hace felices saber que estamos ayudando cada día a que la gente de desarrollo programe mejor y con más calidad.

Esto creo que es una práctica muy útil que debemos seguir haciendo, ya que ofrecemos un punto de objetividad que quizás dentro del equipo de desarrollo es más complicado de ver. Pero la pregunta es… ¿Porque no nos aplicamos a nosotros mismos las mismas practicas?

Personalmente creo que es muy importante que tratemos nuestro trabajo como si se tratara del de desarrollo. Que quiero decir con esto? Pues principalmente dos puntos:

  • Tratar nuestros diseños o nuestros tests cases como si de código se tratara. Es decir, si vamos a realizar un mismo procedimiento de test con varios juegos de datos, porque no utilizamos una estrategia de DataDriven en lugar de replicar todo el procedimiento? Si como prerequisito dentro de un test case tenemos un procedimiento de un Test Case anterior, porque no lo referenciamos o lo linkamos directamente en lugar de reescribirlo? Realmente es necesario tener TCs de varias hojas o Prerequisitos de más de media página?
  • Tratar los tests automáticos como si se tratara de código fuente. Porque nos resistimos tanto en subirlos a un sistema de versionado? En el caso de que esten automatizados en un lenguaje de programación, también deberíamos pasarles exactamente los mismos procesos de métricas que el código fuente y actuar al respecto. Otro buen ejemplo puede ser crear objetos reutilizables para no crear código duplicado dentro de la automatización.

Que ganamos realmente jugando con otras reglas? Primero de todo, desconfianza de la gente de desarrollo, ya que si algo es bueno, debe ser bueno para todos no solo para algunos. Segundo más trabajo de mantenimiento y tercero provocar que seguir haciendo las cosas mal por nuestro lado.

En mi caso, hace unos 4 mes aproximadamente tuve que realizar cambios en casi todos mis tests automaticos por no haber utilizado elementos reutilizables… por lo que tenia el código duplicado una cantidad innombrable. El resultado, me costo 1 semana entera adaptar los tests automáticos. Eso si aprendi la lección y aproveche que tenía que rehacer más del 60 % de los tests para construir elementos reutilizables para no tener tanto código duplicado. Hace 15 días me volvieron a cambiar una estructura que me hacía fallar el 60 % de los tests aproximadamente. Me costo adaptarlo 4 horas, por lo que tarde un 10 % de la primera vez.

Otro ejemplo práctico, en el tiempo que mi equipo de desarrollo ha realizado tres mini periodos de refactoring (aproximadamente 3 días cada uno de ellos), yo solo he realizado uno a mis tests que no supero un día! Lo que me hace pensar… realmente soy tan bueno que no necesito refactorings? O es que realmente no le doy la suficiente importancia en mis tests a la refactorización?

Esto son solo unos pequeños ejemplos al respecto, ahora también obligo al equipo de desarrollo a que para cerrarme la tarea de la implementación de los tests se asegure que los he subido al sistema de versionado y que tenga una etiqueta, de esta manera tenemos todo un poquito más controlado.

Y vosotros, aplicáis las mismas reglas a la gente de desarrollo que a vosotros mismos? Utilizáis los mismos criterios? Que procedimientos seguis para comprobar la calidad de vuestros tests?

Share and Enjoy:
  • Facebook
  • Twitter
  • Google Buzz
  • LinkedIn
Tagged with:  

4 Responses to Quien vigila a los vigilantes?

  1. Ines dice:

    Me has dado en la herida!!!, Cuantas veces me pregunto si soy buena en mi trabajo. Efectivamente deberíamos aplicar lo mismo que aplicamos para los desarrolladores a nosotros mismos pero al igual que recomendamos que un desarrollador no se teste a si mismo, creo que tampoco deberíamos auto-evaluarnos; tal vez uno de nuestra propia especie podría sacarnos los colores ¿qué pensáis? o podemos pecar de “Vanity”.

  2. twiindan dice:

    Buenas Ines,

    Efectivamente la autoevaluación es muy costosa y se realiza muy escasamente… como he puesto en el ejemplo a mi me ha costado meses darme cuenta de detalles que debería haber visto desde el principio. Aun así creo que es adecuado que de vez en cuando también nos autoevaluemos.

    Igualmente también como comento es muy importante un poco de objetividad, por lo que puede ser necesario un poco de evaluación de afuera. Una ejemplo en el caso de automatización es intentar obtener las mismas métricas que en desarrollo (codigo duplicado, documentado, checkstyle…) y aplicar los mismos filtros.

    Otra opción es pedir una evaluación al exterior. Aquí hay dos opciones principalmente creo yo, que nos evalue una persona de QA o alguien de otro departamento. Respecto a alguien de QA podemos tener el problema de que tenga miedo de atacar a alguien de la misma especie porque no esta acostumbrado, y puede ver que el tiene los mismos errores, aun así si lo hace correctamente nos puede aportar una información muy valiosa. La otra opción es utilizar a la gente de desarrollo y de producto (dependiendo si nos referimos a automatización o a diseño de TCs). Al estar fuera del equipo o de la disciplina nos puede dar una visión más objetiva pero a la vez puede ser más incompleta o ambigua al no tener el conocimiento completo de nuestra disciplina.

    Igualmente yo creo que lo importante es empezar a realizarlo, y poco a poco quizas ir añadiendo nuevos evaluadores dependiendo las tareas que queremos evaluar. Como comento es algo que me he dado cuenta en los últimos meses, por lo que aun no lo he puesto en practica, aunque si que es algo que quiero impulsar si es posible :p.

    Ya os ire contando

  3. Desde hace un tiempo ya, por mi actividad, he propuesto hacer foco en la prueba individual de componentes, repetible y evidenciada.
    Hasta este post, no he encontrado mas que tibios apoyos a una “buena idea”, pero nunca al punto de “revisar” lo que se hace.

    Como especifico prueba individual de componente, la califico de repetible ya que a lo largo del Ciclo de Vida del componente, se va a repetir, salvo las modificaciones que pueda sufrir el componente que a su vez van a modificar las pruebas.
    Es poco serio a esta altura, encontrar componentes que cuando cancelan, evidencian que no se les ha realizado prueba alguna, pero pasa.

    Como se indica, mas que apoyo, hay que empezar a realizar una mirada introspectiva y crítica hacia nuestro propio trabajo, porque es una real garantía de mejora.

    Saludos,

  4. Raynald dice:

    Justamente estaba hablando con Paul Gerrard (http://gerrardconsulting.com/index.php?q=node/602) sobre la “autocomplacencia” en que se mueven muchos testers. Es como el “espain is different”, pués tenemos el “tester is different” y lo justifica todo (a veces, vale, no digo que sea la regla ;-), pero encuentro que nos falta algo de autocritica, de inovación… Para animar expo:QA he puesto un debate el primer día sobre el tema

Deja un comentario

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