segunda-feira, 23 de março de 2020

Agilidade e qualidade seriam antagônicas?


#agilidade é o conceito dominante em projetos de #software. Mas, como fica a #qualidade? Vejamos como esses dois conceitos podem ser aplicados com responsabilidade e em conjunto. Vou mostrar o resultado de uma pesquisa que fiz recentemente.




"Qualidade está implícita em times ágeis"

Certa vez, em uma palestra, estava falando exatamente sobre qualidade e agilidade, quando fui interrompido por alguém que levantou essa "pérola": A qualidade está implícita em times ágeis. Hmmmm. Será mesmo?

Em nenhum projeto a qualidade está implícita. Seja qual for a metodologia seguida. Qualidade não é "seguir" um roteiro e não pode ser adquirida por "sinergia".

Qualidade é o grau de utilidade esperado ou adquirido de qualquer coisa, verificável através da forma e dos elementos constitutivos do mesmo e pelo resultado do seu uso. (Wikipedia)

Quando falamos sobre qualidade de software, existem padrões específicos para avalia-la, os quais eu já repeti exaustivamente. 

Existem vários padrões para avaliar a qualidade de software, como norma ISO/IEC 25010, que substituiu a norma ISO 9126. 



A imagem anterior é da antiga norma, mas serve para demonstrarmos os vários aspectos sob os quais devemos avaliar a qualidade de um software. Destaque para: 


  • Funcionalidade: O software faz o que deveria fazer?
  • Confiabilidade: Mesmo sob condições adversas?
  • Eficiência: Da maneira esperada?

A única maneira de garantirmos a qualidade do que estamos construindo é com ações e não com palavras.


Sobre testes e qualidade


O objetivo deste artigo não é discorrer sobre testes e qualidade de software, coisa que já fiz em muitos livros e artigos que escrevi, por exemplo: 




Todos se encontram na seção de livros deste blog. Mas tem um que é gratuito e que você pode baixar aqui: 

Como avaliar projetos de software

Além de outros artigos do Bom programador: 



Sobre agilidade e testes

Kent Beck, o criador do método Test Driven Development, (TDD) é o primeiro signatário do Manifesto Ágil, mas, hoje em dia, quando se fala em "métodos ágeis", as pessoas pensam apenas em: Scrum, Kanban e Planning Poker

Mas, na verdade o movimento ágil começou com outros métodos, como: Extreme Programming e TDD

Porém, o marketing da agilidade focou nos métodos mais lúdicos e simples de implementar, pois haveria menos resistência. E, com efeito, conseguiram. 

Hoje, os fornecedores de produtos e serviços ditos "ágeis", vendem "rapidez", com entregas frequentes em ciclos de curto espaço de tempo. Ok, isso é ótimo. Mas, eu pergunto: E como fica a qualidade das entregas?

Simplesmente falando: Não é possível desenvolver software, com todos os testes necessários, e entregar nos prazos típicos de "sprints" que as equipes usam.

E por que conseguem entregar? Porque estão entregando produtos inacabados!


Testes fazem parte do produto e com ele devem ser entregues ao cliente!
O cliente pagou pelo seu tempo, portanto, pagou pelos testes, mas você não os entrega... O que é isso? Deixar de entregar algo que foi pago? Estelionato? 

As regras que deveriam ser escritas em pedra são: 

  1. Testes devem ser criados com base nos requisitos: Sim, o requisito é o foco e não o código implementado. Roteiros e scripts deveriam ser escritos no momento em que coletamos as "histórias de usuários". E deveriam ser versionados e mantidos;
  2. Testes devem ser criados ANTES do software: Sim! Já que você tem os roteiros e scripts, crie os casos de teste antes do software começar a ser escrito;
  3. Devem existir testes segregados e automatizados: Isso mesmo! Se você não sabe o que é "segregação de testes", aqui tem um artigo meu bem interessante.
Se você não segue estas regras, então não está concluindo seu trabalho como desenvolvedor de software e está entregando serviço incompleto!

Pesquisa

Eu fiz uma pesquisa, a qual repeti recentemente, com resultados muito parecidos e o quadro que obtive confirma minhas suspeitas de que as 3 regras de teste estejam sendo negligenciadas. 



Usa testes automatizados?




Testes automatizados são a única prova de que você testou seu software. Lamento, mas não há nenhuma outra maneira de comprovar que você testou o software, sem a presença de testes automatizados reproduzíveis pelo Cliente! Isso é muito importante: Deve ser possível repetir os testes de forma automática e idempotente. 

E os testes devem ser guardados e versionados juntamente com a versão do software.

Como podemos ver, cerca de 1/3 dos desenvolvedores não praticam isso. Hoje, todas as linguagens de programação modernas possuem frameworks para criação de testes automatizados, mas este não é o problema. 

Conversando com alguns desenvolvedores, ficou claro que o motivo é mais "falta de tempo". Simplesmente, os "sprints" são planejados sem considerar o tempo de criação dos casos de teste, que podem demorar tanto quanto as unidades de código! 


Cria roteiros e scripts de teste?



Este, realmente é um problema bastante sério! Roteiros de teste são cenários a serem testados, que incluem um ou mais scripts de teste. Por exemplo: "Usuário não cadastrado quer comprar um produto". Todos os scripts para cumprir esse cenário devem ser detalhados. 

