Mi primer EuroSTAR

Después del refrescante QA&TEST Bilbao 2013 llegaron palabras mayores. A raiz de mi colaboración periódica en el blog de la conferencia internacional de software testing EuroSTAR, la organización de la misma me invitó a asistir al evento (realizado entre el 4 y el 7 de Noviembre en Gotemburgo, Suecia) a cambio de escribir algunos posts sobre lo que estaba pasando en ella (por ejemplo este o este otro).

Para el que no lo sepa, EuroSTAR está entre las 3 conferencias más importantes de testing en Europa, y puede ser la que tenga más historia (con 20 ediciones a su espalda). Este año han asistido más de 1000 personas al evento y ha consistido de un día y medio de tutoriales (11 en total, 5 de un día, 6 de medio día), 3 workshops y 47 charlas en 4 tracks con la crème de la crème del testing europeo y mundial debatiendo sobre el tema de este año: “Questioning testing”.

El nivel de las charlas ha sido bastante alto, pero lo que más me ha llamado la atención es que es un evento en el que constantemente pasan cosas, mucho más allá de las charlas. La conferencia facilita la generación espontánea de charlas informales, demostraciones, workshops improvisados y sesiones de testing colectivo proporcionando el espacio y el tiempo para ello. Hay incluso quién dice que este aspecto es lo mejor de todo el evento! También hay que decir que la comunidad internacional está muy acostumbrada a la vertiente social del testing, quien más quien menos asiste con regularidad a testing social meetups en sus países de orígen, y eso se nota en estas situaciones.

Chilling out at EuroSTAR 2014

Chilling out at EuroSTAR 2014

Mucha información tengo ahora que procesar, del más alto nivel y de las más variadas fuentes; pero más allá de la infoxicación que pueda sufrir ahora mismo, mantengo mi opinión sobre la asistencia a eventos de este tipo, son un subidón de adrenalina testeadora importante, además de permitirte estar en contacto con lo más avanzado de esta profesión que no se acaba nunca. 100% recomendable!

La edición del 2014 es en Dublín y el tema es “Diversity, innovation & leadership”. Nos vemos allí? 😉

Mi primera charla

El martes pasado ocurrió, ya puedo decir que he dado una charla como ponente en una conferencia de testing, y no me desmayé ni quedé en blanco ni nada, de hecho fue lo suficientemente bien como para querer repetir 🙂

Tal y como anuncié hace unos meses, el comité organizador del QA&TEST Bilbao 2013 había aceptado mi paper y desde entonces hasta el día de autos he estado creando la presentación propiamente y mentalizándome al respecto.

Los que me conocen saben que soy un control-freak, por lo que una cosa así me ha puesto bastante al límite de mi mismo, por suerte asistí a la edición del año pasado y quedé impresionado con el nivel y la cercanía, qué lugar mejor pues para hacer una primera charla sobre mis opiniones y experiencias?

Pero bueno, al grano con lo que quería contar en este post:

Por qué es importante dar charlas?

Para compartir tus opiniones y experiencias!

 

Por qué es importante dar charlas sobre testing?

Las charlas generan debate, la información fluye, los contenidos mejoran, la comunidad crece!

 

Y si no me gusta la idea o no tengo nada innovador que contar?

Pues no dés charlas, no todo tester es generador de contenidos y eso está bien, encuentra tu lugar, tu aporte a la profesión y explótalo!

 

Tengo una idea para una charla, qué hago?

Busca un lugar para darla! No tiene porqué ser una conferencia, un grupo de discusión o un meetup pueden ser buenos lugares también!

 

Voy a dar una charla, me das un consejo?

Sé tú mismo! Conserva tu nivel de formalidad, tu sentido del humor, tu grado de profesionalidad y tus ideas, son lo mejor que tienes!

 

Voy a dar una charla, me das otro consejo?

Ensaya mucho, es tu momento para dejar una buena impresión!

 

Hala pues, más o menos esto quería decir. Para terminar os dejo con la única foto que tengo del momento histórico. Nos vemos en futuras charlas? 😉

qatest2013_me

QA & Test Bilbao 2013, allá vamos!

For the first time, presentaré una sesión dentro de la conferencia internacional QA & Test Bilbao 2013 en calidad del software y sistemas embebidos. La charla que daré se llama “Testing beyond software: a case study”, en la que pretendo explicar un caso práctico de aplicación de procesos de testing más allá del desarrollo de software, en un escenario de uso operativo del software, un ejemplo perfecto de calidad aplicada a la producción.

