Pruebas y control de calidad de una app: qué se prueba y qué probás vos

Las pruebas y el control de calidad de una app son el conjunto de verificaciones que se hacen antes (y después) del lanzamiento para detectar errores, confirmar que la app hace lo acordado y que se comporta bien en los dispositivos reales de tus usuarios. Si sos cliente, no hace falta que sepas programar para participar: hay una parte del control de calidad que solo vos podés hacer. Esta guía explica los tipos de pruebas, cómo se cubren los dispositivos y qué revisar de tu lado.

Probar no es lo mismo que «ver que ande»

Un desarrollador que prueba su propio trabajo tiende a recorrer los caminos que ya sabe que funcionan. El control de calidad busca lo contrario: romper la app, usarla de forma inesperada y comprobar que lo importante resiste. Ninguna prueba demuestra que no hay errores; reduce la probabilidad de que los más graves lleguen a tus usuarios.

Tipos de pruebas

Tipo	Qué verifica	Quién suele hacerla
Funcionales	Que cada función haga lo que debe	Equipo de desarrollo y calidad
De integración	Que las partes (app, servidor, servicios externos) funcionen juntas	Equipo técnico
De regresión	Que un cambio nuevo no rompa lo que ya andaba	Equipo, a menudo con pruebas automáticas
De usabilidad	Que las personas entiendan cómo usarla	Diseño, con usuarios reales
De rendimiento	Velocidad, consumo de batería y datos, respuesta con muchos usuarios	Equipo técnico
De seguridad	Protección de datos y accesos	Equipo técnico, según el riesgo
De aceptación	Que el resultado cumple lo que pediste	Vos, como cliente

Las pruebas automáticas, que ejecutan comprobaciones programadas en segundos, sirven sobre todo para regresión. No reemplazan la prueba manual, pero ahorran tiempo en cada nueva versión.

Dispositivos, versiones y condiciones reales

Una app que anda en el teléfono del desarrollador puede fallar en otro. Hay mucha diversidad, especialmente en Android: marcas, tamaños de pantalla, versiones del sistema y potencia de los equipos. Conviene acordar de antemano:

• Qué versiones mínimas de Android e iOS se van a soportar.
• Una lista de dispositivos de prueba representativa, que incluya equipos modestos y no solo modelos recientes.
• Condiciones reales: conexión lenta o inestable, falta de conexión, poca batería, llamadas o notificaciones que interrumpen.
• Distintos tamaños de letra y orientaciones, si corresponde.

Cuando no se dispone de todos los equipos, existen servicios de laboratorio de dispositivos en la nube; consultá a tu equipo si los usa.

Versiones beta con usuarios de verdad

Antes del lanzamiento público, una beta cerrada con un grupo reducido permite ver cómo se usa la app fuera del entorno controlado. Las tiendas ofrecen canales para esto: pruebas cerradas en Google Play y TestFlight en el App Store. Un buen grupo beta incluye personas de perfiles distintos y recibe una forma simple de reportar problemas.

Criterios de aceptación: cómo se sabe que algo está terminado

«Funciona» es subjetivo. Un criterio de aceptación es una condición verificable, redactada antes de construir, que define cuándo una función se da por buena. Por ejemplo: «si el usuario ingresa un mail inválido, ve un mensaje que lo explica y no pierde lo que ya completó». Con criterios claros, el cliente y el equipo evalúan lo mismo y se evitan discusiones al final. Cómo escribirlos está en la guía de documentar los requisitos de una app.

Qué probar vos como cliente

Hay tareas de control de calidad que dependen de tu conocimiento del negocio, no de la técnica.

1. El recorrido completo de tu caso más común. Hacelo como lo haría un usuario real, de principio a fin.
2. Los casos incómodos: cancelaciones, cambios, datos mal cargados, pedidos duplicados.
3. Los textos y los datos: nombres, precios, mensajes, términos propios de tu rubro.
4. Los permisos: que cada tipo de usuario vea solo lo que debe ver.
5. Los avisos y correos: que lleguen, con el contenido correcto y en el momento adecuado.
6. Distintos teléfonos: pedile la app prestada a alguien con un equipo más viejo o más chico que el tuyo.

Cuando encuentres algo, reportalo con tres datos: qué hiciste, qué esperabas que pasara y qué pasó. Si podés, sumá una captura y el modelo de teléfono. Un reporte así se corrige mucho más rápido que «no anda».

Qué no debería faltar antes de lanzar

• Una lista de los problemas conocidos y su gravedad, para decidir con criterio qué se corrige antes y qué después.
• Una forma de ver errores una vez publicada la app (monitoreo).
• Un plan para corregir rápido si aparece algo serio en producción.

La calidad no termina en el lanzamiento: sigue con el mantenimiento de la app. También te conviene repasar los errores comunes al lanzar. Si querés que revisemos el estado de una app antes de publicarla, escribinos desde el formulario de contacto.