Tickets DoD

Definition of Done para componentes

Esta checklist define las condiciones mínimas que debe cumplir un ticket de desarrollo de un componente antes de considerarse Ready for QA.

Un ticket puede pasar a Done una vez que todos estos puntos estén cumplidos y el componente haya sido validado por QA.

Cuando algún criterio no aplique al componente, deberá aclararse explícitamente en el ticket.

Maqueta

El componente debe respetar de manera fiel el diseño definido en Figma.

Deben coincidir, entre otros aspectos:

• estructura y distribución;
• tamaños y espaciados;
• tipografías;
• colores;
• bordes y sombras;
• imágenes e íconos;
• estados visuales.

Cualquier diferencia respecto del diseño debe haber sido previamente acordada con el diseñador o responsable del proyecto.

Responsive

El componente debe comportarse correctamente en todo el rango de resoluciones comprendido entre 1920px y 375px. No olvidar revisar en resoluciones 2k o 4k.

Cuando existan diseños específicos para distintas resoluciones, la implementación debe respetarlos de manera fiel.

En las resoluciones intermedias, aunque no exista un diseño específico, el componente debe mantener una estructura consistente, legible y funcional, sin cortes, solapamientos ni desbordes inesperados.

Animaciones y efectos de entrada

El componente debe incluir las animaciones y transiciones definidas por el diseñador.

Además, cuando corresponda, debe contar con un efecto de entrada integrado al sistema de animaciones smooth del sitio.

Las animaciones deben:

• ejecutarse de manera fluida;
• respetar la dirección y el timing definidos;
• no producir saltos de layout;
• funcionar correctamente al volver a visualizar el componente;
• contemplar la experiencia en dispositivos o navegadores con menor rendimiento.

Integración con CMS

Todo contenido dinámico del componente debe obtenerse desde CMS.

La estructura necesaria para administrar ese contenido también debe estar correctamente configurada en el CMS, incluyendo:

• campos;
• labels;
• tipos de contenido;
• valores por defecto;
• opciones y variaciones;
• campos obligatorios, cuando corresponda.
• En caso de trabajar con Prismic, el componente debe ser probado localmente utilizando la funcionalidad Simulate de Slice Machine.

No deben quedar textos, imágenes o configuraciones editables hardcodeadas dentro del componente.

Campos vacíos y sobrecarga de contenido

El componente debe contemplar correctamente tanto campos vacíos como contenidos que excedan las longitudes utilizadas en el diseño.

Esto incluye:

• títulos y descripciones más largas;
• botones sin texto o con textos extensos;
• imágenes ausentes;
• imágenes con distintas proporciones;
• listas con más o menos elementos;
• links o campos opcionales sin completar.

La ausencia o sobrecarga de contenido no debe romper el diseño, generar errores ni dejar espacios visuales innecesarios.

Cuando un campo sea obligatorio para el funcionamiento del componente, debe configurarse como obligatorio en el CMS (en caso que lo permita) o manejarse de manera segura desde el código mostrando parcialmente el componente u ocutandoló.

Variaciones

Cada slice debe incluir todas las variaciones definidas en el diseño y contempladas dentro del alcance del proyecto.

Las variaciones deben compartir la lógica y los estilos comunes siempre que sea posible, evitando duplicación innecesaria de código.

Cada variación debe poder seleccionarse, configurarse y visualizarse correctamente desde Prismic.

Funcionalidad

Todas las interacciones del componente deben funcionar según lo definido en el diseño, el ticket o la documentación del proyecto.

Esto incluye, cuando corresponda:

• botones;
• links;
• sliders;
• tabs;
• accordions;
• modales;
• formularios;
• reproducción de contenido;
• navegación interna o externa;
• estados hover, focus, active y disabled.

No deben existir errores visibles en la consola relacionados con el componente.

Links y CTAs

Todos los links y llamados a la acción deben estar correctamente integrados.

Se debe validar que:

