Pare já de chorar e comece a testar! - Blog 4ALL Tests
Carregando:

Pare já de chorar e comece a testar!

Pare já de chorar e comece a testar!

Pare já de chorar e comece a testar!

Autor: Júlio de Lima (iam@juliodelima.com.br)

Especialista em teste de software com ênfase em automação de testes de software, possui formação em Tecnologia da Informação e certificações internacionais (CTFL e CTAL-TM pelo ISTQB) e nacional (CBTS pela ALATS) relacionada a testes de software além de ser certificado na ferramenta SoapUI Pro pela SmartBear Software. Atualmente é consultor de automação de testes e instrutor na Qualister. É professor do curso de pós-graduação em Qualidade de Software na Uniasselvi (Blumenau, SC). Trabalhou, entre outros, em projetos de teste em Cloud Computing na UOL, em ferramentas de negociação do mercado de ações (MegaBolsa e E-PUMA) na BM&FBovespa;, em projetos de telecomunicações na Vivo via Aitec do Brasil e em softwares de gestão pública no Assessor Público. É grande entusiasta da disciplina de testes de software e práticas ágeis.

Introdução

O princípio das atividades de muitas empresas de desenvolvimentos de sistemas deu-se em um momento em que o importante era criar um sistema e entrega-lo ao cliente o quanto antes, de modo a atender suas necessidades. O foco era apenas a criação do sistema, que fosse útil ao cliente e seguisse o que o mesmo havia solicitado e em um curto espaço de tempo. O resultado disto foi uma total despreocupação quanto a ação de documentar a especificação do sistema. Por isso, hoje, uma grande parcela das empresas de desenvolvimento de sistemas não possui especificação formal (casos de uso, diagramas, etc) e atualizada de seus produtos.

Especificação e os testes

Algumas fontes levam os testadores a acreditar, erroneamente, que o bom teste é apenas aquele que é projetado baseando-se em especificações formais. Uma vez que as empresas não possuem estas especificações, muitos testadores gastam parte do seu tempo reclamando e exigindo que haja documentação, o que seria o mundo perfeito, um objetivo que para muitas organizações talvez nunca seja alcançado, por diversos motivos: Pressão no prazo, falta de recursos financeiros, escassez de profissionais que executam este trabalho, etc. Para muitos, este é um fator desmotivador, que gera porfias e discussões, e pior, desperdício de tempo e esforço que poderia ser dedicado testando. Por isso, faz-se necessário parar de chorar e começar a testar com base em outros oráculos, ao invés de perder tempo lutando com um dos maiores débitos tecnológicos do mercado de desenvolvimento de sistemas.

Oráculos de teste

Segundo Rex Black e Jamie Mitchell, em seu livro Advanced Software Testing Vol. 3 "Oráculos de teste são fontes que utilizamos para determinar os resultados esperados de um teste". Estas fontes não são necessariamente especificações formais, elas podem ser qualquer fonte confiável, que nos diz qual é o resultado esperado para uma determinada ação executada no sistema como Documentos relacionados à utilização da aplicação, Manual do produto, Bases de conhecimento, Outros softwares, Modelos e diagramas, etc. Um outro tipo de oráculo poderia ser pessoas que estão envolvidas no ciclo de desenvolvimento, e que possuem o conhecimento de como o produto deve comportar-se:

  • Analistas de negócio
  • Especialistas
  • Clientes
  • Desenvolvedores

Técnicas

A extração das informações destes oráculos pode ser uma tarefa um tanto quanto complexa, mas que, quando executada de maneira estruturada, pode ser mais simples e intuitiva. Vemos a seguir algumas técnicas que podem auxiliar na tarefa de extração de conhecimento destes oráculos.

Entrevistas

Consiste em elaborar perguntas ao oráculo, com o objetivo de conhecer qual é o comportamento esperado da aplicação. É necessário atentar-se a formular bem as perguntas e tentar explorar ao máximo todos os pontos intrínsecos, vagos ou ambíguos. Caso contrário os resultados poderão ser insatisfatórios.

Exemplo:

  • Clientes que nunca compraram participarão da promoção de fim de ano?
  • Qual é a regra de descontos para os tipos de clientes Física e Jurídica?
  • Quando o cliente esquece sua senha, como ele a obtém novamente? Via e-mail, criando uma nova senha, através do CPF?

Check-lists

É um grupo de características comuns que devem ser levantadas durante a extração das informações de um oráculo. Serve como um guia, com perguntas genéricas, que ajuda a revelar o comportamento esperado da aplicação.

Exemplo:

  • Quais são as mensagens de erro e sucesso;
  • Quais são as relações entre o módulo atual e os demais;
  • Os dados são salvos ao sair do campo ou ao submeter o formulário.

Brainstorms

São reuniões que envolvem diversos oráculos, que possuem o conhecimento sobre qual é o comportamento esperado do sistema. Utilizada para levantar o maior número possível de informações relacionadas ao comportamento de uma aplicação.

  • Oráculo 1 diz "CPF deve ser validado junto a receita federal";
  • Oráculo 2 diz "Não devem existir clientes com o mesmo CPF";
  • Oráculo 3 diz "Menores de 18 não podem se cadastrar e comprar".

