[quote=marcosalex]
Ninguém está defendendo que bug não deve ser corrigido , mas se foi descoberto depois da entrega do cliente e a alteração demandar tempo, o tempo vai ter de ser trabalhado junto com as outras entregas. [/quote]
Voce nao esta defendendo, o Fernando esta. Se foi descoberto depois da entrega é outra historia, e realmente pode demandar tempo. Mas se foi descoberto antes da entrega não pode ser ignorado.
Eu também não estou entendendo porque eu defendo que bugs não devem ser corrigidos 
rsrs…
Fui analista de testes, gosto da área e sempre fui chato para encontrar e corrigir errros. Em momento algun eu defendi que bugs não devem ser corrigidos.
[quote]marcosalex wrote:
Ninguém está defendendo que bug não deve ser corrigido , mas se foi descoberto depois da entrega do cliente e a alteração demandar tempo, o tempo vai ter de ser trabalhado junto com as outras entregas.
Voce nao esta defendendo, o Fernando esta. Se foi descoberto depois da entrega é outra historia, e realmente pode demandar tempo. Mas se foi descoberto antes da entrega não pode ser ignorado.[/quote]
O que eu estou expondo neste tópico é que a gestão deve tomar cuidado para identificar o nível custo x benefício de um projeto (sistema ou não sistema)
Existem balanças a serem equilibradas:
Se você pesar demais para um lado só da balança, você está errado. Investir em testes demais pode trazer mais custos (desnecessários). Corrigir certas falhas ou bugs (vamso deixar de lado a semântica das palavras), pode ser ineficiente. Você consegue visualizar isso?
Como o rapaz disse antes : erro de CRUD é inaceitável. Você tem que ser um bom gestor para fazer a balança parar no meio.
Você sabe porquê ? Porque todos os software feitos nos EUA têm uma cláusula de não inputabilidade, o que significa que se der merda vc não pode processar o fornecedor. O famoso “este software não é garantido para um terminado fim ou uso”.
Aqui , nunca vi essa clausula (porque é ilegal) o que significa que vc sim pode processar empresas que fizeram software que lhe causou prejuizo.
Vc está dizendo que erros não descobertos existem mesmo assim ?
Isso é uma falácia. Compare com “Aliens não descobertos existem” ou “Deus não descoberto existe” ou "Cidade perdida das antigas civilizações com capacidade de warp não descobertas, existem ".
Falha de lógica.
É inaceitável que se defenda a pior qualidade do software em vez da melhor qualidade. Inaceitável mesmo. Não importa se é o que todo o mundo faz. Eu não faço.
não existe isso de abrir mão de algo necessário, só pq já se fez muito. Se precisar tem que fazer.
[quote]fernando.palma wrote:
Se você pesar demais para um lado só da balança, você está errado. Investir em testes demais pode trazer mais custos (desnecessários). Corrigir certas falhas ou bugs (vamso deixar de lado a semântica das palavras), pode ser ineficiente. Você consegue visualizar isso?
não existe isso de abrir mão de algo necessário, só pq já se fez muito. Se precisar tem que fazer.[/quote]
Concordo “não existe isso de abrir mão de algo necessário, só pq já se fez muito. Se precisar tem que fazer.”. Acho que o Marcos está sendo mais pontual do que eu: “Ou estão interpretando errado ou distorcendo”.
O papel da gestão é justamente saber decidir sobre “o que é necessário”.
As balanças que eu falei são os pilares da gestão. Não só de TI.
Acrescentando ao assunto, eu mesmo escrevo sobre o impacto dos bugs de software e o prejuízo de testar pouco ou não corrigir erros que devem ser corrigidos. Ex:
http://testesdesoftware.blogspot.com/2007/05/artigo-iii.html
[quote=fernando.palma]fernando.palma wrote:
As balanças que eu falei são os pilares da gestão. Não só de TI.
[/quote]
Tais balanças são extremamente burocráticas e não condizem com o mundo real, pois teste é investimento e caso não ocorram na proporção necessária irão onerar o cliente no futuro, vide manunteções corretivas.
Uma equipe com desenvolvimento guiado a testes (tdd?) e um bom analista de testes na fase de homologação garantem sim uma cobertura de 100%, a menos que algo esteja errado no processo.
Erro técnicos de codificação(nullPointer) sequer devem chegar aos usuários, o analista de testes deve buscar erros de implementação como funcionalidade x ou y não condizer com o requisito do cliente.
Fico imaginando rios de dinheiro fluindo do bolso dos clientes em processos burocráticos e ineficientes quando leio tópicos como este.
Cara, não existe 100%. É uma dos conceitos pré-liminares de qualidade e testes. Como você garante que 100% dos caminhos de um sistema “imenso” foram cobertos?
A depender do sistema e de seu porte, é como você garantir todas as possibilidades do jogo da mega-sena. Não é uma analogia exagerada. Existem infinitas possibilidades.
Ferramentas ajudam a cobrir os testes, mas nunca escutei dizer que alguma ferramenta garante 100%.
Aquele que garante um software livre de erros que atire a primeira pedra.
Quem conseguir garantir em 100% a cobertura dos testes está sendo, no mínimo, inocente.
Existem coisas que apenas os usuários são capazes de realizar.
[quote=fernando.palma]
O papel da gestão é justamente saber decidir sobre “o que é necessário”.
As balanças que eu falei são os pilares da gestão. Não só de TI.[/quote]
Aqui vai uma dica para o seu próximo blog post: Como tornar os gerentes necessários?
Software é a projeção pelos requisitos desejáveis, o que acontece na implementação é que Bugs sistemicos pode ser fator de refatoração seja por novas especificações ao comportamento da VM ou seja por requisitos novos acrescentados ao dominio envolvido na criação do mesmo, uma coisa que achei interessante foi a Palestra do Paulo Silveira sobre TDD, acho que ele faz uma excelente abordagem e recomendo ver o video, pois na certa a forma que vocês estão aqui pensando esta bem equivocada, à chegar proximo do software ideial.
Abraços a todos,
:arrow: Paulo Silveira explicando TDD
[quote=marcosalex][quote=sergiotaborda]
Vc está dizendo que erros não descobertos existem mesmo assim ?
[/quote]
Não, estou dizendo que não posso afirmar que não tem erro só porque você não achou. Novamente você parece nunca ter visto uma lista de bug fixes ou Service Pack. Se o cliente identificou um erro depois, significa que aquele programa estava com um erro.
[quote=sergiotaborda]
É inaceitável que se defenda a pior qualidade do software em vez da melhor qualidade. Inaceitável mesmo. Não importa se é o que todo o mundo faz. Eu não faço.[/quote]
De novo, você está ditorcendo ou entendendo errado. Ninguém defendeu pior qualidade. Mas acho que você entendeu e por algum motivo obscuro está prolongando a discussão. Novamente, insisto pra você se relaxar. hehehehe[/quote]
Nunca vi tanta besteira num topico so, % de bugs, meus deus!
Bugs são completamente diferente de problemas na especificação original do software. Seu processo que está 100% bugado!
[quote=mochuara]
Bugs são completamente diferente de problemas na especificação original do software. Seu processo que está 100% bugado![/quote]
Não viaja se você não sabe o que é “especificação sobre o código começa ir atrás disso”, outra coisa bugs é fator de troca de informação entre codigos seja por algoritmos desalinhado seja por falta de fazer uma laminação correta sobre o mesmo.
:arrow: Paulo Silveira explicando TDD
[quote=rubensdemelo]Aquele que garante um software livre de erros que atire a primeira pedra.
Quem conseguir garantir em 100% a cobertura dos testes está sendo, no mínimo, inocente.
Existem coisas que apenas os usuários são capazes de realizar.[/quote]
Comentário típico de quem acha que testar é navegar pelo sistema “clicando” nas telas.
Cobertura é algo muito simples, ou vc tem ou não tem, não existe essa de só o usuário consegue.
Sou o único aqui que acha que desenvolvimento de sistemas é uma ciência exata?
[quote]Comentário típico de quem acha que testar é navegar pelo sistema “clicando” nas telas.
Cobertura é algo muito simples, ou vc tem ou não tem, não existe essa de só o usuário consegue.
Sou o único aqui que acha que desenvolvimento de sistemas é uma ciência exata?[/quote]
Bom , se existe uma maneira de você testar um sistema ERP garantindo 100% de cobertura, então realmente eu que estou atrasado. Estou sendo sincero.
Não afirmei que é inexata. Mas TI é cada vez mais complexa. Não só em desenvolvimento de sistemas, mas como todo.
Claro que testar não é só navegar (testes de caixa preta). Obviamente.
[quote=JavaLivros][quote=mochuara]
Bugs são completamente diferente de problemas na especificação original do software. Seu processo que está 100% bugado![/quote]
Não viaja se você não sabe o que é “especificação sobre o código começa ir atrás disso”, outra coisa bugs é fator de troca de informação entre codigos seja por algoritmos desalinhado seja por falta de fazer uma laminação correta sobre o mesmo.
:arrow: Paulo Silveira explicando TDD[/quote]
Sistema com “32% de bug não conhecido” pra mim é sinal que foi tempo gasto em estimativas e não em trabalho real. Eita informação inútil, nenhum analista de negócios esta preocupado com isso…
Se compartilhasse com a opinião dos gerentes de plantão eu procuraria uma forma de me congelar para o futuro porque atualmente não existe compilador de UML, ou de blablabla (e o marcio duran prova que ele esta distante). Software hoje em dia é executado por máquinas somente e ainda especificados por código portanto qualquer processo que afaste os programadores dos usuários e do processo de especificação do software, menor será as chances do processo da certo.
Existe um apelo gande entre o circulo dos “gerentes” por ferramentas pra especificar software e esse é um interesse que parte de um grupo de usuários que é legítimo. O que me impressiona é programadores acreditarem nessa utopia, ou então fingirem tao bem.
[quote]rubensdemelo wrote:
Aquele que garante um software livre de erros que atire a primeira pedra.
Quem conseguir garantir em 100% a cobertura dos testes está sendo, no mínimo, inocente.
Existem coisas que apenas os usuários são capazes de realizar.
Comentário típico de quem acha que testar é navegar pelo sistema “clicando” nas telas. [/quote]
Como você garante 100% das verificações/correções de especificação do software?
Fernando Palma
Galera tá viajando, acha que só porque faz TDD e passa todos os testes o software não tem bug. Acha que empresa decente corrige todos os bugs antes de lançar
Olha quanto bug antigo tem no Java, vê quantas versões já lançaram desde que reportaram ele
http://bugs.sun.com/top25_bugs.do
Olha o Chrome, 8.000 bugs, milestones diferentes pra eles
http://code.google.com/p/chromium/issues/list
Sejam realistas, é impossível não lançar um browser como o Chrome sem bugs, além de ser um programa altamente complexo ele vai rodar em uma variedade enorme de hardwares, sites, SOs, nenhum desenvolvedor vai conseguir criar teste pra simular tudo. Tem muito bug que eles não vão conseguir reproduzir ou vai demorar até descobrir o problema, até parece que vão deixar de lançar versão nova por causa disso
Justamente. Estou impressionado com o fato de pessoas afirmarem que é possível encontrar e eliminar 100% dos bugs.