Blog > Integração Contínua para Testadores - Parte 3

15/fev

Nesta série iremos aprender especificamente como aplicar os scripts de automação de teste em um cenário de uso da Integração Contínua, o que deveríamos ter automatizado e como fazer uma boa organização para um feedback mais rápido. Este post não tem a intenção de mostrar algo automatizado executando, mas sim uma das possíveis organizações da automação na Integração Contínua.


Introdução

Nesta série iremos aprender especificamente como aplicar os scripts de automação de teste em um cenário de uso da Integração Contínua, o que deveríamos ter automatizado e como fazer uma boa organização para um feedback mais rápido. Este post não tem a intenção de mostrar algo automatizado executando, mas sim uma das possíveis organizações da automação na Integração Contínua.

Primeiro de tudo: A Pirâmide de Automação de Teste

Ela vem como complemento, dentro do ágil, aos Quadrantes de Teste Ágil e tem um foco no que desprender mais tempo no momento de automatizar uma aplicação.

A leitura da pirâmide é simples: a base da pirâmide é mais importante e prioritária, mas não excluir os outros níveis da pirâmide.

Neste interpretação devemos ter, obrigatoriamente, testes unitários (lembre-se de que eles são desenvolvidos pelo programador) como a base também da entrada da qualidade dentro da Integração Contínua.

Para um melhor entendimento:

  • Unitário: compõe os testes unitários, ou seja, aqueles que são criados de forma isolada
  • Serviços: aqui temos diversos tipos de testes que podem ser aplicados, alguns onde temos que ter o conhecimento do código-fonte, e outros onde este conhecimento não é necessário
    • Componentes: testa módulos com um isolamento sobre a aplicação, geralmente usando drivers ou stubs.
    • Integração: integra as diversas partes internas ou externas da aplicação (módulos por exemplo)
    • API: testes que irão testar a API exposta para comunicação, como REST ou SOAP
  • UI: significa User Interface (Interface Gráfica) que podem compor dois tipos de testes:
    • Testes Funcionais: testes que irão validar requisitos funcionais com fatores de sucesso ou falha (muitos testadores conhecem como testes positivos e negativos)
    • Testes de Aceitação: com um foco no que o usuário irá fazer na aplicação. Também conhecidos como E2E ou Testes de Cenários

Segundo: para nós testadores, como focar nos outros pontos da pirâmide?

Vamos desconsiderar a parte de testes unitários da pirâmide e informar no que é comumente utilizado no dia a dia profissional de um testador.

Veja que dentro dos outros dois níveis eu alterei o nome dentro de Serviço e de UI. Esta substituição foi feita para dar um exemplo mais claro de tipos de teste que podem ser feitos, por um testador, nestes dois níveis.

Serviços

Testes com REST ou SOAP: atualmente grande parte das aplicações desenvolvidas possui algum desta camadas de serviços para troca de informações da aplicação para com outro agente externo (podendo ser outra aplicação, uma app mobile, etc…)

Vamos pegar o caso de uma app mobile. Muitas empresas possuem, além da app mobile uma página que dispõe dos mesmos serviços (ou até mais funcionalidades). Há um backend comum as duas aplicações, e a comunicação da interface web e mobile para com o backend é através de REST.

Com isso temos que testar esta camada: enviar dados e obter as respostas necessárias.

Testes Funcionais e Aceitação

Esta camada é a mais comum entre os testadores: automação de teste funcional e aceitação.

Testes Funcionais: são os testes focados em uma única funcionalidade, podendo ser o fluxo principal da funcionalidade ou de excessão (comumente conhecidos na área de teste como testes positivos e negativos).

  • Exemplo de teste positivo: Efetuar login com usuário e senha válidos
  • Exemplo de teste negativo: Efetuar login sem preencher o campo senha

Teste de Aceitação: são testes pensando na utilização total do sistema por parte do usuário e que deve ser percorrido para garantir que o conjunto de funcionalidades utilizada pelo cliente não contém erros. Estes são comumente chamados de teste "fim a fim" (E2E) na área de teste.
Um exemplo seria o cenário de compra de uma passagem aérea, onde o comprador da passagem no site tem que pesquisar a passagem, selecionar a passagem, informar os dados básicos e de pagamento, efetuar o pagamento e visualizar a confirmação de compra.

O que a Pirâmide tem a ver com Integração Contínua?

Provavelmente em um projeto com as características citadas acima nós iríamos automatizar, certo?

Muitos não sabem como criar uma estratégia para executar os testes automatizados, mas uma saída é utilizar a Integração Contínua.

Nós podemos adotar a seguinte abordagem de execução de teste utilizando um sistema de Integração Contínua

Na imagem acima podemos ver todos os passos que devemos (ou deveríamos) inserir no ciclo de build da Integração Contínua.

Note que há um item em cinza: Execução de Smoke Test de Aceitação.

Ele é um pequeno grupo de scripts automatizados que irão confirmar que a(s) funcionalidade(s) mais usada(s) será(ão) validadas primeiro. Assim não corremos o risco de executar todos os Testes Funcionais e de Aceitação sabendo que há algum problema nas principais funcionalidades.

Conclusão

Neste post aprendemos conceitualmente o que é necessário, como testador, inserir no ciclo de Integração Contínua. Obviamente estes testes são automatizados e aprendemos através da Pirâmide de Automação de Teste a importância da execução da automação. Por fim visualizamos uma ordem proposta, e utilizada no mercado, de sequenciamento da execução da automação de teste.

Referências

TestPyramid - Martin Fowler Blog - http://martinfowler.com/bliki/TestPyramid.html

Succeeding with Agile - Livro onde a Pirâmide de Automação de Teste apareceu pela primeira vez. - http://www.amazon.com/gp/product/0321579364

POSTS RELACIONADOS

AGENDA

CURSOS RELACIONADOS