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 do 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 a unidade dos recursos não apenas no contexto dessa história específica, mas também em 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 foi criado principalmente para automatizar o teste funcional de aplicações, mas em alguns casos pode ser usado para automatizar o teste de unidade de configurações que envolvem Inclusões de script e Regras de negócio.

Testes 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 CQ/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 os testes repetíveis e independentes da IU. Ao criar casos de teste, siga estas diretrizes.

Ao criar testes:

• Use o teste 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.
• Testes de limpeza de clones. Use uma destas opções para preservar os testes:
  • Testes de pacote em um app com escopo e carregue o app para o GIT.
  • Salve os testes antes do clone.
  • Promova testes para a instância de produção, mas NÃO EXECUTE OS testes NA PRODUÇÃO.
• Crie testes autocontidos.
• Crie novas etapas de teste REST ou do lado do servidor se houver etapas de teste ausentes. 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 Transações de teste para solucionar problemas de 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: "Esta é uma amostra de pacote de testes para testar 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.

Testes 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.