Automação de Teste de Software – Parte 4 – Padronização

No post  Automação de Testes de Software é só record and play #SQN comentamos sobre dicas para automação de testes de software. À partir dai surgiu uma série de postagens cujo objetivo foi detalhar os tópicos lá citados. Nas postagens anteriores foram comentados os seguintes tópicos:

1) Definição de FerramentasPrimeiro passo seria definir, de acordo com contexto de seu projeto, qual ferramenta de automação e qual ferramenta de integração contínua será utilizada.

2) Definição do Ambiente de testeSegundo passo seria definição das aplicações\configurações do ambiente de teste necessários para que execute as ferramentas de automação e integração contínua.

3) Priorização do Backlog: Terceiro passo seria montar um backlog com as funcionalidades do sistema que para a criticidade do negócio seria interessante que existisse uma suíte de testes automáticos sendo executados.

Seguindo a sequência o próximo item abordado será:

4. Padronização da Automação

Uma das definições encontradas para Padronização é:

“A padronização tem como objetivo definir especificações técnicas que auxiliem na maximização da compatibilidade, reprodutibilidade, segurança ou qualidade de determinado processo, produto ou serviço.”[1]

Padronizacao
Trabalho Padronizado [2]

A ideia central por trás de padronização de testes automáticos é a definição de padrões ou estruturas que servem de modelo ou referência para construção de testes.

Nessa fase, seria o momento de extrair recursos da ferramenta selecionada e práticas de automação para definir junto com a equipe quais seriam os padrões adotados.

Trazendo um pouco para prática, aqui na MATERA formamos um grupo denominado Padrão QF-Test. Este grupo se formou com objetivo fazer o levantamento e definição de padrões e melhores práticas para automação. Além disso, o grupo também é responsável por divulgar e disseminar conhecimento sobre a ferramenta, dessa forma, auxiliando na implantação da cultura entre os testadores para adotarem esses padrões.

Alguns exemplos de padronizações que poderiam ser adotadas são:

  1.  Comentário no código: Incluir comentários explicando a finalidade do teste. Detalhar parâmetros e variáveis de forma que fique bem explicativo para outra pessoa caso haja a necessidade de manutenção no código, facilitará o entendimento.
  2. Utilização de packages e procedures: No caso do QF-Test é possível centralização de testes em packages\procedures.  Assim, a chamada desse teste poderá ser realizada apenas com uma simples mudança de parâmetros de acordo com a finalidade de cada teste. Tal prática visa evitar possíveis repetições via crtl C + crtl V, otimizando também a manutenção. Por exemplo: Na construção de um teste de validação de cadastro de pedido de venda que existem 10 cenários mapeados ao invés de escrever as 10 vezes, vou centralizá-lo fazendo a chamada dessa procedure mudando os parâmetros out no teste. Havendo a necessidade de alguma modificação, o esforço será centralizado em apenas um único ponto, evitando assim o retrabalho de replicação da mesma alteração para os demais cenários.
  3. Sempre inserir massa de dados do teste: Objetivo é  evitar falsos positivos. Manter a integridade do teste deixando-o com menor nível de acoplamento possível. Para isso, uma alternativa poderia ser popular os dados necessários via script.
  4. Pré-configurações: Objetivo é garantir que as configurações necessárias para validação de uma determinada funcionalidade foi realizada. É muito importante que um teste fique independente de outro para evitar que a quebra de um não afete o funcionamento de outro.
  5. Legibilidade: Utilizar os recursos da ferramenta que deixam o código “mais limpo” e de fácil compreensão. Presar pela organização do código, deixando-o o mais legível possível. Uma dica seria dividir o teste em tipos de validação como: CRUD, valores válidos, inválidos, obrigatórios e depois validar as regras de negócio.
  6. Valores fixos: Sempre evitar valores fixos no código, de preferência pela utilização de variáveis.
  7. Nomenclatura: Optar pela utilização de nomes de fácil compreensão e relacionados ao contexto da aplicação. Isso para para parâmetros, variáveis, procedures, etc. Os nomes utilizados podem referenciar os campos da tela, por exemplo.

Esses foram alguns exemplos, é claro que pode haver variação de uma ferramenta para outra, mas é importante que esse trabalho seja realizado.

Vantagens

Caso sua pergunta foi: Qual vantagem eu teria em dedicar parte do meu precioso tempo do projeto nessa etapa?

Alguns das possíveis respostas seriam:

  • Facilidade no entendimento do código de automação, consequentemente facilitando a manutenção também
  • Aumento de produtividade
  • Nivelamento de conhecimento entre os analistas de teste
  • Organização

Desvantagens

Alguns testadores acreditam que padrões são um limitador para que deixar sua criatividade fluir durante os testes e isso pode ser na verdade uma aversão a mudanças. É importante ressaltar pontos positivos na adoção de padrões, e estes não impedem que cada analista de teste escreva seu código ou  implemente algo além do mínimo definido.

Conclusão

Adotar padrões para automação é de suma importância, principalmente quando falamos na temida manutenção. Com um padrão definido para estrutura do teste, a manutenção, que é o “bicho papão” de muitos testadores será menos traumática.

O indicado seria levantar dentro de seu cenário, quais seriam as melhores práticas a seguir, e definir um padrão a ser adotado. Nesse caso, poderia ser aplicado um framework\template de automação.

Para auxiliar nessa tarefa de compartilhar o conhecimento entre os testadores usamos bastante testing dojo como forma de capacitação. Seria uma dica interessante para aplicar no seu projeto.

Por fim, não deixe de definir e disseminar a cultura de usar padrões para automação.

Referências:

[1] https://pt.wikipedia.org/wiki/Padroniza%C3%A7%C3%A3o

[2] http://slideplayer.com.br/slide/46055/

 

Links:

[1] http://www.matera.com/br/2015/07/10/automacao-de-testes-de-software-e-so-record-and-play-sqn/

[2] http://www.matera.com/br/2016/04/13/automacao-de-teste-de-software-parte-1-definicao-de-ferramentas/

[3] http://www.matera.com/br/2016/05/10/automacao-de-teste-de-software-parte-2-definicao-do-ambiente-de-teste/

[4] http://www.matera.com/br/2016/07/29/automacao-de-teste-de-software-parte-3-priorizacao-do-backlog/

[5] http://www.matera.com/br/2015/05/13/aplicando-testing-dojo/

[6] https://www.qfs.de/en/qf-test/test-automation-with-qf-test.html

Por ARIANE FERREIRA IZAC

Analista apaixonada por testes, dançarina, corredora e colecionadora de viagens! Filha de peixe (jornalista) peixinho (blogueira) é. Meu grupo no LinkedIn só poderia ser "Diário de uma paixão: Teste de Software"

Postado em: 31 de agosto de 2016

Confira outros artigos do nosso blog

Testes de Performance – A Estratégia

18 de março de 2019

Ariane Ferreira Izac

Realizando Testes de Carga utilizando autenticação Basic Auth com a Ferramenta Jmeter

24 de janeiro de 2019

Raiany de Araújo Silva

O que foi a trilha Testes no TDC Porto Alegre 2018

28 de dezembro de 2018

Ariane Ferreira Izac

Introdução a Testes de Performance

11 de dezembro de 2018

Ariane Ferreira Izac

Deixe seu comentário