Un compañero nos contará cómo testear Web Responsive con Galen ¡No os lo perdáis!

Un ejemplo pequeño para empezar. Vamos a hacer una prueba sencilla. Cargamos la web de amazon, introducimos una palabra y hacemos click en Buscar (icono de la lupa).

Herramientas que voy a utilizar:

• Eclipse, como entorno de desarrollo
• Java 1.8
• Selenium, con versiones 2.42
• Chrome como navegador, por tanto, Chrome driver, con versión 2.19

Para empezar, debemos descargar:

1. Los .zip, tanto del cliente como del servidor del WebDriver
2. El .zip del web driver para Chrome

Procedemos:

1. Crear un nuevo proyecto Java en Eclipse, por ejemplo FirstSelenimProject
2. Incluir en el src/ de ese proyecto tanto el chrome-driver como los .jar correspondientes a cliente y servidor de web-driver, es decir, el .jar de selenium-server-standalone-java-X.jar y extraer el contenido de selenium-java-X.zip.
3. Crear una nueva clase .java con el siguiente contenido:

import java.util.Arrays;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;

public class TestExample {
	
	public static WebDriver driver;
	
	@BeforeClass
	public static void setUp(){
		System.setProperty("webdriver.chrome.driver", "src/chromedriver"); 
		
		ChromeOptions options = new ChromeOptions();
	    	options.setExperimentalOption("excludeSwitches", Arrays.asList("ignore-certificate-errors"));
		driver = new ChromeDriver(options);            
	}

	@AfterClass
	public static void tearDown(){
		driver.quit();
	}

	@Test
	public void testMethod() throws InterruptedException{
		driver.get("https://www.amazon.com");
		WebElement searchInput;
		WebElement searchButton;

		searchInput = driver.findElement(By.xpath("//*[@id='twotabsearchtextbox']"));
		searchButton = driver.findElement(By.xpath("//*[@id='nav-search']/form/div[2]/div/input"));
			
		searchInput.sendKeys("flores");
		searchButton.click();
	}
}

Tras ejecutar la clase, se observa que se abre una ventana nueva de Chrome y comienza a hacer los pasos que le hemos indicado en el test.

Pues bien, con esto ya sabemos cómo lanzar pruebas contra nuestro navegador, ahora sólo queda indagar para saber cómo utilizar todos los métodos que interaccionan con los elementos de la página.

En un nuevo post, comentaré de qué formas diferentes podemos identificar los elementos que aparecen en la web.

¡Espero que sea de ayuda! ;)

Las pruebas o test funcionales son pruebas específicas que nos sirven para validar que el software hace lo que debe hacer y no hace lo que no debe hacer. Básicamente se utilizan para determinar que el sofware está funcionando como se especificó.

Hace unos meses intenté explicar esto a mis compañeros de equipo puesto que todos vamos a poner nuestro granito de arena en probar las aplicaciones lo más profundamente posible.

Los desarrolladores, con nuestra mente de desarrolladores, tendemos a hacer pruebas unitarias, esto es, probar funcionamientos de tipo: Tengo esta entrada –> debo obtener esta salida. Pero un test funcional requiere algo más, comprobar una característica por completo, un camino funcional.

De ahí que, si estamos acostumbrados a testear de forma unitaria, no lleguemos a ver “más allá de nuestra nariz” e intentemos probar nuestra aplicación como si sólo conociésemos el código.

Tenemos que ir más allá, meternos en la piel del usuario que utilizará la aplicación y comprobar los caminos que éste llevará a cabo cuando la maneje.

Plantearnos preguntas:

¿Se puede acceder a esta funcionalidad desde otro sitio? como por ejemplo en el caso de los registros en webs, a veces, si introduces mal las credenciales a la hora de hacer login, se te redirige a una página donde te invita a registrarte (página distinta a la original de registro).

¿Qué sucede si el usuario accede a este lugar sin hacer antes tal otra cosa? como por ejemplo comprar una canción antes de hacer login ¿te redirige a login?

En fin, mil posibilidades.

Y vosotros, al probar funcionalidades ¿qué os soléis preguntar?

¡A las pruebas!

Esta entrada simplemente pretende plasmar una buena práctica a la hora de seguir un esquema o plantilla cuando hay que reportar un bug.

Para quien no las conoza, existen medios como JIRA, que son herramientas enfocadas a la gestión de las tareas del equipo, es decir, son como agendas avanzadas que permiten indicar qué debe hacer cada trabajador, cómo hacerlo, establecer el tiempo que le ha llevado acometer cierta tarea etc.

Pues bien, cuando testeamos, encontramos bugs y de alguna manera debemos reportarlos para que el resto del equipo sepa que existen y se puedan resolver lo antes posible.

Una manera clara de indicar el error que acabamos de detectar, es la siguiente:

1. Crear una nueva issue tipo “bug” (o un nuevo “ticket” donde describiremos el bug) con un título descriptivo de lo que ha ocurrido, por ejemplo: “Error al publicar una canción favorita en red social”

2. Elegir los valores adecuados para los indicadores “fecha en que ha ocurrido”, “entorno”, “proyecto” etc, si corresponde

3. La descripción debe ser lo más estricta posible ¡He aquí el quid de la cuestión! por ello ésta contendrá los siguientes puntos:

• Acciones: Es donde contarás paso a paso lo que has hecho para reproducir el bug, por ejemplo:
  • Acceder a la web
  • Buscar una canción
  • Agregar esa canción a “mis favoritos”
  • Ir a menú > “mis favoritos”
  • Intentar publicar esa canción en una red social

Cuantos más detalles des mejor, piensa que la persona que lo lea, de primeras, no tiene ni idea de qué es lo que ha pasado ni cómo ha podido ocurrir. Todo detalle es poco.

• Comportamiento obtenido: comentas lo que ha ocurrido + detalles, por ejemplo:
  • Aparece página de error de tipo “loqueseaException”
• Comportamiento esperado: lo que debería haber ocurrido, por ejemplo:
  • Debería aparecer notificación de éxito.

Nos podemos valer además de unas “Precondiciones” (como primer punto, antes de los de la lista anteriormente mencionada) y unas “Notas” (como punto final). Las “precondiciones” nos sirven para indicar por ejemplo situaciones o elementos necesarios para poder reproducir el bug si no se ha podido indicar de alguna forma en el paso 2, por ejemplo: “Ocurre sólo desde el navegador Firefox con versión X”. Las “Notas” por su lado, pueden ser apuntes que creas convenientes para dar luz a los desarrolladores a la hora de afrontar la resolución o fix de ese error, por ejemplo: “Reproducido sólo entre las 15:00h y las 17:00h ¿ocurrió algo con el entorno en ese periodo de tiempo?”

Con esto, se tiene de una forma sencilla, un reporte de 10. Al final es ahorrar tiempo puesto que, cuanto más detalle, menos dudas tendrá el receptor de la issue.

Es lo que he aprendido en el día a día, espero que lo pongáis en práctica :)

Si eres QA seguro que te has visto en situaciones como: tener que certificar a última hora, encontrar un bug blocker en una release candidate o probar un caso enrevesado a ver qué ocurre. Pues bien todas esas reacciones son las que muestran estos gifs. Ver esta web con reacciones de QAs

Seguro que os echáis unas buenas risas ;)

¡Buen lunes!