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!

Nace #SOFT #WAR #FAIR :-)

Los que me conocen, saben que siempre he estado en contra del eterno enfrentamiento entre testers y desarrolladores, ya que ambos perfiles “construyen” el software y lo hacen conjuntamente, así que un enfrentamiento a este nivel no hace más que estropear la dinámica del equipo y alejarse del objetivo común.

La pregunta es…

¿Qué haces tú para superar este tópico?

Personalmente, aparte de mantener cada día el objetivo común en mi mente y trabajar en pos de la harmonía dentro del equipo tecnológico, hoy mismo he hecho un paso más adelante para romper con esta lacra que no hace más que atrasarnos a nivel mundial como profesión:

He montado un blog colectivo de desarrollo y calidad!

Pues sí, nace #SOFT #WAR #FAIR, un blog de desarrollo de calidad y calidad del desarrollo, escrito de momento a seis manos, que espero que tenga una larga vida y lista de adeptos y colaboradores 🙂

Captura de pantalla 2013-10-26 a la(s) 12.06.52


Espero que lo disfrutéis!

http://softwarfair.wordpress.com/

[Encuesta – Resultados] Demuestra tus asunciones!

[Encuesta – Resultados] Demuestra tus asunciones!

Siempre me ha preocupado la sobrevaloración de las capacidades técnicas en la carrera del tester, probablemente debido a mi falta de bagaje académico en este aspecto. He dejado constancia de mi opinión (que son importantes per se sobrevaloran a veces) en diversos sitios, por ejemplo aquí mismo y, recientemente, en una conversación en LinkedIn al respecto, por decir dos de ellas.

Cuando vi los resultados de la encuesta sobre el liderazgo en el número de Marzo del “The Testing Planet” me sentí aliviado: las habilidades técnicas / de programación son posicionadas en sexto lugar (de siete) como respuesta a la pregunta “¿Qué habilidades crees que se necesitan para ser un líder influyente y eficaz en el sector del software testing?”, y la comunicación es la primera. Estos son los resultados completos a la pregunta:

The Testing Planet - Leadership survey results

Después de ver esto, sentí la urgencia de escribir sobre ello, sobre cuán diferentes son las prioridades por aquí, donde las habilidades técnicas se valoran mucho más que las comunicativas, analíticas o estratégicas. Pero antes de hacerlo, decidí poner a prueba esta presunción, así que hice una encuesta yo mismo, con esta pregunta solamente, a la comunidad Hispana que me sigue, para probar mi teoría. Traduje la pregunta, la posteé y la distribuí a través de las redes sociales para obtener algunas respuestas.

He dicho antes que no tengo bagaje técnico, pero sí que tengo una licenciatura en Investigación de Mercados (escépticos: lo podéis ver en mi perfil en LinkedIn ;-)), entonces estoy al corriente de algunos de los sesgos derivados de comparar los resultados a ambas preguntas: las muestras no tienen el mismo tamaño ni los mismos rasgos demográficos, hay matices en la traducción al castellano que hacen que las preguntas o su interpretación no sean 100% equivalentes, puede haber duplicidad en las muestras… y, sobretodo, las encuestas no son una ciencia exacta, pero te pueden ayudar a entender una tendencia. Así pues, más allá de los números, estaba interesado en el ranking de las capacidades, y los resultados fueron… EXACTAMENTE LOS MISMOS!

Resultados de la encuesta sobre habilidades en este mismo blog

Las habilidades técnicas o de programación están posicionadas en sexto lugar de siete y las de comunicación e interpersonales en primer lugar. Estoy realmente sorprendido (y encantado) con estos resultados, ya que me han ayudado a consolidar dos átomos de aprendizaje:

  1. Demuestra tus asunciones, puesto que pueden estar completamente equivocadas

  2. Potencia tus habilidades comunicativas!

Así pues, qué has hecho hoy para ser un mejor comunicador en lo que al testing se refiere?

Testers técnicos? Testers mejores!

Testers técnicos? Testers mejores!

Así a simple vista, parce que esta notícia (“Recruiters’ advice to testers – get technical!”) y este super-post de Toni Robres (“Tienen que saber programar los testers?”) van de lo mismo, de que ahora toca que los testers sean más técnicos y demás…

Pues no.

Para empezar, el primer artículo no debería llamarse Recruiters’ advice to testers… sino más bien Recruiters’ threat to testers… Porque todo el articulo en si mismo parece diseñado para meter el miedo en el cuerpo de los testers, algo así como…

Si no aprendes a programar, vendrá el hombre-agile-del-saco y te comerá.

Tomémonoslo con calma, que esto es serio. Si tuviera que resumir mi lectura del post de Toni en una frase sería algo así como un consejo, algo más como…

Tester, aprende a programar, que te puede ir bien.

Y humildemente me permito añadirle…

Tester de software, aprende cosas sobre software,
que te puede ir (muy) bien.

Cuidado que no es lo mismo que la amenaza de antes por parte de los recruiters. Se trata de hacer mejor nuestro trabajo. El saber no ocupa lugar, si aprendes cómo se hace el software, seguro que le puedes sacar partido a la hora de testearlo, y esto no tiene nada que ver con el advenimiento del agilismo, tiene que ver con si te interesa profundizar en lo que haces, para saber más y hacerlo mejor y con mayor eficiencia.

Sujeto A: pues yo no quiero saber más, ni hacer mejor mi trabajo.

Sujeto B: ok, pues yo no te quiero en mi equipo.

Más claro no lo puedo decir. Y además me ha salido un interludio teatral que vale para cualquier trabajo en equipo.

Aprender a programar puede venir bien, pero también tener nociones de HTML, bases de datos, aplicaciones web, algo de seguridad… Dependerá de a lo que se dedique la empresa en la que trabajas y/o hacia donde quieras dirigir tu carrera. Pero “get technical” así porque sí, porque lo dicen en el sector y si no prepárate, pues no, porque no es un requisito para TODOS los trabajos relacionados con el testing.

Y ojo, que yo no soy un “tester técnico” (sin saber muy bien qué es eso) pero sí que sé “cosas”, “cosas” que he ido aprendiendo a medida que las he ido necesitando o que las he descubierto y me han gustado, y ahora me facilitan la vida, y si me facilitan la vida, pues quiero saber más y quiero que me la faciliten más. Y en este deseo en forma de saco meto también las ganas y la necesidad de mejorar en la parte del negocio, que también ayuda a testear mejor: quiénes son tus usuarios, cómo usan las aplicaciones, cuál es el origen de los requerimientos…

Además, es que con esto hay que ir con cuidado, porque en España tenemos una obsesión por poner ofertas de trabajo que piden un montón de cosas porque es lo que toca, aunque luego no tenga nada que ver con lo que se tiene que hacer. Entonces, para terminar, lanzo una advertencia con mi tono más duro:

Recruiters del mundo, no vale incorporar por defecto a partir de ahora conocimientos técnicos en las ofertas de trabajo de y sobre testing, o me enfado.

Y yo cuando me enfado… Pues eso, que me enfado. 😐