¡Bueno, bueno! Estos últimos meses han sido toda una locura y para colmo me apunté a la idea de cumplir el 30 days of testing challenge que propuso Ministry Of Testing antes de que comenzara julio.

Voy a dejar por aquí mi progreso aunque ya adelanto que no he cumplido todos los retos… pero lo importante es intentarlo!! Ahí van:

DÍA 1: Buy one testing book and read it by day 30

He de confesar que todavía no lo he leído por completo. De todas formas, es un libro que incluso puedes leer sin seguir un orden y por eso se lee muy fácilmente. Cualquier lección que leas es cortita y te aporta mucho en poco tiempo. Entre otras muchas ideas, te hace ver qué otras ciencias te pueden aportar valor como tester. Está genial.

DÍA 2: Take a photo of something you are doing at work

DÍA 3: Listening to a testing podcast

DÍA 4: Share a testing blog post with a non-tester

DÍA 5: Read and comment on one blog post

Fui yo quien recibió un comentario de Giulliana, quien aportó más información sobre Testlink en el post que escribí sobre los primeros pasos con esta herramienta.

DÍA 6: Perform a crazy test

Para crazy testing el que hemos hecho de PokemonGo, donde no se muestran los mapas, la pokédex está desmaquetada, el login se peta y los km se cuentan como les place…

DÍA 7: Find an accessibility bug

Sé que no es un bug de una aplicación, tipo “este sitio no es adecuado para que un daltónico lo utilice” pero no me digáis que esto que me encontré camino Galicia no es un buen bug de accesibilidad.

DÍA 8: Download a mobile app, Find 5 bugs and send the feedback to the creator

Recuerdo haber utilizado la aplicación de la Bruja de oro, para poder mira si mis décimos de navidad estaban premiados (nunca hay que perder la ilusión jeje)

Pues bien, al utilizarla vi algún problema, no son 5 bugs, pero me impactó que tras comentarle al creador el bug que había encontrado, me contestara y además muy agradecido por el feedback. ¡Así es genial!

Qué lujo saber que hay gente así, os dejaré el hilo del email para que le echéis un ojo.

DÍA 9: Create a mindmap

Done!! simplemente es confidencial.

DÍA 10: Find an event to attend

La TestNigth en Valencia.

DÍA 11: Take a picture of your team

Podeís verlos en estos tweets de Jokin ^^ tanto a los testers ¡¡como al equipo completo!!

DÍA 13: Find a user experience problem

DÍA 14: Step outside of your confort zone

Hemos movido nuestro puesto de trabajo durante dos horas junto con los compañeros de otro departamento para ver cómo trabajan y qué dificultades se encuentran. Es un modo de ver si podemos ayudar o aportar algo bueno a su forma de trabajar puesto que podríamos facilitarles herramientas que automaticen ciertas acciones etc.

Realizar este tipo de actividades es muy bueno tanto personalmente como para la empresa.

DÍA 17: Find and share a quote that inspires you

DÍA 18: Find a broken link. And report it

Utilizando http://www.brokenlinkcheck.com/ sobre la web de renfe, he encontrado este error.

DÍA 19: Find and use a new tool

Este mes he estado utilizando la herramienta meldium. La he instalado como un plugin en el navegador chrome. Sirve para hacer login automáticamente en todas las aplicaciones sin necesidad de poner nombre de usuario y contraseña en todas y cada una. Es como si tuviéramos un contenedor de accesos directos. De todas formas, no en todas las aplicaciones puedes hacer ese login automático pero sí que te permite almacenar usuario y contraseña para poder acceder más rápido. De esta manera, al llegar al trabajo, abro rápidamente todas las aplicaciones que necesito sin preocuparme de guardarlas en marcadores por ejemplo.

DÍA 20: Find a good place to perform some security tests

Pues voy a darle una vuelta a esta charla de Jose Selvi

DÍA 21: Pair test with someone

Haciendo una kata en el curro con mis compañeros y viendo más de cerca el TDD Viniendo de java siempre tiendo a imaginarme las soluciones mucho antes de lo que es necesario. Es decir, intento averiguar qué estructura de datos será la más adecuada o qué problemas se engloban bajo una misma idea. Pero estoy aprendiendo a que, entender el problema que tienes entre manos es un proceso de aprendizaje y TDD te lleva por esa línea, es decir, partiendo de tests sencillos mientras que pensar directamente en la solución más adecuada te puede llevar por mal camino.

