• Español

      • Definition of Done

      El Definition of Done (DoD) reúne los requisitos que una historia o task cumple antes de considerarse terminada. No es un paso a paso: los requisitos se cumplen en su totalidad sin importar el orden, aunque algunos dependen de otros — las pruebas de QA, por ejemplo, necesitan una versión ya desplegada. El flujo es iterativo: se vuelve a etapas anteriores para corregir errores o atender las sugerencias del code review.

      Code

      Escribir el código es la primera etapa de la entrega de valor y cumple los estándares de codificación establecidos por el equipo:

      • Code guidelines: el código sigue los lineamientos de codificación del proyecto — formato, estructura, nomenclatura de variables, documentación y buenas prácticas — para que sea consistente, legible y fácil de mantener.
      • Peer review: otra persona del equipo revisa el código para identificar problemas, errores, mejoras o violaciones de las pautas de codificación.

      Testing

      Cubre las pruebas que realiza quien desarrolla, no las del equipo de QA: el código cumple el mínimo de cobertura en pruebas unitarias. No todos los equipos definen un code coverage mínimo y no todos los componentes tienen pruebas unitarias: hay productos legado donde agregarlas requeriría un esfuerzo demasiado alto.

      QA

      Las pruebas funcionales aseguran que cada entrega cumpla un conjunto mínimo de artefactos de prueba, para lograr entregas seguras con un nivel mínimo de incidencias reportadas por los clientes. El ciclo de pruebas incluye:

      • Pruebas exploratorias: permiten conocer más el producto que se entrega y familiarizarse con su contexto. No siempre son necesarias, pero en la mayoría de los casos aportan valor al proceso.
      • Casos de prueba: esquemas de prueba de extremo a extremo escritos en Gherkin o en lenguaje natural. Viven en QAlity, la herramienta integrada con Jira. No siempre se crean casos nuevos: se pueden reutilizar del repositorio de pruebas.
      • Reporte de fallos: cada error detectado se informa en Jira — como issue de tipo Sprint Bug, como subtarea de la task principal con la lista de errores o como comentario en la task principal.
      • Re-test: verifica que un defecto reportado se corrigió de manera efectiva, re-ejecutando los casos de prueba que lo revelaron.
      • Pruebas de regresión: tras revisar la solución del último error reportado, un escaneo exhaustivo del componente verifica que la corrección no introdujo bugs nuevos.
      • Pruebas de integración: validan la funcionalidad como un único elemento — no backend y frontend por separado, sino el flujo completo frente al usuario.
      • Pruebas de seguridad: validan los requisitos mínimos de seguridad definidos y aprobados en el Definition of Ready (DoR), para proteger la integridad, disponibilidad y confidencialidad de la información de los clientes.

      Validaciones de plataforma

      • Internacionalización: se valida el producto en sus tres idiomas: inglés, español y portugués.
      • Responsive: se validan las tres dimensiones definidas en nuestros productos — tablet (735), navegador web (1240) y móvil (320). Aplica por ahora al perfil colaborador, y más adelante al de líder.
      • Usuarios staff en flujos de Admin: todo flujo construido para el usuario Admin se comprueba también con el usuario staff de Crehana sobre cualquier otra organización, porque los equipos staff client-facing (como Customer Success) ejecutan acciones sobre las cuentas de los clientes.
      • Dominios personalizados: cada implementación se revisa tanto en el dominio crehana.com como en el dominio personalizado del cliente, replicando en el segundo todas las pruebas del principal. La lista está en Clientes con dominio personalizado (Confluence). Organización de referencia para pruebas: app.crehana.com.
      • Corporaciones: una organización de tipo corporación controla una o más organizaciones de tipo child. Se valida que un Admin corporativo pueda realizar las mismas acciones sobre cualquiera de sus organizaciones children. El flujo está descrito en la guía de corporaciones en Notion.
      • Organizaciones Full Suite: organizaciones que conectan los dos productos, Learning y Talent (como Crehana). En iniciativas que impactan el sidebar o el footer del Admin o del Colaborador — por ejemplo una sección nueva como Catálogo o Documentos — se valida que el cambio también se refleje en estas organizaciones.
      • Mailings: cada correo manual o automático que envía la plataforma se valida con criterios de frontend, backend, producto y QA, considerando el primer nivel de personalización que ya existe en las organizaciones Learning: correo remitente, logo y color del CTA. Los criterios completos están en los lineamientos de casos de prueba sobre mailings (Confluence).

      UAT

      El User Acceptance Testing (UAT) formaliza la entrega de la funcionalidad propuesta. Cumple cada criterio de aceptación detallado en el Definition of Ready y participan el Product Owner, el Product Manager o integrantes de ventas u operaciones. Es obligatorio solo para funcionalidades nuevas o modernizaciones de componentes que requieren la aprobación del cliente final; ejecutarlo queda a criterio del QA Engineer.

      Deploy

      El deploy cierra el DoD: sin código desplegado y visible para el equipo, la validación funcional no es posible. Su significado varía según el equipo:

      • Done: la versión está desplegada y disponible en el entorno de QA.
      • Beta: en el equipo de Apps, la versión se subió a la store de cada proveedor (iOS, Android) para la validación de estos últimos.