Suporte a Metodologia Personalizada

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

Objetivo

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

• Políticas internas específicas que exigem verificações adicionais ou reduzidas.
• Diretrizes internas para usar ferramentas específicas ao realizar testes.
• Decisões políticas que mudam 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 transmitidas de volta para a Deque para empacotamento e implantaçã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, a sequenciação de versões, o empacotamento e a implantação da metodologia. Sua equipe é responsável apenas por editar os arquivos de configuração da metodologia. Você não precisa atualizar números de versão, construir pacotes ou executar qualquer comando de instalação ou banco de dados. A Deque cuida de tudo isso em seu nome.

O processo de ponta a ponta é:

Nota sobre o 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 de acordo 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 extraída. Se uma edição corromper o pacote, esta é sua única maneira 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 determinada alteração — ou deixar de lado um que é listado — pode produzir um pacote que falha apenas depois de retornar para a Deque.

3. Valide cada arquivo que você tocar. Cada arquivo é JSON e deve permanecer um JSON válido após a edição (sem vírgulas finais, chaves/colchetes equilibrados). 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 sua organização requerer a metodologia em idiomas adicionais, informe à Deque — a Deque habilita o 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 localidade 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ê quer mudar 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 a 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 sob o 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 precisar alterar o impacto de padrão para uma regra, siga estas instruções.

Os impactos no axe Auditor são armazenados no nível de regra, não no nível dos Critérios de Sucesso WCAG ou ponto de verificação. Uma única regra pode afetar múltiplos 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 desta regra em todos os tudo Critérios de Sucesso WCAG conectados à 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.

Mapeamentos de valor 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.

⚠️ Deque interno — 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 esses são erros de caminho, então atualize a lista conforme necessário 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 todo o objeto de wcag21aa e adicioná-lo ao final do arquivo.
2. Altere o id do novo objeto 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 pontos de verificação 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 ponto de verificação aplicável com o padrão correto.

Atualizar as Descrições Curta e Longa do Problema para Regras Específicas

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

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

Passos:

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 seu local atual.

Atualizar a Recomendação de Remediação

Se você quiser mudar a biblioteca de remediação e as descrições associadas para se alinhar com sua política, use as seguintes instruções.

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

Passos:

1. Em recommendations.en.json, procure a regra específica (por exemplo, alt-text-dynamic-image-inconsistent) e a combinação de ponto de verificação para a 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 seu local atual.

Remover Tipos de Ativos Digitais

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

Arquivos a serem atualizados:

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

Passo 1: Remover do arquivo de metodologias de teste

Arquivo: dist/bundle/testingMethodologies.json

Encontre e remova todo o objeto 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: Remover do arquivo de localidade em inglês

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

Remova o mesmo objeto de metodologia deste arquivo.

Adicionar um Novo Tipo de Ativo Digital

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

Arquivos a serem atualizados:

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

Passo 1: Adicionar 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: Adicionar 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 deva suportar a nova metodologia, adicione-a 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 de localidade de ponto de verificação

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

Para cada ponto de verificação que deva suportar a nova metodologia, adicione o conteúdo da 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 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
  }
}

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 suportam descrições ou recomendações predefinidas através de 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 (por exemplo, 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 padrão personalizado, por exemplo, ["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 (tipicamente vazio [] para pontos de verificação personalizados).
• grouping — agrupamento lógico para organização (por exemplo, "custom.1", "1", "s.1").
• categories — categorias de acessibilidade relevantes (podem ser vazias [] para não-WCAG).
• terms — array opcional de referências de termos de glossário com propriedades id e ordinal.

Passo 2: Adicione conteúdo localizado ao checkpoints.en.json

Use o formato de id hifenizado: converta pontos em hífens (por exemplo, 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 adequadas para listas.

Adicionando um Checkpoint WCAG

Arquivos a serem atualizados — 6 arquivos para uma implementação completa do checkpoint WCAG:

1. package/dist/bundle/checkpoints.json — defina o checkpoint com campos específicos do 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 ao checkpoint.
4. package/dist/bundle/locales/descriptions.en.json — descrições de problemas localizadas.
5. package/dist/bundle/recommendations.json — recomendações de remediação vinculadas às descrições dos problemas.
6. package/dist/bundle/locales/recommendations.en.json — conteúdo de recomendação localizado (título, descrição, passos, 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 checkpoint WCAG, escolha Crie sua própria descrição em vez de um predefinido, e então insira manualmente a descrição e (se necessário) a recomendação adaptada ao problema encontrado.

Passo 1: Defina o checkpoint

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 (por exemplo, "1.4.3.a", "2.1.1.b").
• successCriteria — número de critérios de sucesso WCAG (por exemplo, "1.4.3").
• standards — "wcag2a" (Nível A), "wcag2aa" (Nível AA) ou "wcag2aaa" (Nível AAA).
• automatedRules — array de ids de regras automáticas.
• grouping — número da diretriz WCAG (por exemplo, "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 ao id da recomendação.

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

Passo 6: Adicione conteúdo de 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"
  ]
}

Remover um Checkpoint Específico

Use estas instruções se houver um checkpoint específico que você não quer que sua equipe teste e relate.

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. Em checkpoints.json, procure o checkpoint específico (por exemplo, 1.2.1.b). Exclua o objeto inteiro associado a este checkpoint enquanto mantém o JSON válido. Salve o arquivo.
2. Em descriptions.json, procure o checkpoint específico (por exemplo, 1.2.1.b). Exclua apenas o objeto que utiliza o checkpoint sob a regra enquanto mantém o JSON válido. Uma única regra pode se aplicar a múltiplos checkpoints — remova apenas o objeto do checkpoint que está removendo; não remova a regra completa. Salve o arquivo.
3. Em recommendations.json, procure o checkpoint específico (por exemplo, 1.2.1.b). Exclua todos os objetos associados a este checkpoint (pode haver mais de um) enquanto mantém o JSON válido. Salve o arquivo.
4. Em checkpoints.en.json, procure o checkpoint específico usando o formato hifenizado (por exemplo, 1-2-1-b). Exclua o objeto inteiro enquanto mantém o JSON válido. Salve o arquivo.
5. Em recommendations.en.json, procure o checkpoint específico usando o formato hifenizado (por exemplo, 1-2-1-b). Exclua todos os objetos associados a este checkpoint (pode haver mais de um) enquanto mantém o JSON válido. Salve o arquivo.

Enviando Alterações de Volta para a Deque

Quando as edições estiverem completas e validadas:

1. Confirme se cada arquivo editado ainda passa na validação de JSON (veja Antes de começar).
2. Confirme se as alterações 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 pacote, mapeá-lo para a versão correta do axe-core e implantá-lo em um instância de teste para verificação. Depois que sua equipe verificar as alterações na instância de teste e aprovar, a Deque promove a metodologia para sua instância produção.

Suporte

Para perguntas sobre este processo, o escopo de alterações acordado ou para solicitar suporte adicional de idiomas, entre em contato com o seu ponto de contato da Deque.