Recentemente estive envolvido em um projeto onde qualidade e tempo andavam em lados opostos, qualidade a equipe tem e muita, porém nos faltava tempo. “O projeto deve ser entregue dentro de 15 dias” e após muita luta e esforço de todos, conseguimos o prazo de 30 dias, dependendo do tamanho do projeto isso poderia ser um ótimo prazo, mas não para esse.

Um portal para fins educativos, com conceitos chaves como COMUNICAÇÃO, GESTÃO E CONTEÚDO.

Infelizmente não posso falar o nome da empresa. Você agora deve esta se perguntando certo mais o que isso tem haver com TESTES DE SOFTWARE, pois bem a equipe conseguiu terminar o projeto dentro do prazo, porém na apresentação para a direção da empresa, vários repito vários BUGS foram surgindo na apresentação.

O que ficou claro para todos foi a equipe esqueceu uma fase importante e talvez junto com a implementação a fase mais dispendiosa, mais cara como alguns acadêmicos definem, a fase de TESTES. Não que nenhum dos programadores não tenha testado o que faziam, sim eles faziam isso, porém não realizavam testes mais profundos no momento em que as funcionalidades eram adicionadas, isso gerou a equipe RETRABALHO, pois além de parar todo o desenvolvimento para realizar os testes, “Já que éramos uma equipe pequena que fazia uso de metodologia ágil”, nos tínhamos uma certeza “falhamos”, não pelo que foi feito e sim pelo o que não foi feito.

Mas Rafael por que contar toda essa historinha para falar de testes? Por que não ir direto ao ponto, onde você falaria das questões como testes servem para detectar defeitos e não acertos. Por que não falar das estatísticas que mostram que empresa que investem no estudos e aplicações de testes como algo primordial para o processo de desenvolvimento de software obtém ótimos resultados do ponto de vista de qualidade, satisfação do cliente, menos retrabalho.

Não falei, pois tudo isso já é falado aos quatro cantos do mundo. O que queria mostrar é que até mesmo uma equipe de alto nível pode falhar feio, se subestimar a engenharia de software, pois para muitos, o que Summerville, Pressman entre outros pregam não são aplicáveis ao mundo real de desenvolvimento de software.

Não é ter que aplicar tudo que esta na teoria para a prática e sim os conceitos ou boas práticas junto com suas necessidades é claro. No próximo POST “amanhã”, eu irei falar sobre uma outra forma de evitar problemas com bugs INSPEÇÃO DE SOFTWARE.