Suporte à Metodologia Personalizada

Configuração de Metodologia de Teste Manual Personalizada no Axe Auditor

Objetivo

Os clientes que utilizam o axe Auditor às vezes precisam ajustar a metodologia de teste manual (o DequeWay). Essa necessidade pode surgir de:

• Políticas internas específicas que exigem verificações adicionais ou reduzidas.
• Diretrizes internas para usar ferramentas específicas ao realizar testes.
• Decisões de política que alteram vários atributos de problemas (impacto, descrições, recomendações).

Este documento descreve as personalizações que podem ser feitas na metodologia de teste manual no axe Auditor e explica como essas alterações são enviadas de volta para a Deque para embalagem e implementação na sua instância hospedada.

Como Funciona: Papéis e Fluxo de Trabalho

A instância do axe Auditor da sua organização é hospedada e gerenciada pela Deque. Isso significa que a Deque gerencia a instalação, sequenciamento de versões, empacotamento e implementação da metodologia. Sua equipe é responsável apenas por editar os arquivos de configuração da metodologia. Não é necessário atualizar números de versão, criar pacotes ou executar quaisquer comandos de instalação ou de banco de dados. A Deque cuida de tudo isso em seu nome.

O processo de ponta a ponta é:

Nota de escopo: Este documento lista todos os tipos de personalização disponíveis para completude. As alterações específicas que sua equipe fará devem estar alinhadas com o escopo de mudança acordado.

Antes de Começar

1. Faça backup do original. Antes de editar qualquer coisa, faça uma cópia da pasta package descompactada. Se uma edição quebrar o pacote, esta é sua única forma limpa de reverter.

cp -r package package_backup_original

2. Edite apenas os arquivos listados em cada seção. Os arquivos são interdependentes. Editar um arquivo não listado para uma alteração específica — ou não editar um que é listado — pode produzir um pacote que falha apenas quando retorna para a Deque.

3. Valide cada arquivo que você editar. Cada arquivo é JSON e deve permanecer um JSON válido após a edição (sem vírgulas finais, com chaves/colchetes balanceados). Valide 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. Suposição de idioma. Estas instruções assumem o inglês (en). Se a sua organização exigir metodologia em idiomas adicionais, informe a Deque — a Deque habilita suporte a idiomas durante a configuração. Nesse caso, cada edição que você fizer em um arquivo .en.json também deve ser feita no arquivo de local correspondente (por exemplo, o equivalente .nl.json) para cada idioma adicional.

Atualizações Permitidas

Atualizar a metodologia de teste para um ponto de verificação específico

Útil quando você deseja alterar as instruções de teste para um ponto de verificação específico no axe Auditor.

Arquivos atualizados: package/dist/bundle/locales/checkpoints.en.json

Passos:

1. Localize o ponto de verificação específico da Deque no arquivo JSON (por exemplo, 1.1.1.a).
2. Procure o atributo testing-methodology sob esse ponto de verificação específico.
3. Faça as atualizações apropriadas para qualquer tipo de ativo listado sob testing-methodology.
4. Salve o arquivo em seu local atual.

Nota: O nome do ponto de verificação visível no axe Auditor também pode ser alterado usando as mesmas instruções. Em vez de atualizar a seção testing-methodology, atualize o atributo name no ponto de verificação relevante no mesmo arquivo.

Atualizar o Impacto de uma Regra

Você pode alterar o nível de impacto (bloqueador, crítico, sério, moderado, menor) para cada problema dentro do axe Auditor. No entanto, se você precisar alterar o impacto padrão para uma regra, siga estas instruções.

Os impactos no axe Auditor são armazenados no nível regra, não no nível de Critérios de Sucesso WCAG ou ponto de verificação. Uma única regra pode afetar vários pontos de verificação da Deque (por exemplo, id da regra alt-text-dynamic-image-inconsistent). Modificar o impacto para a regra altera o impacto padrão para um problema desencadeado pela violação dessa regra em todas as tudo Critérios de Sucesso WCAG conectados a essa regra.

Arquivos atualizados: package/dist/bundle/descriptions.json

Passos:

1. Localize a regra específica da Deque no arquivo JSON (por exemplo, alt-text-dynamic-image-inconsistent).
2. Procure o atributo impact sob essa regra específica.
3. Atualize o impacto com um valor numérico (veja a tabela abaixo).
4. Salve o arquivo em seu local atual.

