Documentación de control de calidad

6.5 Documentación de control de calidad

La documentación de control de calidad engloba el conjunto de especificaciones, procedimientos, criterios de aceptación y registros relacionados con la validación y aseguramiento de calidad de un producto editorial multimedia. Mientras que la documentación de usuario explica cómo usar el producto, y la documentación de mantenimiento explica cómo mantenerlo operativo, la documentación de calidad responde a la pregunta fundamental: «¿Cómo sabemos que este producto funciona correctamente y cumple las expectativas?» Es la documentación que vincula la intención comercial y funcional del producto con la evidencia verificable de que esa intención se ha cumplido.

Desde la perspectiva de gestión empresarial de la calidad, esta documentación es el corazón de la garantía de calidad. Sin ella, la calidad depende de intuición o de memoria personal, y no es auditable ni reproducible. Para un producto editorial multimedia con potencialmente miles de usuarios y millones de transacciones, la ausencia de documentación de calidad es garantía de problemas recurrentes, insatisfacción del cliente, y incapacidad para demostrar mejora continua.

Especificaciones de requerimientos funcionales

La documentación de calidad comienza con una especificación clara de qué debe hacer el producto. Para un producto editorial multimedia, esto incluye: funcionalidades de búsqueda (debe permitir búsqueda por título, autor, categoría, fecha de publicación, debe devolver resultados en menos de 2 segundos), funcionalidades de lectura (debe soportar múltiples formatos de archivo como PDF, EPUB, compatibilidad con dispositivos móviles, accesibilidad para usuarios con discapacidad visual), funcionalidades de sincronización (debe sincronizar progreso de lectura entre dispositivos sin pérdida de datos), funcionalidades de suscripción (debe procesar pagos correctamente, debe respetar plazos de suscripción, debe permitir cancelación fácil).

Cada requerimiento debe ser específico y medible. «El sistema debe ser rápido» no es un requerimiento de calidad; «el sistema debe cargar la página de inicio en menos de 2 segundos con conexión típica de banda ancha 4G» es un requerimiento verificable. «La búsqueda debe funcionar bien» es inaceptable; «la búsqueda debe devolver resultados relevantes en los primeros 5 hits en 95% de las búsquedas típicas de usuario» es verificable.

Casos de prueba y escenarios de validación

Para cada requerimiento funcional, la documentación de calidad debe establecer casos de prueba que verifiquen su cumplimiento. Un caso de prueba incluye: descripción clara de lo que se prueba, pasos a ejecutar en orden específico, datos de entrada (usuario de prueba, contenido específico, etc.), resultado esperado, y criterio de aceptación (se considera pasado si X, fallido si Y).

Para el requerimiento de búsqueda mencionado antes, un caso de prueba sería: «TC-001: Búsqueda simple por título. Pasos: 1) Acceder a página de inicio. 2) Localizar campo de búsqueda. 3) Ingresar término 'marketing digital'. 4) Presionar botón búsqueda. Resultado esperado: página de resultados muestra libros cuyo título contiene 'marketing' o 'digital', ordenados por relevancia, en máximo 2 segundos. Criterio de aceptación: se encuentran al menos 5 resultados relevantes en la primera página.»

Para productos multimedia con múltiples dispositivos y navegadores, la matriz de validación se expande significativamente. Debe documentarse qué combinaciones son soportadas: navegadores Chrome, Firefox, Safari en versiones X.X y superiores; sistemas operativos móviles iOS 14+ y Android 10+; conexiones de red WiFi, 3G, 4G. Un caso de prueba que pasa en Chrome en desktop pero falla en Safari en iPhone es un resultado de validación incompleto.

Criterios de aceptación y umbrales de calidad

La documentación debe establecer umbrales claros de qué se considera producto de calidad aceptable. Esto incluye cobertura de pruebas (mínimo 80% del código debe ser ejercitado por pruebas automatizadas), tasa de defectos críticos (máximo 0 defectos críticos o de alta severidad permitidos en release a producción), tasa de defectos moderados (máximo 2 defectos moderados sin resolver), bugs conocidos (todos los bugs conocidos deben estar documentados y priorizados).

