Arquitetura Genérica de Automação de Testes

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 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:

  1. Test Generation: apoia a criação de casos de testes manuais e automatizados.
  2. 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.
  3. 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.
  4. 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:

  1. Criação manual de casos testes
  2. Desenvolvimento, captura e/ou criação de dados para testes
  3. Criação automática de casos de testes

2. Test Definition: essa camada já oferece ferramentas para:

  1. Especificação de testes, sejam eles de alto ou baixo nível
  2. Definição de dados para testes de baixo nível
  3. Especificação do passo a passo de cada teste
  4. Definição dos scripts de testes para uma futura execução

3. Test Execution: aqui, podemos encontrar suporte para:

  1. Execução automática de testes
  2. Registro das execuções de testes
  3. Relatórios de resultados de testes

4. Test Adaptation: na última camada, temos as ferramentas que fornecem suporte para essas tarefas:

  1. Controle do ambiente de testes
  2. Interação com o sistema em teste
  3. Monitoramento do sistema em teste
  4. 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.

Leandro Teixeira
Analista de Testes Sênior
Apaixonado pelo meu trabalho em QA e pela inclusão de pessoas com deficiência no mercado tech e na sociedade em geral.

Este site utiliza cookies para proporcionar uma experiência de navegação melhor. Consulte nossa Política de Privacidade.