Pruebas de Interfaces

1. Por qué y qué probar en una interfaz

La interfaz es lo único que el usuario ve de la aplicación: si un botón no responde, un formulario acepta datos erróneos o nadie encuentra la opción que busca, la aplicación ha fallado aunque el resto funcione. Las pruebas comprueban que la interfaz funciona, que es usable y que es accesible, y que sigue siéndolo después de cada cambio.

2. Pruebas automatizadas de interfaz

Un robot manipula la interfaz como lo haría un usuario (escribir, pulsar, esperar) y comprueba el resultado. Para que las pruebas sean estables, los controles se localizan por identificadores o por su rol accesible, no por su posición en pantalla.

1@ExtendWith(ApplicationExtension.class)
2class LoginTest {
3
4    @Start
5    void start(Stage stage) throws IOException {
6        Parent raiz = FXMLLoader.load(getClass().getResource("/login.fxml"));
7        stage.setScene(new Scene(raiz));
8        stage.show();
9    }
10
11    @Test
12    void credencialesIncorrectasMuestranError(FxRobot robot) {
13        robot.clickOn("#usuario").write("ana");
14        robot.clickOn("#clave").write("mal");
15        robot.clickOn("#entrar");
16        FxAssert.verifyThat("#mensaje", LabeledMatchers.hasText("Usuario o contraseña incorrectos"));
17    }
18
19    @Test
20    void botonDesactivadoSinDatos(FxRobot robot) {
21        FxAssert.verifyThat("#entrar", NodeMatchers.isDisabled());
22    }
23}

1class LoginScreenTest {
2    @get:Rule val compose = createComposeRule()
3
4    @Test
5    fun muestraErrorConEmailInvalido() {
6        compose.setContent { LoginScreen() }
7        compose.onNodeWithText("Email").performTextInput("ana")
8        compose.onNodeWithText("Entrar").performClick()
9        compose.onNodeWithText("Introduce un email válido").assertIsDisplayed()
10    }
11}

1import { test, expect } from "@playwright/test";
2
3test("suscripción con correo válido", async ({ page }) => {
4  await page.goto("http://localhost:5173/");
5  await page.getByLabel("Correo electrónico").fill("ana@mail.com");
6  await page.getByRole("button", { name: "Suscribirme" }).click();
7  await expect(page.getByText("Suscripción completada")).toBeVisible();
8});
9// npx playwright test --headed      (ejecuta en Chromium, Firefox y WebKit)

3. Pruebas de usabilidad

Las pruebas automáticas dicen si la interfaz funciona; solo las personas dicen si es fácil de usar. Con 5 usuarios se detectan la mayoría de los problemas importantes (Jakob Nielsen).

1. Objetivos: qué se quiere averiguar («¿encuentran cómo devolver un pedido?»).
2. Participantes: 5–8 personas del perfil real de usuario (no los desarrolladores).
3. Tareas: escenarios realistas sin pistas («Quieres devolver las zapatillas que compraste ayer»).
4. Sesión: el usuario piensa en voz alta; el moderador observa y no ayuda. Se graba la pantalla.
5. Métricas: tasa de éxito, tiempo por tarea, errores, clics, satisfacción (cuestionario SUS).
6. Informe: problemas encontrados, gravedad, evidencias y propuestas de mejora priorizadas.

El cuestionario SUS

El System Usability Scale son 10 afirmaciones que el usuario puntúa del 1 al 5 tras usar el sistema. Las impares son positivas (se resta 1) y las pares negativas (se resta de 5); la suma se multiplica por 2,5 y da una nota de 0 a 100. La media de la industria es 68.

4. Pruebas de accesibilidad

• Automáticas: axe DevTools, Lighthouse (pestaña de Chrome), WAVE. Detectan alrededor de un tercio de los problemas: falta de texto alternativo, contraste, etiquetas, roles.
• Teclado: recorrer toda la interfaz con Tab, Mayús+Tab, Enter, Espacio y flechas; el foco siempre visible y en un orden lógico.
• Lector de pantalla: NVDA (Windows), VoiceOver (macOS/iOS), TalkBack (Android). ¿Se entiende qué es cada control?
• Zoom y contraste: al 200 % no se pierde contenido; contraste mínimo 4,5:1 en texto normal.
• En Android, Accessibility Scanner; en JavaFX, probar con el lector de pantalla del sistema y setAccessibleText.

1// Prueba automática de accesibilidad con Playwright + axe
2import AxeBuilder from "@axe-core/playwright";
3
4test("la página de inicio no tiene errores de accesibilidad", async ({ page }) => {
5  await page.goto("/");
6  const resultados = await new AxeBuilder({ page }).withTags(["wcag2a", "wcag2aa"]).analyze();
7  expect(resultados.violations).toEqual([]);
8});

5. Plan de pruebas y documentación

Las pruebas se planifican y sus resultados se documentan para poder repetirlas y demostrar la calidad.

• Plan de pruebas: alcance, tipos de prueba, entornos (sistemas, resoluciones, navegadores, dispositivos), responsables, criterios de aceptación.
• Casos de prueba con datos concretos y resultado esperado, trazados a los requisitos.
• Informe de resultados con las incidencias abiertas (con capturas y pasos para reproducirlas) y su gravedad.
• Automatizar la ejecución en integración continua (GitHub Actions) para que cada cambio pase las pruebas antes de publicarse.

6. Ejercicios