Monday, June 27, 2011

100% de corbertura de código em testes é válido ?


Você deve estar se perguntando o que cobertura de código tem haver com o post anterior no qual prometi dar um exemplo do porque é preciso ter conhecimento de outras áreas da engenharia de software para ser um bom engenheiro de teste. É justamente com a área de codificação que quero mostrar como é importante um engenheiro de teste ter conhecimento de linguagens de programação para tomar decisões importantíssimas em um projeto.

Dias atrás me deparei com a pergunta do título deste post em uma das comunidades de teste que participo e por coincidência no mesmo momento estava estudando a linguagem Python que é uma linguagem bastante usada na web e que possui algumas particularidades bem interessantes e que pude utiliza-la para justificar 100% de cobertura de código com testes pode se tornar válido dependendo do contexto do projeto. Vamos ao exemplo.

Imagine que você esteja para definir o plano de teste de um projeto de desenvolvimento de um sistema web, que tenha uma criticidade média e será desenvolvido em Python apenas com o complilador oficial, sem uso de ferramentas como eclipse, por diversos motivos plausíveis. No plano de teste do projeto, o que você definiria como um critério de saída na fase de teste de componenente ?

Antes de responder esta pergunta, um bom engenheiro de teste deve ter conhecimento mínimo das características da linguagem utilizada. Python apenas verifica os erros de codificação no último momento possível, isto significa em tempo de execução. Python é uma linguagem muito flexível e tem como objetivo de ser muito rápida por isso a mesma, diferentemente de java, não faz quase nenhuma verificação de sintaxe em sua compilação, ou seja, se o programador utilizar uma função que não foi definida previamente, o erro só será descoberto no momento que a instrução de código que utiliza a esta função for executada (o que chamamos de "runtime error").

Um bom engenheiro de teste tendo conhecimento dessa caracteristica da linguagem e sabendo que o sitema tem um criticidade mediana, deveria definir a meta de 100% de cobertura das instruções de código como um critério de saida importante na fase de testes de componentes para que todos o código Python seja exercitado e pelo menos garanta que não existirá nenhum "runtime error" no sistema.


Alguns de vocês podem achar que testes de componentes/unitários são de responsabilidade da equipe de desenvolvimento e que você poderia simplesmente questionar o líder da equipe de desenvolvimento para definir os critérios de saída para a fase de teste de componente. Se prestar atenção você perceberá que está exigindo que este engenheiro de software tenha conhecimento mínimo de teste que teoricamente esta fora do escopo dele. O que também pode acontecer é deste seu colega definir esta meta de 100% de cobertura do código e você não entender tão facilmente a exigência dele e achar que o mesmo está infrigindo justamente um dos princípios mais importantes de teste que é: "Testes exaustivos em impossível" e que 100% de cobertura é um absurdo, quando na verdade o critério de saída que ele está surgerindo faz algum sentido e deve ser levado em consideração.

Resumindo, para que você se destaque como engenheiro de teste será necessário um eforço maior do que dominar todos os conceitos e técnicas de teste. Também não é a toa que umas das mais famosas certificações de teste (ISTQB) na sua versão básica exige o conhecimento das técnicas relacionadas a cobertura de código conhecidas como "statement" e "decision coverage". No próximo post veremos um pouco mais dessas duas técnicas em detalhes.

Espero ter conseguido exemplificar bem o que havia prometido no post anterior e até breve. :)

No comments: