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!

Eurostar Community Spotlight

Eurostar Community Spotlight

La gente de Eurostar (la conferencia nº 1 de testing en el mundo) me ha entrevistado esta semana como parte de la colección de posts “Community spotlight” de su blog oficial. Te interesa? Aquí tienes la entrevista: http://www.eurostarconferences.com/blog/2013/5/31/community-spotlight-mauri-edo

Eurostar community Spotlight

Qué verguenza, no? 😉

Lo que se esconde detrás de un máximo de caracteres

Lo que se esconde detrás de un máximo de caracteres

Es ideal que los QAs y los testers estén involucrados en la captura de requerimientos y su posterior conversión en especificaciones. El agilismo así lo defiende y yo lo comparto, puesto que permite reconocer y alertar sobre áreas de riesgo, detectar potenciales problemas futuros, conocer de antemano los detalles de la funcionalidad que va a venir, adelantar el diseño de las pruebas… Es ideal, pero no siempre es posible.

En esos casos, la documentación disponible es de cosas ya hechas; es decir, funcionalidad ya implementada. En esa documentación pueden faltar detalles de implementación o meta-conocimiento del que disfrutaríamos si hubiéramos estado involucrados desde en un principio.

Hay varias maneras de recuperar ese terreno perdido, la idea de “Show & Tell” de Darren McMillan me parece fantástica (por la que el desarrollador hace una “demo” de la funcionalidad al tester, antes de submitar el código al repositório). Otra manera es mediante el própio testing exploratorio, mediante la própia exploración de la funcionalidad, apretando las tuercas a cada frase, cada palabra, cada coma, de la especificación de lo testeado.

En cualquier caso, los objetivos son los mismos:

  1. Disponer del conocimiento máximo de las aplicaciones a testear
  2. En caso de que el objetivo anterior no se cumpla, hacer todo lo que esté en nuestra mano para conseguirlo 🙂

Este objetivo no es un fin en sí mismo, es un medio para hacer mejor nuestro trabajo. Por ejemplo, un caso real con el que me he encontrado esta misma semana: nueva funcionalidad para una aplicación, me puedo incorporar a testearla sin haber podido participar en su concepción, luego valido  y re-valido todo lo que dice en la especificación que viene con la funcionalidad, y me encuentro con…

El campo XXX puede albergar un máximo de 256 caracteres.

“Eso habrá que verlo”, me digo. Y no era así, admitía 255, uno menos de lo esperado y especificado. En este punto, me podría haber parado, reportar el defecto y a otra cosa, pero en ello no ganaba conocimiento, luego me pregunté…

Y de dónde viene esta limitación?

Un dato así, a grandes rasgos, puede venir de…

  1. Exigencia expresa transmitida por el equipo de negocio
  2. Limitación técnica
  3. “Había que poner un máximo y no sabíamos cual”

Es fácil salir de dudas, preguntando al desarrollador responsable de la funcionalidad. En este caso, se trataba de (2): el límite viene del ancho de la columna de la base de datos que almacena el valor en el campo. Pero había un detalle, el campo es de tipo tinytext, cuyo ancho máximo es 255 caracteres y no 256, luego esto no es un defecto, es una errata en la documentación y ya está, puesto que no había problema por parte de negocio en que el campo tuviera una capacidad de 255 caracteres.

Learnings del caso concreto:

  • Saber de donde viene el máximo establecido en el campo concreto
  • Un defecto menos en el bugtracker, una errata corregida en la documentación
  • Aprender que el tipo de dato tinytext en SQL admite hasta 255 caracteres, útil para futuras pruebas de esta y otras funcionalidades.

Admito que no es un aprendizaje enorme ni me va a arrojar luz sobre las grandes dudas del testing o de la humanidad, pero si de cada pequeño cambio en una funcionalidad sacamos un conocimiento así, al cabo de un tiempo estaremos bastante más cerca del conocimiento máximo de las aplicaciones que testeamos.

Status update

Por varias razones, el área de QA de Netquest (la empresa donde trabajo), vuelve ha quedar como una área unipersonal conmigo al frente. De la experiencia de trabajar en equipo extraigo una gran conclusión, que es la siguiente:

Incorporar y formar a un nuevo compañero es una tarea muy difícil sin tener el área organizada y con un roadmap claro y bien definido.

Entonces, antes de que volvamos a incorporar (inlcuso entrevistar) a una nueva persona en el área, quiero tener los deberes hechos: dibujar un buen plan, establecer unos objetivos concretos, trabajar para conseguirlos y tener unas líneas de acción desarrolladas e iniciadas para que la nueva incorporación tenga un “camino a seguir”. A su vez, tener el área bien organizada permite ahorrar tiempo en algunos aspectos, tiempo a dedicar en mejorar en otros aspectos de organización, alcanzar hitos del roadmap y formar a esa nueva persona en su nuevo puesto. Todo parecen virtudes, a conseguir con trabajo duro!

Mi principal meta con todo esto es conseguir la calidad total en las aplicaciones de Netquest y en sus procesos, idealmente sin dejarme la vida en ello. Según lo aprendido y siguiendo esta meta, los objetivos concretos son:

  1. Revisar, actualizar y completar las especificaciones de las herramientas que desarrollamos, esto es un prerrequisito para…
  2. Crear, actualizar y gestionar la batería de casos de test manuales que cubran las funcionalidades especificadas, para lo que necesito una buena herramienta de TC Management.
  3. Avanzar en la automatización, haciendo una primera inmersión en JUnit (framework que ya se usa en uno de los proyectos) y clarificando qué es conveniente automatizar y con qué herramientas.

Seguiremos informando al respecto…