Un criterio de calidad es una comprobación que el trabajo debe superar para poder avanzar. Los criterios de calidad permiten que lo de "suficientemente bueno para lanzar" deje de ser una decisión subjetiva y se convierta en algo que el sistema aplica de forma uniforme en todo momento.
Bloqueantes y orientativos
Cada criterio de calidad es de uno u otro tipo, y esa distinción constituye el núcleo del diseño:
- Bloqueante — si falla, la tarea se detiene. El trabajo no avanza hasta que se supere o un ser humano lo autorice.
- Orientativo — si falla, se registra como hallazgo y se adjunta a la solicitud de incorporación de cambios, pero la tarea continúa.
Empieza con criterios orientativos. Observa qué señala realmente un criterio de calidad en el trabajo real durante una o dos semanas y, después, promueve a bloqueante los que lo merezcan. Un criterio que bloquee desde el primer día, sin haber sido ajustado previamente, solo enseñará a los equipos a sortearlo.
Puerta bloqueante
- Cobertura inferior al 80%Falla
La tarea se detiene
Vuelve como trabajo pendiente en lugar de abrir una pull request que solo rechazarías.
- Alguien con autoridad puede anularla. La anulación registra quién, cuándo y sobre qué.
Puerta consultiva
- Cobertura inferior al 80%Falla
Se registra un hallazgo
La tarea continúa hasta la revisión.
- El hallazgo se adjunta a la pull request para que tú lo evalúes.
Qué puede verificar un criterio de calidad
Los criterios de calidad se aplican en la fase de verificación y pueden abarcar:
- el correcto funcionamiento de tu propia suite de pruebas
- los umbrales de cobertura
- la corrección de estilo y el análisis estático
- el escaneo de seguridad, configurado en Seguridad
- pruebas en navegador sobre una vista previa en ejecución
- las pruebas procedentes de proveedores externos adjuntas al pull request
El criterio de calidad más valioso suele ser siempre tu suite de pruebas existente, ya que ya refleja lo que tu equipo considera importante.
Dónde puede detener un criterio de calidad el trabajo
Los criterios de calidad se ejecutan durante la verificación, después de que el agente desarrollador haya finalizado y antes de la Revisión. Un fallo bloqueante devuelve la tarea como trabajo pendiente en lugar de generar un pull request que acabarías rechazando.
Ese orden es deliberado: es más barato fallar durante la ejecución que fallar ante tus ojos.
Políticas
Los criterios de calidad se agrupan en políticas, que son las que realmente se asocian a los proyectos. Una política es un conjunto nombrado de criterios de calidad con sus configuraciones bloqueantes u orientativas, de modo que puedas tener una estándar para servicios de producción y otra más flexible para herramientas internas.
Las políticas tienen versión controlada. Publicas un cambio y puedes volver a una versión anterior si un nuevo criterio de calidad resulta ser demasiado estricto.
Sobrescrituras
Un criterio bloqueante puede ser sobreescrito por una persona con la autoridad necesaria. La sobrescritura se registra: quién, cuándo y en qué caso.
Ese registro es el objetivo. Un criterio que nadie pueda sobreescribir llevará a que la gente lo sortee; un criterio que cualquiera pueda sobreescribir sin dejar rastro no es un criterio de calidad. Una sobrescritura que deje constancia es a la vez útil y transparente.
Qué no hacen los criterios de calidad
Los criterios de calidad verifican propiedades. No determinan si el trabajo resuelve el problema adecuado; eso corresponde a los criterios de aceptación en la especificación y a la propia Revisión.
Un cambio puede superar todos los criterios de calidad y, aun así, ser el cambio equivocado.