8.1 Opções para melhorar a automação de teste
ALTA-E-8.1.1 (K4): Analisar os aspectos técnicos de uma solução de automação de teste implementada e fornecer recomendações para melhorias.
Conceitos-chave:
Verificação.
Além das tarefas de manutenção necessárias em andamento para manter o TAS sincronizado com o SUT, há também oportunidades para melhorias do TAS.
Essas melhorias podem ser realizadas para alcançar uma série de benefícios, incluindo
- Maior eficiência (reduzindo ainda mais a intervenção manual),
- Melhorar a facilidade de seu uso,
- Implementar novas funcionalidades
- Melhorar o suporte para as atividades de teste.
A decisão sobre como as melhorias no TAS serão feitas, será influenciada pelos benefícios que irão agregar mais valor para um projeto.
As áreas específicas de um TAS que podem ser consideradas para melhoria, incluindo:
Essas áreas são descritas em mais detalhe abaixo.
Geração de Scripts
As abordagens de scripts variam da estruturada às baseadas em dados e às mais sofisticadas orientadas por palavras-chave, conforme descrito no capítulo 3.2.2.
Pode ser apropriado:
- atualizar a abordagem atual de script do TAS para todos os testes automatizados novos.
- revisar todos os testes automatizados existentes ou,
- revisar os testes automatizados que envolvam maior esforço de manutenção.
Em vez de mudar toda a abordagem de script, as melhorias de TAS podem se concentrar na implementação de scripts. Por exemplo:
- Avaliar sobreposição de caso de teste, passo ou procedimento em um esforço para consolidar os testes automatizados.
Casos de teste contendo passos semelhantes não devem implementar esses passos várias vezes. Esses devem ser feitos em uma função e adicionada a uma biblioteca, para que possa ser reutilizada. Isso aumenta a capacidade de manutenção do testware.
Quando os passos de teste não são idênticos, mas semelhantes, a parametrização pode ser necessária.
Observação: esta é uma abordagem típica de testes orientados por palavras-chave.
- Estabelecer um processo de recuperação de erros para o TAS e o SUT.
Quando um erro ocorre durante a execução de casos de teste, o TAS deve ser capaz de se recuperar a partir desta condição de erro, e ser capaz de continuar com o próximo caso de teste.
Quando ocorre um erro no SUT, o TAS precisa ser capaz de executar ações de recuperação necessárias no SUT (p. ex., uma reinicialização completa do SUT).
- Avaliar mecanismos de espera para garantir que o melhor tipo está sendo usado.
Há três mecanismos de espera comuns:
1. Temporizador embutido no script de automação – pode ser uma causa raiz para vários problemas de automação de teste.
2. Espera dinâmica por sondagem (polling) – exemplo: verificar de tempos em tempos se uma certa mudança de estado ou ação ocorreu. É muito mais flexível e eficiente:
- Espera somente o tempo necessário e nenhum tempo de teste é desperdiçado;
- Se o processo demorar mais tempo, o polling aguardará até que a condição seja verdadeira. Deve-se incluir um mecanismo de tempo limite (timeout), senão o teste pode esperar para sempre em caso de problema.
3. Uma alternativa melhor é subscrever ao mecanismo de evento do SUT, sendo mais confiável do que as outras duas opções.
Nesse caso a linguagem de script de teste precisa suportar a subscrição de eventos e o SUT precisa oferecer esses eventos para o TAS. Deve-se incluir um mecanismo de tempo limite (timeout), senão o teste pode esperar para sempre em caso de problema.
- Tratar o testware como um software.
Desenvolvimento e manutenção do testware é apenas uma forma de desenvolvimento de software. Assim as boas práticas de codificação (p. ex., usando diretrizes para codificação, análise estática, revisões de código) devem ser aplicadas.
Pode ser uma boa ideia usar desenvolvedores de software (em vez de Engenheiros de Teste) para desenvolver certas partes do testware (p. ex., bibliotecas).
- Avaliar scripts existentes para revisão ou eliminação.
Alguns scripts podem ser problemáticos (p. ex., falhando frequentemente ou com custos de manutenção elevados) e pode ser adequado redesenhar esses scripts.
Outros scripts de teste podem ser removidos do conjunto de testes porque eles não estão mais adicionando valor.
Execução de Teste
Quando um conjunto automatizado de teste de regressão não é concluído durante a noite, isso não pode lhe causar surpresa.
Quando o teste demora muito tempo, pode ser necessário testar o SUT usando instâncias diferentes simultaneamente, mas isso nem sempre é possível.
Quando sistemas alvos e caros são usados para testes, isso é uma restrição, e todos os testes precisam ser executados em uma instância única do SUT.
Pode ser necessário dividir o conjunto de testes de regressão em várias partes, cada um executando em um período definido (p. ex., em uma única noite).
Uma análise mais aprofundada da cobertura de teste automatizada pode revelar duplicação. Remover a duplicação pode reduzir o tempo de execução e pode gerar mais eficiência.
Verificação
Antes de criar funções de verificação, adote um conjunto padrão de métodos de verificação para uso em todos os testes automatizados.
Isso evitará a reimplementação de ações de verificação entre vários testes. Quando os métodos de verificação não são idênticos, mas semelhantes, o uso da parametrização ajudará a permitir que uma função seja usada em vários tipos de objetos.
Arquitetura
Pode ser necessário alterar a arquitetura para apoiar melhorias da testabilidade do SUT. Estas mudanças podem ser feitas na arquitetura do SUT ou do TAS.
Isso pode proporcionar uma grande melhoria na automação de teste, mas pode exigir mudanças significativas e investimento no SUT ou TAS.
Por exemplo, se o SUT vai ser alterado para fornecer API para testes, em seguida, o TAS também deve ser refatorado adequadamente.
Adicionar esses tipos de funcionalidades em um estágio mais tardio pode ser bastante caro; é muito melhor pensar nisso no início da automação (e nos estágios iniciais do desenvolvimento do SUT – ver capítulo 2.3, modelagem para testabilidade e automação).
Pré e pós processamento
Prover padronização para tarefas de configuração (pré-processamento) e desinstalação (pós-processamento). Isso otimiza as tarefas realizadas repetidamente para cada teste automatizado, reduzindo tanto os custos de manutenção, quanto reduzindo o esforço necessário para implementar novos testes automatizados.
Documentação
Isso cobre todas as formas de documentação desde a documentação dos scripts (o que os scripts fazem, como devem ser usados etc.), a documentação do usuário para o TAS e os relatórios e logs produzidos pelo TAS.
Suporte às ferramentas
Somente adicione novas funcionalidades ao TAS quando essas forem usadas – como relatórios detalhados, logs, integração a outros sistemas etc. Adicionar funcionalidades não utilizadas aumenta a complexidade e diminui a confiabilidade e a facilidade de manutenção.
A atualização com novas versões do TAS, disponibilizam novas funções ou corrigem falhas identificadas. O risco é que a atualização do framework (atualizando as ferramentas de teste existentes ou introduzindo novas) possa ter um impacto negativo nos casos de teste existentes.
Deve-se testar a nova versão do TAS executando testes por amostragem antes do lançamento. Os testes por amostragem devem ser representativos dos testes automatizados em diferentes aplicações, tipos de teste e ambientes.
