Soporte para Metodologías Personalizadas

Configuración de Metodología de Pruebas Manuales Personalizadas en axe Auditor

Propósito

Los clientes que usan axe Auditor a veces necesitan ajustar la metodología de pruebas manuales (el DequeWay). Esta necesidad puede surgir de:

• Políticas internas específicas que requieren más o menos verificaciones.
• Guías internas sobre el uso de herramientas específicas al realizar pruebas.
• Decisiones de políticas que cambian varios atributos de los problemas (impacto, descripciones, recomendaciones).

Este documento describe las personalizaciones que se pueden hacer a la metodología de pruebas manuales en axe Auditor y explica cómo esos cambios vuelven a Deque para ser empaquetados y desplegados en su instancia alojada.

Cómo funciona: roles y flujo de trabajo

La instancia de axe Auditor de su organización está alojada y gestionada por Deque. Eso significa que Deque gestiona la instalación, la secuenciación de versiones, el empaquetado y el despliegue de la metodología. Su equipo solo es responsable de editar los archivos de configuración de la metodología. No necesita actualizar números de versión, crear paquetes ni ejecutar ningún comando de instalación o base de datos. Deque se encarga de todo eso en su nombre.

El proceso completo es:

Nota sobre el alcance: Este documento enumera todos los tipos de personalización disponibles para mayor claridad. Los cambios específicos que su equipo realizará deben alinearse con el alcance de cambio acordado.

Antes de comenzar

1. Haz una copia de seguridad del original. Antes de editar cualquier cosa, haz una copia de la carpeta package descomprimida. Si una edición rompe el paquete, esta es su única forma limpia de revertir.

cp -r package package_backup_original

2. Edita solo los archivos enumerados en cada sección. Los archivos son interdependientes. Editar un archivo no listado para un cambio dado, o no editar uno que es listado, puede producir un paquete que solo falla después de que haga un recorrido de ida y vuelta a Deque.

3. Valida cada archivo que toques. Cada archivo es JSON y debe seguir siendo JSON válido después de la edición (sin comas finales, llaves y corchetes balanceados). Valida antes de enviar:

# Validate a single file
python3 -m json.tool package/dist/bundle/descriptions.json > /dev/null && echo "VALID" || echo "INVALID"

# Or validate every JSON file in the bundle at once
find package/dist -name "*.json" -print0 | while IFS= read -r -d '' f; do
  python3 -m json.tool "$f" > /dev/null 2>&1 && echo "VALID:   $f" || echo "INVALID: $f"
done

4. Suposición de idioma. Estas instrucciones asumen inglés (en). Si tu organización requiere metodología en idiomas adicionales, informa a Deque; Deque habilita el soporte de idiomas durante la configuración. En ese caso, cada edición que hagas en un archivo .en.json también debe realizarse en el archivo de localización correspondiente (por ejemplo, el equivalente de .nl.json) para cada idioma adicional.

Actualizaciones permitidas

Actualiza la metodología de prueba para un punto de control específico

Útil cuando deseas cambiar las instrucciones de prueba para un punto de control específico en axe Auditor.

Archivos actualizados: package/dist/bundle/locales/checkpoints.en.json

Pasos:

1. Localiza el punto de control específico de Deque en el archivo JSON (por ejemplo, 1.1.1.a).
2. Busca el atributo testing-methodology bajo ese punto de control específico.
3. Haz actualizaciones adecuadas a cualquier tipo de recurso enumerado bajo testing-methodology.
4. Guarda el archivo en su ubicación actual.

Nota: El nombre del punto de control visible en axe Auditor también puede cambiarse usando las mismas instrucciones. En lugar de actualizar la sección testing-methodology, actualiza el atributo name bajo el punto de control relevante en el mismo archivo.

Actualiza el impacto de una norma

Puedes cambiar el nivel de impacto (bloqueante, crítico, serio, moderado, menor) para cada problema dentro de axe Auditor. Sin embargo, si necesitas cambiar el impacto predeterminado de una norma, sigue estas instrucciones.

Los impactos en axe Auditor se almacenan a nivel norma, no a nivel de Criterios de Éxito de WCAG o punto de control. Una sola norma puede afectar a múltiples puntos de control de Deque (por ejemplo, id de la norma alt-text-dynamic-image-inconsistent). Modificar el impacto de la norma cambia el impacto predeterminado para un problema desencadenado por la violación de esta norma a lo largo de todo Criterios de Éxito de WCAG conectados a la norma.

