Opa, olá. Primeiro gostaria de parabenizar pelo Artigo. Ficou muito bom!!! Um ponto citado e muito importante, é essa briga(também pode ser levada no sentido literal), entre equipes de desenvolvedores e teste. Geralmente os desenvolvedores não concordam com os erros encontrados.... Enfim. Um detalhe que poderia ser adicionada é a remuneração. Infelizmente no Brasil, até mesmo o profissional certificado não ganha tão bem. Fora, ele ganha bem, muito bem.
Ah, ia me esquecendo, discordo num ponto : "Os testes não devem ser feitos pelo desenvolvedor". Acredito que estes devem fazer testes sim, de suas unidades criadas. E além disso, passar por uma bateria de testes por uma equipe especializada nesta tarefa.

Abraços

Realmente... o que tiver de dar errado, na hora em que tiver que dar errado, vai dar errado... a Lei de Murphy está aí para aterrorizar a vida de nós desenvolvedores.

Assim como o amigo acima, também discordo com o "Os testes não devem ser feitos pelo desenvolvedor". Aqueles erros que provavelmente seriam os mais comuns podem ser evitados pelo programador se ele testar seu programa à medida em que o desenvolve.

Bem verdade, porém, que há erros que são percebidos somente por quem usa o programa. Então a fase de testes com certeza não deve ser dispensada e deve ser realizada por uma equipe diferente da de desenvolvimento. Até porque como os programadores já sabem como fazer as coisas no software não tentam caminhos diferentes para se chegar ao mesmo objetivo e muitas vezes aí está o erro. Nesse ponto, eu concordo com você (na verdade, então, quanto àquela frase, eu discordei apenas em parte).

Só acrescentando algo: os testes podem ser usados não somente para verificar se o programa está funcionando bem, como também se melhorias podem ser feitas neles para torná-los mais fáceis de usar. São os testes de usabilidade. Já tive oportunidade de fazer um teste desses no curso técnico e é bastante interessante.

Mas parabéns pelo artigo, está excelente, realmente muito interessante.

Um abraço.

Muito bom o artigo, parabéns.

Obrigado Pelo auxilio!

Espero seus próximos Artigos. Este ficou muito bom.

Excelente artigo!

Meus parabéns!

Realmente é impossível fugir da lei de Murphy, o que podemos fazer com esses testes exaustivos é diminuir as suas conseqüências, ok, muito bom artigo, parabéns !!!

No tocante a testes feitos pelo próprio desenvolvedor, não há como evitar isso de uma forma absoluta.
Quem programa tem sempre que dar uma peneirada primeiro.

Quando eu fazinha joguinhos, pedia pera meu sobriho (na época com 8 anos de idade) para testar.
Qualquer sombra de erro era assim facilmente (?) detectável, pois criança consegue dar pau em qualquer coisa (afinal, o próprio Murphy já foi criança)...
Mas com programas comerciais, sérios, não há essa chance toda.
Principalmente desenvolvedores free lancers raramente conseguem a ajuda de alguém que tenha paciência de testar exaustivamente algum aplicativo. E alguns erros serão descobertos até alguns meses depois, o que é bastante ruim para a imagem do desenvolvedor.

Existem erros inexplicáveis que até mesmo não valem a pena serem procurados, pois será uma enorme perda de tempo.
Já vi um programa de Caixa em PAL (do Paradox) que funcionava muito bem, mas com um pequeno senão: No mês de novembro (?) ele simplesmente duplicava TODOS os lançamentos.
A solução mais rápida (e também a mais picareta) foi fazer um "bacalhau" que varria os bancos de dados em busca de duplicidades.
Funcionou assim por 4 anos (!!!!), e foi feito outro programa "à prova de novembros".
Certo é que até hoje ninguém descobriu o fenômeno espiritista que dobrava sistematicamente os lançamentos.

Certos erros são devidos ao excesso de certeza de que temos de que o código está "certinho": Já vi editores de texto apresentarem anomalias tais que um código copiado e colado sofre alguma corrupção, fazendo com que uma rotina que deveria funcionar "igualzinho" a outra possa simplesmente tirar o programa do ar...

Em desenvolvimento web, então, é um tanto comum acontecer por exemplo uma linha com
<div id=nome_da_divisao
e aí não funciona de jeito nehum pois esta fatando o ">" que fecharia a tag.
Ou então, um teclado de qualidade inferior pode fazer com que fique <div i=nome_a_ivisao> ou qualquer coisa assim.

