Una aplicación puede pasar todas las demostraciones y fallar el primer lunes en manos de los usuarios. Basta con que un cliente escriba el NIF con guion, que una factura mezcle líneas al 21 % y al 10 % con un descuento global o que alguien vuelva atrás en el navegador justo después de pagar con Bizum. Las pruebas funcionales ponen a la aplicación frente a esas situaciones antes de que lo hagan sus clientes. Revisamos cada función contra lo acordado con el proveedor de desarrollo o, si nadie lo dejó por escrito, contra lo que el negocio espera. Da igual quién haya programado el software: su propio equipo, una agencia o nosotros. Todo el trabajo se hace en remoto, sobre un entorno de pruebas o de preproducción, sin tocar sus datos reales.
El trabajo no termina con una lista de errores. Queda en su poder una batería de casos que crece con cada versión y que cualquier persona de su equipo puede volver a pasar.
Antes de probar nada, ordenamos las funciones según lo que cuesta que fallen. En una tienda online, el cobro y el cálculo de portes van primero; la página de «Quiénes somos» puede esperar. En una intranet de una gestoría, el envío de documentación al cliente pesa más que el buscador.
Si hay documento funcional, historias de usuario o pliego técnico, lo leemos buscando contradicciones y huecos. Una regla ambigua detectada antes de programar se resuelve en una llamada; descubierta en producción, se convierte en semanas de parches.
NIF de personas y sociedades, NIE con y sin letra, IBAN de distintos bancos, códigos postales que empiezan por cero, direcciones con «s/n» o «3.º B», apellidos compuestos, tildes y «ñ», envíos a Canarias, Ceuta y Melilla, donde no se aplica IVA sino IGIC o IPSI. Muchos formularios aceptan datos de ejemplo y se rompen con los de sus clientes.
Tipos de IVA del 21, 10 y 4 %, recargo de equivalencia, retención de IRPF en facturas a profesionales, redondeos por línea frente a redondeos por total y, cuando aplica, el registro de facturación de Verifactu o TicketBAI. Aquí un céntimo de diferencia acaba en una llamada de su asesoría.
Seguimos una operación completa: pago por TPV virtual de Redsys, asiento en a3ERP, Sage 50 u Holded, etiqueta de SEUR, MRW o Correos y aviso por correo electrónico al cliente. Un fallo en la costura entre dos sistemas no lo ve ninguno de los dos proveedores.
Repetimos los casos de las zonas que ha tocado el desarrollo y de las que ya fallaron alguna vez. Es la forma más barata de evitar que un arreglo en el carrito rompa el área de clientes.
Cada fallo entra en Jira, GitLab o Azure DevOps con pasos, entorno, datos y resultado esperado. Al final del ciclo recibe un informe con lo cubierto, lo pendiente y el riesgo de publicar hoy.
El primer ciclo lleva más tiempo porque se escriben los casos desde cero; a partir del segundo, se reutilizan y el trabajo se acorta mucho. Solo necesitamos acceso remoto al entorno de pruebas y un interlocutor que conozca el negocio.
Una videollamada para ver la aplicación en funcionamiento y entender quién la usa, para qué y qué pasaría si fallara cada parte.
Alcance, navegadores y dispositivos, datos necesarios y lo que se deja fuera de forma consciente, con la estimación de horas por escrito.
Ejecución de los casos, registro de incidencias y verificación de cada corrección en cuanto el desarrollador la sube al entorno.
Recomendación de publicar o esperar, con incidencias abiertas, zonas sin probar y la batería de casos lista para el próximo ciclo.
Un buen informe de incidencia ahorra más horas que la propia prueba. «La factura sale mal» genera días de correos de ida y vuelta entre usted, el proveedor y su asesoría. «Pedido de 3 unidades con descuento del 15 %, cliente con recargo de equivalencia, el total del PDF difiere en 0,02 € del de pantalla» se corrige esa misma tarde. Así redactamos cada hallazgo, con captura o vídeo corto.
Sí, y es uno de los casos más habituales. Muchas empresas encargan el desarrollo a una agencia y quieren una revisión independiente antes de aceptar la entrega. Trabajamos con el entorno de pruebas que le facilite el proveedor y registramos las incidencias en la herramienta que él use, sin juicios de valor: hechos reproducibles.
No. Pedimos un entorno de pruebas con datos ficticios o anonimizados. Si solo existe producción, acordamos con usted qué acciones se pueden hacer sin efectos reales, por ejemplo pedidos con un método de pago de prueba que luego se anulan.
Es lo normal en muchas pymes. Empezamos con pruebas exploratorias, usando la aplicación como lo haría un empleado nuevo, y anotamos cómo se comporta. De ahí sale una primera descripción funcional que le servirá también para futuros proveedores.
Por horas, a 75 €/h + IVA, con un tope fijado en el plan de pruebas que no se supera sin su aprobación. Si publica versiones cada mes o cada semana, las pruebas recurrentes pueden incluirse en un plan Start, Business o Premium con cuota mensual fija.
Cuéntenos qué software es, quién lo desarrolla y qué le preocupa. Le enviamos un plan de pruebas con la estimación de horas.
Hemos recibido su solicitud
Tendrá respuesta en un día laborable. Si nos avisa de una avería que tiene parado a su equipo, la tratamos con prioridad.
No encontramos esa ciudad. Revise cómo está escrita o elija la capital de provincia más cercana: como trabajamos en remoto, el servicio es el mismo en cualquier punto de España.
