Validar funcionalidade do app

Conforme a aplicação é criada, valide se ela funciona conforme o esperado.

Teste de unidade

O teste de unidade/história garante que os requisitos especificados em uma história sejam validados antes de fechar a história. Uma História/Unidade é a menor parte testável de um sistema ou aplicação que pode ser configurada e executada.

Quando a configuração da história estiver concluída, os desenvolvedores precisarão testar os recursos da unidade não apenas no contexto dessa história específica, mas também de outras histórias relacionadas que compartilham componentes com a história atual.

Como prática recomendada, os desenvolvedores precisam atribuir a história ao proprietário do processo ou à parte interessada designada para validar se a configuração da história atende aos resultados esperados antes de encerrar a história.

O Automated Test Framework (ATF) da ServiceNow destina-se principalmente à automação de testes funcionais de aplicações, mas em alguns casos pode ser usado para automatizar o teste de unidade de configurações que envolvem Script Includes e Business Rules.

Teste do sistema

O teste do sistema é realizado em um sistema completo quando o desenvolvimento é concluído. Teste a interação geral de componentes e integrações com outras aplicações dentro do escopo. O teste do sistema é realizado pela equipe de P&R/Teste, mas os desenvolvedores precisam colaborar com a equipe de CQ e os responsáveis pelo processo para garantir que os casos de teste forneçam uma cobertura abrangente. Os desenvolvedores serão responsáveis pela correção dos problemas encontrados durante o teste do sistema.

Automated Test Framework

O Automated Test Framework (ATF) deve ser aproveitado para automatizar o teste do sistema funcional de aplicações da ServiceNow para reduzir o tempo e os custos de teste e tornar o teste repetível e independente da IU. Ao criar casos de teste, siga estas diretrizes.

Ao criar testes:

• Use testes com parâmetros para evitar casos de teste duplicados.
• Siga um padrão de nomenclatura de teste.
  • <app initial>:<functionality that is being tested>
  • CSM: resolver caso
• Descreva o caso de uso de cada teste em sua descrição. Por exemplo: amostra que testa o caso de uso.
• Desenvolva testes em uma instância de desenvolvimento e promova/execute o teste em uma instância de teste.
• Os clones apagam os testes. Use uma destas opções para preservar os testes:
  • Agrupe os testes em um app com escopo e carregue o app para o GIT.
  • Salve os testes antes do clone.
  • Promova testes para instância de produção, mas NÃO EXECUTE OS testes EM PRODUÇÃO.
• Crie testes autocontidos.
• Crie novas etapas de teste REST do lado do servidor ou que não tenham etapas de teste. Por exemplo: Verificação do corpo do e-mail.
• Use a etapa de teste do lado do servidor sempre que possível e quando as capturas de tela não forem importantes.
• Comece com a etapa Representar.
• Esteja ciente da limitação do navegador.
• Use os logs de teste e as transações de teste para solucionar erros de teste.

Ao criar pacotes de testes:

• Siga um padrão de nomenclatura de pacote de testes. Por exemplo: ITSM INT: casos de uso.
• Descreva o pacote.
  • Descrição do pacote de testes: "Este é um pacote de testes de amostra para testar o plug-in/aplicação".
  • Forneça todas as informações adicionais possíveis na descrição.
• Organize os pacotes de testes por áreas de recursos.

Teste de aceitação do usuário

O teste de aceitação do usuário (UAT) é um teste realizado para avaliar a conformidade da aplicação com os requisitos de negócios e avaliar se a aplicação é aceitável para entrega. Usuários, clientes ou outras partes interessadas autorizadas realizam testes de aceitação. Os desenvolvedores serão responsáveis pela correção dos problemas encontrados durante o teste do sistema.