QA Tech Argentina · Guía práctica · Web y móvil
Pruebas funcionales: que tu app haga lo que promete
Las pruebas funcionales verifican que cada función cumpla lo esperado. Registro, búsqueda, compra, edición de perfil, permisos de usuarios. Una guía para diseñar casos, priorizar y documentar resultados en productos usados en Argentina.
Lectura de 14 minutos · Con ejemplos de validaciones locales y errores típicos de cada release.
Registro y login
Altas, accesos y permisos por rol.
Compra y pagos
Checkout, cuotas y factura electrónica.
Datos locales
CUIT, CBU, IVA y códigos postales.
Web y móvil
Chrome, Android medio y modo sin conexión.
Regresión
Humo de 15 minutos antes de liberar.
Base conceptual
Qué son y qué no son las pruebas funcionales
Una prueba funcional compara lo que pasa con lo que debería pasar según requisitos, diseño o sentido común del negocio. No mide velocidad ni seguridad. Mide corrección.
Si el formulario pide CUIT, debe aceptar un CUIT válido y rechazar uno inválido con un mensaje claro. Si el botón dice confirmar compra, debe generar el pedido, descontar stock y enviar el comprobante. Esa simpleza es su fuerza: permite discutir con desarrollo y producto sobre hechos, no sobre opiniones.
Son la base antes de pensar en automatizar o medir rendimiento. Cuando la validación funcional está ordenada, cada defecto se entiende, cada flujo crítico tiene su caso y cada release empieza con una lista corta de lo que debe andar sí o sí. En QA Tech Argentina las usamos como idioma común entre diseño, desarrollo y soporte: si algo no cumple la función prometida, se registra, se prioriza y se vuelve a probar hasta que el comportamiento coincide con lo acordado.
Cómo distinguirlas en la práctica
- Funcional: el sistema calcula bien las cuotas con interés y muestra el total con IVA discriminado.
- No funcional: cuánto tarda esa pantalla con mil usuarios a la vez, o si los datos viajan cifrados. Eso se valida en rendimiento y seguridad.
- Señal de faltante funcional: dos personas del equipo describen distinto lo que debería hacer el mismo botón. Ahí falta un caso escrito.
La corrección se comprueba contra lo acordado: diseño, regla de negocio y comportamiento visible.
Para dejar de probar a ciegas
Empezá por los flujos que mueven dinero o datos sensibles: acceso, pagos, altas y reportes. El resto se ordena en el siguiente ciclo.
Revisar servicios de QARitmo de trabajo por sprint
Cuándo aplicarlas en tu ciclo de entrega
Convienen en cada sprint y antes de cada release a producción. En equipos argentinos con entregas semanales, recomendamos una pasada corta durante el día sobre lo nuevo y una regresión más amplia antes de liberar. También son clave después de migraciones, cambios de proveedor de pago o actualizaciones de framework.
Pasada intradiaria sobre lo nuevo
Historias recién terminadas, con datos frescos y ambiente actualizado. Detecta choques de integración el mismo día.
Regresión antes de liberar
Flujos críticos completos: login, compra, facturación y permisos. Es la red que sostiene el deploy.
Después de cambios sensibles
Migración de base, nuevo agregador de pagos, cambio de versión de framework o de app móvil.
Si solo tenés dos horas
Usalas en los caminos que mueven dinero o datos personales. El resto puede esperar al siguiente ciclo sin culpa.
Un buen caso tiene título claro, precondiciones, pasos numerados, datos concretos y resultado esperado. Mejor varios casos cortos y reutilizables que un caso gigante que prueba cinco cosas a la vez.
Ver proceso de trabajo
Casos cortos con datos realistas se reutilizan release tras release.
Diseño de casos
Casos cortos que cualquiera puede repetir
Guardalos en una planilla o en tu gestor de casos con un identificador estable para referenciarlos en los defectos. Usá datos argentinos realistas: DNI de 7 u 8 dígitos, CUIT con guiones, teléfonos con código de área, direcciones de CABA y del interior.
Título + precondición
Qué se prueba y desde dónde se parte. Ejemplo: usuario registrado con CBU cargada, carrito con dos unidades, ambiente de prueba reiniciado.
Pasos y datos
Pasos numerados con valores concretos, no genéricos. CUIT 20-12345678-5, postal 5000 Córdoba, tarjeta local en modo sandbox.
Resultado esperado
Qué debe verse y qué debe guardarse. Sin resultado esperado escrito, el caso no sirve para discutir con desarrollo.
Evitá mezclar validaciones distintas en un mismo caso. Separar permite marcar qué falló exactamente y reutilizar cada pieza en la regresión del mes siguiente.
Técnicas y cobertura de pruebas
Técnicas simples que cubren casi todo
Partición de equivalencia, valores borde y tablas de decisión resuelven la mayoría de los casos sin complicarte. No necesitás aplicar todas las técnicas formales para tener buena cobertura de pruebas: con tres herramientas bien usadas y pruebas exploratorias con tiempo acotado, la validación de producto digital rinde mucho más.
Equivalencia y bordes
Probar los límites, no solo el centro
Para un campo de descuento que acepta de 1 a 100, probá 0, 1, 99, 100 y 101. Para edad mínima, DNI o cantidad de cuotas, los errores viven en los bordes. Agrupá valores equivalentes y elegí un representante de cada grupo en vez de repetir cien variantes iguales.
Tablas de decisión
Combinar sin perderse
Para envíos, combiná provincia, peso y método de pago en una tabla: cada fila es un caso. Lo mismo para promociones con medio de pago y banco. La tabla muestra combinaciones olvidadas y evita probar dos veces lo mismo con distinto nombre.
Prioridad por riesgo: qué probar primero
No podés probar todo. Ordená por riesgo: probabilidad de fallo por impacto. Un error en el cálculo de cuotas con interés impacta en facturación y reclamos. Un typo en una pantalla secundaria, menos. Asigná prioridad alta a login, pagos, altas y reportes críticos.
Marcá qué queda fuera de cada ciclo y por qué. Esa lista de exclusiones es tan valiosa como la de pruebas, porque fija expectativas con producto y evita discusiones después del release. Las pruebas exploratorias con charter —por ejemplo, 60 minutos buscando errores en el checkout como usuario nuevo— complementan la cobertura planificada.
Orden sugerido
- Alta — Acceso, compra, pagos y emisión de comprobantes.
- Media — Buscador, filtros, edición de perfil y notificaciones.
- Baja — Textos secundarios y preferencias visuales. Se programan para el próximo ciclo.
Detalles que rompen en producción
Validaciones típicas argentinas
Son detalles que suelen romperse si solo se probó con datos genéricos. Prestá atención a CUIT y CUIL, validación de CBU, precios con IVA discriminado, percepciones según jurisdicción, formatos de factura electrónica y direcciones con piso y departamento.
- En pagos, probá tarjetas locales en modo sandbox, rechazo por fondos, cuotas sin interés y pagos en efectivo que quedan pendientes hasta acreditar.
- En logística, probá códigos postales de distintas provincias y costos de envío diferenciados, con direcciones largas del interior.
- En facturación, verificá letra de comprobante, CAE y datos del receptor tal como los pide la operatoria local.
Set de datos que conviene tener a mano
DNI de 7 y 8 dígitos, CUIT válido e inválido, CBU de prueba, teléfonos con 011, 0341 y 0351, calles con piso, departamento y loteo. Si el ambiente los conserva entre ciclos, la regresión deja de ser una lotería.
La foto muestra una mesa real de validación: comprobantes, mate y ambiente de prueba.
Defectos que se entienden
Reporte de defectos que se puede reproducir
Un defecto útil se puede reproducir. Incluí entorno —navegador, versión de app, ambiente—, pasos exactos, dato usado, resultado esperado y obtenido, y evidencia. Agregá severidad, cuánto rompe, separada de prioridad, cuándo conviene arreglarlo.
Ejemplo: no poder emitir factura es severidad alta aunque haya pocos usuarios afectados. Sé específico en el título. “Error 500 al confirmar compra con tarjeta Visa en Chrome” sirve. “No anda el pago” no sirve, porque obliga a adivinar.
Antes de marcar duplicado
Buscá por título y por flujo antes de cargar uno nuevo. Los defectos duplicados sin búsqueda previa son uno de los errores que más tiempo hacen perder al equipo.
Cada reporte anota modelo, sistema operativo y versión de app.
Pruebas en web y en móvil
En web probá en Chrome y al menos otro navegador, más vista mobile, porque gran parte del tráfico argentino entra por celular. En móvil probá en Android de gama media con poca memoria y en iOS si tu audiencia lo usa.
Verificá comportamiento sin conexión, interrupciones por llamada y permisos. Si tu app depende de notificaciones push o geolocalización, probalas con datos reales de barrios y con GPS desactivado. Anotá modelo y versión del sistema en cada reporte para que desarrollo reproduzca el contexto exacto.
Errores comunes que vemos en equipos
Ninguno es grave si se nombra a tiempo. Todos se corrigen con rutina.
·Casos sin resultado esperado: se prueba, pero nadie sabe qué debía pasar.
·Ambientes desactualizados o datos que cambian entre ejecuciones.
·Probar solo el camino feliz. El usuario real se equivoca, vuelve atrás, recarga y paga dos veces por apuro.
·Regresión manual que nadie quiere hacer porque tarda horas y no está acotada.
·Defectos duplicados y capturas sin contexto de versión o dato usado.
Dejá una checklist de humo de 15 minutos antes de cada deploy y evitás las fallas más visibles.
Puente hacia automatización
Cuando un caso se repite, es candidato a automatizar
Empezá por login, registro y compra básica. Dejá afuera lo que cambia cada semana o lo visual muy fino. Documentá los casos de forma que otro tester pueda automatizarlos después sin preguntarte todo.
La base funcional ordenada es lo que hace que la automatización no se caiga en la primera semana. En la página de Automatización explicamos criterios y herramientas para dar ese paso con calma.
Preguntas habituales
Lo que nos preguntan antes de ordenar las pruebas
¿Cuántos casos necesito para un MVP?
Para un MVP web típico con registro, catálogo y pago, entre 40 y 80 casos principales suele cubrir los flujos críticos. Lo importante es priorizar, no inflar el número. Con login, búsqueda, compra, pagos locales y edición de perfil bien cubiertos, el resto se agrega por riesgo en los sprints siguientes.
¿Sirve probar sin requisitos escritos?
Sí, con pruebas exploratorias y checklist basadas en el producto real. Recorré como usuario nuevo, anotá cada suposición sobre lo esperado y acordala con el equipo. Esa nota breve vale como requisito hasta que producto la confirme o la corrija.
¿Cada cuánto conviene hacer regresión?
Antes de cada salida a producción, aunque sea breve. Una pasada de humo de 15 minutos sobre acceso, compra y facturación frena los errores más visibles. La regresión amplia se reserva para cambios de pagos, migraciones o nuevas versiones de app.
¿Qué datos de prueba conviene conservar?
Usuarios por rol, productos con stock conocido, tarjetas de sandbox aprobadas y rechazadas, CUIT y CBU de prueba y direcciones de distintas provincias. Si el ambiente se reinicia, dejá un guion corto para recrearlos igual cada vez.
QA Tech Argentina es una guía independiente sobre calidad de software. Si querés ordenar tus casos con ayuda externa, escribinos y lo revisamos juntos.
Cierre de ciclo
Cubrí lo importante en cada release: flujos que mueven dinero, datos sensibles y validaciones locales. El resto, anotado y programado.
Av. Corrientes 1233, Buenos Aires · Lunes a Viernes de 9:00 a 18:00 · [email protected]