Este artigo serve de guia introdutório para entender de forma teórica o que é a Arquitetura Genérica de Automação de Testes (do inglês gTAA – Generic Test Automation Architecture).
Por experiência própria, vejo que muitos QA Automatizadores têm dificuldades na concepção de uma Solução de Automação de Testes (do inglês TAS – Test Automation Solution). Portanto, resolvi compartilhar esse artigo com vocês. 🙂
O conteúdo abaixo foi baseado no material provido pelo o ISTQB (International Software Testing Qualification Board).
Afinal o que é a Arquitetura Genérica de Automação de Testes (gTAA)?
Um QA Automatizador tem o papel de projetar, desenvolver, implementar e manter testes automatizados. À medida que cada solução é desenvolvida, tarefas semelhantes precisam ser realizadas, perguntas precisam ser respondidas e questões semelhantes precisam ser tratadas e priorizadas. Estes recorrentes conceitos, etapas e abordagens na automação de testes tornam-se a base da Arquitetura Genérica de Automação de Testes, chamada de gTAA.
A gTAA apresenta camadas, componentes e interfaces que são posteriormente redefinidos em uma Arquitetura de Automação de Testes (TAA) concreta para uma TAS específica. Portanto, a gTAA permite uma abordagem estruturada e modular para construção de uma TAS, por meio de:
- Definição do espaço conceitual, camadas, serviços e interfaces, desta forma permitindo o desenvolvimento da automação de testes por QA Automatizadores internos ou externos.
- Suporte a componentes simplificados para o desenvolvimento eficaz e eficiente da automação de testes.
- Reutilização de componentes de automação de teste para TASs diferentes.
- Facilitar a manutenção e evolução das TASs.
- Definir os recursos essenciais para um usuário de uma TAS.
Mas como a gTAA é estruturada para prover esses benefícios?
A gTAA é estruturada em camadas horizontais:
- Test Generation: apoia a criação de casos de testes manuais e automatizados.
- Test Definition: apoia a definição e implementação de casos de testes / suítes de testes. Contém meios para definir testes de alto e baixo nível.
- Test Execution: apoia a execução dos testes e dos registros dos resultados dos testes executados. Fornece uma ferramenta de execução de teste para executar os testes selecionados automaticamente e provê relatórios dos testes.
- Test Adaptation: fornece adaptadores diferentes para conectar os testes automatizados ao sistema a ser testado, por meio de APIs, protocolos, serviços, entre outros.
Qualquer projeto de automação de testes deve ser entendido, configurado e gerenciado como é feito no desenvolvimento de sistemas — ou seja, requer o gerenciamento de projeto. Ele pode ocorrer de forma independente do gerenciamento de projeto do sistema em desenvolvimento.
Vamos conferir mais detalhes de cada camada?
1. Test Generation: contém ferramentas que fornecem suporte para as seguintes atividades:
- Criação manual de casos testes
- Desenvolvimento, captura e/ou criação de dados para testes
- Criação automática de casos de testes
2. Test Definition: essa camada já oferece ferramentas para:
- Especificação de testes, sejam eles de alto ou baixo nível
- Definição de dados para testes de baixo nível
- Especificação do passo a passo de cada teste
- Definição dos scripts de testes para uma futura execução
3. Test Execution: aqui, podemos encontrar suporte para:
- Execução automática de testes
- Registro das execuções de testes
- Relatórios de resultados de testes
4. Test Adaptation: na última camada, temos as ferramentas que fornecem suporte para essas tarefas:
- Controle do ambiente de testes
- Interação com o sistema em teste
- Monitoramento do sistema em teste
- Simulação do ambiente com o sistema em teste
Com base nos padrões estabelecidos pelas camadas da gTAA, o QA Automatizador pode escolher quais ferramentas se encaixam melhor com as necessidades da sua TAS. Abaixo, alguns exemplos:
- Jira, para o gerenciamento do backlog da automação de testes
- XRay, para a criação, definição, especificação e execução de testes manuais
- Cucumber + Ruby + Watir, para codificar os testes de front-end
- Cucumber + Ruby + HttParty, para codificar os testes de APIs
- Cucumber + Ruby + Appium, para codificar os testes mobile
- GitHub, para controlar o código fonte da TAS
- Cucumber Report, relatório customizado para a TAS
- Jenkins, integração contínua
E qual conclusão podemos tirar disso?
Geralmente, uma TAS baseada em uma gTAA será implementada por um grupo de ferramentas, plugins, e/ou componentes. Portanto, é muito importante lembrar que a gTAA é vendor-neutro, ou seja, não pré-define qualquer método ou metodologia concreta, ou tecnologia, ou ferramenta para o desenvolvimento de uma TAS.
O propósito é que a gTAA seja implementada independentemente da linguagem de programação ou metodologia escolhida, seguindo as melhores práticas estabelecidas pela gTAA.
Dessa forma, usufrui-se de benefícios do método, da tecnologia ou da ferramenta escolhida, de acordo com as necessidades de cada projeto, cliente ou sistema.