Mapeamento de valores de impacto

Adicionar um Novo Padrão de Acessibilidade (por exemplo, um Padrão Específico da Organização)

Se você tiver padrões de teste específicos da organização que gostaria de fornecer às suas equipes além dos padrões existentes (como WCAG 2.1 AA ou ACAA), use os passos a seguir.

⚠️ Interno Deque — resolver antes de publicar: A lista de arquivos para esta seção referencia três caminhos relacionados a pontos de verificação que são inconsistentes com o restante do documento (que usa dist/bundle/…): package/dist/checkpoints.json, package/dist/issue-descriptions.json, e package/dist/bundle/checkpoints.json. Confirme se dist/checkpoints.json e dist/issue-descriptions.json são realmente arquivos compilados distintos, ou se são erros de caminho, então atualize a lista de acordo e remova esta nota.

Arquivos atualizados:

• 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

Passos:

1. Crie um novo objeto de array para o padrão em standards.json. A abordagem mais fácil é copiar o objeto inteiro para wcag21aa e adicioná-lo ao final do arquivo.
2. Altere o id do objeto recém-copiado para algo único que represente o padrão que ele representa.
3. Atualize o array rubric para o novo objeto para representar todos os padrões de teste subjacentes que fazem parte deste novo padrão.
4. Em descriptions.json, para todas as regras associadas ao seu novo padrão, adicione o id do novo padrão (de standards.json) ao array standards.
5. Em testingMethodologies.json, adicione o id do novo padrão sob o array standards para cada tipo de ativo digital ao qual este padrão se aplica.
6. Em standards.en.json, adicione um novo objeto com o id e nome do novo padrão. O campo name é o que os usuários veem na interface do usuário do axe Auditor.
7. Em dist/checkpoints.json, atualize o array standards sob cada descrição de problema para os checkpoints aplicáveis.
8. Em issue-descriptions.json, atualize o array standards para todos os objetos de regra aplicáveis.
9. Em dist/bundle/checkpoints.json, atualize o array standards de cada checkpoint aplicável com o padrão correto.

Atualize as Descrições Curta e Longa de Problemas para Regras Específicas

Use estas instruções para atualizar o texto de seleção de descrição de problema (curta) e a descrição longa do tipo de problema para cada regra. Uma única regra pode afetar vários Critérios de Sucesso do WCAG — alterar este texto afeta todos Critérios de Sucesso aos quais está conectado.

Arquivos atualizados: package/dist/bundle/locales/descriptions.en.json

Etapas:

1. Em descriptions.en.json, procure pela regra específica (por exemplo, alt-text-dynamic-image-inconsistent).
2. Atualize o texto para shortText (Descrição Curta do Problema) e issueDescText (Descrição Longa do Problema) conforme apropriado.
3. Salve o arquivo em sua localização atual.

Atualize a Recomendação de Remediação

Se deseja alterar a biblioteca de remediação e as descrições associadas para alinhar com sua política, use as instruções a seguir.

Arquivos atualizados: package/dist/bundle/locales/recommendations.en.json

Etapas:

1. Em recommendations.en.json, procure pela combinação específica de regra (por exemplo, alt-text-dynamic-image-inconsistent) e checkpoint para o qual você deseja mudar a biblioteca de remediação.
2. Atualize o texto para recommendationType (Técnica de Recomendação), rule, howtofix, e background (seções da recomendação a serem corrigidas) conforme apropriado.
3. Salve o arquivo em sua localização atual.

Remova Tipos de Ativos Digitais

Use isso quando um determinado tipo de ativo não se aplica à sua organização (por exemplo, se testes em PDF ou Android estão fora do escopo).

Arquivos a serem atualizados:

• dist/bundle/testingMethodologies.json — dados principais de metodologias de teste
• dist/bundle/locales/testingMethodologies.en.json — traduções em inglês

Passo 1: Remova do arquivo de metodologias de teste

Arquivo: dist/bundle/testingMethodologies.json

Encontre e remova o objeto inteiro da metodologia que você deseja excluir.

// 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

Passo 2: Remova do arquivo de localidade em inglês

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

Remova o mesmo objeto de metodologia deste arquivo.

Adicione um Novo Tipo de Ativo Digital

