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ú?

Anuncios

Reportar defectos ES comunicarse!

The Testing Planet ha publicado un texto mío sobre el bug-reporting y como encajarlo dentro de nuestra estrategia de comunicación como testers para con el resto del mundo. Aquí lo tienes: http://www.ministryoftesting.com/2013/06/dude-pen/

Image

En el artículo, propongo un nuevo mnemotécnico para pulir nuestros reportes de defectos: DUDE, PEN!. Un buen defect report es (como mínimo y en inglés):

  • Direct
  • Unique
  • Documented
  • Entire
  • Prioritised
  • Easy to find
  • Neutral

Espero que te guste! Me dejas tu opinión en los comentarios? 😉

[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?

TestBash 2.0 – el descubrimiento

TestBash 2.0 – el descubrimiento

Hace unas semanas, asistí al TestBash 2.0 y me lo pasé fantásticamente, presencié ponencias muy interesantes, conocí a gente muy agradable… e hice un descubrimiento, y ahora os lo voy a contar.

Bueno, no inmediatamente, aguantad un par de párrafos, ok? 😉

Según la organización, TestBash 2.0 es…

A one day affordable software testing conference in Brighton on Friday March 22nd 2013

Es decir…

Una asequible conferencia de un día sobre software testing en Brighton, el Viernes 22 de Marzo de 2013

Esta sencilla frase remarca dos diferencias básicas entre ésta y cualquier otra conferencia sobre software testing que yo conozca: “un día” y “asequible”. Estos aspectos, cuando aparecen juntos, hacen que una conferencia sobre testing de software sea mucho más accesible que las otras.

Los asistentes a conferencias más “tradicionales” son gente que puede con el mayor coste y duración de las mismas. Hay un sesgo en la muestra pues. Si una conferencia es más accesible que las otras, el sesgo de la muestra se reduce, la diversidad de la misma aumenta y uno se puede llevar una idea menos sesgada de su audiencia. Creo que la audiencia del TestBash 2.0 representó bastante bien a la comunidad de testers británica a ojos de un extranjero barcelonés como yo: una comunidad de testers grande, amplia, diversa, respetuosa, dinámica y orientada a la excelencia.

Así pues, ahora que sé más sobre la comunidad de testers británica, he descubierto que…

Quiero que mi comunidad de testing local sea grande, amplia. Quiero que mi comunidad local sea diversa y respetuosa con esa diversidad. Quiero que mi comunidad local sea dinámica y orientada a la excelencia.

Y hacia ello voy!

Liveblogged! “Introduction to test strategy” por Rikard Edgren (Webinar)

Liveblogged! “Introduction to test strategy” por Rikard Edgren (Webinar)

Pues sí, esta es mi primera experiencia de Liveblogging, para comprobar si me gusta más que tuitear las cosas en vivo. Este post no ha sido fabricado siguiendo los estándares del liveblogging, pero desarrollado en vivo y posteado después (en inglés), tan pronto como mi perfeccionismo en las ediciones de los posts me ha permitido. Ahora lo he traducido (un día después) y ya lo tenéis en español!

Para empezar, este webinar es parte de una serie de webinars promovidos por la Eurostar Conference y presentado por Rikard Edgren, una de las tres mentes maestras que hay detrás del blog Thoughts from the test eye y autor del paper, para nombrar uno de muchos, “The little black book on test design”, que me acabo de leer y he disfrutado mucho 🙂

El webinar se ha centrado en estrategía de testing para un proyecto concreto, no sobre políticas ni procesos, sinó en porqué testear y cómo hacerlo, además de todo aquello que hay entre medias.

https://i1.wp.com/api.ning.com/files/dTvw7iNu8*opXNhxnI6h29xU4cSJX*UdcFnH9tNDBd5nc1n4G1s49t--VH0JmYyUBYdB*Rb94CU0hhjG9G9Fow__/Dibujo1.JPG

En referencia al porqué, Rikard empezó con el concepto de “misión de testing”, como la respuesta a la pregunta “Por qué estamos testeando?”, ya que es bastante difícil hacer buen testing sin conocer bien cuál es la misión del mismo, el porqué testeamos, y quién ha hecho llegar esta misión al equipo. Ejemplos de misiones pueden encontrarse en los materiales del curso BBST Foundations ofrecido por la AST (slides 69-73), como encontrar problemas importantes, parar releases prematuras, evaluar productos de terceros… La misión del testing afecta a la estrategia ya que distintas misiones de testing requieren de distintos tests, ergo de distintas estrategias de testing.

Rikard sugirió el llamado “so… trick” para luchar contra las misiones de testing vagas, como “testea el producto”. Añadiendo al final de esta frase un “so…” (un para que…) y obteniendo una respuesta al mismo, la misión se va definiendo progresivamente, proporcionándonos más información valiosa para ejecutar un mejor y más centrado testing.

Basados en los requerimientos, y en contraste con el “todo”, hay cosas “importantes” de testear.

https://i1.wp.com/api.ning.com/files/R-HNOsRY-LTSkbeYyuwdWX*4IMd4gbqliPK8KWAcROojUyVhkXhtsEKa5VjD668ZSoesdGr*UgMQUqu3Ojzs-Q__/Dibujo2.JPG

Para identificar qué es importante de testear, algunos consejos pueden ser hablar con los stakeholders, preguntándoles qué es lo que quieren saber tantas veces como sea necesario, además de obtener ideas de otras fuentes (como las listadas en el paper “37 sources for test ideas”, co-escrito por el presentador). Si la misión es, por ejemplo, identificar problemas importantes, puede elaborarse con ejemplos (parches, quejas, críticas destructivas…)  o también usando guías (checklists, casos de estudio, requerimientos…).

Rikard cambió de tercio para hablar del Análisis del Contexto, basado en el modelo HTSM de James Bach: cómo puede afectar el entorno al testing, qué debe ser testeado (referencias aquí al mnemotécnico SFDIPOT, popularizado por James Bach también dentro del modelo mencionado), qué características de calidad son importantes de considerar (capacidad, robustez, usabilidad, carisma… Ver más en el poster co-creado por el própio presentador “Software Quality Characteristics”).  Rikard ofreció también ejemplos en lo que se refiere a la robustez, siendo muy agradecidos por un servidor ya que muchas veces los webinars se quedan en la superfície teórica del tema tratado, echándose de menos aplicaciones prácticas del mismo.

Finalmente, el tema de la estrategia del testing fue abordado. El objetivo de la estrategia del testing es conducir el testing para alcanzar la misión del mismo, consistiendo en guías que describen qué hay que testear y cómo hay que hacerlo, con la intención de comunicar esta estrategia tanto a los testers como a los stakeholders; algunos ejemplos se presentaron para reforzar la necesidad de que la estrategia sea detallada, haciéndola útil. Además del detalle, la unicidad de la estrategia se trató también, puesto que cada situación requiere una estrategia de testing única, prefiriendo varias estrategias útiles y justificadas antes que una única perfecta y total estrategia, probablemente incumplible o incompleta.

Aspectos de una estrategia de testing pueden ser objetivos, técnicas, ideas de testing, fuentes de información, oráculos, modelos… pero estos tienen que ser siempre ajustables, ya que las situaciones (porqué testeamos, el contexto actual…) cambian. Debido a esto, un mínimo de sentido del riesgo es necesario, para centrarse en lo que es importante, además de estar siempre listos para añadir nueva información y feedback de los testers y stakeholders.

En resumen, Rikard se refirió a la estrategia del testing como el resultado de la información recopilada y compartida más el propio proceso de pensamiento, animándonos a encontrar estrategias adecuadas para nuestro contexto, aprendiendo a entender qué es importante para nosotros, para nuestro testing, en nuestra situación.

Fin del liveblogging, gran webinar sobre un tema muy interesante!

expoQA 2012

expoQA 2012

Inesperadamente, he asistido a la edición de este año del expoQA. Digo inesperadamente porque no tenía intención de asistir (las conferencias en general son muy caras, y tal y como está el patio, me parece muy bien que la empresa donde trabajo sea cauta en este aspecto), pero resulta que fui el afortunado ganador del sorteo de una entrada gratis entre los lectores del Testing Planet, revista-diario trimestral muy molona sobre testing, fabricada por la gente del Software Testing Club, y es muy feo rechazar los regalos, no? 😉

Total, que me planté en Madrid la noche del 5 de Junio y el 6 por la mañana, tras algún que otro incidente con el transporte interurbano madrileño (sí, he dicho “interurbano”, porque el venue no era muy accesible que digamos), estaba listo para devorar lo que fuera que se cociera en expoQA, sin saber muy bien cuál era la filosofía de la expo en si misma; es decir, son unas conferencias sobre testing y demás, pero ¿dadas por quién y a qué nivel? Pues a eso iba, a capturarlo.

expoQA

A toro pasado puedo decir…

Nivelazo.

Sin ser muy consciente de ello, me iba a exponer a varias charlas profundamente motivadoras e inspiradoras de #testingheroes como Paul Gerrard, Julian Harty, Graham Thomas, Stefaan Luckermaans, John Reber, Derk-Jan de Grood, Fred Beringer et al. Cada cuál hablando un poco de “su libro”, pero a grandes rasgos, hablando todos de lo mismo: la evolución del perfil profesional del tester, el futuro del rol, la importancia de la automatización para dejar espacio a otros tipos de testing y de mayor valor, como el testing de performance, el testing en dispositivos móviles, el testing de infraestructura…

Eddy Bruin, charlando sobre testing en dispositivos móviles

De las casi 40 ponencias, keynotes y charlas realizadas en los días 6 y 7 de Junio, “mi expoQA” se consolidó en 13 sesiones sobre dos grandes temas: mobile testing (fantásticas charlas por parte de Julian Harty y Eddy Bruin – en la foto -, así como una demo de SilkMobile, herramienta para automatización funcional en móviles de Borland / Micro focus) y filosofía / metodología / background / proceso del testing en general (este tema/s principalmente tocado por los grandes popes anteriormente mencionados).

Me esforzaré por ejecutar un Top 3 de charlas a las que asistí, aunque me quedaba con 7 de las 13, creo…

  1. “The redistribution of testing” – Paul Gerrard: primera sesión, primera keynote, inicio electrizante del expoQA. Que poderío, que ideas tan claras, qué manera de salirse del dogma y ofrecer visión de futuro del tester y su profesión sin sonar fatalista ni pedante. Fantástico.
  2. “Test process improvement : answering the BIG questions” – Graham Thomas: es muy fácil señalar que algo tiene que mejorarse, así como preguntarse cómo mejorarlo, lo que es más complicado es responder a esas preguntas. Muy profesionalmente, este consultor independiente británico ofreció pistas sobre cuándo, quién, cómo… mejorar el proceso de testing. Muy interesante.
  3. Ex Aequo “Mobile testing” – Julian Harty / “Testing in a new world” – Eddy Bruin: empate en mi mente para estas dos en tercer lugar, fantásticas introducciones ambas al mundo de la movilidad y sus entresijos. Justo lo que necesitaba para perder el miedo al desconocido móvil y empezar a tener referencias básicas para empezar con buen pie en este terreno, que hace meses que llama a la puerta de Netquest. Mención especial a Julian Harty, improvisando una sesión magistral (por eso no hay link al programa) ante la ausencia del ponente oficialmente invitado a hablar de este tema. Los grandes se hacen grandes en estos momentos…

Como siempre me pasa en festivales, conferencias y demás, no asistí a las premiadas como mejores charlas de la edición (es algo innato en mi). Fueron las siguientes:

  • “Mutation: a testing technique ready for its transference to industry” – Macario Polo: escogida como la mejor ponencia por parte del comité de la expo, la técnica de la mutación se refiere a introducir errores en el código para comprobar si el testing encuentra esos errores, evaluando la confianza de las suites. Fantástica idea, que puede pegar fuerte en el futuro cercano.
  • “Exploratory Testing Myths” – Luis Fraile: elegida como mejor ponencia por parte de los asistentes, la charla de Luís trató del testing exploratorio desde el punto de vista desmitificador y práctico. Me quedo con mal sabor de boca por no haber asistido a esta, pero no se puede tener todo…

En resumen, gran experiencia, puede ser una práctica recomendable asistir a una gran conferencia sobre testing una vez al año, cargando las pilas y tomando ideas y ejemplo de lo más puntero en el sector, para luego volver a la tierra y aplicar algo de lo que se haya aprendido, ya sea en términos prácticos o filosóficos.

Nos vemos en la próxima edición (o lo intentaremos)!