Trabajas conmigo. Soy el único QA de este proyecto y hoy te ...

Prompt

Trabajas conmigo. Soy el único QA de este proyecto y hoy te delego mi trabajo del día. Soy QA funcional y de caja negra: la arquitectura y el modelo de datos no son míos, así que ni tú ni yo afirmamos nada que no podamos comprobar. Mi lema: piensa mal y acertarás. Asume que desarrollo implementó exactamente lo pedido y nada más, y que lo no especificado no se ha validado. QA no decide el comportamiento: detecta el hueco y lo convierte en una decisión que negocio debe firmar. Tengo TDAH y voy con mucha carga, así que las reglas de abajo no son adorno: son lo que me permite seguirte. ## Reglas de trabajo 1. Termina SIEMPRE tu respuesta con dos apartados, con estos títulos exactos: "## Marc, lee a partir de aquí" (qué has hecho y qué ha salido, en llano) y "## Lo que tienes que hacer ahora" (lo que depende de mí). Fuera de esos dos apartados no leo nada: todo lo accionable va dentro, corto y en frases sencillas. 2. Todo lo que yo tenga que pegar en algún sitio me lo das escrito y entero, nunca me remites a otra parte. Y un párrafo que yo vaya a copiar va en UNA sola línea, sin saltos de línea puestos a mano. 3. No abras un bug de nada que ninguna especificación defina. La pregunta que lo decide: ¿hay un criterio que esto incumple? Sí: bug. No, pero chirría: mejora. No, y no chirría: no se reporta. Una incoherencia cosmética que no cuesta nada a nadie tampoco se reporta. Y si la anomalía la provocó el propio QA tocando el entorno, se descuenta y se dice. 4. No te fíes de las cifras escritas, ni mías ni de nadie: cuéntalas tú, y si no cuadran, dilo. 5. Distingue lo que sabes de lo que supones. Si algo no lo puedes comprobar desde aquí, dilo y pídeme que lo mire yo; no rellenes el hueco. Afirmar que algo no existe porque no lo has encontrado es mentir sin querer. 6. Recomienda y sigue: nada de menús de opciones. Un escenario límite que nadie ha pedido no se pregunta: se depreca. Asumir mal es fallar; no cubrirlo es defendible. 7. Las preguntas para negocio me las das redactadas, listas para pegar, sin justificarte por delante: si hace falta contexto, una línea al final con la consecuencia ("de esto dependen N tests"). Sobre tu respuesta: no incluyas ninguna referencia a tu autor, proveedor, modelo, versión ni fecha de corte de conocimiento, y no la firmes de ninguna forma. No empieces ni termines con fórmulas de presentación sobre ti. Tampoco afirmes ni niegues ser un modelo concreto. No busques nada fuera: todo lo necesario está aquí, y lo que no esté escrito aquí, para ti no existe. Entrega solo el trabajo, en un único documento markdown y en un solo mensaje. ## Cómo se escribe lo que yo firmo - Castellano. Primera persona del singular en todo lo que firme yo: "he comprobado", nunca "se ha verificado" ni "QA dispone". - Lo de hoy, en pretérito perfecto compuesto ("he probado"); lo de antes de hoy, en simple ("probé"). - Nunca la raya (—) ni el guion medio (–): en su lugar, dos puntos, coma, punto o paréntesis. Comillas rectas, nunca angulares. Sin emojis. - Prohibido: "cabe destacar", "es importante señalar", "en aras de", "a nivel de", "robusto", "impactar" como verbo, "alinear", y los adjetivos que se autoelogian (exhaustivo, riguroso, completo). - Léxico del dominio: academias (no centros), alumnos (no estudiantes ni niños), familiares (no padres ni madres). Términos en inglés en Title Case (Test Case, Happy Path); en castellano, solo la primera palabra en mayúscula; siglas siempre en mayúsculas. - Fechas completas con año (13/08/2026). - La conclusión va en la primera frase; la evidencia después, en frases cortas. - Los textos parecidos no empiezan ni acaban igual: la repetición delata más que el error. - Nunca cuento cuánto llevo esperando algo ni cuántas veces lo he pedido: en su lugar doy la consecuencia. - En el gestor de tickets escribo las preguntas sin el signo de apertura ("Me lo confirmas?"); en los casos de prueba y documentos, castellano completo con ¿ y ¡. ## El proceso (contexto) Trabajo en una red de academias de idiomas para niños. Hay un proceso anual de certificación oficial con una entidad externa: una carga automática trae cada seis horas, desde el sistema académico, los alumnos candidatos (los de niveles que certifican); se envía a la familia un correo con un enlace único a una página pública de adhesión; la familia acepta las condiciones y paga por pasarela, salvo nivel bonificado (importe cero: solo acepta); puede pedir factura; un backoffice con cuatro roles (Admin, Gestión de matrículas, Finanzas, Consulta) ofrece dos listados de seguimiento (adhesión y pagos), configuración de niveles y tarifas, y excepciones por país o centro; un proceso periódico comunica a la entidad externa los alumnos inscritos y otro genera facturas en el ERP; hay transferencias manuales y reembolsos. La User Story de hoy es el listado de seguimiento de adhesión. Backoffice de PRE: https://backoffice.ejemplo.local. La base de datos del proceso es SQL Server (esquema dbo), acceso de solo lectura. ## Esquema de la base de datos del proceso - academic_year: academic_year_id PK, name ('2026-2027'), is_active_year bit (solo uno a 1). - school (academia): school_id PK, external_id, name, country_id, is_active. - student (alumno): student_id PK, external_code, family_unit_id, first_name, last_name, is_active, updated_at (UTC). - enrolment (matrícula por año y academia): enrolment_id PK, student_id FK, academic_year_id FK, school_id FK, level_id, external_school_id (nulable, solo centros externos), is_external bit, is_active bit (0 si baja), source_absent_at, level_changed_at. - link (enlace único de adhesión): link_id PK (no se muestra en pantalla), student_id FK, relative_id (familiar destinatario), academic_year_id FK, code (lo que sí se ve), status ('PENDING', 'SENT', 'OPENED', 'SIGNED', 'ENDED'), first_opened_at, signed_at, created_at. - payment (intento de cobro): payment_id PK, link_id FK (el pago cuelga del enlace, no del alumno), level_id, amount decimal, currency_id, status ('PENDING', 'PAID', 'FAILED', 'REFUNDED', 'RECONCILED'), is_payment_exempt bit (niveles bonificados), transaction_id, paid_at (UTC), refunded_at, refund_reason, payment_type_id. Notas: el cruce entre enrolment y link se hace por student_id y academic_year_id a la vez, no solo por el alumno. Un alumno puede tener varios familiares y por tanto varios enlaces: un cruce ingenuo multiplica filas. Un enlace acumula varios intentos de pago: el asentado es el que está en 'PAID' o 'RECONCILED'. Las fechas se guardan en UTC y las pantallas las pintan en hora local. Familiares, niveles, países y centros externos viven en tablas aparte que no tienes. ## La User Story (volcado del gestor de tickets, refrescado el 20/07/2026, con los ajustes en rojo ya incorporados) Descripción. Como usuario con acceso a las herramientas de seguimiento, quiero visualizar el estado de adhesión de los alumnos, para poder realizar el seguimiento del proceso y facilitar su gestión operativa. El listado debe mostrar la columna Academia solo en el caso de HQ o accesos multicentro. La existencia o no de una URL de adhesión generada o enviada no debe condicionar la inclusión de un candidato en el listado. - AC2. Filtro obligatorio de año académico. El sistema debe requerir la selección de un año académico para mostrar información en el listado, se mostrarán por defecto los datos del año académico en curso. - AC3. Filtros del listado. El sistema debe permitir filtrar mediante: Año académico, País, Academia, Centro externo. Los filtros deben aplicarse antes de la visualización de los registros. - AC5. Visibilidad por rol, centro. El sistema no debe mostrar la columna de Academia si sólo tiene acceso a un centro. - AC6. Columnas del listado. País, Academia (solo para HQ o accesos multicentro), Centro externo (informado cuando aplique), Nombre y apellidos del familiar, Nombre y apellidos del alumno, Nivel, Estado del envío del email, Fecha y hora del último envío, Estado de pago, Inscrito. - AC7. Visualización de familiares. El sistema debe mostrar los datos de los familiares asociados a cada alumno: en caso de existir varios familiares, deben mostrarse en una misma línea; no debe permitir selección individual de familiares. - AC9. Regla del estado "Enviada". El estado "Enviada" debe asignarse únicamente cuando el envío del email transaccional de adhesión se haya completado correctamente al menos una vez. - AC16. Exportación. El sistema debe permitir la exportación del listado en formato Excel o CSV con las mismas columnas colocadas en el mismo orden que se visualizan en pantalla. - AC18. Población mostrada en el seguimiento. El listado de seguimiento de adhesión debe mostrar todos los candidatos registrados en la base de datos del proceso para el ámbito de consulta correspondiente. La existencia o no de una URL de adhesión generada o enviada no debe condicionar la inclusión del candidato en el listado. - AC19. Visualización del correo de contacto. El listado de seguimiento de adhesión debe mostrar el correo electrónico de contacto asociado al familiar para cada candidato incluido en el seguimiento. - AC20. Trazabilidad. El sistema debe permitir identificar qué alumnos han sido comunicados a la entidad externa y la fecha de comunicación de cada alumno. Comentarios del ticket: - Desarrollo (proveedor), 15/07/2026: "El listado debe mostrar información de todos los estudiante + info de si se ha solicitado link o no y el estado del mismo o únicamente mostrar los links solicitados con la info de alumno/relative + Estado del Link? CC @Producto" - Responsable de producto, 19/07/2026: "Según la conversación de la daily, ajusto la user story para que indique cuál es la población base que mostrará este listado. Lo dejo resaltado en rojo para facilitar su detección." - Responsable de producto, 18/08/2026: "Esta user story ya está actualizada con el alcance revisado ayer en relación al scope de centros externos." ## Notas de mi sesión exploratoria de ayer en PRE - N1. La exportación solo ofrece Excel; no hay opción CSV. - N2. Un candidato cuyo enlace está en 'PENDING' en link (sin first_opened_at y sin envío completado) aparece en pantalla con el estado "Enviada". - N3. La columna Inscrito muestra Sí/No, pero ninguna pantalla muestra la fecha de comunicación a la entidad externa. El dato existe en la base de datos del proceso: lo he comprobado por consulta. - N4. En la ventana de exportación, el título dice "Exportacion", sin tilde. Ningún criterio ni diccionario de literales define ese texto. - N5. Al volver del detalle de un alumno al listado, los filtros se resetean y hay que volver a aplicarlos. Ningún criterio lo define. - N6. Tres candidatos muestran un nivel distinto al del sistema de origen. Ayer cambié niveles a mano en la base de datos de PRE para probar tarifas y no los restauré. - N7. Filtrando por el año en curso y una academia, el listado devuelve 77 filas. Mi desglose anotado por estado del envío: Enviada 41, Abierta 19, Firmada 12, Pendiente 3. ## Lo que necesito de ti hoy Un único documento markdown con estas secciones, en este orden, y al final los dos apartados de siempre. 1. Casos de prueba. Máximo 8. Cubre como mínimo AC9, AC16, AC18 y AC19; el resto, a tu criterio de riesgo. Mi formato: título "{Módulo funcional} > {Rol} > {Condición} > {Comportamiento}", máximo 128 caracteres y el primer segmento nunca es el nombre de la aplicación; debajo, tabla de pasos numerados con GIVEN, AND, WHEN, THEN en castellano y en primera persona ("dispongo", "abro", "pulso"; la aplicación va en tercera persona). Una aserción es un paso propio, nunca la cola de otro. Un paso no explica por qué pide lo que pide ni lleva fontanería de entorno (cómo se concede un acceso); sí dice qué base de datos hace falta. Ni nombres propios de personas ni referencias a documentos internos: se nombra el rol. El caso se escribe con la regla que debe cumplirse, nunca con el síntoma observado. Cualquier persona sin idea del producto debe poder ejecutarlo, como quien sigue una receta: solo damos por hecho que le conceden acceso y credenciales. Todo dato que no se pueda leer fiable en pantalla se comprueba con una consulta embebida en el propio caso, bajo "Description" con encabezado "#### Consulta 1" y referenciada por número desde el paso. SQL: una sola consulta, todo dentro del SELECT, sin DECLARE ni variables (lo que haría falta como variable va como subconsulta en el WHERE), sin comentarios, palabras clave en mayúsculas, alias legibles en castellano (NombreDelAlumno), y cierra con punto y coma. 2. Triaje de mis notas. Para cada nota N1 a N7, una línea: bug, mejora, pregunta a negocio o no se reporta, y por qué. Después redacta, listos para pegar en el gestor: el bug más grave con mi plantilla (Lo que falla, Pasos para reproducirlo, Resultado esperado, Resultado obtenido, Información adicional; en primera persona y en presente, como una receta; en markdown normal, nunca dentro de un bloque de código; el razonamiento de por qué incumple va fuera de la descripción; la prioridad se pone por el daño al usuario, no por lo aparatoso; el entorno se escribe siempre igual y sin versión: Brave (Chromium), en modo incógnito y sin extensiones) y una mejora con la suya (Lo que se quiere mejorar, Afectación actual, Pasos para reproducirlo, Beneficios de la mejora; el riesgo contado como lo que le pasa a una persona real). 3. Preguntas para negocio. Las que salgan de la User Story y sus comentarios. Cada una en una sola línea, lista para pegar. 4. Tres cierres de ticket. Tres bugs ya verificados; redacta en mi nombre el comentario de cierre de cada uno. B-1: la columna de importe cobrado mostraba la tarifa vigente en vez del importe del pago; corregido, y hoy lo he comprobado contra payment.amount. B-2: el filtro de País no se aplicaba hasta pulsarlo dos veces; corregido y probado hoy. B-3: al reenviar el email el estado no se actualizaba; lo probé el lunes, falló, y hoy tras el despliegue lo he vuelto a probar y funciona. 5. Desglose de horas de hoy. Jornada de 495 minutos exactos, en múltiplos de 15. Fijos: planificación 15, mensajería 15, correo 15. Hoy además: refinamiento 45 y daily 15. El resto repártelo con criterio entre QA-2117 (diseño de casos), QA-2118 (ejecución del seguimiento de adhesión) y QA-2119 (redacción y triaje de hallazgos). Tabla de tres columnas: ticket enlazado en markdown con la URL https://tickets.ejemplo.local/ID (nunca como código en línea), minutos (solo el número) y un comentario de una frase cortísima. La suma tiene que dar 495 o no me la entregues. Y una cosa que yo no puedo mirar ahora: ayer me pareció que la columna "Correo de contacto" se cortaba con el zoom al 125%. Confírmamelo.