Mapas mentais

Técnica utilizada para identificar o comportamento de uma aplicação visualmente de maneira incremental através do relacionamento entre funcionalidades e comportamentos.

Exemplo:

O acompanhamento dos oráculos para a validação das informações obtidas utilizando estas técnicas é algo que pode ajudar a evitar problemas como inconsistências e falso entendimento.

A escolha da técnica

A escolha da técnica pode ser influenciada por alguns fatores como:

  • Complexidade do módulo: Quando alta, podemos utilizar entrevistas e mapas mentais;
  • Maturidade da equipe: Quando baixa, podemos utilizar Check-lists para evitar que informações importantes deixem de ser abordadas;
  • Prazo para extração dos dados: Quando baixo, podemos utilizar BrainStorms para obter a maior quantidade de informações em um curto espaço de tempo.

Gerenciando o conhecimento obtido

A criação de uma base de conhecimento, onde as informações que foram extraídas dos oráculos podem ser armazenadas e compartilhadas com toda a equipe pode ser considerada uma excelente forma de gerenciar o conhecimento obtido a partir dos oráculos. Uma ferramenta muito utilizada para este fim são as Wikis, onde o conhecimento pode ser compartilhado e toda a equipe pode contribuir, aumentando a riqueza do conhecimento e diminuindo a probabilidade de informações errôneas, tornando este, um oráculo muito confiável, que acaba tornando-se útil a outras áreas como Desenvolvimento, Análise de Negócios, Arquitetura, UX, etc.

Projetando os testes

Uma vez que conhecemos o comportamento e os resultados esperados para determinadas ações, já podemos iniciar projeto e criação dos testes. As condições e casos de teste são derivados a partir das informações que foram coletadas dos oráculos e podem ser priorizadas, de modo a testar as características mais importantes primeiro. A abordagem de utilização de oráculos para projetar testes é muito utilizada em equipes que seguem metodologias Ágeis.

Heurísticas

Algumas práticas podem auxiliar o testador a conseguir elencar condições de teste. Segundo Cristiano Caetano em seu artigo Testes Exploratórios (Parte 1): Introdução a utilização de heurísticas, que são atalhos mentais propostos por testadores experientes, ajuda os testadores a levantar condições de teste para determinadas características de um software. Os atalhos mentais geralmente são organizados em uma estrutura mnemônica, ou seja, utilizando-se da primeira letra de cada atalho mental utilizado pelo testador. Vemos abaixo uma heurística chamada "San Francisco Depot", proposta por James Bach, em seu artigo "How Do You Spell Testing?":

  • (S)tructure (O que o produto é): Que arquivos ele usa? Como ele foi construído? São vários ou um único programa? Que tipo de material físico é distribuído com o produto? É possível testar módulo por módulo?;
  • (F)unction (O que o produto faz): Quais são as suas funcionalidades? Que tipo de tratamento de erro o produto realiza? Que tipo de interface ele possui? O produto realiza algum processamento invisível para o usuário? Como o produto se comunica com o sistema operacional?;
  • (D)ata (Quais dados o produto processa): Que tipo de entrada de dados o produto processa? Como é a saída produzida pelo produto? Quais tipos de status o produto pode estar? O produto é distribuído com algum tipo de pré-configuração?;
  • (P)latform (Qual plataforma o produto depende): Qual sistema operacional o produto é compatível? O ambiente e infra-estrutura precisa de alguma configuração especial? O produto depende de algum componente de terceiros?;
  • (O)perations (Como o produto será usado): Quem vai usar o produto? Onde e como o produto será usado? Para que o produto é usado? Existem funções que os usuários usarão com maior freqüência? Existe alguma forma de obter os dados reais do usuário para a criação de testes mais realísticos?.

Existem diversas outras heurísticas proposta por outros especialistas, e claro, podem ser encontradas gratuitamente na internet. Outra possibilidade é criar nossa própria heurística, baseado nos nossos atalhos mentais, você pode criar isto analisando como você projeto seus testes hoje, basta elencar quais são as características você analisa antes de começar a testar.

Conclusão

Como testadores, devemos lidar com as dificuldades provenientes do débito tecnológico relacionado a documentação dos softwares que testamos. Utilizar técnicas pode tornar mais simples e organizada a extração do conhecimento contido nos oráculos de teste. Uma vez que conhecemos quais são os resultados esperados para determinadas ações executadas na aplicação podemos projetar e criar os testes.

Agradeço aos amigos testadores e desenvolvedores que contribuiram dando feedback sobre este post: Cristiano Caetano, Marina Scocuglia, Otniel Mata e Rafael Sousa.


Compartilhe :
   
Tags :
QA   Conceitos  

Aprendendo Testar

Site criado para mostrar o caminho das pedras para novos na área de Testes de Software