Archivos actualizados: package/dist/bundle/descriptions.json

Pasos:

1. Localiza la norma específica de Deque en el archivo JSON (por ejemplo, alt-text-dynamic-image-inconsistent).
2. Busca el atributo impact bajo esa norma específica.
3. Actualiza el impacto con un valor numérico (ver la tabla abajo).
4. Guarda el archivo en su ubicación actual.

Mapeos de valores de impacto

Añadir un nuevo estándar de accesibilidad (por ejemplo, un estándar específico de la organización)

Si tienes estándares de prueba específicos de la organización que te gustaría proporcionar a tus equipos además de los estándares existentes (como WCAG 2.1 AA o ACAA), usa los siguientes pasos.

⚠️ Interno de Deque — resolver antes de publicar: La lista de archivos para esta sección hace referencia a tres rutas relacionadas con el punto de control que son inconsistentes con el resto del documento (que usa dist/bundle/…): package/dist/checkpoints.json, package/dist/issue-descriptions.json, y package/dist/bundle/checkpoints.json. Confirma si dist/checkpoints.json y dist/issue-descriptions.json son realmente archivos compilados distintos, o si son errores de ruta, luego actualiza la lista en consecuencia y elimina esta nota.

Archivos actualizados:

• package/dist/bundle/standards.json
• package/dist/bundle/descriptions.json
• package/dist/bundle/testingMethodologies.json
• package/dist/bundle/locales/standards.en.json
• package/dist/checkpoints.json
• package/dist/issue-descriptions.json
• package/dist/bundle/checkpoints.json

Pasos:

1. Cree un nuevo objeto de arreglo para el estándar en standards.json. El enfoque más sencillo es copiar todo el objeto para wcag21aa y añadirlo al final del archivo.
2. Cambie el id del objeto recién copiado a algo único que signifique el estándar que representa.
3. Actualice el arreglo rubric para el nuevo objeto para representar todos los estándares de prueba subyacentes que forman parte de este nuevo estándar.
4. En descriptions.json, para todas las reglas asociadas con su nuevo estándar, agregue el id del nuevo estándar (de standards.json) al arreglo standards.
5. En testingMethodologies.json, agregue el id del nuevo estándar bajo el arreglo standards para cada tipo de activo digital al que se aplica este estándar.
6. En standards.en.json, añada un nuevo objeto con el id y nombre del nuevo estándar. El campo name es lo que los usuarios ven en la interfaz de usuario de axe Auditor.
7. En dist/checkpoints.json, actualice el arreglo standards bajo cada descripción de problema para los puntos de control aplicables.
8. En issue-descriptions.json, actualice el arreglo standards para todos los objetos de regla aplicables.
9. En dist/bundle/checkpoints.json, actualice el arreglo standards de cada punto de control aplicable con el estándar correcto.

Actualizar las descripciones de problemas cortas y largas para reglas específicas

Use estas instrucciones para actualizar el texto de selección de descripción de problemas (corta) y la descripción larga del tipo de problema para cada regla. Una sola regla puede afectar múltiples Criterios de Éxito WCAG — cambiar este texto afecta a todos Criterios de Éxito a los que está conectado.

Archivos actualizados: package/dist/bundle/locales/descriptions.en.json

Pasos:

1. En descriptions.en.json, busque la regla específica (por ejemplo, alt-text-dynamic-image-inconsistent).
2. Actualice el texto para shortText (Descripción Corta del Problema) y issueDescText (Descripción Larga del Problema) según corresponda.
3. Guarde el archivo en su ubicación actual.

Actualizar la recomendación de remediación

Si desea cambiar la biblioteca de remediación y las descripciones asociadas para alinearse con su política, use las siguientes instrucciones.

Archivos actualizados: package/dist/bundle/locales/recommendations.en.json

Pasos:

1. En recommendations.en.json, busque la regla específica (por ejemplo, alt-text-dynamic-image-inconsistent) y la combinación de puntos de control para la que desea cambiar la biblioteca de remediación.
2. Actualice el texto para recommendationType (Técnica de Recomendación), rule, howtofix, y background (secciones de la recomendación para corregir) según corresponda.
3. Guarde el archivo en su ubicación actual.

Eliminar tipos de activos digitales