Nas linguagens onde se pode fechar os loops mas provê-los de uma saída alternativa ("o pulo do gato") é bom testá-los à medida em que se vai escrevendo o código.
Isso é chato, mas a quantidade de erros a depurar no final será algo próximo de zero.

Agora, cometer erros em programas grandes escritos em Pascal é dose pra leão.

No Cobol, para melhor depurar, temos de impimir o código, e para isso precisamos de uma impressora onde o ponto seja um caracter cuja impressão seja muito bem legível.
Todos sabemos da importância do ponto em Cobol.
E já tivemos uma impressora Centronics (que deu nome ao padrão adotado nas impressoras matriciais) cujo ponto era deteminado por apenas uma das agulhas.
Essa "economia" fazia com que a turma ficasse procurando até chifre em cabeça de cavalo.
Tinha hora em que o ponto não aparecia, tinha hora em que o ponto no papel era uma "cortesia" de algum mosquitinho que aparecesse eventualmente na sala.

Agora imaginem dar manutenção em programas escritos por terceiros em linguagem Assembly e depurados em linguagem de máquina... É dose para dragão de Comodo!...

Tem hora que dá a impressão de que foi o Murphy que inventou a informática e o processamento de dados...

Bom, ainda bem que eu não sou programador, pq eu odeio programar e admiro muito quem programa.
as vezes o murphy aparece nos servidores que eu configuro também.. mas eh assim mesmo.. vou começar a testar desta forma para ver se ele desaparece..
Belo artigo...

Ótimo artigo

Oi Aline ótimo artigo convido-lhe a escrever esse assunto no linuxfast.com.br lá a presença feminina é grande e você com certeza será bem vinda
Abraços

=)

Acabo de avaliar o artigo com 8 pontos. Achei interessante, bem desenvolvido, mas faltou algo que pra mim é vital: definição ou referência a fontes onde pesquisar.
É que sou iniciante e tão leigo que chego a ter uma sensação de cegueira sobre Linux de um modo amplo e geral.

Adotei o Ubuntu há menos de um mês e ainda não posso dizer que estou engatinhando porque mesmo nessa tentativa os tropeços são sucessivos e de alta frequência, ou seja, ainda não consigo engatinhar. Estou gostando da experiência, especialmente no que diz respeito a aprendizado. É muito boa a sensação de que percebe que está manjando horrores sobre seja lá o que for. Sentir-se ignorante é horrível, mas isto pode ser abrandado por uma outra sensação: a de estar aprendendo. É assim que estou: aprendendo. O que há de mais fascinante em matéria de Linux é o fato de nós, usuários, podermos contar com uma comunidade tão grande e participativa como a que o sistema tem no mundo todo. Isto não tem preço e não tem par.

Instalei recentemente - há uma semana - o Rosegarden. Parece ótimo, mas não pude comprovar suas qualidades, já que está sem som, tanto in quanto out, abre no quadrante superior direito da tela, e tunca de um modo tal que acabo tendo que reiniciar.

Postei ontem, no VOL, um pedido de ajuda que logo foi respondido e me parece que a solução esta ali, mas num informatiquês que, provavelmente, nem o Sr. Bill entenderia. O primeiro tropeço foi com a seguinte sentença:

"12 Deverá ser fornecida uma unidade de teste com pressão compatível com a pressão máxima do BOP, com carta registradora de pressão, com os sistemas de baixa e alta pressão, para a realização rápida dos testes. Além disso, as válvulas e acessórios de linha deverão ser do tipo autoclave."

Pra mim isto é Grego dos mais puros. É claro que como foi o meu primeiro acesso para questionamentos, achei que seria mais simples a resposta e não me ocorreu alertar a comunidade para a minha estupidez no assunto, mas gostaria de deixar uma sugestão: Levem em consideração que o Linux é um sistema em franca expansão e que por isso mesmo a comunidade dos novatos talvez seja maior do que a dos veteranos e que "o usuário não sabe o que eles sabem e consequentemente" precisam de uma linguagem mais simples, que o tecniquês seja definido ou que seja fornecida uma referência referência sobre o problema para o qual pede ajuda. Não sei se o que estou propondo é possível, mas se for vai revolucionar mais ainda esta revolução que o Linux já é.

Grato,
WGuedes