Arquitetura Genérica de Automação de Testes

Neste artigo você vai ver:

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.

 

5f74be17637e1af3e85b3508_autor-blog-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.

Artigos relacionados

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