Nos veremos allí? 🙂

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

[Encuesta] Las habilidades de un “software testing leader”

Hagamos un ejercicio, responde a la siguiente pregunta…

Y, cuando haya reunido suficientes resultados para decir algo fundamentado al respecto, lo publicaré en este blog. Hay trato? 🙂

PS: sí, me encanta el misterio…

Update: ya he plasmado unas reflexiones sobre esta pequeña encuesta, puedes leerlas aquí.

De casos de test a mapas mentales: una experiencia personal

De casos de test a mapas mentales: una experiencia personal

La mecha que prendió este post fue este comentario en una de mis entradas de análisis de herramientas de test case management, preguntando por el resultado de la investigación en este tema realizada al principio del año 2011. La búsqueda terminó al cabo de algunos meses, a medida que me iba dando cuenta de que una herramienta de este tipo no encajaba en mi contexto actual, pero nunca concluí la investigación oficialmente. No la estoy concluyendo ahora con este post, a lo mejor la retomo en el futuro, pero dos años después de sus inicios, el hecho es que hemos vivido y testeado adecuadamente sin casos de test ni herramientas de gestión de los mismos. Así es como lo hicimos.

Antes de empezar, no estoy intentando afirmar cuál es la mejor solución en este aspecto, esto es el relato de una experiencia personal solamente, un caso de estudio si queréis. Simplemente food for thought, cosas a considerar si os encontráis en esta situación. Espero os sirva de ayuda 🙂

Nuestro contexto

Intentaré resumir nuestro contexto en unas pocas líneas, contáctadme si no es suficiente para entender la situación:

  • 2 aplicaciones web-based
  • Ambas aplicaciones son maduras, con más de 3 años de existencia cada una
  • +500 casos de uso (y creciendo!), desde simples CRUD a grandes y complejos casos de integración de sistemas con interpretaciones condicionales y reglas de negocio implicadas
  • Un departamento de 2 testers, emparejado con un equipo de 4-5 developers superlistos
  • Un promedio de 2-3 releases al mes
  • Sin automatización disponible (en el momento de iniciar la investigación)

El primer número que me vino a la mente fue que necesitábamos una herramienta que gestionara como mínimo +500 casos de test (digamos, el happy path de cada uno de esos casos de uso), ergo se supone que tendremos que desarrollar esos +500 casos de test, y también se supone que tendremos que mantener esos +500 casos de test, sin reclutar nuevos compañeros ni reducir la velocidad de releases que defendemos.

No podíamos realizar esa inversión, nuestro foco hubiera pasado de testear a crear y mantener casos de test, con la sensación de que se trata de una tarea interminable, ya que hay casos de uso nuevos cada mes, más revisiones de los ya existentes, implicando nuevos casos de test a redactar y casos de test viejos a mantener, más en algún momento explorar los unhappy paths si teníamos tiempo.

Qué hacíamos mientrastanto?

Al principio de todo, 2 años antes de que esta búsqueda empezara, intentaba crear los casos de test en Excel al principio de la fase de testing (desarrollábamos bajo waterfall por aquél entonces) antes de testear efectivamente, de lo que aprendí lo siguiente:

  1. Los casos de test evolucionan mientras testeas, por ello tu manera de pensar y la herramienta que uses tiene que estar preparada para esto.
  2. El mantenimiento y la reutilización de los casos de test es un tema candente, difícil de gestionar en un entorno cambiante como el nuestro, por las razones antes mencionadas.

Con este enfoque, descubrí que invertía más tiempo creando, editando y adaptando a la situación actual mis casos de test en Excel que testeando efectivamente. Progresivamente, fui abandonando ideas; primero, abandoné la idea de reusar casos de test (con lo que el asunto del mantenimiento desapareció también); y después, abandoné la idea de preparar todo el conjunto de casos de test antes de empezar el testing, abrazando un diseño de testing y una ejecución más dinámicos. Estaba haciendo testing exploratorio sin saberlo, pero no me sentía cómodo con la idea de no tener documentación de test. Por esto último empecé la investigación de una herramienta de gestión de casos de test.

Y… Apareció el mind mapping!

