Cómo probar un software a medida antes de aceptarlo

Para probar un software antes de aceptarlo, prepara una lista de tareas reales de tu negocio y hazlas tú mismo en la versión entregada. Comprueba los casos raros, los datos y los permisos de cada usuario, y apunta cada fallo con pasos para repetirlo. Acepta la entrega solo cuando lo pactado funcione, y pide que quede por escrito.

Por qué tienes que probar tú.

El equipo de desarrollo hace sus propias pruebas, pero no conoce tu negocio como tú. Lo que para ellos funciona puede no servir en tu día a día.

Las metodologías públicas lo recogen. Métrica versión 3 incluye un proceso específico de implantación y aceptación del sistema. Es el momento en que el cliente comprueba que lo entregado es lo que pidió.

También tiene consecuencias legales. Si el contrato dice que la obra se hará a tu satisfacción, el Código Civil prevé que, sin acuerdo, la aprobación quede al juicio de un perito. Mejor resolverlo antes con pruebas claras.

Prepara las pruebas antes de la entrega.

No esperes a recibir la versión para pensar qué probar. Prepara una lista de tareas concretas, sacadas de tu documento de requisitos.

Cada prueba debe tener un resultado esperado. «Crear un presupuesto para un cliente nuevo y enviarlo por correo» es una prueba. «Ver si funciona» no lo es.

Si aún no tienes ese documento, mira cómo preparar el encargo de un software.

Qué revisar en cada entrega.

• Las tareas principales. Las que tu equipo hará cada día, de principio a fin.
• Los casos raros. Un cliente sin correo, una factura rectificativa o un producto agotado.
• Los datos. Que lo que guardas aparece igual al volver a abrirlo y en los informes.
• Los permisos. Que cada usuario ve solo lo que debe ver.
• La accesibilidad. Si te la piden o la necesitas, la referencia vigente del W3C es WCAG 2.2.

La seguridad merece un apartado propio. El RGPD prevé, según el riesgo, un proceso para verificar y evaluar con regularidad la eficacia de las medidas de seguridad. Pregunta qué pruebas de seguridad ha hecho el proveedor.

Cómo informar de un fallo.

Un buen aviso de fallo ahorra días. Incluye qué hiciste, qué esperabas y qué pasó, con una captura si puedes.

Indica también en qué dispositivo o navegador ocurrió y si se repite. Un fallo que no se puede repetir es muy difícil de arreglar.

Usa un único lugar para los avisos, como una hoja compartida o el gestor de tareas del proyecto. Así nada se pierde en el correo.

Ordena los fallos por gravedad. No es lo mismo un error que impide facturar que una palabra mal escrita en un botón.

Pruebas de apps en el móvil.

Las apps se prueban en el móvil, no en una demostración. Las tiendas lo facilitan.

En las pruebas internas de Google Play, los testers suelen recibir la versión unos segundos después de añadirlos. En iPhone se usa TestFlight. Para personas de fuera del equipo, Apple pide una descripción de la beta y datos para revisarla.

Prueba en varios móviles, con conexión mala y sin conexión. Lo que funciona en la oficina puede fallar en la calle. Tienes más detalle en cómo publicar una app en las tiendas.

Cuándo aceptar y qué firmar.

Acepta una entrega cuando las pruebas pactadas funcionan. Los detalles menores pueden quedar en una lista para la siguiente versión, siempre que estén apuntados.

Deja constancia por escrito: qué se probó, qué quedó pendiente y en qué fecha se acepta. Ese documento sirve después para distinguir un fallo de origen de un cambio. La cláusula de aceptación del contrato la explicamos en qué debe incluir un contrato de desarrollo de software.

Cómo lo hacemos nosotros.

Trabajamos por fases, cada una con su presupuesto cerrado. Durante el primer año tras la entrega corregimos sin coste los fallos de origen de nuestro desarrollo.

Un ejemplo de proyecto con varias piezas que probar es el de Nutrivazquez, con un CRM web y una app en Android y en iOS. Puedes ver cómo trabajamos en desarrollo de software a medida. Y las fases completas, en fases del desarrollo de software.

Preguntas frecuentes.