[quote=victorcosta]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
[/quote]
Ninguém esta afirmando que TDD é a ultima palavra em exterminar bugs. Até porque desenvolver software livre de bugs não é o objetivo de ninguém. Meu não é, e o seu? Ninguém compra software porque é livre de bugs mas porque atende melhor as suas necessidades. Nesse aspecto se vc usa TDD é porque esta preocupado em desenvolver software de uma forma iterativa dando atenção a continuas melhorias no design.
Por favor, o pessoal da gerencia aí, nao queiram distorcer agora, como se estivessemos todos dizendo que bugs nao podem existir.
A discussao aqui é: qualidade de software é negociavel?
Ninguem esta dizendo que nao existem bugs, o que eu acho um absurdo, um caso de picaretagem, é voce saber que o bug existe e falar “ah deixa isso ai, isso nao eh importante.”
Um bug encontrado em producao tem que ser sanado o quanto antes, respeitando as prioridades do cliente, DO CLIENTE.
Nao é uma questao de semantica, voce considera tam em vez de TAM um bug? Voce considera 10 real em vez de 10 reais bug?
1 - A menos que vc utilize um ciclo de desenvolvimento que siga o waterfall, vc pode sim demonstrar o resultado para o cliente a medida que as funcionalidades ficarem prontas, evitando o desgaste de refazer toda uma nova funcionalidade apenas pq alguem entendeu errado o que o cliente pediu.
2 -Correções só existem para funcionalidades que possuiam bugs, ou seja, não é o assunto em questão.
3 - Uma funcionalidade é constituida de uma método ou o agrupamento destes, se cobrirmos 100% destas funcionalidades em nossos testes podemos sim chegar aos 100%.
4 - Um sistema não se faz apenas por código e sim com processos bem definidos e capacitação das pessoas envolvidas neste. Um sistema para ser colocado em produção exige a dedicação e comprometimento de tais profissionais, caso algum destes não esteja capacitado ou desinteressado em gerar algo com qualidade, tudo vai por agua abaixo, seja utilizando metodologias ageis ou não.
5 - A maneira que você expoe os fatos, me parece que um sistema depende tão somente da parte burocratica para que seja entregue, e pior, entregue com qualidade aceitavel e não qualidade de verdade.
Entendo que nem todas as empresas possuem a coragem e colaboração de seus profissionais para entregar sistemas que realmente agreguem valor ao negocio e possuam baixo custo de manutenção, mas não é por isso que devemos aceitar esta realidade. A idéia é melhorar sempre e acho que é por isso que estamso discutindo este assunto.
[quote]Entendo que nem todas as empresas possuem a coragem e colaboração de seus profissionais para entregar sistemas que realmente agreguem valor ao negocio e possuam baixo custo de manutenção, mas não é por isso que devemos aceitar esta realidade. A idéia é melhorar sempre e acho que é por isso que estamso discutindo este assunto.
[/quote]
aleck, achei que seu ponto de vista foi bem razoável, ao ocntrário de colocações meio “radicais” que observei este tópico.
Concordo. Quero isso. Mas não é simples, há momentos que devemos usar a balança, concorda?
Ou você defende a posição que quanto mais qualidade melhor?
[quote=fernando.palma][quote]Entendo que nem todas as empresas possuem a coragem e colaboração de seus profissionais para entregar sistemas que realmente agreguem valor ao negocio e possuam baixo custo de manutenção, mas não é por isso que devemos aceitar esta realidade. A idéia é melhorar sempre e acho que é por isso que estamso discutindo este assunto.
[/quote]
aleck, achei que seu ponto de vista foi bem razoável, ao ocntrário de colocações meio “radicais” que observei este tópico.
Concordo. Quero isso. Mas não é simples, há momentos que devemos usar a balança, concorda?
Ou você defende a posição que quanto mais qualidade melhor? [/quote]
Acho apenas que a qualidade é proporcional ao custo em relação ao desenvolvimento inicial e a manutenção/melhorias.
Em relação ao custo do projeto a qualidade irá aumentar o custo total do projeto e em relação a manutenção e melhorias, a qualidade provavelmente irá diminuir este custo.
Além do mais, vejo que o tempo de vida de um sistema costuma ser maior que o tempo de desenvolvimento, então a manutenção ao meu ver pesa mais que o valor inicial de criação.
No meu ponto de vista este é o verdadeiro equilibrio, gastar mais para não ter dor de cabeça no futuro.
A discussão foi boa e pelo que vejo envolveu pessoas com conhecimento na prática sobre testes e qualidade de software, mas vemos que são opiniões variadas e que expressam diferentes pontos de vista sobre o que é qualidade, acho que o melhor a fazer é juntar os pontos positivos de cada um e chegar a um consenso sobre o que realmente é qualidade de software e se esses bugs residuais podem ser admissiveis em um sistema entregue ao cliente, gostei de todos os posts mas vejo que em alguns pontos as opiniões pessoais ofuscaram as profissionais e partiram para um lado meio ofensivo, mas entendo que discussões como estas envolvendo profissionais inseridos em projetos de grande porte sempre geram essas discussões calorosas, mas é pra isso q servem os fóruns né, então continuem discutindo que estarei acompanhando e tirando o melhor de cada post para aplicar no meu dia-a-dia.
[quote]Em relação ao custo do projeto a qualidade irá aumentar o custo total do projeto e em relação a manutenção e melhorias, a qualidade provavelmente irá diminuir este custo.
Além do mais, vejo que o tempo de vida de um sistema costuma ser maior que o tempo de desenvolvimento, então a manutenção ao meu ver pesa mais que o valor inicial de criação. [/quote]
Ok, estamos falando a mesma língua. Você se refere ao nível de confiabilidade, resiliência e sustentabilidade do sistema. Se mantemos níveis baixos achando que iremos economizar com isso, sofremos o efeito inverso: o prejuízo lá na frente é maior.
Quando falo das balanças, refiro-me a isso: quem coordena o projeto tem que identificar a qualidade que equilibre a balança e não traga maior custos lá na frente.
Quando eu dei exemplos lá em cima, pontuei: existem sistemas que eu desenvolvo internamente que serão utilizados por 3, 5 usuários em um determinado tempo. ex: contagem de votos de uma eleição.
Um sistema como este é utilizado anualmente e os profissionais já o conhecem. Certos investimentos não valem apena para este sistema. Mas claro: se tiver um bug que prejudique o trabalho eu corro para corrigir.
Em um contra exemplo, que eu também já dei: tenho um sistema que está entrando em produção SCRH. Será utilizado por todos os colaboradores. Qualquer problema, dúvida, mensagem que não esteja clara, fluxo não intuitivo. Qualquer ponto destes pode gerar um custo grade para o período de manutenção: centenas, milhares de chamados pro servicedesk. É claro que eu irei investir mais na qualidade deste sistema. Aqui eu não posso correr riscos
Concluindo a analogia: um campo obrigatório que não está sendo validado como obrigatório é um erro. Deve ser corrigido. Entretanto entre estes dois sistemas, o impacto deste defeito será muito maior no segundo exemplo: SCRH.
[quote=aleck][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.
[/quote]
Concordo inteiramente. como sempre o pessoal não desenvolvedor não tem a minima ideia de como se produz software hoje em dia.
Alguns estão dizendo que todos os softwares tem bugs e estão dando exemplo de software com bugs e correções posteriores. O que vcs não entenderam é que isso acontece porque o processo de desenvolvimento das companhias que desenvolvem esse software é falho. O sistema tem bugs não porque os desenvolvedores são estupidos ou porque é da natureza do software ter bugs e sim porque a companhia tem um processo falho.
Com o processo correto sim é possivel eliminar 100% dos bugs. Se o seu processo não garante isso, o problema é do seu processo.
Imaginemos uma central nuclear. Se algo dá errado , por minimo que seja, temos um efeito chernobyl. mas como testar os sistemas de segurança ? Não dá para deixar o nucleo explodir e ver no que dá. Ou seja, o usuário não pode sair usando para testar.
Teste é feito independentemente daquilo que o usuário faz e sim é possivel ter cobertura de todas as situações. É por isso que os testes têm que ser automáticos!
Testes são feitos diretamente no codigo, por codigo, para o codigo. Humanos falham, sobretudo em situações repetitivas , não queremos esse fator no teste.
E deixo sublinado mais uma vez :qualidade não é negociável. jamais. Qualquer processo, empresa ou pessoa que coloque a qualidade na mesa de negociação merece ser terminado… exterminado, porque isso sim é um grande bug.
Sim, é uma mudança de cultura. Mas só é necessária porque a cultura dominante atual é baseada em lacunas graves de metodologia, profissionalismo, valores e principalmente qualidade.
Um dos valores do desenvolvimento de software moderno é Respeito. É preciso respeitar o cliente, mas é preciso , principalmente respeitar os colegas de profissão. Caso contrário estamos lidando com mercenários aproveitadores. Esses simplesmente devem ser banidos.
Bom eu já tentei demonstrar que não concordo, mas respeito seu ponto de vista.
Faço a mesmo pergunta: como garantir 100% dos testes para especificação? Como eliminar 100%? Sabemos que grande parte dos erros vêm da especificação.
Em um livro de testes de sofwtare de Leonardo Molinari ele exemplifica: por mais que você realize testes automatizados ou mecânicos, dificilmente cobrirá 100% dos testes de uma simples calculadora.
Pelo que eu entendi você está usando um conceito de qualidade mais moderno e radical que o meu. Qualidade para mim é planejada, mensurada e existem níveis. Nada impede de qu eeu mude de idéia um dia, mas eu preciso comrpeender o novo coceito e acreditar. no momento, acredito fiemlmente que a qualidade tem requisitos, variáveis e são negociáveis a depender do uso do produto/serviço.
Concordo plenamente. Sem tirar nem por. Espero que eu não esteja passando uma imagem contrária aesta sua afirmação.
[quote]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]
Concordo com ressalvas.
Existem validações que não são para o usuário fazer. Você tem que garantir o cumprimento dos testes que mitiguem os riscos. Claro que nunca chegará a 100% (inisito).
Imaginem produzir um sistema que controla a temperatura de calderões quimicos de uma industira. Se esse sistema falha, o calderão explode e todos morrem.
Como utilizar pequenas entretas neste caso? Como deixar que o usuário valide? O desenvolvedor deste sistema tem que testar muito e estes testes (neste caso) são caríssimos.
Procurei no google e achei algo sobre este pensamento sobre qualidade.
[quote]
"Guilherme fala sobre os frameworks com a perspectiva de quem está no mercado de uma empresa referência da web brasileira e fala do que vive no dia-a-dia. Ele não tem motivos políticos para defender Ruby ou Python, ele fala da produtividade e da qualidade que encontra ao usar tais ferramentas. Sua frase mais forte, que nós da Ato gostamos é: ?Qualidade não é negociável?. Não adianta: ?faz qualquer coisa pra terminar mais rápido? ou ?faz qualquer coisa porque sai mais barato?. De novo: ?Qualidade não é negociável?. "[/quote]
Pelo que eu entendi, a filosofia é contra o fato de entregar mais rapido e entregar a custo mais baixo. Quero deixar mais uma vez claro que não é esta a minha filosofia: manter bugs. Tente observar meus posts. Eu estou falando da balança: eu prevejo o custo no futuro e comparo com valores presente e tomo decissões.
[quote]Conta pro Google e pra MS o segredo que você vai ficar rico
Estamos falando com o próximo Bill Gates! O cara que consegue liberar código sem nenhum bug, por maior e mais complexo que seja! Adeus Service Packs, adeus Bug Fixes!! Sergio Taborda rules!! [/quote]
Pois é, Marcos.
Eu também fico assustado com afirmações deste tipo: “corrigir 100% dos bugs”
[quote=fernando.palma][quote]Conta pro Google e pra MS o segredo que você vai ficar rico
Estamos falando com o próximo Bill Gates! O cara que consegue liberar código sem nenhum bug, por maior e mais complexo que seja! Adeus Service Packs, adeus Bug Fixes!! Sergio Taborda rules!! [/quote]
Pois é, Marcos.
Eu também fico assustado com afirmações deste tipo: “corrigir 100% dos bugs”
[/quote]
Vcs ficam assutados porque vcs não tenderam até agora. É normal as pessoas terem medo do futuro e do desconhecido.
Em vez de ficar lendo os dinosauros do teste de software leia sobre práticas ageis e principalmente - ja que é gerente - scrum.
Não faça waterfall, faça integração continua, automatize testes, incluia testes na equipa de desenvolvimento durante o desenvolvimento e terá melhores resultados. Especifique menos e dialogue mais.
O “segredo” não é meu. Não fui eu que inventei agile … .oO(damm! :lol: )
[quote=fernando.palma][quote]Conta pro Google e pra MS o segredo que você vai ficar rico
Estamos falando com o próximo Bill Gates! O cara que consegue liberar código sem nenhum bug, por maior e mais complexo que seja! Adeus Service Packs, adeus Bug Fixes!! Sergio Taborda rules!! [/quote]
Pois é, Marcos.
Eu também fico assustado com afirmações deste tipo: “corrigir 100% dos bugs”
[/quote]
se foram identificados 10 bugs e corrigiram os 10, então temos 100%!
Não é o fato dele ser imune a defeitos, a questão é o estado em que o software se encontra.
[quote]Vcs ficam assutados porque vcs não tenderam até agora. É normal as pessoas terem medo do futuro e do desconhecido.
Em vez de ficar lendo os dinosauros do teste de software leia sobre práticas ageis e principalmente - ja que é gerente - scrum.
Não faça waterfall, faça integração continua, automatize testes, incluia testes na equipa de desenvolvimento durante o desenvolvimento e terá melhores resultados. Especifique menos e dialogue mais. [/quote]
Eu realmente não osu especialista em métodos de gestão ageis mais conheço sim. Posso afirmar sem falsa modéstia que sou disciplinado com estudos e gosto de estar atento para novas tendências.
O que eu e o Marcos estamos querendo dizer (pelo menos posso falar por mim) é que perfeição não existe independente do métdo. Não existe uma esfera perfeita. Não existem 100% de correção de bugs.
Vou me arriscar a falar um pouco de XP e Scrum mesmo não sendo especialista. Se falhar e algum ponto, por favor, me corijam.
Trazem vantagens para o usuário final, pois facilita mudanças de requisito. Usuário adora mudar requisito;
Traz motivação aos programadores, que não gostam de regras, metodologias e afins (exemplo aqui no fórum), puca documentação;
É agil, como o nome sugere;
Traz integração maior da equipe e menos hierarquia.
O que você precisa notar - acredito eu - é que existem projetos e projetos. Não posso confiar em XP e SCRUm em determinados projetos.
Outro ponto: o principal objetivo de quem está lá em cima e decide pro gestão agil é gastar menos. Este mantra do “qualidade ou existe ou não existe” é um motivador para a equipe. É o gatilho. Quem segue metodos ágeis repete isso como se fosse uma nova tendência, mas existem conceitos que não passam pro tendências, é fato.
Lembre do meu exemplo do inmetro: para diferentes produtos existem diferentes níveis de qualidade exigidos.
Lembro do exemplo do sistema do calderão: o nível de testes é caríssimo. Exige um planejamento de testes “macho”
Eu não uso cascata (waterfal) e tenho testes durante todo ociclo de via V MODEL. Tenho iteratividade om o cliente. Não uso automação no momento, mas já utilizei. No projeto que estou, em específico, ainda não foram implantadas ferramentas de teses, mas pretendo.
Essa sua sugestão não contradiz o facto de que “qualidade não é mensurável”, tão pouco prova que “é possível eliminar 100% de bugs de um sistema”.
[quote]se foram identificados 10 bugs e corrigiram os 10, então temos 100%!
Não é o fato dele ser imune a defeitos, a questão é o estado em que o software se encontra. [/quote]
Agora sim. Isso significa que eu corrigi 100% dos que encontrei. Até ai tudo bem.
A bem de quem está lendo vou corrigi-lo, mas se vc pensa o que escreveu vc não estudou o suficiente, por isto não é XP/Scrum é completo non sense.
As diferenças entre metodologia moderna e tradicional são :
Respeite valores acima de tudo.
A unica coisa que temos a certeza (absoluta) em relação ao software é que ele evoluirá.
Isto define o termo ágil. Ágil vem do facto do software mudar constantemente , portanto o processo de desenvolvimento tem que acompanhar essa mudança. Um processo Ágil é aquele que funciona mesmo quando o software muda.
A mudança de requisito é a tradução direta do que significa “evolução do software”. Ou seja, o usuário mudar o requisito não é a exceção, é a regra. Ele fará isso , e é bom que você aceite esse fato. Lutar contra ele não traz vantagem.
Portanto, esta não é uma vantagem, é a propria base para a definição do que é ser ágil. É aceitar a alteração de requisitos on-the-fly
completa palhaçada. Agil não significa desleixado ou preguiçoso. Sim ha documentação em processos ageis. Mas é tudo uma questão de saber qual documentação é util e qual não é. A primeira documentação , obrigatória , de um processo ágil é o código.
Código não escrito para funcionar é escrito para ser lido. Para ser lido por outras pessoas. Código limpo, bem programado, enxuto, bem comentado ( bem significa util não extenso)
A segunda é o manual do usuário.
Em scrum vc ainda tem os burndown charts e os backlogs. normalmente estes ficam em software.
Vc pode adicionar mais : modelos UML tb são aceitáveis. Mas podem ficar num quadro branco visivel a todos, não necessáriamente precisam ficar no word ou numa ferramenta case.
documentar não é escrever words! documentar é guardar informação de forma a poder de lida e consultada depois por qualquer um!
(abertura , outra cacaracteristica ágil)
Tautologia.
Ai que entram o valores. Respeito, abertura , comunicação, são os valores que tornam a integração maior naturalmente.
Quando as pessoas se entendem ha consenso. Com consenso não ha necessidade de hierarquia.
Isso é porque vc não sabe o que XP e Scrum são. Se soubesse vc não pensaria assim.
Aliás o seu raciocino é tipo de pessoas no lugar de gerente.
Eu acho que é porque vc acham que XP e Scrum matam a necessidade de gerentes. E vc tem razão.
Só que se a pessoa realmente entender de desenvolvimento ela assume um dos muitos papeis no XP/Scrum e continua trabalhando feliz como antes. Agora se a pessoa é um prevaricador ai sim é para ter medo mesmo porque essas pessosas têm os dias contados.
quem é agil não coloca a qualidade como parametro. Qualidade é para existir e ponto final. Não tem essa de “niveis de qualidade” porque isso - para uma pessoa que segue valores como abertura - é o mesmo que “niveis de falta de qualidade” .
Defender a qualidade não é algo de agile é algo de ser profissional. E apenas quem é profissional consegue seguir agile (porque só uma pessoa profissional consegue seguir valores doe a quem doer). Qualidade é um fim em si mesmo que tem que ser alcançado junto com a entregua do software. é o mesmo tipo de qualidade de que a ISO fala.
Testes são caros se forem mal feitos ou feitos no ponto errado do processo. Porque a metodologia tradicional os faz no lugar errado
eles são caros. Em agile se fazem mais testes,mais depressa,mais barato. E isso acontece porque são feitos testes diferentes em fases diferentes do processo. Um equivalente na linha de produção - para vc entender - seria : no método tradicional o produto é testado no fim da linha de montagem. No método ágil o produto é testado a cada passo da linha de montagem. Além disso cada componente dele é testado da mesma forma. E além disso temos tb o teste no final. Porque já foram feitos muitos testes durante o processo o teste final não precisa ser tão demorado, extenso ou caro como se ele fosse único. É a distribuição dos testes (automáticos) ao longo do processo que barateiam os testes e garantem menos defeitos no final.
O melhor ponto a favor de processos ageis não é a falha dos tradicionais,mas o sucesso dos ageis.
Empresas que falham usando processos ageis, falham porque não os implementam direito.
Ah! sim, isso é outra coisa que vc precisa entender : processos ageis se implementam, não se adoptam.
Gostei dos seus pontos, entretanto existem alguns que eu já vi de perto e tenho lá minhas contra-indicações. Mas tudo bem.
[quote]
Um equivalente na linha de produção - para vc entender - seria : no método tradicional o produto é testado no fim da linha de montagem. No método ágil o produto é testado a cada passo da linha de montagem.[/quote]
Eu já te respondi isso lá em cima: não uso cascata. Testes devem ser realizados em todo o ciclo de vida do projeto. Eu falei até do V model.
você não precisa de gestões ágeis para ter esta vantagem. Modeo iterativo já existe há muitos anos na engenharia de software.
O que eu não consigo aceitar é que sistemas como o que eu exemplifiquei sejam tratados sem planejamento de testes e qualidade. Testes são caros sim, mesmo se executados durante todo o ciclo de vida. No exemplo do sistema do caldeirão eu vou pedir pro cliente fazer varias avaliações e ir evoluindo?. Eu tenho que ter um proceso de testes interno bom, sim, não da pra ele avaliar: se falhar todo mundo morre.
Concordo que 100% dos bugs na primeira entrega é complicado, mas como o Fernando disse existem bugs que podem ficar pra próxima entrega e tambem acho que as ferramentas case no processo de automação de testes podem auxiliar bastante e conferir mais confiabilidade e estabilidade ao sistema já na primeira entrega.
A discussão esta boa e acho que chegaremos a um ponto em comum.
Metodologia e automação de testes, explore mais essa funcionalidade!!!