Utilice esto cuando un tipo de activo dado no se aplique a su organización (por ejemplo, si las pruebas de PDF o Android están fuera de alcance).

Archivos a actualizar:

• dist/bundle/testingMethodologies.json — datos de metodologías de prueba principales
• dist/bundle/locales/testingMethodologies.en.json — traducciones al inglés

Paso 1: Eliminar del archivo de metodologías de prueba

Archivo: dist/bundle/testingMethodologies.json

Encuentre y elimine todo el objeto para la metodología que desea eliminar.

// BEFORE — remove this entire object (example: "native-mobile-android"):
{
  "id": "native-mobile-android",
  "techniques": ["general"],
  "standards": [
    "wcag2a", "wcag21a", "wcag22a",
    "wcag2aa", "wcag21aa", "wcag22aa",
    "acaa", "en301549-wad",
    "508-2017-wcag2", "508-2017-wcag21"
  ]
}
// AFTER — object completely removed

Paso 2: Eliminar del archivo de localización en inglés

Archivo: dist/bundle/locales/testingMethodologies.en.json

Elimine el mismo objeto de metodología de este archivo.

Agregar un nuevo tipo de activo digital

Utilice esto para agregar un nuevo tipo de activo digital — por ejemplo, una web-app o metodología macos. El ejemplo a continuación utiliza web-app; sustituya su propio id de tipo de activo según sea necesario.

Archivos a actualizar:

• dist/bundle/testingMethodologies.json — datos de metodologías de prueba principales
• dist/bundle/locales/testingMethodologies.en.json — traducciones al inglés
• dist/bundle/locales/checkpoints.en.json — contenido de puntos de control en inglés con secciones de metodologías de prueba
• dist/bundle/checkpoints.json — datos de puntos de control principales
• dist/bundle/descriptions.json — descripciones de problemas con referencias de metodologías de prueba
• dist/bundle/schemata.json — definiciones de esquemas con referencias de metodologías de prueba

Paso 1: Añadir al archivo de metodologías de prueba

Archivo: dist/bundle/testingMethodologies.json

Agregue el nuevo objeto de metodología al arreglo.

{
  "id": "web-app",
  "techniques": ["general", "html", "aria", "css"],
  "standards": [
    "wcag2a", "wcag21a", "wcag22a",
    "wcag2aa", "wcag21aa", "wcag22aa",
    "acaa", "en301549-wad",
    "508-2017-wcag2", "508-2017-wcag21"
  ]
}

Paso 2: Añadir al archivo de localización en inglés

Archivo: dist/bundle/locales/testingMethodologies.en.json

Agregue el mismo objeto de metodología a este archivo.

Paso 3: Añada referencias al archivo de puntos de control

Archivo: dist/bundle/checkpoints.json

Para cada punto de control que deba apoyar la nueva metodología, añádalo al arreglo testingMethodologies de ese punto de control.

{
  "id": "1.4.3.a",
  "testingMethodologies": [
    "desktop", "mobile", "kiosk",
    "native-mobile-ios", "native-mobile-android",
    "pdf",
    "web-app",          // ← Add this line
    "ms-excel", "ms-powerpoint", "ms-word", "windows-desktop"
  ]
}

Paso 4: Añada contenido de metodología de prueba al archivo de localización del punto de control

Archivo: dist/bundle/locales/checkpoints.en.json

Para cada punto de control que deba apoyar la nueva metodología, añada el contenido de la metodología de prueba.

{
  "1.4.3.a": {
    "name": "Color Contrast (Minimum)",
    "testing-methodology": {
      "desktop": "<ol>...</ol>",
      "mobile": "<ol>...</ol>",
      "native-mobile-android": "<ol>...</ol>",
      "web-app": "<ol>\n<li>Open the web application in a modern browser</li>\n<li>Use browser developer tools to inspect text elements</li>\n<li>Check color contrast ratios using accessibility tools</li>\n<li>Verify contrast meets WCAG requirements</li>\n</ol>",  // ← Add this new entry
      "pdf": "<ol>...</ol>"
    }
  }
}

Paso 5: Añada referencias al archivo de descripciones

Archivo: dist/bundle/descriptions.json

Para descripciones de problemas que deban apoyar la nueva metodología, agréguelas al arreglo testingMethodologies.

