A qualidade está nos detalhes

Artigos

As sete pragas do teste de software – A praga da casa nova


Dois grupos distintos de pessoas encontram bugs com freqüência: os testadores ou as equipes de teste, que são pagos para encontrar tais defeitos, e os usuários que se deparam com eles por acidente. Obviamente os usuários não fazem isso de propósito, mas ao usarem o software para trabalhar (ou socializar, ou divertir-se, etc.) as falhas são ativadas. Com freqüência, isto é resultado de uma combinação mágica entre a interação da aplicação com usuários reais, utilizando dados reais e em um ambiente real. Não é óbvio que os testadores deveriam se esforçar para recriar tais dados e ambientes em seus laboratórios de teste, a fim de encontrar tais defeitos antes que o software seja entregue?

Na verdade, a comunidade de testes vem tentando com afinco e por décadas fazer justamente isso. Eu chamo isso de “trazer o usuário para o laboratório de testes”, seja em corpo ou espírito. Minha própria dissertação de doutorado teve como tópico testes baseados em estatísticas de uso (statistical usage testing). E eu não fui nem de perto o primeiro a ter essa idéia, como mostra minha extensa bibliografia. Contudo existe um limite para o sucesso de tais empreitadas. Testadores simplesmente não conseguem ser usuários reais ou simular suas ações de uma maneira realista o suficiente para encontrar todos os bugs importantes. A menos que você efetivamente viva no software, você irá deixar passar defeitos importantes.

É como adquirir uma casa nova. Não importa quão bem a casa seja construída. Não interessa o quão cuidadosos sejam a construtora e seus subcontratados durante a obra. A casa pode ser inspecionada minuciosamente a cada etapa do processo de construção, pela construtora, pelo proprietário e pelo fiscal do governo. Existem alguns problemas que só serão encontrados uma vez que a casa seja ocupada e por algum tempo. A casa precisa ser usada, é preciso jantar nela, dormir nela, tomar banho nela, cozinhar, farrear, relaxar, enfim, é preciso fazer todas as coisas que os proprietários de uma casa fazem em suas casas. Só quando o filho adolescente tomar um banho de uma hora enquanto a irrigação do jardim está ligada é que se perceberá que o sistema hidráulico é deficiente. Só quando tentarmos estacionar o carro na garagem é que perceberemos uma rebarba na coluna. Os construtores não vão, e com freqüência não conseguem, perceber tais problemas.

O tempo também influi. É preciso alguns meses com lâmpadas queimando, semana sim, semana não, para perceber um curto na fiação. É preciso um ano para que as cabeças dos pregos saiam das paredes secas. Esses são problemas para o proprietário, não para os construtores. Esses problemas são equivalentes aos vazamentos de memória (memory leaks) e perda de dados (data corruptions). É preciso tempo para encontrar estes defeitos.

Estes são alguns defeitos que simplesmente não podem ser encontrados enquanto ninguém more na casa, e com software não é diferente. O software precisa passar por usuários reais, realizando trabalho real, em ambientes reais, para que alguns defeitos apareçam.

A equipe de teste não é proprietária de nenhuma casa. Podemos fazer o que podemos, e nada mais. É importante entendermos nossas limitações e nos planejarmos para o inevitável feedback dos usuários. Fingir que o projeto acaba quando a aplicação é entregue é simplesmente errado. Existe um período de garantia que estamos subestimando e que ainda é parte do processo de teste.

Share Compartilhe esse artigo

Publicado em: 22/10/2009

Autor: Texto traduzido e adaptado de James A. Whittaker

O que fazemos?

Newsletters

Cadastre-se em nosso site para receber nossas novidades em seu e-mail.





©Copyright 2009-2017 - Todos os direitos reservados.