La kata en concreto ha sido http://codekata.com/kata/kata16-business-rules

DÍA 22: Share your favorite testing tool

Con esta herramienta tengo un amor-odio interesante… Echad un ojo a mi post sobre Gatling

DÍA 23: Help someone test better

Perfecto, en casa tengo ayuda con Ruby y yo soy la que ayudo con el testing. Done.

DÍA 24: Connect with a tester who you haven’t previously connected with

Es Meike, tester en Estocolmo, podéis encontrarla en su web. Hablamos en inglés por hangouts sobre nuestros antiguos trabajos y alguna que otra anécdota.

Meike nice to meet you!!

Día 26: Invite a non-tester to a test event

¡¡Hecho!! me lo llevaré a la TestNight ;)

Día 27: Say something nice about the thing you just tested

Revisar una historia, ver que incluye algo que puede llegar a ser un problema para los usuarios, comentarlo, ver que todos se vuelcan en ello para solventarlo y mejorar. Simplemente genial.

Día 28: Summarise an issue in 140 characters or less

Qué mejor sitio que en twitter ¿no?

Día 31: Bonus, compartir todo el challenge

¡Pues aquí está! Seguro que completaré alguna cosita más en el futuro así que si procede, lo apuntaré (al final será un reto un poco asíncrono jajaj)

Me lo he tomado con humor si…

¡Nos vemos!

¿Conocéis lo fácil que es escribir ciertas sentencias cuando utilizas un IDE? Por ejemplo, al escribir desde IntelliJ en java

1

sout

1
System.out.println();

Seguro que alguna vez os ha pasado que escribimos tantas veces la estructura de algo, que hasta se hace pesado.

A mi me ocurre con la estructura de los nuevos tests funcionales que implemento. Al utilizar otras herramientas como TestNG y las anotaciones, debo escribir bastante para generar la estructura básica de un nuevo test. Por ello, si me valgo de estos snippets es mucho más fácil.

Como ejemplo, os cuento dónde encontrarlos en IntelliJ para que podáis generar los que os apetezca y os faciliten un poco la vida.

Si accedemos a:

1
File > Settings > Live Templates

Podemos generar un nuevo grupo de estructuras como se observa en la imagen anterior y agregar la pertinente. También se pueden establecer variables dentro de ese código como he hecho con el nombre del método (el nombre del test).

Además de esto, habrá que ir abajo a Define para definir el lenguaje de programación al que queremos que se aplique este snippet.

Hecho todo esto y en este caso de ejemplo, al escribir

1

nt

¡Fácil y sencillo! Espero que sea útil.

Escribo este post para tener siempre a mano un proyecto mínimo que sirva para empezar con las pruebas funcionales.

Ya hice un post con un ejemplo básico y sencillo pero con este, la idea es tener un proyecto que además esté mavenizado y que utilice testNG.

El proyecto estará mavenizado porque así tendremos una estructura de directorios organizada y nos va a permitir realizar tareas de una forma muy fácil como tener localizadas las dependencias que queramos (por ejemplo utilizaremos las de selenium), descargar plugins necesarios, etc

Por otro lado, haremos que descargue y utilice testNG puesto que es un framework que nos va a ayudar a organizar y gestionar nuestros tests en este proyecto java (lanzar sólo los tests que consideramos críticos, sólo los que tienen que ver con una necesidad, relanzar automáticamente los que han fallado…)

Todos los elementos que voy a utilizar: Java8, IntelliJ, Selenium y TestNG.

¡Empezamos!

Creamos entonces un proyecto java básico y lo hacemos con

1

maven-quickstart

• (1) Primero, desde la linea de comandos hacemos:

1
$ mvn archetype:generate -DgroupId=com.examples -DartifactId=basic-testing-project -DarchetypeArtifactId=maven-archetype-quickstart

Con esto, se nos pregunta en dos ocasiones y debemos pulsar ENTER en ambas (marcadas en amarillo):

Esto nos genera una estructura como la siguiente:

Como se puede ver, ya tenemos creado el pom.xml, que es el fichero XML que contiene toda la info necesaria para construir el proyecto.

• (2) Importamos el proyecto en IntelliJ:

1
File > Open

• (3) Si no tenemos Java8, ya va siendo hora de descargarlo:

1
File > Project Structure > Project > Project SDK

• (4) Ahora vamos a modificar ese

  1

  pom.xml

  , añadiendo varias dependencias, las dos de selenium y la de testNG:

<dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-java</artifactId>
      <version>2.52.0</version>
</dependency>
<dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-server</artifactId>
      <version>2.52.0</version>
</dependency>

<dependency>
      <groupId>org.testng</groupId>
      <artifactId>testng</artifactId>
      <version>6.8</version>
      <scope>test</scope>
</dependency>

quedando así:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.examples</groupId>
  <artifactId>basic-testing-project</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>basic-testing-project</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-java</artifactId>
      <version>2.52.0</version>
    </dependency>
    <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-server</artifactId>
      <version>2.52.0</version>
    </dependency>
    <dependency>
      <groupId>org.testng</groupId>
      <artifactId>testng</artifactId>
      <version>6.8</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

• (5) Además, descargo chromedriver y lo incluyo en la carpeta src del proyecto.

• (6) Y sólo nos queda ajustar la clase principal y la clase de test. Yo voy a implantar el page-factory que os comentaba en este post

La estructura final sería:

Y listo, sobre el test

1

testMethod

1

TestExample

PD. Podemos ir más allá y tener siempre la última versión de chrome driver descargada utilizando plugins para maven como este

De igual manera, sería modificar el

1

pom.xml

Nota. Si podemos ir actualizando el

1

pom.xml

RESUMEN (Para la vagancia)

El proyecto completo Y las url necesarias para descargar chromedriver y SDK Java8

¡Saludos!

Testlink es una herramienta open-source que nos facilita la gestión de los proyectos de testing que creamos y además nos ayuda a mantener la calidad de aquello que estamos probando.

Necesitamos un lugar donde escribir todos los tests, todos y cada uno de los pasos a seguir para poder probar las funcionalidades y comportamientos de nuestra aplicación (y no podemos pretender tenerlo escrito en un papel).

Partamos por ejemplo de probar una web donde gestionar usuarios, canciones y listas de reproducción.

He aquí el croquis mental :)

En testlink nos construiremos nuestra batería de pruebas de esta forma:

TestSuite: la colección de tests cases de nuestro proyecto, le pondremos el nombre del mismo.

TestCases: cada una de las pruebas software que haremos, con todas las condiciones que deben cumplir para ver si hacen lo que deben (lo establecido), agrupandolas debidamente.

La idea es tener cada grupo de tests acorde con algún patrón como el Page Object, así para esta web tendríamos tres grandes grupos:

1. Gestión de usuarios
2. Gestión de canciones
3. Gestión de listas de reproducción (Serán sub-test suites de la test suite principal)

Dentro de estos grupos se tienen distintas “pages” (A, B y C) y distintos test cases como los numerados a continuación.

Centrándonos únicamente en Gestión de usuarios tenemos:

• (A) Listado de usuarios
  1. Buscar usuario por nombre (con resultado exitoso o no)
  2. Buscar usuario por email (con resultado exitoso o no)
  3. Buscar usuario por sexo (con resultado exitoso o no)
  4. Acceder al perfil del usuario
• (B) Perfil de usuario
  1. Editar datos de usuario y guardarlos (con resultado exitoso o no)
• (C) Nuevo usuario
  1. Agregar nuevo usuario (aceptando o cancelando finalmente)
  2. Agregar nuevo usuario habiendo introducido carácteres no permitidos

A grandes rasgos explico rápido cómo:

• Crear un nuevo proyecto en testlink

• Añadir test suites (como en el caso de “Mi web”, “Listado de usuarios”, “Gestión de canciones”, “Gestión de listas de reproducción” y las carpetas de “Caminos éxito/fallo”).

• Añadir test cases (caso de todas las pruebas anteriormente numeradas)

• Añadir pasos a estos test cases (en ellos se pueden incluir notas muy útiles que sirven para determinar cuál es el comportamiento esperado de cada paso)

Para reforzar aún más la organización de estos test cases, cada test suite puede tener otra división en exitosos o fallidos. En la imagen final se puede observar claramente.

¡Esto es todo por hoy!

Por cierto la imagen del mapa mental del principio no está hecha a mano (aunque lo parezca ^^ )

He utilizado Balsamiq Mockups, una interfaz sencilla para plasmar ideas. Me encanta desde que lo descubrí haciendo mi proyecto fin de carrera.

¡A cuidarse!

El sábado de la semana pasada estuve en Bruselas con intención de ir a FOSDEM, un ciclo de conferencias ¡gratis! de desarrollo.