{
  "id": "some-issue-id",
  "data": [
    {
      "type": "issue",
      "testingMethodologies": [
        "desktop", "mobile",
        "native-mobile-android", "pdf",
        "web-app"        // ← Add this line
      ]
    }
  ]
}

Paso 6: Añada referencias al archivo de esquema

Archivo: dist/bundle/schemata.json

Añada la nueva metodología de prueba a las definiciones de esquema.

{
  "testingMethodologies": {
    "desktop": null,
    "kiosk": null,
    "mobile": null,
    "native-mobile-ios": null,
    "native-mobile-android": null,
    "pdf": null,
    "web-app": null,   // ← Add this line
    "ms-excel": null,
    "ms-powerpoint": null,
    "ms-word": null,
    "windows-desktop": null
  }
}

Añadir un nuevo punto de control

Agregando un punto de control no WCAG

Importante: Los puntos de control no WCAG no soportan descripciones o recomendaciones predefinidas a través de descriptions.json y recommendations.json. Al registrar problemas con estos puntos de control, usted introduce descripciones y recomendaciones manualmente usando la función Cree su propia descripción en la herramienta.

Archivos a actualizar — solo 2:

• package/dist/bundle/checkpoints.json — definir el punto de control
• package/dist/bundle/locales/checkpoints.en.json — proveer metodología de prueba localizada

Paso 1: Añada el punto de control a checkpoints.json

{
  "id": "custom.1.1",
  "requiredSenses": {
    "sight": true,
    "hearing": false
  },
  "successCriteria": "",
  "automatedRules": [],
  "testingMethodologies": ["desktop", "mobile"],
  "grouping": "custom.1",
  "categories": [],
  "standards": ["custom"]
}

Campos clave:

• id — identificador único usando su formato personalizado (por ejemplo, custom.1.1, brand.2.3, TT.01.A, s.1.1).
• successCriteria — cadena vacía "" para puntos de control no WCAG (o un formato personalizado como "tt-01.A").
• standards — su identificador estándar personalizado, por ejemplo, ["custom"], ["TT508"], ["smoke"], ["brand"] (no ["wcag2a"]).
• testingMethodologies — plataformas donde aplica este punto de control: desktop, mobile, kiosk, native-mobile-ios, native-mobile-android, pdf, windows-desktop, ms-excel, ms-powerpoint, ms-word.
• requiredSenses — qué sentidos se necesitan para probar este punto de control (sight, hearing: true/false).
• automatedRules — arreglo opcional de identificadores de reglas automatizadas (típicamente vacío [] para puntos de control personalizados).
• grouping — agrupación lógica para la organización (por ejemplo, "custom.1", "1", "s.1").
• categories — categorías de accesibilidad relevantes (puede estar vacío [] para no WCAG).
• terms — arreglo opcional de referencias de términos del glosario con propiedades id y ordinal.

Paso 2: Añada contenido localizado a checkpoints.en.json

Use el formato de id con guiones: convierta los puntos en guiones (por ejemplo, custom-1-1, no custom.1.1).

"custom-1-1": {
  "examples": "<ul>\n  <li>Example 1: Describe a scenario where this applies</li>\n  <li>Example 2: Describe another scenario</li>\n</ul>",
  "related-techniques": {
    "general": "<ul>\n  <li>Technique reference 1</li>\n  <li>Technique reference 2</li>\n</ul>",
    "html": "<ul>\n  <li>HTML-specific technique</li>\n</ul>"
  },
  "testing-methodology": {
    "desktop": "<ol>\n  <li>Step 1 for desktop testing</li>\n  <li>Step 2 for desktop testing</li>\n</ol>",
    "mobile": "<ol>\n  <li>Step 1 for mobile testing</li>\n  <li>Step 2 for mobile testing</li>\n</ol>"
  },
  "name": "Your Custom Checkpoint Name",
  "overview": {
    "general": "General description of what this checkpoint tests and why it matters for accessibility.",
    "html": "HTML-specific description if applicable; otherwise can match general."
  }
}

Use \n para nuevas líneas y etiquetas HTML adecuadas para listas.

Agregando un punto de control WCAG

Archivos a actualizar — 6 archivos para una implementación completa del punto de control WCAG:

