Blog > Defeito ou feature não documentada?

11/jan

Neste artigo fazemos uma revisão do papel e importância do profissional de testes em um time de desenvolvimento de software.

Introdução

Um processo maduro de desenvolvimento exige que sejam realizadas revisões formais a fim de que inconsistências, contradições, omissões e ambigüidades sejam descobertas nos requisitos nas fases iniciais do projeto. No entanto, essas revisões são raramente realizadas, além disso, o time de testes nem sempre participa das atividades de levantamento de requisitos (a fim de criticar, identificar as consistências e garantir a testabilidade dos requisitos).

Dessa forma, muitas vezes os requisitos são finalizados e entregues para os arquitetos de software e analistas de testes sem nenhuma qualidade. Isso quando existem requisitos ou os requisitos estão atualizados. Jogue a primeira pedra que nunca teve que testar uma aplicação sem requisitos, enquanto os requisitos estavam sendo escritos ou com requisitos completamente desatualizados.

Some-se a isso os erros introduzidos pelos desenvolvedores durante o desenvolvimento. Sejam erros de programação, lógica, falta de atenção, ou por ruído. Ruído, neste contexto, é a compreensão incorreta do que deve ser feito e como deve ser feito. Um exemplo clássico de ruído entre significação e significado pode ser observado na figura abaixo. Tente dizer rapidamente o nome da cor da fonte de cada palavra ao invés do nome da cor que está escrito em cada palavra. Você perceberá que apesar do problema estar bem formulado e todas as variáveis claramente definidas, ainda assim, um ruído entre significação e significado criado por um modelo mental seu fará que você cometa alguns erros.

Por fim, para dar sustentação a tese de que o desenvolvimento às vezes é realizado sem um entendimento sólido do que deve ser construído, podemos citar Robert Glass. Robert Glass, no seu famoso livro "Facts and Fallacies of Software Engineering" afirma: "Fato 32 - Pesquisas indicam que quando um desenvolver diz que o código foi completamente testado, normalmente isto significa que apenas cerca de 55% a 60% dos caminhos lógicos do código foram realmente testados. Isso demonstra quão pouco o desenvolvedor entende acerca do código que ele mesmo criou".

Defeito ou feature não documentada?

As features não documentadas indicam algum comportamento da aplicação que foi inserido em função de alguma orientação verbal, mas no entanto, não foi documentada em nenhum requisito. Também podemos citar os casos de acréscimos, ou seja, comportamentos existentes na aplicação não especificados nos requisitos.

A priori, podemos classificar genericamente os defeitos nas seguintes categorias:

  • Omissão: O defeito ocorre em virtude da falta parcial ou total de um requisito;
  • Errado: O defeito ocorre porque o requisito foi implementado incorretamente;
  • Acréscimo: O defeito ocorre em virtude de um comportamento ou elemento não especificado no requisito;

É lugar comum relegar os testes para segundo plano e, normalmente, ao final do projeto. O folclore mais comum é: “O objetivo principal dos testes é apenas encontrar defeitos quando a aplicação estiver pronta”. No entanto, a experiência tem mostrado que essa é uma simplificação de um problema mais complexo. Ou seja, encontrar defeitos na aplicação é apenas uma parte do problema.

Com base no que foi exposto, o grande desafio do testador é reduzir a lacuna entre o que foi especificado, o que foi desenvolvido e o que foi testado. A abordagem para redução dessas lacunas devem seguir as seguintes diretrizes (mas não se limitar somente a elas):

  • O que foi especificado: Esta lacuna é a causa da maioria dos males dos projetos. Os testadores devem se envolver nas atividades de concepção por meio de revisões formais ou outros métodos a fim de detectar precocemente inconsistências, contradições, omissões e ambigüidades nos requisitos;
  • O que foi desenvolvido: Nesta lacuna, devemos reduzir as omissões, os erros e os acréscimos. Com a melhora da qualidade dos requisitos, ocorre conseqüentemente uma redução das omissões. Os erros e acréscimos devem ser reduzidos por meio da utilização de mecanismos para garantir que os desenvolvedores dominem a tecnologia utilizada no projeto (plataforma de desenvolvimento, banco de dados, frameworks, etc) e não insiram ou utilizem componentes, frameworks, ou qualquer coisa de alguma tecnologia emergente por conta própria sem aprovação dos responsáveis pelo projeto (normalmente a utilização do framework XPTO da tecnologia KYZ traz consigo comportamentos novos e inesperados não definidos nos requisitos);
  • O que foi testado: Nesta lacuna, devemos aumentar a amplitude e a profundidade dos testes. Não necessariamente testar mais, mas testar com inteligência para garantir a qualidade do produto final. Com a melhora da qualidade dos requisitos, ocorre conseqüentemente um melhor entendimento dos objetivos dos testes. Dessa forma, é possível aumentar a cobertura dos testes.

Parênteses

P: Por que nem sempre o que foi testado não cobre 100% do que foi especificado (mesmo que tenha sido especificado errado, deveríamos garantir a cobertura)?

R: Porque temos que trabalhar utilizando requisitos ambíguos e incompletos. A omissão ocorre pelas mesmas razões das omissões que ocorrem no desenvolvimento.

P: Por que nem sempre o que foi desenvolvido não foi testado 100%?

R: Três razões: primeira, testador também é gente, em função do ruído, houve um entendimento errado dos objetivos dos testes, logo, não testamos o que deveria ser testado; segunda, muitas vezes é impossível garantir cobertura de todos os caminhos possíveis, logo, 100% de cobertura de testes do que foi desenvolvido é uma meta impossível; terceiro, houve um acréscimo de funcionalidades que foram transmitidas verbalmente pelos analistas para os desenvolvedores, logo, estas funcionalidades não são testadas por puro e simples desconhecimento da sua existência.

P: Mesmo assim tem uns testadores chatos lá na empresa que abusam e testam coisas que não estão nos requisitos. O que devo fazer?

R: [Resposta Longa] Claro, é da natureza dos testadores pensar em situações exóticas não cobertas pelos requisitos. O teste de software é a única atividade do ciclo de vida de desenvolvimento de um software, cujo sucesso depende da falha, do erro, do fracasso. Um ciclo de teste só é bem sucedido quando encontra defeitos; se não forem encontrados defeitos, provavelmente os casos de testes não foram bem projetados ou não está sendo realizada uma boa cobertura dos possíveis cenários de testes. Além disso, é senso comum que os desenvolvedores não pensem criticamente e sigam os requisitos à risca (existem exceções, claro, não podemos generalizar). Por exemplo, um requisito diz que deve existir um cadastro de pessoa na aplicação. Este cadastro é composto pelos campos: Nome e CPF. Provavelmente, o testador encontrará erros do tipo: o campo CPF aceita letras e números, quando o cadastro é salvo sem preencher nenhum dos campos ocorre uma exceção, o campo CPF aceita um CPF inválido, entre outros. SEMPRE, os testadores vão testar mais do que foi especificado, mesmo que as lacunas sejam reduzidas, sempre haverá um meio de encontrar um bug cabeludo escondido no código.

R: [Resposta Curta]: Não faça nada. Eles sabem o que estão fazendo.

POSTS RELACIONADOS

AGENDA

CURSOS RELACIONADOS