Há algum tempo existem frameworks para testes baseados em comportamento, conhecidos como: BDD - Behavior Driven Development, uma técnica "ágil" frequentemente negligenciada em projetos ágeis. 

Escrever roteiros (ou cenários) e scripts (para testar uma funcionalidade específica de um cenário), servem para dirigir a criação de casos de teste automatizados. 

O maior problema das equipes ágeis é "encaixar" isso dentro de um "sprint". Deve ser feito dentro do "Sprint"? Deve haver um "Sprint" específico para criar testes? Devem ser feitos durante a "Inception?" A verdade é que simplesmente se esqueceram disso.

Sem roteiros e scripts, os testes deixam de serem baseados nos requisitos e passam a serem baseados na implementação, deixando importantes funcionalidades de fora. 

Como podem ver, metade das respostas foram "não", ou seja, os testes, quando existem, são criados "ad hoc", sem roteiro e sem script, muitas vezes feitos apenas com o esforço do próprio desenvolvedor, mas sem terem fundamento nos requisitos.


Cria casos de teste antes de desenvolver o software?





Se as pessoas não criam roteiros e scripts de teste, tampouco criam os casos de teste antes de desenvolver o software. Geralmente, o desenvolvedor corre feito um louco para entregar (Go Horse Process), pois o "Scrum master", que forçou a barra no Planning Poker, não tem a menor ideia do que seria criar um caso de teste. 



Os testes automatizados, quando existem, foram feitos após a construção, como maneira de auxiliar o desenvolvedor a testar mais rápido! Foram feitos para testar coisas específicas que o desenvolvedor considera importante, e nem sempre cobrem todo o código construído. 

Durante o "Planning Poker", são estimados "pontos ágeis" (WTF!!!!) que servem para escolher o que "cabe" e o que "não cabe" no "Sprint". Em muitos casos que eu vivenciei, testes sequer são considerados. Quando perguntados, os "Scrum Masters" dizem que seguem a "definição de pronto", e que os testes fazem parte disso. Só que não há prazo para isso. 


Sua equipe pratica segregação de testes?



Se você não segrega seus testes, então como pode saber se as integrações funcionaram? Como pode avaliar o comportamento sistêmico? É claro que não pode. Os testes, quando existem, são criados "ad hoc" e testam aspectos sem objetividade. 

O pior é as pessoas sequer saberem o que significa segregar testes... E os que sabem, não praticam. Mais uma vez, conversando com desenvolvedores, me disseram que não haveria tempo para isso.

Segregar testes é criar testes com orientação e objetivos diferentes. Eu escrevi um artigo que explica isso detalhadamente: 

Falando sobre testes…

Podemos segregar testes quanto ao modo e ao objetivo: 


  • Testes caixa preta: Avaliam a entrada e saída, sem considerar a implementação (testes de aceitação);
  • Testes caixa branca: Avaliam a implementação, considerando a complexidade ciclomática e a cobertura de código;
  • Testes unitários: Testam apenas uma unidade, verificando se está funcionando de acordo com os requisitos;
  • Testes de integração: Testam a integração entre as unidades, verificando se seguem os requisitos e a arquitetura do software;
  • Testes de sistema: Testam o software sob carga normal, stress e também testam a segurança;

Simplesmente, em sprints muito curtos e com muita funcionalidade em seu "backlog", não dá para praticar esse tipo de segregação. O que tenho visto é esses testes serem deixados para o final, feitos de forma manual e sem incluir tudo o que é necessário. 


Roda análise estática do seu código?


Análise estática é submeter seu código a algum software de LINT que varre o código-fonte buscando por erros de programação, falhas de segurança e outras vulnerabilidades. Praticamente todas as linguagens de programação possuem ferramentas assim, algumas somente estáticas (sem executar o código) e outras dinâmicas (avaliam cobertura de testes). 

A complexidade dos softwares modernos e seus frameworks impossibilita que um desenvolvedor cuide de todos os aspectos importantes, de modo a garantir um código limpo e conciso. Daí a necessidade de usar ferramentas de análise estática. Da mesma forma, uma ferramenta de análise dinâmica pode dizer o percentual do código que está sendo efetivamente executado em cada caso de teste, o que nos dá segurança de que testamos o máximo possível.


Conclusão

Como podem ver, o resultado da pesquisa mostra que testes não são uma preocupação importante nos projetos modernos. Muitas vezes, pressionados por ciclos curtíssimos de entrega, os desenvolvedores negligenciam as atividades de qualidade, focando apenas em concluir sua tarefa. 

Com isso, a qualidade geral do produto de software cai, gerando muitas falhas e retrabalho, aumentando o prejuízo das empresas. 

É claro que, quando as coisas dão errado, os gerentes buscam como culpados justamente os desenvolvedores, que trabalham contra o tempo para atender o que os "agilistas" venderam. 

Quer ver uma coisa? Durante o próximo "Poker Planning" coloque uma carta 2 vezes maior do que você realmente pensa, e diga o seguinte: "Metade dos pontos são para desenvolver e metade para testar direito". É como soltar "pum" no elevador! Todos olharão para você horrorizados. 




Nenhum comentário:

Postar um comentário