Al ser así, me imaginé hordas de gente con espíritu aplastante y mucho agobio ¡pero no! había bastantes personas pero todo estaba muy organizado, nada masificado… Creedme, por ejemplo el Codemotion es mucho peor en ese sentido.

Además se notaba ambiente amigable y se podían intercambiar ideas sin problemas con cualquier persona que se sentara a tu lado ¡practicando inglés a tope!

Bueno, como era de esperar, pasé gran parte del día metida en la sala de testing y automatización, así que voy a resumir abajo los puntos que me han parecido interesantes de estas charlas.

Junit-contracts, A Contract Testing Tool

por Claude Warren

Habló sobre las “pruebas de contrato” y fue aquí donde conocí este concepto. Hace referencia a que se tiene una interfaz o clase abstracta y se le realizan pruebas a cualquier implementación de esa interfaz, es decir, cualquier clase derivada de esa interfaz (o clase abstracta) debe pasar con éxito la batería de pruebas que se implementó para esa interfaz.

Es, por decirlo de alguna manera, una forma de seguir un patrón para organizar las pruebas.

Tras conocer esto, me he interesado por este post de Alberto Peña que me ha aclarado ciertos puntos sobre este tipo de pruebas. Espero que os sirva.

Testing interoperability with closed-source software through scriptable diplomacy

por André Vadla

Interesante. Nos presentaron Frida, un kit de herramientas que permite injectar javascript para poder testear aplicaciones nativas de Windows, Mac, Linux, iOS y Android.

Graba los pasos, clicks etc que has seguido en una aplicación y genera código en javascript que después puedes coger y utilizar en tus pruebas automáticas.

Si alguna vez necesitamos realizar pruebas de integración donde debamos testear nuestro sistema junto con otros que son de código cerrado, esta puede ser una solución.

Testing embded systems

por Itamar Hassin

Debido a que el IoT (internet de las cosas) está cada vez más presente, nos mostró cómo hacer testing unitario de sistemas embebidos utilizando Unity y cómo hacer testing de integración utilizando Cucumber y el protocolo Wire (de tal forma que puedes conectar varios sistemas al pc y probar su integración siendo Wire el mediador entre ambos).

Es muy interesante, aunque creo que me falla algo al querer testear sistemas donde medias con otras herramientas (ya que introduces un punto de incertidumbre ajeno al sistema real que estás probando) pero menos es nada, eso está claro. Además hay que tener mucho cuidado en producción ya que cualquiera podría conectarse al Wire y hacer maldades.

Jenkins as a code

por Łukasz Szczęsny, Marcin Zajączkowski

No pude pasar. Como os comentaba, la organización era bastante buena, por lo que si una sala estaba llena, la cerraban y no pasaba nadie más. Lo bueno es que las charlas están grabadas e irán apareciendo en la web de FOSDEM a lo largo de estos días. Si alguien quiere ver esta, puede pasarse por aquí, que es el directorio donde aparecerán todas las charlas que se dieron en esa sala.

Simulating Humanoid Robots in the Cloud: the testing behind the biggest world competition

por Jose Luis Rivero

Desde la Open Source Robotics Foundation nos mostró el simulador open source Gazebo.

También ideas que nunca hay que olvidar, como contar con que los mejores testers son los usuarios reales, saber que la mejor forma de probar el contexto es intentar llevar a cabo esa prueba en el propio contexto, tener cuidado con las máquinas que se utilizan en la nube porque pueden ser diferentes a las finales y la importancia de la integración continua para poder testear tan pronto como sea posible. Además hizo la charla bastante divertida :)

How to properly blame things for causing latency

por Adrian Cole

Una charla un tanto curiosa pues nos contactó a tarvés de videoconferencia y a veces había problemas técnicos que nos hacían echar unas risas :)

El tema es que todos los componentes ya están distribuidos por toda la red, la arquitectura se hace cada vez más compleja y esto hace que los flujos de datos puedan sufrir retardos. Por ello la clave está en encontrar qué es lo que está haciendo que nuestro software sea lento. Nos comentó que las herramientas que pueden ayudarnos en este contexto pueden ser: Zipkin, ideada para pruebas de tracing distribuido y Spigo, para simular arquitecturas complejas.

Del evento también puedo decir que había zonas para comer, merchandising…

libros…

En resumen, he sacado info interesante, cositas que no conocía y me ha encantado el ambiente.

En fin, espero que os interese algo de aquí. ¡Que vaya bien! :)