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” nós (programadores) testamos o que sabemos que vai funcionar. E quando não funciona, desconfiamos que o teste está errado, e não o código. Afinal, somos geniozinhos espertos e sagazes que nunca erram.
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.
Outra maneira de criar testadores é 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, pois se ele escreveu asserts pobres e o programa continua funcionando, ele precisa pensar em casos de testes mais elaborados.
Lembre-se que testar bem requer experiências, tanto boas quanto ruins.
Neste caso a avaliação seria aplicada em relação ao número de bugs (faltas para os mais puritanos) encontrados e corrigidos.
No semestre passado, participei de uma turma de tutores que avaliou alunos em Programação 1. Lá, o professor (Dalton) estimulava os alunos a escreverem asserts para o próprio programa. O que de fato acontecia era que eles escreviam poucos (e pobres) asserts.
"Encontrar bugs no programa dos outros é bem mais divertido que no seu!"
Eu me baseio nessa idéia. É um estimulo muito grande para o aluno mostrar que o programa que o professor fez quebra pra determinada entrada.
E tem mais!!! Imagine estimular a troca de programas entre os alunos. Equipes escreveriam asserts para o programa de outras equipes.
Alguns vão dizer: "Isso pode inibir os alunos!"
É exatamente essa a idéia. O cara vai pensar: "Ai papai, se eu não testar essa parada direito nego vai cair matando."
Faz sentido?
4 comentários:
Post nerd.
Oi, João.
Acho a idéia legal. Acredito que a essência é mudar a cultura dos alunos para fazê-los parar e pensar nos testes. Tentarei dizer aqui como vejo a idéia que você postou.
Quando o aluno tem que entregar um programa, ele parte para programar e tem como objetivo principal entregar um programa funcionando. Infelizmente, o foco dele passa a ser produzir o código, tentar rodar o programa e entregar. O teste ficou como uma tarefa secundária (e chata) no processo.
Se você colocar o aluno para uma rodada de testes apenas, a tarefa principal (na verdade, única) será testar. Não existe outra coisa a fazer e ele terá que pensar nos testes! Acredito que esse é um dos principais fatores para os testes com essa abordagem terem melhor qualidade.
Outro ponto é quando o aluno testa seu próprio programa. Os testes funcionam simplesmente porque ele escreveu os testes para o que ele pensou quando programava. Assim, acho que os testes do próprio programador tende a pegar poucos erros mesmo; sendo o programador um bom testador ou não.
Colocar outro para testar é um lado bom porque outro tende a pensar diferente do programar. Ah! tem sempre a possibilidade de o outro ser maléfico como você e se sentir estimulado em encontrar erros nos programas dos coleguinhas. (Isso me pareceu ser sua maior motivação...)
Se vocês pretendem colocar isso em funcionamento em P1, vale lembrar que o objetivo é mudar a cultura dos alunos para eles testarem criando um “desenvolvedor mais completo”. Não acho que seja simular um ambiente de desenvolvimento onde as tarefas são divididas e você tenta explorar isso para ter um programa com menos erros.
Cuidado na vida!
Lauro
Concordo... É natural do ser humano achar que a culpa é do outro, por isso dá mais prazer procurar bugs em outras "terras". Além do que quando procuramos bugs em nossas criações sempre, pelo menos pra mim, vou achar que já conheço todo o meu programa e fazendo isto eu estou bloqueando o meu cérebro, dessa maneira ele não vai querer achar nada mesmo!
Uma pequena observação:É uma pena que a cadeira de Testes de Software tenha entrado agora no curso, imaginem só se tivéssemos tido a oportunidade de testar quando estávamos aprendendo a programar, o quanto de experiência que já tínhamos:)
Concordo com grande parte do que foi falado no post.
Sou defensor da idéia de que bons testadores são desenvolvedores, e que os bons desenvolvedores são bons testadores. Acredito que nosso problema não é só colocar os desenvolvedores pra testar, e sim dar uma idéia de como e o que testar.
Uma bibliografia interessante que eu acho são os livros da série "How to break software", que dão alguns cenários e uma visão interessante do ambiente em que o software funciona.
Tenho a impressão de que fazer a pessoa se sentir vigiada não deveria ser algo interessante. O ideal seria a cobrança partir de si mesmo para produzir bons códigos, independente da intenção de quem for utilizar o software produzido.
No mais, gostei do post. E, apesar de achar ruim a idéia de que a pessoa deva se sentir vigiada para produzir bons códigos, acho que faz sentido sim.
Postar um comentário