Os últimos dias que antecedem a uma entrega, com frequência, são repletos de correria, stress, pressão e claro bugs e mais bugs, que parecem intermináveis.
O que pode nos levar a pensar, que estamos cometendo os mesmos erros. Pensamos, refletimos, avaliamos e discutimos durante reuniões de Sprint Retrospective, que as vezes parecem intermináveis, o porquê de, mais uma vez, termos feito diversas horas extras nos últimos dias que antecederam a entrega.
Abaixo, listamos alguns dos fatores, que podem contribuir para esse número de bugs elevado, os quais podemos combater e assim, pelo menos, reduzir sua probabilidade de ocorrência.
Ausência de testes durante a sprint
Um dos problemas mais comuns que econtramos está relacionado a ausência de testes intermediários durante a sprint, sobrecarregando os testes de sistema realizados nos últimos dias e consequentemente proporcionando um número maior de CRs graves nos últimos dias.
Testes mal priorizados
Durante a execução do ciclo de testes de sistema, a priorização da ordem de execução também tem se mostrado um elemento fundamental para permitir que a maior parte dos defeitos graves sejam encontrados nos primeiros dias de execução.
Prazos irreais para testes
Sistemas gigantescos, com diversos requisitos de hardware, contando apenas com alguns dias para testes. Mais um grande motivo, para que o planejamento seja mal feito, a execução corrida e, desse modo, defeitos graves acabem não sendo antecipados ou até mesmo escapando.
Prazos irreais para correção
Desenvolvedores pressionados pelo “dia da entrega” implementando soluções, que nem sempre são a “melhor” solução, podendo, também, gerar novos bugs no sistema.
Especificação Deficiente
Estórias ou requisitos mal descritos, ausência de Product Owner ou Engenheiro de Requisitos, proporcionam dificuldades para desenvolvedores e testadores, o que acaba significando um maior número de defeitos.
Testes mal realizados
Diversos pontos da estratégia de testes podem precisar de uma boa revisão, é comum a ausência dos testes estáticos na documentação, a precariedade dos testes unitários, e a falta dos de componente. Criando, dessa forma, um enorme gargalo nos testes de sistema ou de regressão.
Porém, ledo engano nosso, achar que ao identificar e corrigir todos os possíveis problemas, nenhum bug grave será encontrado nos últimos dias. Na verdade, isso apenas minimiza o problema (o que é fundamental) e, hoje, não temos como garantir, que iremos conseguir antecipar todos os defeitos graves.
Enquanto houver tempo para testar, e o time possuir qualidade e disposição, devem haver bugs, inclusive graves…
E se adiarmos a entrega por mais alguns dias… continuaremos a encontrar bugs…
E você o que acha? Que outras medidas podem ser tomadas?
Acompanhe as novidades do BdB pelo Facebook, acesse e curta nossa página.
Bytes don't Bite! 
Considero boas práticas:
. Haver pelo menos um Eng. de Testes na equipe. Durante o desenvolvimento da Sprint ele vai planejar os testes que serão realizados
. Pelo menos uma rodada de testes entre cada Sprint. Executados por um Eng. de Testes, melhor ainda se foi o mesmo que planejou os testes
. Bugs encontrados são priorizados com as atividades em cada Sprint
. Bugs corrigidos são verificados na rodada de testes seguinte
Abaixo um idéia de como seria o fluxo de desenvolvimento:
. Sprint 1 Plan (apenas atividades) -> Sprint 1 -> Testes da Sprint 1
. from Sprint 2 until Sprint N do
Sprint Plan (atividades e bugs) -> Sprint -> Verificação dos Bugs corrigidos na Sprint anterior -> Testes da Sprint
Usei essa abordagem e gostei, espero que sirva de inspiração.
Perfeito… é primordial existir um eng de testes alocado desde o início para planejar e acompanhar as atividades… e dessa forma conseguir um período de execução mais proveitoso…
eu encaro uma coisa como o grande problema… e essa coisa é o TAMANHO do sw que vai ser testado!
Chegamos ao seguinte trade-off:
Ou gasta mais tempo pra testar mais coisa
ou não gasta tanto tempo mas testa menos coisa (menor garantia da qualidade do todo independente da estratégia que utilize para selecionar a parte que vai ser testada)
Para resolver isso eh muito mais simples.
Quem escreve os códigos conhece muito mais o programa do que os testadores.
Nós, testadores caçamos os erros muitas vezes sem saber onde encontrá-los e as vezes até sabemos onde encontrar por conta da recorrência dos erros.
No dia em que desenvolvedores encararem os testes como algo que faz parte de suas atividades, certamente esses erros serão diminuídos e muito.
Se antes de cada snapshot, baseline ou release ser gerada, os desenvolvedores fizerem ao menos uma rotina de testes interna entre eles, verão que o projeto certamente não se sobrecarregará.
Isso não é para diminuir o trabalho dos testers não, é para não sobrecarregar o projeto, até pq só dará mais trabalho para o próprio desenvolvedor e todo o projeto.
Chegar na mão dos testadores, uma baseline no mínimo, estável.
Isso seria o mundo perfeito, Isso é o que acho, mas ….
Perfeito, os desenvolvedores conhecem melhor o código e quando os testes unitários são bem realizados conseguimos diminuir o número de defeitos.
Cada vez mais precisamos caminhar nesse sentido, onde, testes e desenvolvimento caminham juntos.
Porém, mesmo assim, nesse mundo perfeito, ainda seria praticamente impossível anteciparmos todos os problemas…
Esse mundo perfeito só é possível na teoria. Tal como foi dito no inicio, o “Desenvolvedores” são pressionados para fazerem o software cada vez mais rápido, logo, se eles não tem tempo para desenvolver a melhor solução também não terão tempo para fazer os devidos testes.
Já agora, uma das principais vantagens de ter um tester é o facto de ele estar fora da “box de código”. O testes do developer são orientados a mostrar que o trabalho deles funciona quando é usado da forma esperada, os testes do tester são orientado a mostrar que o software funciona mesmo quando usado de forma incorrecta. São chamados os bullet proof tests.
É possível um envolvimento maior por parte de todos os atores do projecto. Se uma empresa está alerta para a qualidade, e até contrata uma equipa ou um eng. de testes tem de dar um passo em frente e adotar metodologias de desenvolvimento como TDD por exemplo. Estas metodologias numa fase inicial podem causar algum atrito mas com o tempo acabam por não empatar o desenvolvimento.
Excelente pessoal, obrigado pelas contribuições. O ponto que precisamos pensar quanto ao tempo que gastamos implementando testes automáticos ou desenvolvendo uma funcionalidade de maneira mais completa, é que se isso não for feito de maneira correta mais na frente teremos que gastar ainda mais tempo corrigindo os problemas que surgirão… Logo, cada vez mais precisamos de fato de práticas como o TDD para anteciparmos ao máximo o surgimento dos defeitos em fases mais avançadas…
Trabalhar com prazos restritos é a realidade da marioria dos testadores. Então, acredito que o ideal seria fazer uma análise de risco com os envolvidos no projeto para priorizar o que é realmente mais importante testar, diminuindo o impacto de erros graves.
Já usei a seguinte abordagem num projeto ágil onde os desenvolvedores executavam tanto os testes de sprint quantos os testes formais(testes usando baseline de código).
1. Passamos o fluxo de execução de testes para os desenvolvedores;
2. Os desenvolvedores que se sentiram a vontade, executaram testes e reportaram os defeitos(assim como gostariam de receber os defeitos registrados).
Pude constatar que os desenvolvedores que realizaram as tarefas se saíram muito bem atacando os pontos que sentiam maior fragilidade no sistema. Contribuindo para uma maior qualidade do software.
Uma das práticas que fazemos com frequencia é identificar os diversos cenários de testes e repassar por email para os desenvolvedores, eles fazem uma validação inicial, ajudam a verificar se todos os cenários estão corretos, o que também os ajuda durante a implementação
Muito bom post! Parabéns!
Os dois primeiros tópicos me chamam bastante a atenção. Principalmente por ser fácil de resolver (basta disposição). IMHO é muito triste uma equipe de sw ainda ter o pensamento de testar o sistema quando este já está razoavelmente grande. Ora, quanto menos código escrito, menos erros [impactantes] você deverá encontrar. Se pensar bem, aplicando essa lógica de forma mais incisiva, você vai encontrar que a resposta é usar TDD e baby steps. Como o amigo acima citou, isso vai aumentar a carga para os desenvolvedores. Mas pense bem. Aumenta apenas no sentido de ter menos tempo para implementar features novas. O código escrito será melhor e estará 100% coberto por testes! Serão encontrados novos bugs? Provavelmente. Impactantes? Não! E isso sim significa mais valor para o cliente. Pra que o cliente quer novas features se todas contém muitos bugs e o custo de correção é altíssimo?
Enfim, desenvolvedores precisam estar atentos ao bom uso do TDD que implica em bom design e código de qualidade e, acima de tudo, aplicar o princípio de usar Baby-Steps.
Excelente Tiago, obrigado pela contribuição…
Eu acrescentaria o factor da falta de qualidade dos dados.
Muitas vezes os dados usados não testes não são reais, mas manipulados, fabricados para os testes, o que acaba por influenciar o resultado final.
Os casos de testes devem ser seleccionados, especificando os tipos de dados a usar em cada caso. Mas sobretudo deve haver cuidado em recolher/fabricar dados reais (ou que reflictam a realidade futura), que tenham em conta o enquadramento da utilização do sw em causa, mas também os dados que podem na situação real, ser gerados por outras aplicações (ex. dados provenientes de interfaces com outras aplicações).
Este é um ponto importante, muitas vezes negligenciado.
Verdade. Todo aspecto relacionado a configuração do ambiente de testes/desenvolvimento é de extrema importância, e diversas vezes acabamos não percebendo diferenças sutis, que podem influenciar os resultados obtidos.
Parabéns pelo post!
Foi uma grata surpresa conhecer o seu blog a partir da divulgação no DFTestes.
Um outro ponto que eu colocaria em discussão é quando os testes não cabem na sprint. Várias vezes uma implementação ou manutenção exigem testes que ultrapassam o tempo planejado para a sprint. Ou necessitam de uma cobertura maior, ou mais testes não funcionais. Nesses casos, algumas organizações tem montado um Scrum de teste, com sprints próprios.
Que bom que gostou do blog. Realmente, o problema de a quantidade de implementação ser maior que o tempo para testes é comum! Fiquei curioso a respeito do que você chamou de Scrum de teste… como isso funciona com vocês?
Quando os testes unitários são implementados após o desenvolvimento, o risco de se ter resultados fabricados é maior. Concordo com Tiago em se ter um ambiente de desenvolvimento guiado por testes (TDD) bem amadurecido.
Também é importante ter um gerenciamento de entrega contínua e uma equipe de QA bem qualificada, podendo, além de cobrir os testes funcionais relacionados ao que será realmente entregue, agregar valor ao produto sendo desenvolvido e, consequentemente, gerar resultados mais satisfatórios com o produto final.
A buzzword que tem movimentado a indústria de desenvolvimento nos últimos dias é DevOps, que discute justamente a questão de se ter a equipe de desenvolvimento em harmonia com a equipe de infra e a equipe de controle de qualidade.
Quando se pensa em entrega contínua, livre de imprevistos (especialmente os de última hora), é fundamental ter em mente os princípios discutidos em DevOps.
Meus 5 cents! 😛
Obrigado, Ramses.
Realmente os pontos em torno do DevOps abordam questões fundamentais e que cada vez mais precisam ser melhor pensadas.
Um dos pontos iniciais para mim pesa bastante pelo que vi até hoje: Deficiente analise em termos de prioritização. Testes de funcionalidades com diferentes impactos na criticidade para o negócio são incluidos no mesmo saco que outros que deviam ter baixa prioridade/criticidade.
Nada de novo portanto. Tempo poupado na analise inicial e definição do plano é pago posteriormente – e com juros – em fases de execução e analise de métricas posteriores.
Alguma paciência e esforço de análise inicial tem tem tendencia a compensar a longo prazo, especialmente se a carga em sanity/regressão for alta.