Prevenindo Defeitos Usando Técnicas Ágeis

Inúmeros podem ser os deslizes cometidos ao descrever uma história. Eles podem levar a defeitos de implementação caso não sejam validados antes de serem desenvolvidas. Detalhes que aparentemente estão claros na cabeça do analista de negócio, ou mesmo do cliente, acabam não sendo completamente detalhados na descrição da história.

Como prevenir defeitos no software o mais cedo possível é um objetivo sempre almejado por qualquer projeto de desenvolvimento de software e muitas técnicas são utilizadas para caçar esses defeitos precocemente, recomenda-se ler o livro do Gokjo, Fifty Quick Ideas To Improve Your Tests. Duas delas tem dado um retorno bem interessante na manutenção da qualidade no projeto: o Kick-off e o Desk-check de histórias.

Como histórias em análise ainda estão abertas a sugestões, uma proposta seria uma reunião, na qual o analista de negócio (ou um integrante com contexto), apresenta as próximas histórias, comenta a origem, o valor de negócio e o porquê são necessárias. O time tem a oportunidade de discutir detalhes técnicos, fazer questionamentos sobre os requisitos e avaliam se o tamanho da história está adequado. Este feedback pode ser usado para dividir a história onde for apropriado, ou adicionar mais detalhes e exemplos para clarificar àreas que causaram confusão.

Kick off

O kick-off, que na tradução literal seria 'ponta-pé inicial', trata-se de uma lista de checagem com vários itens a serem verificados antes de iniciar o desenvolvimento da história. Essa lista, inclui validações como: a história está completa e realmente pronta para o desenvolvimento? Que considerações técnicas precisam ser observadas durante o desenvolvimento? Já sabemos sobre o design visual? E quanto abordagens para controlar erros e mensagens de ajuda?

Outro problema muito comum são premissas que estão na cabeça do desenvolvedor e não compartilhadas ou verificadas entre desenvolvedor e analista (falha de comunicação). Sendo assim o bate papo inicial traz à tona os conceitos e objetivos sem deixar passar detalhes importantes, além de enriquecer o contexto com o ponto de vista de pessoas em diferentes papéis.

Em um cenário ideal, a participação de analistas de negócio, do analista de qualidade e dos desenvolvedores é fundamental no kick-off  para que todos fiquem a par da funcionalidade a ser desenvolvida e para que o debate seja mais produtivo e proveitoso. Confira uma sugestão de kick-off abaixo:

Checklist para o Kick-off

Envolvidos: Analista de Negócios, Analista de Teste, Desenvolvedores

• A análise da história está completa?
• Houve revisão de QA na análise?
• A história está completa com detalhes e toda a informação relevante?
• O valor da história foi bem compreendido?
• Há dependencia em futuras histórias?
• Há algum débito técnico relacionado?
• Há design visual para a história?
• A história possui mensagens de erros detalhadas?
• Há mensagens de ajuda e outros labels definidos na história, já revisados?
• O tamanho da história é apropriado?

Pelas mesmas razões justificadas no kick-off, o analista de negócio, o analista de qualidade e desenvolvedores devem estar presentes para ampliar o debate sobre dúvidas e problemas durante o desenvolvimento. Seria importante considerar que para histórias grandes, podem ser feitas checagens durante o desenvolvimento, afim de garantir que se está no caminho certo. Deve-se ter atenção para que estes feedbacks não ultrapassem o escopo da história e, se eles fizerem sentido, provavelmente a análise da história não foi acurada.

Desk Check

O desk check (teste de mesa), trata-se de uma lista de checagem a ser utilizada na validação da história, quando o par acredita que esta pronto do ponto de vista de desenvolvimento. Na listagem abaixo, vemos validações como: foram implementados os testes unitários e de aceitação?  Já foi feita uma revisão do código com outro par? Funciona nos principais navegadores? Tais perguntas são importantes para a prevenção de dores de cabeça no futuro. Exemplo: a funcionalidade está linda no google Chrome, mas sequer aparece no Internet Explorer porque as bibliotecas ou a versão do html não funcionam lá.

Checklist para o Desk Check

Envolvidos: Analista de Negócios, Desenvolvedores e pessoas interessadas

• Há cobertura de teste suficiente?
• Outro par foi convidado para revisar o código?
• A história foi testada manualmente?
• A verificação da história pode ter impactado em outra coisa?
• Todos os critérios de aceitação foram cobertos?
• Será que a história precisa de algum tipo de feedback ou correção?
• Foi feita uma completa jornada de usuário através da história?
• A interação com a UI está  consistente com o resto da aplicação?
• Funciona nos principais navegadores?
• O texto na história está consistente com outros textos e labels na aplicação?
• O conteúdo dos textos possui erros gramaticais?
• O esquema de cores está consistente com outras cores na app?

Pode-se dizer  que a maioria dos defeitos são de fato encontrados durante o desk check, por razões óbvias, visto que é quando a história está sendo entregue e quando realmente é possível  fazer um teste preliminar na funcionalidade desenvolvida. De qualquer forma, é recomendável uma atenção especial ao kick-off, pois é onde o mal entendido ocorre e as coisas são implementadas diferentemente do ideal.

Vale salientar que estas listas de checagem não devem ser rígidas, escritas na pedra e seguidas à risca. O importante é que o benefício dessa abordagem está em verificar se aqueles passos foram seguidos durante o desenvolvimento da história. Outro aspecto relevante é que essas listas devem ser personalizadas, uma vez que cada projeto tem suas particularidades e necessidades. Crie a sua lista e veja os benefícios surgindo logo no início. Mantenha o hábito para  que isso não seja esquecido com o tempo.
    
Pratica alguma técnica de prevenção de defeitos e gostaria de compartilhar? Comente nesse artigo.