Tags:

Automação de Teste de Software – Parte 2- Definição do Ambiente de Teste

Na primeira postagem de dicas passadas sobre as diretrizes para automação de testes de software, baseadas na postagem no artigo Automação de Testes de Software é só record and play #SQN, foi abordado o tema Definição de Ferramentas. Dando sequência a essa série de postagens, após ter escolhido as ferramentas de automação e de integração contínua, o próximo passo abordado será:

2. Definição de ambiente de teste

Quando falamos em teste de software, tanto para automático quanto manual um ponto bem importante a ser considerado e que demanda boa parte de nosso tempo é a configuração do ambiente de teste. Não me refiro somente a parte de infra-estrutura, relacionadas a configurações de hardware, que não deixam de ser importantes, mas existem outras questões relacionadas a configuração da base de dados também. Os testes deverão ser arquitetados de forma que não fiquem acoplados em nenhuma base, com intuito que funcionem de forma independente. Dessa forma, evitará quebras desnecessárias quando executar os testes em uma base de dados diferente, evitando “falsos negativos”.

Mas vamos por partes, se achar necessário faça um checklist para garantir que não está esquecendo de nenhum item:

  • Levantar os requisitos mínimos de hardware do servidor como Processadores, Memória;
  • Levantar os requisitos mínimos de software do servidor como o Sistema Operacional, configuração de variáveis de ambiente;
  • Levantar os requisitos mínimos de rede que deverão ser configurados no servidor;
  • Levantar as ferramentas necessárias para executar a aplicação e principalmente as versões corretas das ferramentas que deverão ser instaladas para homologação;
  • Levantar as ferramentas necessárias relacionadas as atividades de teste, ferramenta de automação, integração contínua, facilitadora para análise de diagnóstico (logs), lembrar das versões para homologação também;
  • Levantar configurações do banco de dados, versão, analisar massa de dados necessária para execução do teste (esse item pode estar relacionado mais com arquitetura, mas não deixa de ser uma preparação do ambiente de teste para que a execução dos testes automáticos sejam realizados corretamente);

Em resumo, o que diz respeito a hardware é preciso levantar as configurações mínimas para executar a aplicação e a ferramenta de automação, se atentar as versões e já definir uma politica de atualização para garantir que sempre manterá o ambiente atualizado com a versão que deverá ser homologada.

Ambientes de teste [3]
Ambientes de Teste [3]

Com relação a esse ponto, na MATERA trabalhamos com máquinas virtuais, e mantemos uma base de dados matriz onde uma equipe fica responsável por se atentar a questões de atualização de versão do banco de dados para garantir que sempre validamos na versão correta e a atualização das versões da aplicação fica como responsabilidade dos testadores, essa é uma ideia de política adotada para pensar nessa questão.

Quanto aos dados que serão usados no teste o recomendado sempre é cadastrá-los antes do teste ser executado, via script ou através da aplicação. Dessa forma, garantirá que o teste não está acoplado a base de dados, trabalhará de forma independente e poderá evitar quebras desnecessárias e muitas vezes são difíceis de identificar a origem. Entraremos em mais detalhes a respeito quando comentarmos sobre manutenção dos testes automáticos.

Estamos adiantando um pouco outra ponta mas uma abordagem para contornar essa questão seria criar um “test case” para Configuração. Se para realizar o teste da “funcionalidade X” preciso  configurar tais parâmetros,  realizar determinados cadastros antes de iniciar o teste, será definido isso no início para que o teste seja executado com a configuração correta.

O que pode acontecer é que você como testador não terá conhecimento de tudo que foi descrito acima, calma. Não se desespere, já sinalize a necessidade do envolvimento de outras áreas nesse trabalho em um primeiro momento na formação desse ambiente de teste.

O importante é ter tudo bem definido, se for necessário pesquise mais informações de cada assunto em fóruns, com profissionais que já trabalham com aquilo. Lembre-se de sempre pesar o custo x benefício.

Conclusão

Ambiente de teste é algo que conviverá diariamente na automação, é por isso que ressaltamos a importância de sua definição e manutenção (principalmente com relação a mantê-lo sempre atualizado, em paralelo já crie políticas para isso). A ideia é que ele não seja o vilão da história, construa de forma que seja seu parceiro e provavelmente evitará muitos problemas que são originados por falta de estruturação\configuração de ambiente de teste.

Referências:

[1] http://www.devmedia.com.br/automacao-de-teste-de-software-com-qf-test/33424

[2] https://www.youtube.com/watch?time_continue=3&v=VbV_wMb9byA

[3] http://testwarequality.blogspot.com.br/p/ambientes-de-testes.html

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/ 

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: 10 de maio de 2016

Confira outros artigos do nosso blog

Matera participa da 9ª edição do meetup DevTests Campinas

03 de setembro de 2018

Ariane Ferreira Izac

Teste de mutação com PITest

24 de agosto de 2018

Julio Cesar Consolini

Introdução ao Dev-Test Pairing

13 de junho de 2018

Caio Rizolli

Falando sobre Teste de Intrusão (ou PenTest)

03 de abril de 2018

Jacqueline Costa

Deixe seu comentário