Testlink 1.7.3

Primera parada en la búsqueda de una herramienta de test case management para su implantación en los proyectos en los que trabajo: Testlink.

Cómo ya mencioné en el post que iniciaba esta búsqueda, la herramienta a escoger debe ser opensource por restricciones de presupuesto. Entonces, qué mejor que acudir a opensourcetesting.org y mirar qué tienen en la sección de testing tools, apartado test management? Pues, a fecha de hoy, aparecen 24 herramientas en el apartado, algunas de gestión de casos de test, otras no, algunas de nombre conocido, otras no. La más descargada según el “download data” disponible es Testlink (con más de 200.000 descargas), además de la referencia en el sector según he leido en varios lugares; pues ya puestos, mejor empecemos por el referente!

La evaluación que he hecho de Testlink ha consistido en dos “sesiones”, una de lectura de la documentación disponible sobre la aplicación en la página del proyecto (concretamente el manual de usuario y el manual de instalación) y otra sesión de jugar con la aplicación en la demo disponible. De la primera, debo reconocer que la impresión inicial fue algo negativa, debido a la falta de cuidado de los sites del proyecto (http://www.teamst.org y http://blog.testlink.org), con bastantes links importantes rotos (la demo del primer site, todas las páginas no iniciales del segundo) así como de la ausencia de un resumen de funcionalidades globales, no específicas de cada release. De esta dejadez deriva que haya tenido que trabajar con la versión 1.7.3 de la aplicación, cuando la última estable ha sido la 1.9.2, pero lo que no iba a hacer era montar un entorno con Apache, PHP y una DB en MySQL para hacer una prueba de concepto (tampoco tengo los recursos ni las capacidades para ello). Tras la segunda sesión, 100% práctica, procedo a emitir mi veredicto sobre la adecuación de la herramienta a las necesidades de nuestros proyectos y del equipo.

Testlink es un buena candidata en esta elección que estoy llevando a cabo. Sin haber tratado nunca con una herramienta de gestión de casos de test, lo que me esperaba de este tipo de aplicaciones lo he encontrado en ella; especialmente en lo que se refiere a gestión: permite gestionar varios proyectos con casos de test distintos, admite múltiples usuarios con roles definidos totalmente ad-hoc y con permisos configurables sobre tareas y proyectos, puede organizar los test cases en test suites y estas test suites en otras test suites hasta tener el nivel de anidamiento deseado, admite la creación de test plans (compuestos de las suites o casos deseados) para releases concretas, ejecutando o modificando estos planes (o su contendo) de modo iterativo mediante la creación de builds dentro de los mismos, capacidades más que suficientes de reporting… Sin embargo, me ha sorprendido lo poco orientada que está la aplicación hacia la creación de los test cases diseñados, con una interfaz demasiado simple, exigiendo HTML en las descripciones ya que si no después de visualizan mal, sin espacio para indicar los pasos del caso de test ni el resultado esperado de cada uno de estos pasos, con un espacio único para añadir adjuntos (en lugar de ser “por paso”)… Lo mismo sucede con la ejecución de los casos; de hecho, apenas puede llamarse ejecución sinó más bien marcado de ejecuciones de casos, puesto que consiste en mostrar los casos de test como si fueran a ser impresos en PDF añadiendo un par de campos para establecer el resultado de la ejecución (pass, fail, blocked, not run) y un campo para “notas adicionales”. Nuevamente se ignora el “paso a paso” en la ejecución, lo que dificulta mucho el trabajo si los casos de uso son complejos o tienen muchas partes.

Ciñiéndome a las necesidades expresadas en el post inicial de la búsqueda, mi valoración de Testlink es…

  • Principalmente…
    • Creación, gestión y ejecución de test cases – KO (gestión muy buena, creación y ejecución bastante pobre)
    • Creación, gestión y ejecución de test plans – OK (la creación y ejecución de planes es muy flexible y ajustada a la realidad del proceso)
    • Gestión de resultados de ejecuciones – OK (incluso hay más reporting del necesario)
    • Vinculo entre test cases y use cases / user stories / requerimientos – OK (la definición de requerimientos puede desactivarse “de sistema”, la asociación con casos o historias se puede ajustar en la creación de suites)
  • Más en segundo término…
    • Integración con la herramienta de bugtracking implantada en la empresa: TracKO (puede integrarse, pero exige atorgar permisos importantes al usuario anónimo, mientras que ahora este usuario no tiene permisos más que el de ver la página de login)
    • Gestión de recursos asociados a un test case – KO (un único campo attachment por test case, cuando sería preferible por pasos de ejecución)
    • Facilidad de instalación y mantenimiento como herramienta – KO (requerimientos exagerados en comparación con otras herramientas del mismo estilo, los upgrades tampoco parecen sencillos a juzgar por el manual de instalación de las versiones posteriores a la testeada)
    • Gestión de N proyectos por M usuarios, idealmente con permisos distintos (creación, ejecución, consulta…) – OK (incluso se pueden configurar roles totalmente nuevos)
    • Ejecuciones iterativas sobre un mismo test plan – OK (mediante la creacion de builds asociados a los planes, que pueden tener más o menos casos de test o versiónes más nuevas de los mismos)
  • Y en último lugar…
    • Integración con tests automáticos – KO (sin soporte específico)
    • Test cases, test plans y resultados imprimibles / exportables – OK

Si las valoraciones del primer apartado valen 3 y -3 (OK vs. KO), las del segundo valen 2 y -2 y las del tercero valen 1 y -1, sobre un total posible de 24 puntos máximos, según mi humilde opinión el ajuste de Testlink a mis necesidades es de un 4. Gráficamente…

Resultados de la evaluación de herramientas de gestión de TC - Testlink

Resultados de la evaluación de herramientas de gestión de TC – Testlink

Poco prometedor, el único atenuante es la “antiguedad” de la versión testeada (he leido que en las siguientes versiones pueden haberse dado mejoras en la ejecución / automatización). Iremos viendo qué ocurre con esta cruzada para encontrar una herramienta de gestión de TCs que se ajuste a las necesidades. Seguimos!

Se busca herramienta de test case management

A raiz de mi asistencia al WinterTest 2011, gracias a la investigación previa del evento y sus organizadores / patrocinadores, más el obsequio del número de diciembre de la revista Testing Experience, descubrí que existen y están muy aceptadas las herrramientas de gestión de casos de test. Actualmente, los pocos recursos de mi área hacen que no tenga test cases como tal, sinó que los elabore ad-hoc según el contenido del build a testear… Ya lo sé, no es una buena idea, pero los plazos de entrga y el alternar entre dos proyectos dan para poco más que mantener las especificaciones.

Estos test cases están sobre Excel, y no puedo decir que esté descontento del todo (es una de mis herramientas de ofimática favoritas, aunque sea de Microsoft), pero tiene muchos problemas: separar el diseño de los casos de sus ejecuciones, la gestión de los recursos asociados a los casos de test, la vinculación con los casos de uso / user stories / requerimientos, la gestión de dependencias entre casos… Total que he decidido iniciar la búsqueda de una herramienta de gestión de test cases que sea gratuita, y lo haré del siguiente modo: inspirándome en el artículo sobre RTH elaborado por Bruce Butler, he elaborado primero una lista de lo que yo espero que cubra una herramienta de gestión de test cases, que es esta:

  • Principalmente…
    • Creación, gestión y ejecución de test cases
    • Creación, gestión y ejecución de test plans
    • Gestión de resultados de ejecuciones
    • Vinculo entre test cases y use cases / user stories / requerimientos
  • Más en segundo término…
    • Integración con la herramienta de bugtracking implantada en la empresa: Trac
    • Gestión de recursos asociados a un test case
    • Facilidad de instalación y mantenimiento como herramienta
    • Gestión de N proyectos por M usuarios, idealmente con permisos distintos (creación, ejecución, consulta…)
    • Ejecuciones iterativas sobre un mismo test plan
  • Y en último lugar…
    • Integración con tests automáticos
    • Test cases, test plans y resultados imprimibles / exportables

No se si pido la luna, pero vaya…

Decidido esto, pretendo acudir a las herramientas más populares y a otras obtenidas de fuentes como opensourcetesting.org, las iré evaluando individualmente y, hecho un número de evaluaciones aceptable, me decidiré por una y procederé a incorporarla a mi daytime-job.

Iré posteando mis evaluaciones y la decisión final, así como la implantación de la elegida (espero). Empieza la búsqueda!

Updates:

19/03/2011 – Testlink evaluado.

10/04/2011 – RTH evaluado.

07/05/2011 – Xstudio evaluado.

WinterTest 2011

El pasado 2 de Marzo asistí a mi primer evento como QA después de 3,5 años desempeñando el cargo, con ese poco miedo que te dan las cosas que no conoces, con gente que no sabes cómo es, en un lugar desconocido… El evento en cuestión fue el WinterTest 2011, dentro de la serie de eventos SeasonTest organizada por la asociación TestQA para la divulgación del sector de la calidad del software en España… Y me alegro de haber asistido, pues me descargué de muchos miedos y viví una recarga masiva de energía y motivación entre tantos abanderados de la calidad, con fines y preocupaciones muy comunes que superan cualquier diferencia en bagaje, conocimiento o formación.

 

WinterTest 2011

 

La gran atracción del evento fue la charla con Jordi Ascolies, responsable de calidad y seguridad de Infojobs, una charla muy amena y educativa, donde se trataron temas muy variados entorno al sector, como la seguridad, la gestión de equipos, la situación del sector, la automatización, etc

Me faltó hacer un poco más de networking (soy bastante malo en este tema), cosa que me supo mal, puesto que se palpaba en el ambiente que las inquietudes, las experiencias, los conocimientos que había entre los asistentes me podrían haber ayudado mucho a resolver problemas habituales, así como de inspiración y guía en términos de próximos pasos. Espero cumplir con este propósito en el próximo evento de SeasonTest o en el próximo evento sobre calidad al que pueda asistir, ya que considero que la experiencia fue tan buena que repetiré mientras pueda!

¿Testing funcional o pruebas de caja negra?

¿Qué mejor que empezar un blog que se llama testing funcional con una definición de qué es el testing funcional propiamente?

Según el “Glosario estándar de términos utilizados en pruebas de software” publicado por el ISQTB y traducido por el SSQTB (obsequio por la asistencia al WinterTest 2011), las pruebas funcionales son pruebas diseñadas tomando como referencia las especificaciones funcionales de un componente o sistema (lo que vamos a testear, el software o una parte de él). Pruebas de funcionalidad, para comprobar si el software cumple las funciones esperadas. Queda claro en esta definición que la estructura interna del software o módulo testeado no se evalúa en estas pruebas, por lo que no afectará a la superación o no de las mismas.

En este mismo glosario, se sugiere como alternativa al concepto anterior el de pruebas de caja negra, pero si acudimos a la definición de este segundo concepto nos encontramos que las pruebas de caja negra…

  • …son ajenas a la estructura interna del objeto de las pruebas (en la estructura interna de los componentes se centran las pruebas de caja blanca)…
  • …pero no albergan solamente pruebas funcionales, sinó que también incluyen pruebas no funcionales.

¿?

Entonces… No son sinónimos? Las pruebas de caja negra incluyen a las de funcionalidad, no? Pero, ¿y qué son las pruebas no funcionales? Un poco reticente, busco si en el glosario hay una definición de este concepto, y me sorprendo encontrándola. Las pruebas no funcionales son pruebas que no se refieren a las funcionalidades (obvio), sinó a atributos transversales a la misma, como la usabilidad, la mantenibilidad, la eficiencia, etc.

Googleo un poco los cuatro conceptos (caja negra, caja blanca, funcional y no-funcional) y todas las fuentes confirman lo anterior, además descubro que se llaman pruebas de “caja negra” porque no se mira en el interior de lo que se prueba y se llaman pruebas de “caja blanca” (o de “caja de cristal”) por todo lo contrario.

Además de confirmar los conceptos del glosario, varias fuentes se refieren a la contraposición entre pruebas de caja negra (aspectos externos, en sentido amplio) y pruebas de caja blanca (aspectos internos), existiendo un fuerte debate sobre qué técnica es mejor. Intuyo que parte de este debate se origina en la histórica confrontación entre desarrolladores y QAs, dado que tradicionalmente las pruebas de caja negra son terreno de los testers, más orientados a la funcionalidad, mientras que las de caja blanca son terreno de los desarrolladores, con mayor capacidad técnica; de todas maneras, estos tópicos sobre “confrontaciones” y “terrenos” me parece que cada vez tienen menor validez en la dinámica y cambiante realidad del sector.

Mi opinión en este debate sobre qué tipo de pruebas es preferible es bastante fácil, ambas son deseables, puesto que nos llevan a la exhaustividad del testing. Las pruebas de caja negra nos aseguran que el software hace bien lo que tiene que hacer (el “qué), mientras que las de caja blanca aseguran que lo hace de un modo adecuado (el “cómo”).

Relación entre caja negra, caja blanca, funcional y no-funcional

Relación entre caja negra, caja blanca, funcional y no-funcional

Aunar estas dos pruebas no es tarea fácil, puesto que se requieren más recursos que si nos decantamos por una única metodología, además de perfiles más versátiles o equipos mayores (desarrolladores orientados a la calidad, QAs con conocimientos de desarrollo). Es fácil de ver que estos dos grupos de pruebas son complementarios y, en caso de combinarlos, tendremos aplicaciones mucho más robustas, pero si hay falta de tiempo o recursos y las aplicaciones tienen usuarios finales no técnicos, parece recomendable centrarse en las pruebas de caja negra, asegurando que lo que se tiene que hacer se haga, aunque no del modo idóneo desde el punto de vista más técnico.

Esto no es siempre así, todo el mundo barre para casa, entonces en cada empresa y según el perfil de los implicados o la metodología de trabajo seguida, el tipo de pruebas que domine un proceso de desarrollo de software será de un tipo o de otro. Si nos preocupa la calidad de lo que entregamos, debemos superar las estrecheces y acercar estas dos posturas, más preocupados por el objetivo final que es la producción de software de calidad total. Por ello es recomendable que los equipos de calidad tengan miembros con formación técnica, y que aquellos que no la tengan adquieran conocimientos básicos de la misma, idealmente guiados por los que sí la tengan. También facilita las cosas que el equipo de desarrollo se imponga como objetivo entregar buen código al equipo de calidad, previa comprobación exhaustiva del mismo, como por ejemplo defiende la escuela del Extreme Programming incluyendo entre sus prácticas el Test Driven Development.

Personalmente, soy más de caja negra y funcional, pero valoro las pruebas más técnicas y me alegro de tener compañeros concienciados y capacitados para hacerlas, además de estar entre mis objetivos el poder contribuir a este testing más técnico. Hay que reconocer que la dualidad de visiones es difícil de gestionar en algunos momentos, además de ser fuente de profundas confusiones y malentendidos, pero tengo esperanzas además de una clara convicción de que juntar las dos miradas es el camino a seguir para entregar aplicaciones excelentes. Y a por eso voy!

Los inicios

Empiezo este blog con la intención de tener un lugar donde reunir información sobre Quality Assurance en general y testing de software en particular, así como ofrecer mi visión, experiencia sobre temas determinados de este sector en auge en el mercado español.

Ahora mismo hace unos 3 años y medio que trabajo como QA, todos ellos en la empresa Soluciones Netquest de Investigación, que me ha brindado la oportunidad de dedicarme a esto sin tener experiencia, con unas básicas pero fundacionales guías y con todo lo autodidacta que he sido capaz de ser.

Las cosas han cambiado mucho desde entonces, la empresa tiene cada vez retos más grandes y para estar a la altura hay que formarse y “hacer codos”, así como estudiar a los expertos en el tema. Todo lo que vaya aprendiendo en esta nueva fase de “mirar hacia fuera” pretendo verterlo en este blog, que espero que sea mucho!

Gracias por leer estas frases, espero que este viaje personal hacia el mundo del conocimiento exterior no sea solamente útil para mí.