Para complementar o post sobre a Regra 10 do JOGO.http://ow.ly/15OxX Toda empresa de desenvolvimento de software deveria ter a Regra 10 de Myers escrita por todos os cantos.Um cartaz pregado na porta ou perto da catraca seria uma boa solucao.Voce [programador, analista de requisitos, gerente de projeto, etc] sabe o que diz a "Regra 10 de Myers"?Nao!?Defino..."A Regra 10 de Myers, estabelece que o custo de correcao de defeitos tende a aumentar quanto mais tarde o defeito e detectado.A regra projeta um crescimento exponencial do custo de correcao de defeitos, numa proporcao de 10x. Ou seja, defeitos encontrados em revisoes custam X, defeitos encontrados nos testes custam 10X e defeitos encontrados em producao custam 100X para serem corrigidos."Entenderam?Para ser mais clara...Um defeito encontrado durante o levantamento de dados, escrita do caso de uso e mais barato que um erro encontrado no desenvolvimento e muito mais barato que um erro reportado pela equipe de teste. E como poderiamos solucionar tal problema?Comecar do zero?Processos ageis? TDD? Hum...talvez.Nessas tecnicas a participacao das equipes de teste e desenvolvimento sao essenciais desde o inicio do projeto.Sua empresa possui uma cultura "engessada" no processo de desenvolvimento de software?Hum...entendi, mas tenho algumas solucoes basicas!1) Crie um checklist de testes unitarios para sua equipe de desenvolvimento.2) Pratique a politica de diminuicao de erros - se num determinado projeto vc obteve X erros, no proximo tente X/2. Aprenda com os erros e converse sobre os mesmos.3) Faca reunioes de repasse - antes de homologar um UC, repasse o mesmo para a equipe de teste e desenvolvimento. Aceite as alteracoes!4) Mantenha sempre uma excelente equipe de Analise de Requisitos. As pessoas ocasionalmente resistem a mudanca e evitam aventurar-se em areas pouco familiares.Arrisque!!!Crie o conceito de TIME e entre no JOGO!http://www.agileway.com.br/2008/09/09/scrum-no-metodo-conta-gotas/http://dojofloripa.wordpress.com/2007/09/10/tudo-sobre-tdd/http://blog.seatecnologia.com.br/2010/01/11/dojo-sea-2010 Respondendo a questao da @Kamilla[DFTestes] sobre classificacao dos defeitos.Defeito: estado do software causado por um erroErro: acao humana que produz um resultado incorretoAbaixo classifico os defeitos seguindo 4 identificadores. - Frequencia: sinaliza a frequencia com que o defeito pode ser observado no artefato ou aplicacao. Os tipos de frequencia sao: Sempre e Aleatorio.- Gravidade: indica o grau de impacto com que a ocorrencia afeta a continuidade do projeto de desenvolvimento ou de utilizacao da aplicacao. A gravidade e classificada como: Grande, Media e Pequena.- Prioridade: serve para informar a prioridade de correcao do defeito. Muitas vezes, a propria gravidade ja indica a prioridade, porem, a prioridade serve para ordenar ocorrencias com mesma severidade. Sinaliza a urgencia de resolucao. Os tipos de prioridade sao: Imediata, Alta, Media, Baixa e Sugestao.- Categoria: classifica as ocorrencias e permite levantamento de metricas identificando os tipos de defeitos. Os tipos de categorias sao: Caso de Uso, Interface, Banco de Dados, Sistema, Caso de teste e Prototipo. " Toda empresa deve ter uma cultura e uma filosofia. Sem cultura e filosofia planejadas e assumidas, a empresa move-se apenas em funcao de numeros. Ela se torna um pessimo ambiente para seus funcionarios e uma pessima prestadora de servico para seus clientes. Os clientes passam a ser nao mais seres humanos especiais, mas apenas consumidores em potencial. Uma empresa que