• dirijan al destino esperado;
• los links externos se comporten según lo definido;
• los links internos utilicen la navegación correspondiente del proyecto;
• los campos vacíos no generen links inválidos;
• el área clickeable sea consistente con el diseño;
• los CTAs tengan los estados visuales correspondientes.

Accesibilidad básica

El componente debe cumplir con los criterios básicos de accesibilidad definidos para el proyecto.

Como mínimo, debe contemplar:

• estructura semántica correcta;
• textos alternativos en imágenes relevantes;
• navegación por teclado en elementos interactivos;
• estados de focus visibles;
• botones y links implementados con el elemento HTML correspondiente;
• labels o nombres accesibles cuando sean necesarios;
• jerarquía de headings consistente.

Cross-browser

El componente debe comportarse y visualizarse correctamente en los navegadores soportados por el proyecto.

Como mínimo, debe validarse en las últimas versiones estables de:

• Google Chrome;
• Safari;
• Microsoft Edge.

Cuando el componente utilice funcionalidades con compatibilidad limitada, deberá contar con una alternativa o degradación controlada.

Calidad de implementación

La implementación debe respetar los estándares técnicos y convenciones del proyecto.

Antes de pasar el ticket a QA se debe validar que:

• no existan errores de TypeScript;
• no existan errores de lint;
• el build del proyecto finalice correctamente;
• no haya código comentado o temporal innecesario;
• no existan logs de desarrollo en consola;
• no se duplique lógica que ya exista en el proyecto;
• los componentes reutilizables se aprovechen cuando corresponda;
• los nombres de variables, componentes y propiedades sean claros y consistentes.

Data attributes para QA

Cuando el componente tenga interacciones o elementos que necesiten automatización, deben agregarse los data-testid acordados con QA.

Estos identificadores deben ser:

• estables;
• descriptivos;
• independientes del contenido;
• independientes de clases o estilos visuales.

Analytics y eventos de conversión

Cuando el componente incluya una interacción relevante para los objetivos del sitio, deberá implementar los eventos de analytics definidos para el proyecto.

Esto aplica, entre otros casos, a:

• envío exitoso de formularios;
• inicio de formularios, cuando corresponda;
• descarga de archivos o recursos;
• clics en CTAs relevantes;
• reproducción o finalización de videos;
• suscripciones;
• registros;
• compras o solicitudes de contacto;
• interacciones que formen parte de un funnel de conversión.

Los eventos deben:

• respetar la nomenclatura y estructura definidas para el proyecto;
• enviarse únicamente cuando la acción haya ocurrido correctamente;
• incluir los parámetros necesarios para identificar la interacción, el componente y el contenido involucrado;
• evitar duplicaciones ante múltiples renders o clics;
• no enviar información personal o sensible;
• poder validarse desde las herramientas de debugging disponibles, como el modo Preview de Google Tag Manager o DebugView de Google Analytics.

Cuando el componente no requiera tracking, este punto se considerará no aplicable y deberá quedar aclarado en el ticket.

Validación antes de QA

Antes de mover el ticket a Ready for QA, el desarrollador debe realizar una validación completa del componente en el ambiente correspondiente.

La descripción del ticket debe incluir:

• URL o ambiente donde puede probarse;
• variaciones implementadas;
• consideraciones o decisiones tomadas;
• diferencias acordadas respecto de Figma;
• casos particulares que QA deba revisar;
• eventos de analytics implementados y forma de validarlos, cuando corresponda;
• cualquier punto de esta checklist que no aplique.

Ready for QA

Un ticket puede pasar a Ready for QA cuando:

• la implementación está completa;
• todos los criterios aplicables de esta checklist fueron validados;
• el componente está disponible en un ambiente accesible para QA;
• no quedan tareas de desarrollo pendientes dentro del alcance acordado;
• se agregó al ticket toda la información necesaria para realizar la validación.

Done

Un ticket puede pasar a Done cuando:

• fue aprobado por QA;
• no quedan bugs pendientes asociados al alcance original;
• las correcciones solicitadas fueron implementadas y verificadas;
• la versión aprobada está integrada en la rama o ambiente correspondiente.