Los tests automáticos tienen sentimientos

…y no solo sentimientos, también pueden tener bugs. Incluso peor, pueden fallar ocasionalmente (flaky tests en anglosajón) y ello puede llevar a ponerlos en cuarentena en la ejecución de los builds bajo el lema «ya arreglaremos los tests más tarde», un «más tarde» que no llega nunca, perdiendo cobertura de pruebas lenta y dolorosamente.

Ignorar temporalmente tests que fallan a veces para conseguir un «green build» es válido, pero no arreglar o eliminar esos tests que no son de confianza no lo es. Con esta idea en mente escribí esta carta en nombre de un test ignorado, publicada en el blog de desarrollo de Atlassian.

Espero que te guste 🙂

De testers y code reviews

Hola, me llamo Mauri y yo también he ignorado las revisiones de código con la excusa de que son «terreno de los desarrolladores».

¡Pero ya no! Desde que trabajo en Atlassian que me he dado cuenta que, para que la calidad escale con el desarrollo, hay que invertir esfuerzos en la prevención por delante del control o la mitigación, y un buen lugar para prevenir son las revisiones de código, que acostumbran a ocurrir antes de cualquier testing hands-on.

STASH13_PRactivity

Y no quiero oir a nadie diciendo cosas del estilo «pero yo no soy desarrollador» o «es que no sé leer código», porque no hace falta ser un developercon213añosdeexperiencia para mirarse una revisión de código. Además, leer código es más fácil de lo que aparenta, y las revisiones de código son un buen lugar por donde empezar, ya que los cambios estan asociados a una funcionalidad o bugfix, de tal manera que el código se puede vincular fácilmente a su objetivo.

Listado de 5 cosas al azar que te interesan, como tester, de las revisión de código:

  1. Mayor conocimiento de los sistemas y aplicaciones: como tester más funcional, seguro que ya te conoces todos los recovecos de la interfaz de usuario, ¿por qué no ampliar ese conocimiento con nociones del funcionamiento de la cara interna de las aplicaciones?
  2. Inspiración para futuras fases de pruebas: dependencias inesperadas, secciones complejas, condicionales gigantes, dudas sin resolver expresadas en los comentarios… Este tipo de cosas son pistas invaluables para exprimir las aplicaciones durante la fase de pruebas. Este conocimiento, bien usado y con práctica, hace que el testing sea como jugar al Trivial Pursuit consultando la Wikipedia.
  3. Mejores tests automáticos: el input de un tester en las pruebas automatizadas que vengan con el código (tests unitários, de integración o de lo que sea) puede ser muy útil para que las nuevas funcionalidades nazcan con una cobertura exhaustiva e útil, más allá de los happy paths.
  4. Se cazan bugs también! Que sí, que sí, que se puede! Y no solo bugs, también comentarios confusos, errores de formato, secciones poco claras, tests unitarios que no testean nada… Las revisiones de código son el momento idóneo para corregir este tipo de problemas.
  5. Respeto: también puedes ganarte (más) el respeto de los desarrolladores con tu participación e interés en las revisiones de código, gracias a tus consejos y aportaciones en las mismas. Sabrás que estás por el buen camino cuando tu input sea solicitado en ellas o (todavía mejor) cuando algún desarrollador te pida consejo sobre qué casos de prueba automatizar ¡en la fase de codificación!

Estas son las mías, pero hay muchas más razones por las que, como tester, puede ser interesante participar en las revisiones de código. ¿Cuáles son las tuyas? ¡Cuéntamelo en los comentarios!

Sobre Heartbleed…

Ahora que Heartbleed está prácticamente olvidado, he escrito un post-muy-corto-de-menos-de-300-palabras-que-se-lee-en-2-minutos sobre el mismo. Lo he hecho en inglés y en Medium, con y sin motivo. Este es:

Screen Shot 2014-04-23 at 9.15.09 am (2)https://medium.com/p/a01202354647

 

En resumen, por si el inglés o los links no son lo tuyo: Heartbleed fue descubierto casi simultáneamente por dos organizaciones ejecutando procesos de testing rutinário. Gracias a esto, solamente hemos tardado 2 años en descubrir uno de los mayores bugs de la historia. Esto demuestra que hay que seguir testeando, que el testing nunca se acaba, que el siguiente test puede destapar el próximo Heartbleed, o prevenirlo, con suerte.

Nace Test Huddle!

Listado no exhaustivo y no ordenado de cosas importantes para mejorar como tester:

1. Estar al día de lo que sucede en el sector

2. Conocer a otros testers de otras empresas, ciudades, países, realidades… 

3. Participar activamente en eventos relacionados con el testing

4. Hablar sobre testing! Expresar opiniones y defenderlas! Valorar y comentar las opiniones de otros!

 

Todo esto y más te lo pueden ofrecer las comunidades on-line de testing y calidad del software, y ahora tenemos una nueva comunidad en el mercado y una nueva oportunidad de subirnos al carro conducido por la comunidad global del testing. Se trata de Test Huddle, comunidad asociada a EuroStar, una de las conferencias de testing más importantes del mundo.

logo_headerx2

Yo ya me he registrado, y tú?

Australia, Sydney, Atlassian… y yo.

El pasado 28 de Enero fue mi primera jornada laboral como QA Engineer en la oficina central de Atlassian, en Sydney (Australia). Ha sido un proceso muy largo y complicado en muchos sentidos, aunque tampoco esperaba que entrar a formar parte de una de las empresas más punteras en el desarrollo de software del mundo fuera fácil… 😉

photo (6)

Estoy muy contento por haber llegado hasta aquí aunque, tras tres semanas trabajadas, puedo decir que el nivel es altísimo, así como el volumen de información, lo que implica que me voy a tener que poner las pilas a muchos niveles para estar a la altura de mis nuevos y nombrosos compañeros.

Seguiremos informando desde Down Under, saludos!