Mientras investigaba herramientas concretas, intenté averiguar qué hacían otros profesionales en situaciones similares a la nuestra, y descubrí que el testing exploratorio era real y muy respetado por testers muy influyentes; y descubrí el mind-mapping también.  Inmediatamente cambié el uso de Excel y Notepad en mis actividades exploratorias extraoficiales para usar Xmind como herramienta de soporte para las mismas.

Tan buen punto empecé a hacer esto tuve un momento de esos de “cómo no había hecho esto antes!”, ya que los mapas mentales son la herramienta perfecta para desarrollar y ejecutar pruebas mientras testeas, evolucionando tus ideas de testing mientras testeas efectivamente, disfrutando con el proceso y reforzando la parte creativa del testing, cosa que también tiene su gracia. Además de esto, el uso de mapas mentales nos permitió desarrollar un “mapa mental de ideas de testing” al inicio de los proyectos e iteraciones y evolucionarlo a medida que estas avanzaban y profundizábamos en su contenido, compartiéndolo con el resto del equipo, tanto desarrolladores como stakeholders, creando una gran compilación de ideas de pruebas justo antes de empezar efectivamente a testar, y pudiendo evolucionar esta compilación mientras el testing tenía lugar.

La búsqueda de una herramienta de test case management finalizó de facto…

…en el momento que me pregunté ¿por qué iba a querer invertir esa cantidad de tiempo en documentar esos casos de test cuando estamos cumpliendo razonablemente bien sin ellos? Las primeras respuestas que me vinieron a la mente se referían a registros de ejecución de pruebas, cobertura y reutilización. Así que las analicé profundamente.

El tener registros de ejecución de casos de test no es razón suficiente para implementar una herramienta de gestión de casos de test, por lo que seguí profundizando en las otras respuestas.

Sobre cobertura… somos principiantes en testing exploratorio, así que me sentía inseguro de que nos dejáramos areas importantes sin testear con un enfoque tan dinámico, pero la idea de implementar una herramienta de gestión de casos de test no me era suficiente, preferí pensar en mejorar como testers exploratorios; además, alimentar esas herramientas nos hubiera quitado tiempo de testing efectivo, por lo que la coberturase vería afectada también. Por otro lado, qué cobertura te ofrece una herramienta de gestión de casos de test? La cobertura sobre los casos de test que has sido capaz de introducir en ella, cosa que es una manera sesgada de ver la cobertura. Me sentí más seguro haciendo crecer la cobertura en las áreas importantes a medida que íbamos testeando.

La reutilización ha sido un hito reciente para nosotros, decidiendo no reutilizar nada hasta ahora, recreando y revisando las ideas de pruebas a medida que lo hemos ido necesitando, afilando nuestros sentidos y habilidades exploratorias en cada iteración, aunque probablemente modifiquemos esta conclusión pronto.

Próximos pasos (algunos ya ejecutados)

Habiendo decidido oficialmente que hacíamos testing exploratorio con mapas mentales y siendo felices con ello, empezamos a iterar esta idea para mejorar nuestro desempeño. Cosas que ya hemos hecho al respecto:

  • Invertir tiempo en automatizar validation checks, para combinar nuestra óptica exploratoria profunda con cobertura general y ligera en términos de checking.
  • Documentar formalmente algunos casos de test para los casos de uso más críticos (hablamos de unos 5 o así), creando una mini test-suite a ser ejecutada en cada ciclo de testing, antes de la instalación de una nueva versión. Esta suite no se automatizará nunca, ya que requiere unos 15 minutos de ejecución y quiero los 7 sentidos de un tester pensante en ella, y un robot no me ofrece esa seguridad. Los smoke tests son documentados formalmente también. Estas son pruebas sencillas que demuestran que el testing exploratorio y el documentado formalmente pueden coexistir.

Cosas que espero hagamos en el futuro cercano:

  • Repensar el tema de la reutilización. Quizás podríamos desarrollar un mapa mental con checklists para empezar esa recopilación de ideas de pruebas con algo ya hecho, actualizando estos documentos a medida que los vamos usando, aceptando que tienen que ser actualizados antes de evolucionarlos, pero tomando ventaja del conocimiento y esfuerzo mental ya aplicado.
  • Desarrollar una especie de testing low-tech dashboard, basado en mapas mentales, con la intención de comunicar más fácilmente el estado del testing al equipo et altri.

Finale

Pues ya está. Un proceso de 4 años resumido en menos de 1500 palabras. Espero poder escribir algo más al respecto en los próximos 4 años, a ver si mejoramos en este interminable y fantástico asunto!