1. package/dist/bundle/checkpoints.json — definir el punto de control con campos específicos de WCAG.
2. package/dist/bundle/locales/checkpoints.en.json — metodología de prueba localizada, ejemplos, técnicas relacionadas (utilice el formato de id con guiones: 1-4-3-a, no 1.4.3.a).
3. package/dist/bundle/descriptions.json — descripciones de problemas con niveles de impacto y referencias a puntos de control.
4. package/dist/bundle/locales/descriptions.en.json — descripciones localizadas de problemas.
5. package/dist/bundle/recommendations.json — recomendaciones de remediación vinculadas a descripciones de problemas.
6. package/dist/bundle/locales/recommendations.en.json — contenido de recomendación localizado (título, descripción, pasos, recursos).

Opcional — entrada manual: Si prefieres omitir la adición de descripciones y recomendaciones predefinidas a los archivos JSON, puedes gestionarlas al registrar problemas en la herramienta: selecciona tu punto de verificación WCAG, elige Cree su propia descripción en lugar de uno predefinido, luego ingresa manualmente la descripción y (si es necesario) la recomendación adaptada al problema encontrado.

Paso 1: Define el punto de verificación

Archivo: package/dist/bundle/checkpoints.json

{
  "id": "1.4.3.a",
  "requiredSenses": {
    "sight": true,
    "hearing": false
  },
  "successCriteria": "1.4.3",
  "automatedRules": ["color-contrast"],
  "testingMethodologies": [
    "desktop", "mobile", "kiosk",
    "native-mobile-ios", "native-mobile-android",
    "pdf", "ms-excel", "ms-powerpoint", "ms-word", "windows-desktop"
  ],
  "grouping": "1.4",
  "categories": ["cat.distinguishable"],
  "standards": ["wcag2aa"]
}

Campos clave:

• id — Patrón de numeración WCAG (por ejemplo, "1.4.3.a", "2.1.1.b").
• successCriteria — Número de criterio de éxito de WCAG (por ejemplo, "1.4.3").
• standards — "wcag2a" (Nivel A), "wcag2aa" (Nivel AA) o "wcag2aaa" (Nivel AAA).
• automatedRules — arreglo de identificadores de reglas automatizadas.
• grouping — Número de directriz WCAG (por ejemplo, "1.4", "2.1").

Paso 2: Agrega la metodología de prueba

Archivo: package/dist/bundle/locales/checkpoints.en.json — usa el formato con guiones (1-4-3-a).

"1-4-3-a": {
  "name": "Color Contrast (Minimum)",
  "overview": {
    "general": "Text and images of text have a contrast ratio of at least 4.5:1, except for large text which has a contrast ratio of at least 3:1.",
    "html": "Text and images of text have a contrast ratio of at least 4.5:1, except for large text which has a contrast ratio of at least 3:1."
  },
  "examples": "<ul>\n  <li>Gray text on white background with insufficient contrast</li>\n  <li>Blue text on blue background that doesn't meet requirements</li>\n</ul>",
  "testing-methodology": {
    "desktop": "<ol>\n  <li>Identify all text content on the page</li>\n  <li>Use a color contrast analyzer tool</li>\n  <li>Ensure normal text has at least 4.5:1 contrast ratio</li>\n  <li>Ensure large text has at least 3:1 contrast ratio</li>\n</ol>",
    "mobile": "<ol>\n  <li>Test on a mobile device under various lighting conditions</li>\n  <li>Use mobile accessibility testing tools</li>\n  <li>Verify contrast ratios meet WCAG requirements</li>\n</ol>",
    "assistive-technology": "<p><strong>Screen reader testing is optional for this checkpoint.</strong></p>\n<p><strong>Using NVDA:</strong></p>\n<ol>\n  <li>Navigate through text content</li>\n  <li>Verify text readability</li>\n</ol>"
  },
  "related-techniques": {
    "general": "<ul>\n  <li><a href=\"https://www.w3.org/WAI/WCAG22/Techniques/general/G18\">G18: Ensuring contrast ratio of at least 4.5:1</a></li>\n</ul>",
    "html": "<ul>\n  <li><a href=\"https://www.w3.org/WAI/WCAG22/Techniques/css/C21\">C21: Specifying line spacing in CSS</a></li>\n</ul>"
  }
}

Paso 3: Agrega descripciones de problemas

Archivo: package/dist/bundle/descriptions.json

