No final do mês de agosto fui convidado a ministrar um tutorial sobre teste de software. Antes iniciar efetivamente o bate papo com a equipe de desenvolvimento, convidei todos os presentes a sair do auditório e retornar para o ambiente de produção. Solicitei a cada um dos participantes o desenvolvimento de uma interface para receber, via teclado, os dados de uma pessoa, por exemplo: código, nome, rua, número, bairro, idade e CPF. Além de receber as informações o programa deveria armazená-las em um banco de dados. Enfatizei, TESTEM O PRODUTO ANTES DE ENTREGAR PARA O CLIENTE.
Terminado as atividades de programação e do “suposto teste”, todos me garantiram que os programas estavam corretos. Então solicitei que fossem testados os seguintes casos: 1 – Entre com zero para código. 2 – Entre com um número negativo para o código. 3 – Digite branco para o nome. 4 – Digite zero para idade. 5 – Digite um número negativo para idade. 6 – Digite a letra A para idade. 7 – Digite um CPF inválido.
É perceptível que de acordo com os casos solicitados, as validações dos campos deveriam ser efetuadas. Foi justamente isto que NÃO aconteceu. Veja só os resultados quantitativos da experiência: 9 programadores. 9 programas sendo desenvolvido. 7 casos de testes solicitados, totalizando assim 63 testes efetuados. Percentual de erros encontrados detectados: 74% (47 erros). Média de erros por programadores neste programa: 5,22. Lembre-se que o programa era apenas para armazenar os dados de uma pessoa em uma tabela (poderia ser pior).
No início de setembro desenvolvi a mesma experiência com os alunos recém matriculados na disciplina de Sistemas e Tecnologias da Informação III da Faculdade de Tecnologia de Ourinhos (alunos do sexto semestre do curso). Infelizmente, neste ambiente o percentual de erros detectado foi de 97%. A partir deste dado iniciei uma discussão sobre teste de software.
Ao analisar os números é perceptível que tanto os alunos, como os profissionais participantes da experiência, procuram testar somente os casos que possuem grande possibilidade de acerto. A maioria deles digitam 1 para o código, Pedro Álvares Cabral para o nome, 25 para a idade e assim por diante. Após digitar alguns registros todos julgam que o programa está testado.
A atividade de teste, assim como todas as outras, é de extrema importância para a qualidade do nosso software. É uma atividade que deve ser explorada, formalmente, desde as disciplinas introdutórias dos cursos de computação. É somente com a definição e o aculturamento dos conceitos de processo de produção por parte do mercado e, principalmente, dos alunos chegaremos a algum lugar no contexto produtivo para software. Lembrando: o teste faz parte do processo.
Por fim, convido você a realizar esta experiência em sua empresa ou com seus alunos. Será que nós sabemos testar um software?
José Augusto Fabri
Engenharia de Software 
Acredito que a construção de códigos legíveis e o teste de código deva ser inserido em disciplinas introdutórias de algoritmos.
O grande problema são os famosos testes que não seguem nenhum critério ou técnica, que não são automatizados e que por fim não garantem que o software está pronto para ser utilizado pelo cliente.
Neste ponto cabe aos professores ensinarem de forma prática como utilizar ferramentas de teste e principalmente como criar um bom conjunto de casos de teste.
Infelizmente o topico de testes passa batido algumas vezes ou de forma muito resumida em disciplinas de engenharia de software.
Nào só concordo que o resultado do experimento será parecido se eu for realizá-lo na minha empresa, como sinto falta, aqui no Brasil, de um curso de Testes de software. Temos alguns (poucos) de processo de testes, certificação, mas de fato, nenhum deles ensina a testar.
De fato, a atividade de Teste de SW reune um sem-numero de carências, como processos efetivos, métodos, ferramentas, ambiente de treinamentos (e prática), etc etc… e respostas à questões do tipo “como” e “quando” testar, que ainda são indagações, sem dúvidas, de difícil resposta. Talvez a idéia de Melissa (comentário anterior) de criar ambientes de ensino de Testes na academia (brasileira!) possa beneficiar a indústria, de forma a se desenvolver sistemas mais robustos, com uma maior qualidade, dentre outros aspectos benéficos concernentes a tal atividade. E, claro, sem esquecer da relação academiaXindustria, em que a academia pesquisa “aquilo” que o mercado precisa, bem como pode pensar “passo-a-frente” das necessidades correntes do mercado! Desta forma, pode-se haver uma efetividade no processo! E o ganhaxganha é notório!
Os requisitos nao deveriam ter especificado exatamente quais os tipos esperados dos dados?
talvez seja esse o truque da ‘brincadeira’… mas nao seria de esperar que os testes fossem mal feitos por que os requisitos nao sao lah grande coisa?
(ou seja… deixam coisas “importante” ao arbitrio de quem programa e depois de quem testa)
Guto,
Antes de mais nada, boa tarde.
Bom, lendo seu texto e os comentários abaixo, preciso mencionar algumas coisas.
Com relação aos requisitos, acho estranho as pessoas acharem que tem que estar escrito para que elas façam.
Alguns problemas de desenvolvimento poderiam antes de mais nada serem resolvidos com bom senso, mas isso falta em muitos profissionais, pelo simples fato de estarem ancorados em Casos de Uso (arghhh !), diga-se de passagem, odeio esse termo.
Com relação a testes, basta que pratiquemos um pouco de TDD, acho que já resolveria bastante esse tipo de dor de cabeça.
Até entendo que testar é uma questão de cultura, e que algumas Fábricas de Softwares (olha outro termo totalmente furado) não querem testar e até mesmo dispendem de pouco tempo pra esse quesito por acharem que isso leva tempo e também pelo fato de que se as fábricas testassem o que entregam dificilmente ganhariam dinheiro.
Com certeza nenhum software é desenvolvido sem erros, mas tenho tido contato com softwares construídos e testados baseados em seu comportamento e isso tem diminuído a margem de erros a uma fração tolerante (não que erros sejam tolerantes), mas dado o cenário atual, acho que estamos em um nível aceitável.
Acho que ler e se utilizar do conceito do TDD torna tudo mais fácil e tranquilo de se manter.
Abraços.
Na minha sala (tecnico em informática 2º semestre) o mesmo teste foi feito pelo profº guto, conseguimos 93% de erro.
Oi Professor, tudo bom? Gostei do post e tenho alguns comentários.
Uma observação a ser feita é: Embora os alunos tenham testado o código que eles produziram, ainda sim a quantidade de erros foi alta .
A questão é que “normalmente” testamos (programadores) o que sabemos que vai funcionar. E quando não funciona, desconfiamos que o teste está errado.
O que pode amenizar esse cenário é TDD. Mas TDD no sentido puro, ou seja, construir testes antes de programar. Seguir o fluxo: red bar, green bar, refactoring.
Uma maneira de estimular isso em sala de aula é inverter a ordem, isto é, o programa que resolve o problema é fornecido (com alguns bugs escondidos) e os alunos devem fornecer asserts em que o programa deve ser submetido. Um espécie de “caça aos bugs”.
Isto deve estimular os programadores a pensarem em casos extremos como identificadores menores que zero, nomes vazios etc.
Lembre-se que testar bem requer experiência, tanto boas quanto ruins.
abraços
Boa tarde Guto,
tudo bom..
As vezes tenho acompanhado seus posts.. e esse foi bem interessante, muitos de nós programadores ficamos bitolados e só testamos oq achamos que vai funcionar pois já sabemos q isso funciona, na minha formação não tivemos esse tipo de observação, acredito que muito que somos hoje a nossa base academica também tem uma grande porcentagem… sei que quem faz a faculdade é o Aluno, mas os professores influenciam e muito… cada vez que leio suas matérias vejo que cresceu muito desde quando deu aula pra mim… e que os erros cometidos no passado não estão sendo hoje…
Aprendi muito na “porrada” pois a sala de aula “na minha época” nao pegava no pé… erramos muito por nao saber testar… e hoje trabalhando numa consutoria de nome sei q isso é mais q preciso… pra evitar reclamações do cliente essas coisas…
grande abraços Guto, e tenho aprendido algo com seus comentários
fica com Deus
Elias Lima
A definição do documento de requisitos, que fornece informações de como deve ser a funcionalidade é indispensável, para quem nunca viu falar, lá descreve os limites para cada campo, mascara(caracter aceito no campo) e definição da evolução das ações e resultados esperados, gostaria de saber se foi usado este documento de requisitos para este teste, se foi, concordo que o nível foi baixo.
Alex, questões relacionadas a limite para cada campo, mascaras (caracter aceito no campo) não foram delineadas no documento de requisitos. Porém acredito que algumas ações relacionadas a consistência na área de programação devem estar implicitas em qualquer projeto. Por exemplo: Ao ler um campo como sexo, todos nós programadores, devemos validá-lo… Esta ação também é válida para leitura do CPF…