[1] Comentário enviado por f_Candido em 08/05/2010 - 17:11h

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

0 0

[2] Comentário enviado por vinyanalista em 08/05/2010 - 18:29h

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.

0 0

[3] Comentário enviado por vinipsmaker em 08/05/2010 - 20:25h

Muito bom o artigo, parabéns.

0 0

[4] Comentário enviado por madcow em 08/05/2010 - 23:25h

Obrigado Pelo auxilio!

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

0 0

[5] Comentário enviado por artur_olsen em 08/05/2010 - 23:47h

Excelente artigo!

Meus parabéns!

0 0

[6] Comentário enviado por edisonsousa em 09/05/2010 - 14:48h

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 !!!

0 0

[7] Comentário enviado por Teixeira em 09/05/2010 - 16:06h

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...

0 0

[8] Comentário enviado por pardalz em 10/05/2010 - 12:23h

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...

0 0

[9] Comentário enviado por removido em 10/05/2010 - 18:25h

Ótimo artigo

0 0

[10] Comentário enviado por cainf em 10/05/2010 - 21:26h

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

0 0

[11] Comentário enviado por elismar em 11/06/2010 - 14:53h

=)

0 0

[12] Comentário enviado por wguedes em 11/07/2011 - 18:44h

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

0 0