Cronica VLCTesting (Parte 2)

On 26 diciembre, 2013, in Conferencias, by twiindan

Seguimos con la crónica de VLC Testing 2103. Después de la gran ponencia de Javier Garzas y de poder reposarla en el tiempo de la comida (por cierto, felicitar al catering que nos ofreció una muy buena paella) llego la parte que siempre he considerado más complicada para los ponentes… la hora de la siesta! Eso no impidio a Joaquín Aspiazu el cual nos explico con gran lujo de detalles todo el flujo del desarrollo de software de su empresa PeerTransfer. Para mi fue un gran ejemplo de como una empresa pequeña puede tener un buen modelo de desarrollo de software para conseguir un software de calidad. En este caso, Joaquin explico como utilizaban Kanban para el desarrollo, y para ello no le hizo falta más que una transparencia para poder desarrollar toda la ponencia!

Después me encontré con una ponencia que me sorprendió muy gratamente sobre el tema de la formación a cargo de Maria Luisa Morales. En esta ponencia explicaba varios ejemplos donde ponía en contexto el poder contar con gente formada en temas de testing, o tener gente más amateur que no tenían conocimientos técnicos i de la disciplina. Una frase que me calo mucho y que he podido comprobar más de una vez durante mi experiencia laboral fue “Si crees que formar a tu equipo resulta caro, mira cuanto te cuesta tener gente sin formación”.

Como última ponencia me encontré con Federico Toledo que explicaba diferentes perspectivas sobre la automatización de software, también muy enfocado a temas prácticos y ejemplos para explicar cuestiones tan importantes como el coste, o el mantenimiento de estos. Una presentación un poco introductoria pero que permitió después una charla mucho más profunda con Federico Posteriormente sobre temas de automatización demostrando realmente su expertise.

Ya para finalizar el día se realizó una pequeña mesa redonda donde pude participar como experto junto con Javier Garzas, Federico Toledo, Francisco Sanchez y Santiago Begué. Hubo preguntas muy interesantes, pero personalmente me fallo un poco el formato debido a que las preguntas ya se habían hecho con anterioridad y provoco que no hubiera excesiva participación del publico, donde creo que deber jugar un papel fundamental para que funcione correctamente una mesa redonda.

Con esto finalizo el primer día de las conferencias, pero continuo con unas cervecitas y unas pizzas en un bar para hacer un poco de networking, todo ello preparado por el grupo TrobaTest. 🙂

Como conclusión del evento, creo que han madurado mucho las conferencias, siendo sincero y comparándolo con el evento anterior al que fui en el 2011 creo que ha mejorado muchísimo ya que no es una conferencia tan comercial como ocurrió en la anterior edición, pero si que creo que aun tiene margen de mejora. Hay que reconocer que el lugar y la sala ha sido mucho mejor, y que el catering también ha estado a la altura. Con esta tercera edición el evento esta madurando y se esta consolidando como unas conferencias nacionales dentro del territorio y esperemos que así sea durante los siguientes años, y que intente explotar en mayor medida la fusión entre universidad y empresa en el mundo del testing y de la calidad de software.

Happy Testing!

 

Tagged with:  

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?

Tagged with: