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!

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í? 🙂

Trucos de Selenium IDE – Intro, recording, waiting

Hasta ahora, Selenium IDE me ha salvado mi vida de tester suficientes veces como para decidir lo siguiente:

1. Profundizar en esta herramienta esencial para los testers, con la intención de entender propiamente qué es, qué es lo que he estado haciendo con Selenium IDE, cómo puedo sacar mayor beneficio de la misma, etc.
2. Difundir la palabra sobre esta herramienta (a veces) minusvalorada, defendiendo su honor y ayudando y animando a otros a profundizar, aprender e inspirarse de ella.

Qué mejor manera de hacer esto que blogear? Así que he desarrollado una pequeña serie de posts sobre Selenium IDE, explicando algunos trucos que hago servir, escribiendo porqué y cómo los uso, ya que… To blog is to learn!

Este primer post pretende introducir la serie, explicándonos qué es Selenium IDE y algunos conocimientos básicos sobre la misma. Allá vamos!

Qué es Selenium IDE?

Según SeleniumHQ (el site oficial del proyecto), Selenium IDE es un «add-on para Firefox que hace un sencillo Record-and-playback de interacciones con el navegador». A partir de esta definición, concentrémonos en algunos conceptos:

• IDE: IDE son las inciales de “Integrated Development Environment”, y esto quiere decir que estamos delante de una aplicación que nos ayudará a desarrollar utilidades relacionadas con el software.

• Firefox: sí, Selenium IDE solamente está disponible para Firefox, así que no nos va a ayudar en la ejecución de cross-browser testing, pero es una herramienta ligera e inestimable para automatizar testing funcional de carácter general en navegador.

• Add-on: un add-on para un navegador (también llamado una extensión del mismo) es un complemento instalable que añade funcionalidades o amplía las que tiene el navegador por defecto. Esto es lo que Selenium IDE nos ofrece, añade funcionalidades de record-and-playback de interacciones con el navegador a nuestro Firefox.

• Record-and-playback: esto quedaría mejor com record and/or playback. Puedes grabar o no, pero en lo que estamos interesados es en el playback, en la reproducción, porque es lo que realmente nos porporciona capacidades automatizadoras, la reproducción de…

• Interacciones con el navegador: este es el tema, esto es lo que Selenium IDE hace fantásticamente. Con este add-on podemos grabar, generar, gestionar y ejecutar interacciones von el navegador, simulando los clicks, selecciones, movimientos, escritura… de un usuario real en páginas web y su contenido.

Pues, para resumir esta sección con palabras sencillas, Selenium IDE es un pequeño complemento para nuestro navegador Firefox que nos permite simular interacciones de usuario vía navegador en páginas web. Con él, seremos capaces, entre otras cosas, de ejecutar testing funcional automatizado en navegador web.

Cuándo es Selenium IDE una buena elección para testing automático?

Con Selenium IDE podemos almacenar y organizar casos de test y suites, así que es posible tener una suite de suites automatizada a ejecutar con esta herramienta. Selenium IDE es potente (más de lo que parece), pero limitada; es una gran herramienta para casos de test sencillos pero no tan apropiada para casos más complejos (con muchas ramas, condicionales, casos y demás). Además, tal y como hemos dicho antes, sólo funciona con Firefox, así que si se necesita una herramienta para cubrir casos más complejos y/o funcionando en distintos navegadores, es mejor echarle un vistazo a Selenium Webdriver o Watir. Hay herramientas comerciales que también podrán satisfacer estas necesidades.

Personalmente, yo la uso para ejecutar testing automático ligero, para repetir tareas tediosas pero simples durante una iteración o proyecto, pero sin el objetivo de almacenar o mantener esta automatización; haciendo esto, las pruebas se pueden desarrollar más rápido (aunque seguramente de forma sub-óptima), pero muy efectivas para el coste que implican. Además, Selenium IDE es un fantástico «facilitador» de testing no automático, ya que te puede ayudar en ejecutar rápida y robóticamente pasos tediosos y largos que dejan tu aplicación web lista para ser testeada, en un estado que  sea aburrido de conseguir. Automatizando el camino hasta este punto no estarás cansado ni enfadado, pero sí listo para ejecutar tu mejor testing en él! 🙂

El recording como inicio fácil…

La manera más fácil de empezar un caso de test con Selenium IDE es ejecutarlo manualmente con el botón de grabado a «on»; lamentablemente, hay muchas cosas que se escaparán de este grabado (eventos en background, esperas implicitas que ejecutamos como humanos sin darnos cuenta, cosas así). Por ejemplo, vamos a grabar una simple búsqueda en un motor de búsquedas, buscaremos el término «Software Testing» y veremos si luego aparece un link a la página de la Wikipedia sobre Software Testing en los resultados. Este es el código que obtengo tras grabar esto con Selenium IDE: 

open	http://duckduckgo.com/
type	id=search_form_input_homepage	Software Testing
clickAndWait	id=search_button_homepage
verifyElementPresent	link=More at Wikipedia

Este test se puede reproducir sin ninguno de los problemas antes mencionados, ya que el grabado de Selenium IDE es suficientemente listo como para convertir mi gesto de «click» en el botón de búsqueda en un comando «clickAndWait». La referencia implícita (esta pestaña se encuentra en la consola del IDE) de este comando dice…

clickAndWait(locator)

Generated from click(locator)

Arguments:

     * locator – an element locator

Clicks on a link, button, checkbox or radio button. If the click action causes a new page to load (like a link usually does), call waitForPageToLoad. 

Así que, virtualmente, el ejemplo anterior se corresponde al siguiente…

open	http://duckduckgo.com/
type	id=search_form_input_homepage	Software Testing
click	id=search_button_homepage
waitForPageToLoad	30000
verifyElementPresent	link=More at Wikipedia

…donde el 30000 es simplemente un número arbitrário de milisegundos para llamar a un timeout una vez se hayan superado y la página no se haya cargado aún. El comando «clickAndWait» usa el timeout por defecto especificado en el menú «Options» del IDE, mientras que en «click» + «waitForPageToLoad» tenemos que especificarlo manualmente, luego puede ser mayor o menor que el timeout por defecto.

Podemos alcanzar algo similar usando el comando «pause» del siguiente modo: 

open	http://duckduckgo.com/
type	id=search_form_input_homepage	Software Testing
click	id=search_button_homepage
pause	30000
verifyElementPresent	link=More at Wikipedia

Ejecutando este trozo de código podemos ver que la ejecución de este test SIEMPRE se espera 30 segundos (30000 milisegundos), sin importar si la página se cargó hace 20 segundos, cosa que suena mucho menos eficiente que las anteriores versiones. El tema es que necesitamos que se haga algo justo después de accionar el botón que nos asegure que la página (o recurso, o botón…) se haya cargado antes de seguir en nuestras comprobaciones, puesto que si tuviéramos el siguiente caso de test…

open	http://duckduckgo.com/
type	id=search_form_input_homepage	Software Testing
click	id=search_button_homepage
verifyElementPresent	link=More at Wikipedia

…nuestro test seguramente fallaría ejecutándolo a la máxima velocidad, ya que le estamos diciendo a Selenium IDE que verifique justo después de hacer click, cuando resulta que este click provoca la carga de una página nueva, entonces verificar inmediatamente cosas sin esperar a que la página esté completamente cargada nos llevará fácilmente a que Selenium IDE verifique algo que todavía no puede encontrar, retornando un mensaje…

[error] false

…en la pestaña de log de la consola del IDE mientras ejecutaba el comando «verifyElementPresent», puesto que cuando Selenium IDE está ejecutando este comando no hay link a la Wikipedia en la página (ya que esta no se ha cargado completamente todavía).

Final learnings

Grabar la ejecución de nuestros test cases nos ayudará a definir su esqueleto. Una vez hayamos hecho esto, conviene hacer debugging sobre los mismos (los breakpoints y las ejecuciones paso a paso nos ayudarán con ello) haciéndolos suficientemente robustos como para ser ejecutados a la máxima velocidad sin problemas, sin importar si la red de la oficina parece más lenta de lo normal.

Gracias por leer hasta el final y… nos vemos en el siguiente post de esta serie sobre Selenium IDE!

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!

BBST Foundations course: superado!

Pues sí, dado que en el mes de Agosto «sólo tenía que trabajar», aproveché y me apunté a este curso llamado Black-box Software Testing Foundations, proporcionado por la Association for Software Testing (AST), una asociación americana con bastante renombre, fundada inicialmente por Cem Kaner y que cuenta entre sus afiliados con profesionales de máximo nivel como Ben Yaroch, Matt Heusser, Markus Gärtner…

Este curso es prerequisito para cursar otros dos cursos ofrecidos por la asociación: bug advocacy y test design y, una vez superados los tres anteriores, se puede realizar el curso de instructor para la AST.

El funcionamiento resumido del curso es el siguiente:

• La duración es de 4 semanas
• Se estructura en 6 lecciones, de 3-4 días cada una:
  • Conceptos básicos
  • Estratégia
  • Oráculos
  • Fundamentos de programación y cobertura
  • La imposibilidad del testing completo
  • Mediciones

