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!

Qué haces tú para llevar el testing a la universidad?

La calidad, el testing, el Quality Assurance… nuestro campo está profundamente infra-representado en lo que se refiere a la educación reglada española. En parte porque nosotros, los profesionales del sector, dejamos que así sea y no hacemos la presión suficiente para cambiar esta situación que no hace más que entorpecer nuestra tarea: complica el reconocimiento profesional, ofusca el mercado laboral, dificulta el encontrar perfiles jóvenes con formación específica, etc.

Es muy fácil quejarse, muy fácil. Mucho más fácil que hacer algo al respecto, pero si todos aportamos nuestro granito de arena estaremos mejor que si no hacemos nada, con nosotros mismos para empezar, y tal vez demos un paso decisivo en la dirección de conseguir que la educación universitaria contemple el testing como una profesión en si misma.

Mi granito de arena (el primero y, hopefully, no el último) ha sido proponer, perseguir y, al final, colaborar con la Universitat Oberta de Catalunya (UOC) para que empiece a dar cobertura al testing como tal dentro de los estudios de Ingeniería Informática. El primer paso de esta, espero larga y fructífera, colaboración es en forma de un Crash Course de 5 semanas de duración titulado “Introducción a la calidad del software: Técnicas y métricas”, dirigido por Santi Caballé, donde actuaré como colaborador puntual.

Ahora pues, te toca a ti:

Qué vas a hacer tú para llevar el testing a la universidad?

Características de la calidad del software

A veces, el idioma (en este caso, el inglés) es una barrera que separa a las personas de la información que necesitan o les puede ser útil. Por ello, he pensado en ocasiones en traducir material de otros relativo al testing y a la calidad del software, pero es un trabajo árduo, no soy un profesional de la traducción y está el tema de los derechos de autor…

Sin embargo, a veces, el destino te pone las oportunidades en bandeja, por ejemplo: http://thetesteye.com/blog/2013/06/translations-of-quality-characteristics/

Soy un gran seguidor de thetesteye.com en general y del trabajo de Edgren, Emilsson y Jansson en particular, ambos altamente recomendables. A partir de ahí, y contando con la inestimable colaboración de Núria Cardona y Marcel Puchol, después de unos meses de idas y venidas, hoy os traigo las traducciones de su gran “Software quality characteristics” al Español

Características de la calidad del software (ES)

…y al Catalán:

Característiques de la qualitat del programari (CAT)

Ambas traducciones publicadas oficialmente en thetesteye.com en este link. Espero que las disfrutéis!