Skip to content

Testing

Jump to bottom
Griselda Aguirre edited this page Oct 15, 2026 · 12 revisions

Evidencia del Plan de Pruebas, Planilla de Test Cases, Evidencias, Reporte de Bugs, y tablero Kanban cargados los bugs asignados.

Documentación y Enlaces de Nexus Digital

Documentación Descripción
Plan de prueba inicial Plan de prueba inicial de la aplicación móvil Nexus Digital
Planilla Test Case Planilla inicial de casos de prueba

Testing – Nexus Digital App Móvil

1. Objetivo

Este documento describe la estrategia de pruebas de la aplicación móvil Nexus Digital, las herramientas utilizadas, los casos automatizados y los procedimientos necesarios para ejecutar los tests.

Durante el Sprint 2 se incorporaron pruebas unitarias locales, pruebas instrumentadas de interfaz de usuario y verificaciones de accesibilidad. Los resultados y las incidencias se registran mediante Issues de GitHub y evidencias de ejecución.

2. Entorno de pruebas

Tecnologías y herramientas

  • Aplicación: Android nativo desarrollado en Java.
  • Entorno de desarrollo: Android Studio.
  • JDK: versión 17.
  • Pruebas unitarias: JUnit y Mockito, según el caso.
  • Pruebas instrumentadas de interfaz: AndroidX Test y Espresso.
  • Pruebas de integración de red: JUnit y MockWebServer.
  • Accesibilidad: AccessibilityChecks y Accessibility Scanner.
  • Control y seguimiento: GitHub, Issues y Pull Requests.

Requisitos previos

  • Tener instalado JDK 17 y configurado el entorno de Android Studio.
  • Disponer del Android SDK y de las herramientas de compilación requeridas por el proyecto.
  • Tener el proyecto abierto desde la carpeta raíz de la aplicación Android.
  • Para las pruebas unitarias locales, no es necesario iniciar un emulador ni conectar un dispositivo.
  • Para las pruebas instrumentadas, disponer de un emulador Android o un dispositivo físico con depuración USB habilitada.
  • Utilizar un dispositivo o emulador compatible con el minSdk configurado en el proyecto. Actualmente, la aplicación tiene minSdk 24 (Android 8.0); se recomienda utilizar Android 11 (API 30) o una versión compatible posterior para reproducir el entorno de las pruebas registradas.

Estrategia de automatización

  1. Pirámide de pruebas El proyecto utiliza una estrategia por capas. Se priorizan las pruebas unitarias por su rapidez y aislamiento, se complementan con pruebas de integración y se automatizan flujos seleccionados de la interfaz de usuario.

             / UI \
        /------\
       / Integr.\
      /----------\
     / Unitarias  \
    /--------------\
Capa Herramientas Cantidad ejecutada Estrategia
Unitarias JUnit, Mockito mas de 40 test Automatizar validaciones y lógica aislada.
Integración JUnit, MockWebServer 2 tests informados Automatizar interacciones HTTP y tratamiento de respuestas.
UI instrumentada Espresso, AndroidX Test 1 tests informados en AUT-UI-01 Automatizar los flujos prioritarios de interacción.
Accesibilidad automatizada Espresso AccessibilityChecks 2 tests informados Detectar posibles problemas durante las pruebas de interfaz.
Accesibilidad manual asistida Accessibility Scanner 3 pantallas revisadas Complementar las comprobaciones automáticas mediante inspección de pantallas.

3.1. Justificación de la automatización

  • Pruebas unitarias: se automatizan porque permiten detectar rápidamente errores en validaciones, reglas y lógica de negocio sin depender de la interfaz.
  • Pruebas de integración: se automatizan para verificar la comunicación entre componentes y el comportamiento frente a respuestas HTTP, errores y problemas de conexión.
  • Pruebas de UI: se automatizan los escenarios prioritarios que requieren comprobar interacciones y mensajes visibles. No se duplican mediante Espresso todas las validaciones que pueden verificarse más rápidamente con pruebas unitarias.
  • Accesibilidad: se combinan herramientas automáticas con revisión manual, porque las herramientas no detectan todos los problemas que puede experimentar una persona al utilizar la aplicación.

3.2 Cómo ejecutar los tests

Los comandos deben ejecutarse desde la terminal, ubicándose en la carpeta raíz del proyecto Android, donde se encuentra el archivo gradlew.

3.3. Ejecutar pruebas unitarias locales

En Windows, utilizando PowerShell o Git Bash:

.\gradlew test

En Linux o macOS:

./gradlew test

Este comando ejecuta las pruebas unitarias locales configuradas para el proyecto, sin necesidad de un dispositivo Android conectado.

3.4. Ejecutar pruebas instrumentadas

En Windows:

.\gradlew connectedDebugAndroidTest

En Linux o macOS:

./gradlew connectedDebugAndroidTest

Este comando ejecuta las pruebas instrumentadas de Android en un emulador iniciado o en un dispositivo físico conectado y reconocido por ADB.

Antes de ejecutarlo, verificar que el dispositivo esté disponible y que las opciones de desarrollador y la depuración USB estén habilitadas cuando corresponda.

3.5. Consultar los reportes

Después de la ejecución, los reportes HTML se generan normalmente en las siguientes ubicaciones:

  • Pruebas unitarias: app/build/reports/tests/testDebugUnitTest/index.html
  • Pruebas instrumentadas: app/build/reports/androidTests/connected/index.html

Las rutas pueden variar según la configuración de Gradle y las tareas ejecutadas. Si no se encuentra un reporte, revisar la salida de la terminal para comprobar si la tarea finalizó correctamente.

4. Tipos de pruebas

Tipo Objetivo Herramientas
Unitarias locales Verificar validaciones y lógica de negocio de manera aislada. JUnit, Mockito
Instrumentadas de UI Verificar interacciones y respuestas visibles en la interfaz Android. AndroidX Test, Espresso
Integración de red Verificar el comportamiento de los componentes que realizan solicitudes HTTP. JUnit, MockWebServer
Accesibilidad automatizada Detectar posibles problemas de accesibilidad durante la interacción con la interfaz. Espresso, AccessibilityChecks
Accesibilidad manual Revisar pantallas mediante análisis asistido. Accessibility Scanner

5. Casos de prueba y resultados

Los estados indicados corresponden a los resultados documentados por el equipo. Los casos pendientes deben actualizarse cuando se implementen y ejecuten.

Issue Caso o finalidad Tipo Responsable Estado documentado
[#56](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/56) Validación de email válido. Unitaria local Juan Ignacio Alonso PASS
[#57](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/57) Rechazo de campos obligatorios vacíos, con espacios o nulos. Unitaria local Laura Molina PASS
[#58](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/58) Caso negativo de validación. Unitaria local Juan Ignacio Alonso PASS
[#59](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/59) Rechazo de emails con formato inválido. Unitaria local Augusto Andrés Raffaeli PASS
[#60](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/60) Login exitoso, credenciales inválidas y falta de conexión. Unitaria local María Soledad Scarlata PASS
[#61](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/61) Manejo de errores de autenticación y conexión. Unitaria local María Soledad Scarlata PASS
[#62](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/62) Prueba de integración de red. Integración Yohana Eugenia Grosso PASS
[#63](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/63) Prueba de integración de red. Integración Yohana Eugenia Grosso PASS
[#64](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/64) Login: mostrar error cuando los campos están vacíos. Instrumentada de UI Griselda Leonor Aguirre PASS
[#73](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/73) Verificaciones automatizadas de accesibilidad. Instrumentada de UI Aguirre Griselda Leonor PASS
[#70](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/70), [#71](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/71), [#72](https://github.com/Nexus-Proyecto/Nexus-Digital-App-Movil/issues/72) Análisis de accesibilidad de tres pantallas. Manual asistida Griselda Leonor Aguirre PASS

6. Criterios de entrada y salida

Criterios de entrada

  • Proyecto disponible y compilable.
  • Dependencias de testing configuradas.
  • Casos de prueba identificados.
  • Emulador o dispositivo disponible para las pruebas instrumentadas.

Criterios de salida

  • Resultados registrados para las pruebas planificadas.
  • Evidencias disponibles cuando correspondan.
  • Fallos e incidencias documentados.
  • Pruebas pendientes identificadas para su seguimiento en los siguientes Sprints.

Clone this wiki locally