• Cada lección se compone de:
  • Un ejercicio de orientación (a responder primero y a comentar las respuestas de los otros después)
  • Videoclases impartidas por Cem Kaner (alrededor de 45 mins por lección)
  • Lecturas (algunas obligatorias y otras opcionales)
  • Un ejercicio colectivo sobre la lección (sí, colectivo, con gente, en plan foro). También aquí se requiere valorar el trabajo de otros grupos.
  • Un quiz (un mini-examen, de 10 a 15 preguntas de multirrespuesta)
• Hay un examen final de tipo ensayo compuesto de 6 preguntas, sobre 20 posibles que son publicadas al inicio del curso, para que te lo vayas preparando (si puedes). Como la idea es aprender, el examen se debe hacer sin consultar materiales de ninguna clase aunque nada te lo impide; depende de ti engañar o no (engañarte a ti mismo por un aprobado, vaya).
• Una vez hecho el examen, tienes que ofrecer tu opinión sobre el examen de 2 compañeros, para luego opinar sobre el tuyo tras reflexionar y mirar los materiales con detenimiento.
• La nota final depende del desempeño durante el curso, así como del examen y de las correcciones de examenes de otros. Los quizzes no cuentan para nada, son para que uno mismo pueda saber como progresa.

La experiencia ha sido muy positiva, estoy muy contento de haber realizado este curso, y creo que opinaría lo mismo en caso de haber suspendido, aunque seguramente lo haría con un tono más tristón y apocado 😉

Captura de un slide dentro de una de las videoclases impartidas directamente por Cem Kaner

Cosas chachis del BBST Foundations course:

• Cubre perfectamente las bases del tema: qué es el testing, porqué se testea, cuándo se acaba el testing, cómo se testea, cómo se puede medir el progreso…
• Los materiales son de alta calidad, los slides que acompañan las videoclases son material oficial de la asignatura con el mismo nombre impartida en la Universidad de Florida Tech. Las lecturas incluyen textos básicos «para enmarcar» del propio Kaner, Michael Bolton, James Bach, Doug Hoffmann, Brian Marick…
• El staff del curso (instructores y demás) es también de alto nivel. Los instructores de esta entrega del curso han sido John McConda, Iain McCowatt y Pete Walen, mas puntuales aportaciones de Michael Larsen como actual presidente de la asociación.
• Un grupo de unos 30 testers de distintos orígenes, fases vitales, nuevos en el oficio o grandes veteranos… es siempre una experiencia.
• Está bien de precio. El curso requiere ser miembro de la AST, en resumen, todo junto sale a unos 180 euros.

Cosas rollo del BBST Foundations course:

• La carga de trabajo. MUY ALTA. He sufrido horrores para compaginar el curso con las 8/9 horas de rigor en el tajo más algo de vida conyugal (lo social quedó completamente descartado durante este tiempo)
• La duración. Para asimilar bien todo y disfrutar el curso le falta, a mi entender, una semana más, y así no tener que hacerlo todo deprisa y corriendo. Al no ser así, la presión temporal es muy fuerte: Tener que reflexionar sobre un tema, mirar unos videos, leer un par de textos, hacer una parte de una tarea en grupo y hacer un quiz en 3-4 días ha sido de locos. Por no hablar de asimilar algo… Las lecturas opcionales, por ejemplo, ni tocarlas 😦
• El trabajo en grupo. Ya se sabe. Hay gente agradable y otros que no lo son tanto; hay gente que trabaja y otros que figuran; tu zona horaria puede ser una ventaja o un inconveniente; habrá gente que esté en todo y otros que desaparezcan; habrá dinamizadores y bloqueadores de la evolución del trabajo… Lo que pasa en todas partes, vamos.
• El contenido puede ser fácilmente tildado de «muy básico» por algunos. Ergo la obligación de pasar por este curso para hacer otros de más avanzados puede ser mal vista.
• Si no tienes inglés, nada de nada. Dominar el idioma es vital para sobrevivir; por los materiales y examenes (obviamente) pero también por el trabajo colectivo, o tus compañeros no te van a entender ni tú a ellos.

En resumen, y ya me callo, para mi es un curso BÁSICO para todo aquél que guste de tener el testing como profesión y conocer sus fundamentos a fondo. Es edificante, se aprende, se disfruta y pone las bases para tu progresión como profesional. Eso sí, si volviera a hacerlo, me plantearía seriamente hacerlo durante las vacaciones 😛