Os bugs também têm sentimentos

Muitas vezes uma imagem diz mais do que mil palavras. No blog Cartoon tester, Andy Glover faz uso de imagens extremamente simples, mas que transmitem de maneira objetiva conceitos e práticas interessantes relacionadas com as atividades do engenheiro de testes.

A imagem abaixo é do post do blog, que fala de maneira correta sobre algumas atitudes que devemos ter no nosso dia a dia quando encontramos bugs. Abaixo, uma breve explicação dos pontos mencionados.

Se você encontrar um bug:

1 – Reporte-o, bugs não gostam de ser esquecidos.

Diversos motivos podem levar um testador a esquecer de reportar algum defeito encontrado, prazos apertados, tarefas acumuladas, desorganização ou simplesmente o fato de que algumas vezes os defeitos são encontrados antes mesmo dos testes, em conversas informais, treinamentos, etc.. e nem sempre os envolvidos tomam as devidas ações nessas situações.

2 – Conheça-o melhor, bugs gostam de ser compreendidos.

Antes de reportar um defeito, devemos entender por completo seu comportamento, sua abrangência e quais são seus impactos.

3 – Tire uma foto, bugs gostam de guardar recordações das ocasiões.

Screenshots, fotos e inclusive vídeos ajudam a evidenciar melhor a reportagem de um defeito, facilitando o entendimento do desenvolvedor e evitando CRs reabertas.

4 – Conheça seus companheiros, bugs são socialites.

Ao encontrar um defeito é comum que outros bugs estejam localizados nas suas redondezas, por isso é importante a varredura nas funcionalidades relacionadas para rapidamente detectar novas falhas.

5 – Reporte rapidamente, do contrário os bugs se estabelecem e fazem moradia.

Agilidade na reportagem permite que sua correção também seja antecipada, evitando que outros bugs causados pela falha já existente sejam revelados.

6 – Seja honesto, bugs não gostam de fofocas.

Classificação de severidade e prioridade supervalorizadas, melhorias registradas como defeitos, entre outros problemas frequentes, causam problemas na comunicação da equipe e atrapalham o andamento das atividades.

7 – Guarde como o conheceu, bugs são românticos.

Ao encontrar um defeito, a primeira tarefa é sempre de verificar quais foram os passos prévios para detecção do problema, reportar como podemos reproduzir o issue é essencial para os desenvolvedores durante a correção e também para os testadores no momento da verificação das correções.

8 – Não o ignore, bugs podem morder quando não apreciados.

Em meio a tantos bugs, normalmente encontrados durante os testes, é comum que em alguns momentos desprezemos alguns defeitos encontrados, por acreditarmos que os mesmos são irrelevantes ou nunca serão corrigidos. Porém, já cansei de ver defeitos ignorados sendo reportados posteriormente por clientes ou quando vistos por outros ângulos gerando consequências graves para o sistema.

Adicionaria a lista de atitudes a verificação dos defeitos já existentes, prática bastante simples, mas que muitas vezes é relegada, e que pode evitar trabalho desnecessário de diversas pessoas.

E vocês concordam com os tópicos? Sentiram falta de mais alguma atitude?

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Por que os bugs graves surgem no último dia?

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.

Os desenvolvedores podem testar seu próprio código?

Por esses dias, estive relendo os posts sobre como são conduzidas as atividades de testes no google, entre outras coisas eles falam sobre os papéis, funções e de que maneira a qualidade de software é conduzida dentro da empresa.

No terceiro post da série, diversas afirmações chamaram a minha atenção e valem a nossa reflexão:

“Who better to do all that testing than the people doing the actual coding? Who better to find the bug than the person who wrote it? Who is more incentivized to avoid writing the bug in the first place?”

A partir dessa afirmação podemos ver que estamos passando por uma grande transição na engenharia de software. Onde há vários anos as empresas dão uma ênfase cada vez maior aos aspectos relacionados à qualidade de software e diversas estratégias surgiram e vêm sendo utilizadas para a organização das equipes e divisão das tarefas.

Porém, o que mais me chama atenção nessa primeira afirmação é como a idéia a que estava acostumado, de que precisamos de pessoas com dois perfis diferentes para testar e desenvolver um software está ficando ultrapassada.

Make it or Break it

Cada vez mais precisamos unir as duas disciplinas que se completam para assim entregar produtos de maior qualidade.

Claro, que para que isso aconteça é necessária uma mudança cultural e comportamental. Abandonarmos os antigos conceitos de que desenvolvedores não conseguem enxergar as falhas em seu próprio código, não gostam e não querem testar e tornar tudo em uma única tarefa.

Diversos benefícios podem emergir dessa tendência, como: detecção de defeitos cada vez mais cedo, maior liberdade para o engenheiro de teste focar em aspectos não funcionais, fluxos de integração e outros pontos que fogem a unidade do desenvolvedor, etc.

  “quality is more an act of prevention than it is detection”

Desse modo, técnicas como o TDD podem ser excelentes caminhos para eliminar essa separação entre testes e desenvolvimento. Ajudando a tornar a qualidade cada vez mais um ato de prevenção do que detecção.

” Testing must be an unavoidable aspect of development and the marriage of development and testing is where quality is achieved”

É óbvio, que existem diferenças entre os diversos tipos de projetos e na realidade de cada uma das empresas, onde cada um possui necessidades diferentes as quais precisam ser avaliadas e planejadas.

Está cada vez mais claro o caminho para produzirmos softwares de maior qualidade, testes e desenvolvimento como uma só tarefa, apresentando um grau de automação cada vez maior. Para seguirmos esse caminho várias mudanças são necessárias tanto nas pessoas, como nos processos e ferramentas.

E vocês o que acham? É esse o caminho a ser seguido?