Resumo:
Erros de Teste Clássicos
Classical Testing Errors
Brian Marick, Testing Foundations
Grupo 5
Christian Reis
Pedro M. S. Eleutério
Ricardo J. M. Ribeiro
Wagner S. Bila
Ramon Chiara
Resumo:
Este artigo[
1] discute erros que são comumente cometidos
ao se testar produtos de software comerciais. O autor separa os erros em
cinco categorias e discute os mais comuns, oferecendo conselho e algumas
soluções.
A questão de elaborar e implementar testes em qualquer projeto de
software é uma tarefa com diversas armadilhas; é muito fácil cometer
erros sérios. O objetivo do artigo é apontar estes erros e oferecer
soluções comuns que podem ser facilmente implementadas.
Os erros relacionados ao problema de se testar software comercial estão
agrupados neste artigo em cinco grupos importantes. Erramos, quando
implementamos processos de teste, nos seguintes pontos:
- No propósito da atividade de teste
- No planejamento dos testes
- No pessoal que contratamos para testar
- Na execução dos testes em si
- Na aplicação da tecnologia aos testes
Estes ítens serão abordados a fundo nas próximas seções.
Os erros apontados nesta seção envolvem não entender bem qual o sentido
de se fazer a atividade de testar, e de não aproveitar os resultados de
forma eficaz. Os erros comuns são:
- Atribuir a responsabilidade pela qualidade unicamente à equipe de
teste
A responsabilidade de qualidade é de todos os envolvidos no projeto em
todas as etapas; não é motivante culpar a equipe de teste pelo resultado
de se auditar a qualidade do produto desenvolvido.
- Achar que a tarefa de equipe de testes é simplesmente
encontrar erros.
A tarefa mais importante da equipe de testes é encontrar os bugs
importantes; o comum, no entanto, é focar na quantidade de bugs e não
na relevância dos erros implicar em riscos importantes para o projeto.
- Não encontrar os erros importantes.
Fundamentalmente importantes são os erros que trazem risco significativo
à viabilidade do projeto com relação ao usuário final -- seja do ponto
de vista de execução do sistema em si, seja do ponto de vista da
usabilidade e aplicabilidade do sistema ao problema do cliente.
- Não informar sobre erros de usabilidade.
Se o teste de usabilidade não informa sobre a qualidade das interfaces
do sistema, e existirem problemas de usabilidade, o produto será visto
como ruim pelo cliente, não importando se é um problema formalizado pelo
teste aplicado ou não.
- Não focar em estimar a qualidade.
Um objetivo importante de fazer teste é estimar a qualidade do produto
sendo criado (e estimar a qualidade desta estimativa). A técnica mais
efetiva para avaliar a qualidade geral é fazer uma análise `em largura'
do produto completo.
- Oferecer estatísticas de erros sem o contexto relevante
A estatística associada ao erro tende a ser analisada de forma muito
otimista se não são oferecidos dados adicionais referentes ao volume de
testes executados e à experiência anteriormente obtida; estes dados
podem dar um parecer mais realista da situação na qual o projeto se
encontra.
- Começar a testar tarde demais
Se os testes são preparados e executados em todas as fases do projeto
-- começando antes da implementação em si -- a chance de se encontrar
erros de especificação em uma etapa inicial é muito maior.
Estes erros são relacionados à fase de planejamento dos testes que serão
executados:
Ao se escolher a equipe que conduzirá os testes, é importante se
concentrar nos seguintes erros comuns:
- Usar o teste como um trabalho temporário para
programadores novos
Testar requer prática e experiência; programadores novos têm desejo de
sair logo da área de teste para uma área de maior visibilidade: o
desenvolvimento.
- Recrutar ex-programadores (ruins) para a equipe de teste
Maus programadores muitas vezes têm hábitos ruins - falta de atenção,
desorganização - que os levarão a ser maus testadores.
- Usar testadores que não conhecem o domínio da
aplicação
Muitas vezes, o testador não conhece a fundo o domínio do problema, e os
problemas que serão encontrados por ele serão menos relevantes que os
problemas encontrados por um usuário experiente.
- Não contratar pessoal do suporte técnico e
documentação
O pessoal destes departamentos tem experiência em contato com os
problemas do usuário, e sabem em geral o que é importante, o que é
confuso, e o que é difícil de explicar -- aspectos que estão
intimamente ligados ao surgimento de problemas importantes.
- Insistir que testadores sejam programadores
O bom testador não necessariamente é um programador, e uma equipe de
testadores que é composta unicamente de programadores tem o problema de
baixa diversidade, o que leva ao problema seguinte.
- Não utilizar uma equipe de teste diversificada
Uma equipe de testes pouco variada tende a encontrar bugs concentrados
em áreas específicas. O objetivo do teste é encontrar problemas de forma
ampla, e não em profundidade.
- Separar fisicamente testadores e programadores
Uma relação de trabalho boa e eficiente é importante se queremos obter o
máximo proveito da equipe de teste; muito do trabalho será depuração
feita em conjunto, que é muito complicada quando se separam as equipes
envolvidas.
- Acreditar que programadores não podem testar seu próprio
código
Em efeito, programadores testam o seu código todo o tempo, e encontram
muitos problemas. No entanto, encontram problemas de tipo bem
selecionado, e a ação conjunto do teste de programadores com uma equipe
de teste variada tende a ser a mais eficiente.
- Não treinar e nem motivar os programadores para testar
Até que se valorize o teste feito por desenvolvedores, a equipe de teste
terá que concentrar-se em executar os testes que os desenvolvedores
fazem e os testes que só a equipe de teste tem capacidade de
executar.
Durante a execução dos testes, um conjunto de problemas comuns é:
- Dar mais atenção à execução dos testes do que ao seu
projeto
Um testador que não é sistemático e não planeja o seu teste deixará de
encontrar erros importantes, e não observará casos especiais.
- Não rever os projetos de teste
Assim como programadores, testadores podem se beneficiar de análise
conjunta do projeto dos testes. Testar em isolamento é uma técnica pouco
eficiente de se conduzir a avaliação de qualidade.
- Ser específico demais nas entradas e procedimentos do
teste
Embora o teste deva conter uma descrição da configuração, entradas e
saídas esperadas, ser muito específico na descrição dos passos a ser
tomados torna a manutenção do teste mais cara, a sua elaboração mais
complexa, e reduz a chance de se encontrar um problema associado à
atividade mas não exatamente dentro do caso analisado.
- Não notar e nem explorar irregularidades peculiares
Muitas vezes, irregularidades são esquecidas como irrelevantes, enquanto
a verdade é que freqüentemente são fontes de problemas. Um bom teste
utiliza os casos de teste como um ponto de partida para uma exploração
do produto.
- Checar que o produto faz o que deve, mas não verificar se
ele não faz o que não deve
O teste deve, além de focar na execução correta da ação, verificar se
nada mais foi alterado além do estritamente desejado. Este ponto é
muitas vezes esquecido durante a execução dos testes.
- Elaborar suítes de teste compreendidas apenas por seus
criadores
Se os testes são muito particulares, grande custo é implicado na saída
de seus desenvolvedores, e alto custo de sua manutenção ocorre como
conseqüência.
- Testar apenas através da interface com o usuário
É uma boa técnica oferecer uma interface associada específica para executar
os testes, porque muitos problemas não são encontrados diretamente
através da interface com o usuário.
- Informar problemas incompleta ou ineficientemente
Encontrar os problemas é uma das metades do trabalho da equipe de teste.
Informar os testes é muito importante, mas muitas vezes não há
informação de como reproduzir o erro, do que exatamente ocorreu de
errado, do nível de prioridade do erro, e se oferece pouco apoio para
fazer a depuração em si.
- Adicionar apenas testes de regressão quando problemas são
encontrados
Problemas tendem a se concentrar em áreas do produto; problemas
encontrados em uma área determinada do produto implicam na necessidade
de se fazer uma análise mais profunda daquela região, e não apenas em
acrescentar à regressão.
- Não manter um histórico de anotações para os próximos
testes
Os produtos criados por uma empresa em geral tem grande semelhança entre
si, e os problemas serão muitas vezes parecidos. Manter anotações a
respeito dos problemas encontrados em um produto serve como base
importante para análises futuras.
A aplicação de tecnologia à atividade de teste é muitas vezes benéfica,
mas nem sempre, e nunca desenfreadamente. Os erros seguintes envolvem o
foco tecnológico do teste:
- Tentar automatizar todos os testes
Automatizar os testes, embora possa a longo prazo reduzir o custo total
do teste, tem aplicação específica. Muitas vezes, um teste não justifica
o esforço requerido na sua automação.
- Esperar re-executar testes manuais
Se a maior parte dos testes terá de ser re-executado manualmente, o
tempo gasto no seu desenvolvimento e documentação será desperdiçado.
- Usar ferramentas de automação de interface para reduzir o
custo do teste
Como mudanças de interface são comuns, e há grande uso de widgets
customizados, é difícil aplicar testes de interface automatizados, e há
custo alto na sua implementação. Usar scripts para testar a interface é
uma alternativa interessante que pode ser utilizada de forma mais
proveitosa.
- Esperar que testes de regressão encontrem uma grande
proporção dos defeitos introduzidos
Embora os testes de regressão capturem problemas em partes já existentes
do software causados por mudanças no sistema, a maior parte dos
problemas estão justamente relacionados à funcionalidade nova criada em
si, o que terá de ser analisada em novos testes.
- Abraçar exageradamente a análise de cobertura do código
A análise de cobertura de código é uma observação de quanto do código
está coberto por casos de teste. No entanto, problemas múltiplos podem
acontecer em uma única linha do programa, e dependem de como é
executado aquela parte do código. Apoiar-se apenas em cobertura do
código, portanto, não oferecerá uma análise de qualidade sólida.
- Remover testes da suíte de testes de regressão porque não
aumentam a cobertura
Testes de regressão não têm como objetivo cobrir todo o código, e sim
observar se mudanças no software implicaram na introdução de erros.
Removê-los indiscriminadamente significará reduzir o poder da suíte de
teste.
- Usar cobertura como um objetivo primário para a equipe de
teste
Usar a cobertura para avaliar a equipe é uma forma numericamente simples
de se verificar a sua performance. O problema com avaliar a equipe de
teste através da cobertura é que a equipe passa a se focar neste
objetivo, e não no objetivo real da tarefa. Como a cobertura não é uma
avaliação real da qualidade do software, não pode ser usada para avaliar
a performance da equipe.
- Não analisar a cobertura de código em absoluto
Tendo dito tudo isso, a análise da cobertura oferece uma análise simples
da avaliação do código, e, embora frustrante se utilizada como a
ferramenta única de qualidade, oferece uma base importante o suficiente
para não ser abandonado por completo.
- 1
-
Brian Marick, Classic Testing Mistakes, 1997.
Christian Reis
2000-08-15