Use isso para adicionar um novo tipo de ativo digital — por exemplo, uma metodologia de web-app ou macos. O exemplo abaixo usa web-app; substitua pelo id do tipo de ativo de sua escolha conforme necessário.

Arquivos a serem atualizados:

• dist/bundle/testingMethodologies.json — dados principais de metodologias de teste
• dist/bundle/locales/testingMethodologies.en.json — traduções em inglês
• dist/bundle/locales/checkpoints.en.json — conteúdo de checkpoint em inglês com seções de metodologia de teste
• dist/bundle/checkpoints.json — dados principais de checkpoints
• dist/bundle/descriptions.json — descrições de problemas com referências a metodologia de teste
• dist/bundle/schemata.json — definições de esquema com referências a metodologia de teste

Passo 1: Adicione ao arquivo de metodologias de teste

Arquivo: dist/bundle/testingMethodologies.json

Adicione o novo objeto de metodologia ao array.

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

Passo 2: Adicione ao arquivo de localidade em inglês

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

Adicione o mesmo objeto de metodologia a este arquivo.

Passo 3: Adicionar referências ao arquivo de pontos de verificação

Arquivo: dist/bundle/checkpoints.json

Para cada ponto de verificação que deve suportar a nova metodologia, adicione-o ao array testingMethodologies desse ponto de verificação.

{
  "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"
  ]
}

Passo 4: Adicionar conteúdo de metodologia de teste ao arquivo local de pontos de verificação

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

Para cada ponto de verificação que deve suportar a nova metodologia, adicione o conteúdo de metodologia de teste.

{
  "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>"
    }
  }
}

Passo 5: Adicionar referências ao arquivo de descrições

Arquivo: dist/bundle/descriptions.json

Para descrições de problemas que devem suportar a nova metodologia, adicione-a ao array testingMethodologies delas.

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

Passo 6: Adicionar referências ao arquivo de esquema

Arquivo: dist/bundle/schemata.json

Adicione a nova metodologia de teste às definições do 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
  }
}

Adicionar um Novo Ponto de Verificação

Adicionando um Ponto de Verificação Não-WCAG

Importante: Pontos de verificação não-WCAG não não suportam descrições predefinidas ou recomendações via descriptions.json e recommendations.json. Ao registrar problemas com esses pontos de verificação, você insere descrições e recomendações manualmente usando o recurso Crie sua própria descrição na ferramenta.

Arquivos a serem atualizados — apenas 2:

• package/dist/bundle/checkpoints.json — definir o ponto de verificação
• package/dist/bundle/locales/checkpoints.en.json — fornecer metodologia de teste localizada

Passo 1: Adicionar o ponto de verificação a checkpoints.json

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

Campos principais:

• id — identificador único usando seu formato personalizado (ex., custom.1.1, brand.2.3, TT.01.A, s.1.1).
• successCriteria — string vazia "" para pontos de verificação não-WCAG (ou um formato personalizado como "tt-01.A").
• standards — seu identificador de padrão personalizado, ex., ["custom"], ["TT508"], ["smoke"], ["brand"] (não ["wcag2a"]).
• testingMethodologies — plataformas onde este ponto de verificação se aplica: desktop, mobile, kiosk, native-mobile-ios, native-mobile-android, pdf, windows-desktop, ms-excel, ms-powerpoint, ms-word.
• requiredSenses — quais sentidos são necessários para testar este ponto de verificação (sight, hearing: true/false).
• automatedRules — array opcional de ids de regras automatizadas (normalmente vazio [] para pontos de verificação personalizados).
• grouping — agrupamento lógico para organização (ex., "custom.1", "1", "s.1").
• categories — categorias de acessibilidade relevantes (pode estar vazio [] para não-WCAG).
• terms — array opcional de referências de termos de glossário com propriedades id e ordinal.

Passo 2: Adicionar conteúdo localizado a checkpoints.en.json

Use o formato de id hifenizado: converta os pontos em hífens (ex., custom-1-1, não 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 novas linhas e tags HTML apropriadas para listas.

Adicionando um Ponto de Verificação WCAG

Arquivos a serem atualizados — 6 arquivos para uma implementação completa de ponto de verificação WCAG:

1. package/dist/bundle/checkpoints.json — definir o ponto de verificação com campos específicos para WCAG.
2. package/dist/bundle/locales/checkpoints.en.json — metodologia de teste localizada, exemplos, técnicas relacionadas (use o formato de id hifenizado: 1-4-3-a, não 1.4.3.a).
3. package/dist/bundle/descriptions.json — descrições de problemas com níveis de impacto e referências de ponto de verificação.
4. package/dist/bundle/locales/descriptions.en.json — descrições de problemas localizadas.
5. package/dist/bundle/recommendations.json — recomendações de remediação ligadas a descrições de problemas.
6. package/dist/bundle/locales/recommendations.en.json — conteúdo de recomendação localizado (título, descrição, etapas, recursos).

Opcional — entrada manual: Se preferir pular a adição de descrições e recomendações predefinidas aos arquivos JSON, você pode lidar com elas ao registrar problemas na ferramenta: selecione seu ponto de verificação WCAG, escolha Crie sua própria descrição em vez de um predefinido e, em seguida, insira manualmente a descrição e a recomendação (se necessário) adaptada ao problema encontrado.

Passo 1: Defina o ponto de verificação

Arquivo: 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 principais:

• id — Padrão de numeração WCAG (ex.: "1.4.3.a", "2.1.1.b").
• successCriteria — Número do critério de sucesso WCAG (ex.: "1.4.3").
• standards — "wcag2a" (Nível A), "wcag2aa" (Nível AA) ou "wcag2aaa" (Nível AAA).
• automatedRules — Array de IDs de regras automatizadas.
• grouping — Número da diretriz WCAG (ex.: "1.4", "2.1").

Passo 2: Adicione a metodologia de teste

Arquivo: package/dist/bundle/locales/checkpoints.en.json — use o formato hifenizado (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>"
  }
}

Passo 3: Adicione descrições de problemas

Arquivo: 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"]
    }
  ]
}

Passo 4: Adicione descrições de problemas localizadas

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

Adicione um objeto para a nova descrição:

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

Passo 5: Adicione recomendações

Arquivo: package/dist/bundle/recommendations.json

Use o formato hifenizado (1-4-3-a) e anexe-o ao ID da recomendação.

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

Passo 6: Adicione o conteúdo da recomendação

Arquivo: 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"
  ]
}

Remova um Ponto de Verificação Específico

Use estas instruções se houver um ponto de verificação específico que você não deseja que sua equipe teste e reporte.

Arquivos atualizados:

• 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

Passos:

1. No checkpoints.json, procure o ponto de verificação específico (ex.: 1.2.1.b). Exclua todo o objeto associado a este ponto de verificação, mantendo o JSON válido. Salve o arquivo.
2. No descriptions.json, procure o ponto de verificação específico (ex.: 1.2.1.b). Exclua apenas o objeto que usa o ponto de verificação sob a regra, mantendo o JSON válido. Uma única regra pode se aplicar a vários pontos de verificação — remova apenas o objeto referente ao ponto de verificação que você está removendo; não remova a regra completa. Salve o arquivo.
3. No recommendations.json, procure o ponto de verificação específico (ex.: 1.2.1.b). Exclua todos os objetos associados a este ponto de verificação (pode haver mais de um), mantendo o JSON válido. Salve o arquivo.
4. No checkpoints.en.json, procure o ponto de verificação específico usando o formato hifenizado (ex.: 1-2-1-b). Exclua todo o objeto, mantendo o JSON válido. Salve o arquivo.
5. No recommendations.en.json, procure o ponto de verificação específico usando o formato hifenizado (ex.: 1-2-1-b). Exclua todos os objetos associados a este ponto de verificação (pode haver mais de um), mantendo o JSON válido. Salve o arquivo.

Enviando Alterações de Volta para a Deque

Quando as edições estiverem concluídas e validadas:

1. Confirme se todos os arquivos editados ainda passam na validação JSON (veja Antes de começar).
2. Confirme se as mudanças correspondem ao escopo acordado.
3. Envie a pasta inteira package de volta para a Deque em sua estrutura original (não envie apenas arquivos individuais).

A Deque irá atribuir a versão, empacotar o conjunto, mapeá-lo para a versão correta do axe-core e implantá-lo em uma instância de teste para verificação. Depois que sua equipe verificar as mudanças na instância de teste e aprová-las, a Deque promoverá a metodologia para sua instância de produção.

Suporte

Para perguntas sobre este processo, o escopo de mudança acordado ou para solicitar suporte adicional em outro idioma, entre em contato com seu ponto de contato na Deque.