Qué probar antes de lanzar un sistema
Al revisar un producto, conviene comprobar qué puede averiguar o hacer cada persona con la información disponible. La primera prueba se enfoca en permisos; las demás, en compartir, operar y recuperar información. Elegí las que correspondan al alcance de tu proyecto y pedí que se prueben con datos ficticios en un entorno de prueba.
1. Entrar desde otra cuenta
Situación: el sistema muestra pedidos, turnos, documentos o fichas que pertenecen a cada cliente.
Qué probar: creá dos cuentas de cliente. Con la primera, generá un pedido de prueba y copiá el enlace a su ficha dentro de la plataforma. Abrilo con la segunda cuenta y después en una ventana sin sesión. Si hay perfiles de empleado y administrador, repetí la revisión con esos permisos.
Resultado esperado: cada cuenta ve únicamente lo que las reglas del negocio le permiten. Un pedido privado de la primera cuenta no aparece para la segunda. Si existe un enlace público de seguimiento, queda definido qué campos muestra.
Qué pedir en la entrega: una lista de perfiles con lo que pueden ver, crear, editar, borrar y exportar, junto con el resultado de esta prueba. Ocultar un botón en una pantalla es apenas una parte: el acceso al dato también debe verificarse cuando se solicita.
2. Reenviar lo que el sistema permite compartir
Situación: el producto genera enlaces, archivos descargables, reportes o exportaciones.
Qué probar: reenviá un enlace de prueba fuera de la cuenta que lo recibió. Descargá un reporte y revisá sus columnas. Probá qué ocurre con un enlace temporal después de vencer y con el acceso de una cuenta a la que se le retiró el permiso.
Resultado esperado: lo compartido contiene los datos acordados para ese destinatario. Queda claro si el enlace exige iniciar sesión, si funciona para cualquiera que lo tenga, cuánto dura y cómo se revoca. Un reporte para un cliente no incluye notas internas ni datos de otros clientes.
Qué pedir en la entrega: un ejemplo de cada salida y su regla de acceso. Si una URL de descarga funciona como un permiso temporal para quien la tiene, esa decisión tiene que estar explicada. La cuenta y la copia descargada son cosas distintas: retirar un acceso no borra un archivo que alguien ya guardó.
3. Repetir una operación
Situación: alguien toca dos veces un botón, recarga después de enviar o reintenta porque la conexión tardó.
Qué probar: enviá dos veces el mismo pedido de prueba y revisá el resultado. Para pagos, pedí al equipo una demostración en el entorno de pruebas de la pasarela que incluya reintentos y avisos repetidos del mismo pago.
Resultado esperado: un mismo intento no genera dos pedidos, dos cobros ni dos descuentos de stock. Cuando el negocio permite repetir una operación, el sistema distingue esa decisión de un reintento de la anterior. La pantalla deja claro si está procesando o si ya terminó.
Qué pedir en la entrega: el identificador de la operación, el resultado final y qué impide procesarla dos veces. El término técnico es idempotencia: repetir el mismo intento conserva un solo efecto.
4. Interrumpir un servicio del que depende el sistema
Situación: falla un envío de correo, una conexión externa o la respuesta de una pasarela.
Qué probar: pedí que simulen la falla en el entorno de prueba. Revisá el estado que ve el cliente, el que ve quien administra y lo que ocurre cuando el servicio vuelve.
Resultado esperado: el producto distingue pendiente, completado y fallido según lo que realmente se confirmó. Un mail que no salió no borra un pedido ya registrado. Si el pago todavía no se verificó, la pantalla muestra ese estado y permite saber qué hacer después.
Qué pedir en la entrega: un ejemplo de falla y recuperación, con quién recibe el aviso y qué pasa con los reintentos. Si se necesita intervención manual, tiene que quedar identificado el paso y la persona que lo hace.
5. Recuperar la información
Situación: alguien borra información importante o hace falta recuperar una versión anterior.
Qué probar: pedí que restauren un respaldo en un entorno separado y abran registros concretos. Si hay archivos, que comprueben también esos archivos. Revisá una exportación y confirmá que puedas leerla con las herramientas previstas.
Resultado esperado: se puede mostrar qué se recuperó y de qué momento es la copia. La frecuencia del respaldo, el tiempo de recuperación y la información que podría faltar quedan acordados para el proyecto.
Qué pedir en la entrega: fecha del respaldo restaurado, registros comprobados, responsable y procedimiento. La existencia de un archivo de respaldo no demuestra por sí sola que la recuperación funcione.
Cómo dejarlo acordado con quien desarrolla
Por cada prueba aplicable, anotá estas cinco cosas:
- Escenario: la situación concreta que vas a probar.
- Acción: qué hace la persona y desde qué perfil.
- Resultado esperado: qué debería quedar visible o registrado.
- Evidencia: una captura, una grabación o un registro de la ejecución.
- Responsable: quién corrige o decide si algo queda pendiente.
Por ejemplo: "Cuenta de cliente B abre la ficha privada de un pedido de A. Se rechaza el acceso y no se muestran datos del pedido". Eso se puede verificar al revisar la entrega.
En Exos, el alcance de un sistema a medida se define a partir de las operaciones y de las personas que lo usan. Estas situaciones sirven para acordar las reglas y los resultados que se van a revisar. Podés contarnos qué querés construir y trabajar esa definición con nosotros.