O que você mais gosta Ghost Inspector?
- Mensagens detalhadas de falha e vídeo do que aconteceu durante os testes; foi fácil descobrir por que um teste específico falhou sem precisar executá-lo novamente.
- Integração de API; conseguimos integrar nossos conjuntos de testes em nossos pipelines de CI sem muito esforço adicional (usando o plugin Azure DevOps e integração com Pager Duty para falhas).
- Suporte responsivo - adorei que vocês estão disponíveis para responder perguntas sempre que as temos.
- Direcionamento por dados - usamos esse recurso para capturar e conduzir testes em diferentes ambientes com diferentes dados mestres (um único teste, múltiplas execuções), o que reduziu o custo de propriedade.
- Capacidade de construir testes componentizados que foram construídos a partir de componentes de script reutilizáveis; reduziu massivamente o custo de propriedade ao remover duplicações entre testes.
- Os custos são relativamente baixos para toda a nossa organização quando comparados com outras ferramentas comerciais (HP, Ranorex, Tosca).
- Gravar rapidamente migração de dados ou outros trabalhos de automação ad-hoc é fácil, acelerando a configuração de dados e outros trabalhos. Análise coletada por e hospedada no G2.com.
O que você não gosta Ghost Inspector?
Como um usuário de longo prazo do GI, os seguintes pontos são listados como desvantagens, mas espero que as sugestões sejam consideradas pela equipe :)
- Nosso aplicativo depende fortemente de chamadas de API bem-sucedidas para sincronizar o teste com o aplicativo, o GI não fornece um mecanismo para aguardar o resultado de uma chamada de API específica antes de continuar a execução. Isso resultou em testes instáveis que às vezes funcionavam e às vezes falhavam, dependendo da rapidez com que a API respondia.
- Sem cuidado, os testes acabavam sendo uma longa lista de instruções do navegador (clicar, verificar, navegar, etc.) e o sentido do teste se perdia. Seria ótimo ver uma maneira de agrupar/organizar etapas dentro de um teste que pudessem ser rotuladas com a intenção do teste (rótulos por etapa são uma solução intermediária, mas exigem que os autores dos testes os usem...)
- Variáveis globais/de teste são muito úteis, e seria ainda melhor se fossem sugeridas automaticamente ao escrever etapas (autocompletar/sugerir)
- Locadores de elementos gerados automaticamente com base na marcação ARIA (função, rótulo, para, etc.) seriam melhores do que a abordagem atual baseada na estrutura do DOM (td > div > etc).
- Controle de versão; não há nenhum - embora você possa extrair e controlar a versão dos testes individualmente, uma vez que você começa a importar/chamar outros scripts, todas as apostas estão fora. Um histórico de auditoria para testes (quem editou o quê/quando) ajudaria muito a contornar esse problema. Manter diferentes versões do teste para diferentes conjuntos de recursos (interruptores de recursos) era inviável.
- Integração de API - parar uma execução de teste não está atualmente incluído na integração do Azure Devops, então execuções canceladas precisam ser interrompidas manualmente no GI para evitar consumir minutos
- Você só pode esperar até um minuto por um elemento e isso é global para um teste inteiro, então se você tiver uma etapa ou um processo que leva mais tempo do que isso, você tem que usar uma espera estática que introduz instabilidade em seus testes. Seria ótimo se houvesse um método que permitisse esperar que um elemento fosse mostrado (ou oculto) com um tempo limite maior que 60s. Análise coletada por e hospedada no G2.com.