{
  "id": "insufficient-color-contrast",
  "data": [
    {
      "type": "issue",
      "impact": 4,
      "checkpoint": "1.4.3.a",
      "standards": ["wcag2aa"],
      "references": [
        {
          "standards": ["wcag2aa"],
          "checkpoint": "1.4.3.a"
        }
      ],
      "testingMethodologies": ["desktop", "mobile"]
    }
  ]
}

Paso 4: Agrega descripciones localizadas de problemas

Archivo: package/dist/bundle/locales/descriptions.en.json

Agrega un objeto para la nueva descripción:

"insufficient-color-contrast": {
  "shortText": "Insufficient color contrast",
  "issueDescText": "Text does not have sufficient contrast against its background to meet WCAG 2.1 AA requirements."
}

Paso 5: Agrega recomendaciones

Archivo: package/dist/bundle/recommendations.json

Utiliza el formato con guiones (1-4-3-a) y adjúntalo al identificador de recomendación.

{
  "id": "insufficient-color-contrast-fix-1-4-3-a",
  "data": [
    {
      "type": "recommendation",
      "description": "insufficient-color-contrast"
    }
  ]
}

Paso 6: Agrega contenido de recomendaciones

Archivo: package/dist/bundle/locales/recommendations.en.json

"insufficient-color-contrast-fix-1-4-3-a": {
  "title": "Improve Color Contrast",
  "description": "Increase the contrast ratio between text and background colors to meet WCAG 2.1 AA requirements.",
  "steps": [
    "Use a color contrast analyzer to identify insufficient contrast",
    "Adjust text color, background color, or both to achieve a minimum 4.5:1 ratio",
    "For large text (18pt+ or 14pt+ bold), ensure a minimum 3:1 ratio",
    "Test the changes across different devices and lighting conditions"
  ],
  "resources": [
    "WebAIM Color Contrast Checker",
    "W3C Color Contrast Analyzer",
    "Chrome DevTools Accessibility Panel"
  ]
}

Eliminar un punto de verificación específico

Utiliza estas instrucciones si hay un punto de verificación específico que no quieres que tu equipo pruebe y reporte.

Archivos actualizados:

• package/dist/bundle/checkpoints.json
• package/dist/bundle/descriptions.json
• package/dist/bundle/recommendations.json
• package/dist/bundle/locales/checkpoints.en.json
• package/dist/bundle/locales/recommendations.en.json

Pasos:

1. En checkpoints.json, busca el punto de verificación específico (por ejemplo, 1.2.1.b). Elimina todo el objeto asociado con este punto de verificación manteniendo el JSON válido. Guarda el archivo.
2. En descriptions.json, busca el punto de verificación específico (por ejemplo, 1.2.1.b). Elimina solo el objeto que usa el punto de verificación dentro de la regla manteniendo el JSON válido. Una sola regla puede aplicar a múltiples puntos de verificación — elimina solo el objeto del punto de verificación que estás eliminando; no elimines la regla completa. Guarda el archivo.
3. En recommendations.json, busca el punto de verificación específico (por ejemplo, 1.2.1.b). Elimina cada objeto asociado con este punto de verificación (puede haber más de uno) manteniendo el JSON válido. Guarda el archivo.
4. En checkpoints.en.json, busca el punto de verificación específico usando el formato con guiones (por ejemplo, 1-2-1-b). Elimina todo el objeto manteniendo el JSON válido. Guarda el archivo.
5. En recommendations.en.json, busca el punto de verificación específico usando el formato con guiones (por ejemplo, 1-2-1-b). Elimina cada objeto asociado con este punto de verificación (puede haber más de uno) manteniendo el JSON válido. Guarda el archivo.

Enviar cambios de nuevo a Deque

Cuando los cambios estén completos y validados:

1. Confirma que cada archivo editado todavía pase la validación JSON (vea Antes de comenzar).
2. Confirma que los cambios coincidan con el alcance acordado.
3. Envía toda la carpeta package de vuelta a Deque en su estructura original (no envíes solo archivos individuales).

Deque asignará la versión, empaquetará el paquete, lo mapeará a la versión correcta de axe-core y lo desplegará en una instancia de prueba para verificación. Después de que tu equipo verifique los cambios en la instancia de prueba y dé el visto bueno, Deque promueve la metodología a tu instancia de producción.

Soporte

Para preguntas sobre este proceso, el alcance de los cambios acordados, o para solicitar soporte adicional de idioma, contacta con tu punto de contacto en Deque.