Para productos editoriales, es especialmente importante establecer umbrales para calidad de contenido: integridad de metadatos (datos de autor, fecha, categoría deben estar presentes y correctos), verificación de formato (archivos EPUB deben ser válidos EPUB3, PDFs no deben requerir contraseña para lectura normal), disponibilidad de cobertura (imágenes deben cargar correctamente, con respaldo de imagen placeholder si hay error).

Estos umbrales deben ser públicos y documentados para que todos en la organización entiendan qué significa «suficientemente bueno» para un release. Sin esto, decisiones sobre qué bugs bloquean un release versus cuáles pueden esperar se toman ad hoc, resultando en inconsistencia y discusión política en lugar de evaluación objetiva.

Procedimientos de validación de cambios

Cuando el producto se modifica (nueva funcionalidad, corrección de bugs, actualización de contenido), la documentación de calidad debe especificar qué validaciones son obligatorias antes de que el cambio se libere a producción. Esto típicamente incluye: pruebas unitarias (pruebas automatizadas de componentes individuales), pruebas de integración (verificar que múltiples componentes funcionan juntos), pruebas de regresión (verificar que cambios no rompieron funcionalidad anterior), pruebas de aceptación de usuario (verificar que cambios satisfacen los requerimientos originales).

Para cambios de bajo riesgo (corrección de typo en interfaz), el procedimiento puede ser simplificado. Para cambios de alto riesgo (modificación del algoritmo de búsqueda, cambios en base de datos), el procedimiento debe ser exhaustivo. La documentación debe establecer claramente qué califica como bajo, medio, o alto riesgo para evitar que decisiones de riesgo se tomen inconsistentemente.

Registro y trazabilidad de defectos

La documentación de calidad debe especificar cómo se registran, clasifican y rastrean defectos encontrados. Esto incluye: qué información capturar (descripción del problema, pasos para reproducir, resultado esperado vs. observado, ambiente donde ocurre, severidad, impacto en usuario), cómo clasificar severidad (crítica: usuario no puede completar tarea esencial; alta: funcionalidad disponible pero degradada; media: afecta usabilidad pero hay workaround; baja: cosmetica o impacto mínimo), y qué información capturar para análisis posterior (cuándo se descubrió, quién lo descubrió, quién lo reparó, cuánto tiempo tomó reparar).

Para productos con iteraciones rápidas, el registro de defectos se integra típicamente en sistemas de gestión de proyectos (Jira, Azure DevOps, etc.). La documentación de calidad debe referenciar estos sistemas y establecer qué campos son obligatorios, cómo se priorizan defectos, y quién tiene autoridad para cerrar un defecto como «resuelto».

Ejemplo práctico: Plan de testing para lanzamiento de versión mayor

Supongamos que la plataforma editorial multimedia va a lanzar una versión que añade soporte para audiolibros interactivos con notas marginales sincronizadas. El plan de testing documentaría: 1) Fase de testing unitario: cada componente nuevo (reproductor de audio, motor de notas, sincronización) se prueba aisladamente. 2) Fase de testing de integración: verifica que notas se sincronizan correctamente entre dispositivos, que pausar el audio pausa las notas, que retroceder el audio retrocede a la nota anterior. 3) Fase de testing de regresión: verifica que lectura de libros de texto no se afectó, que búsqueda aún funciona, que suscripciones aún se procesan. 4) Fase de testing de aceptación: usuarios beta utilizan el producto por 1 semana y reportan problemas. 5) Testing de desempeño: verifica que sincronización de notas no consume ancho de banda excesivo. Solo después de todas estas fases documentadas y pasadas, el producto se libera a producción.

Ideas clave

• La documentación de control de calidad especifica qué debe hacer el producto, cómo se verifica que funciona correctamente, y qué se considera calidad aceptable
• Los requerimientos deben ser específicos y medibles: «debe ser rápido» no es especificación; «debe cargar en menos de 2 segundos» lo es
• Los casos de prueba deben incluir pasos específicos, datos de entrada, resultado esperado, y criterio de aceptación verificable
• Umbrales de calidad deben ser establecidos públicamente (cobertura de pruebas mínima, máximo de bugs críticos, etc.) para evitar decisiones ad hoc
• La trazabilidad de defectos documentada permite análisis posterior sobre patrones, velocidad de resolución, y mejora continua
• Productos multimedia requieren matrices de validación que cubran navegadores, sistemas operativos, y tipos de conexión de red