Fonte. Giphy. |
Testes de Unidade.
Que invenção maravilhosa - todos os mais comuns erros detectados antes mesmo do push.
Ficaram no passado as longas horas de debugging, o tempo desperdiçado escrevendo documentação, os recursos desviados fazendo testes de aceitação antes do deploy.
Só que não. :-)
Há long time ago, in a job far, far away eu fiz parte de um time de desenvolvimento bem interessante. A diversidade de talentos e níveis de experiência era bem alta (o que é bom!!!), mas por outro lado, a consolidação de uma cultura rígida e dogmática num ambiente dito ágil levava regularmente ao uso... pouco ortodoxo... das práticas da metodologia que achavam que estavam aplicando.
Quase 50% do esforço de desenvolvimento era gasto em Testes de Unidade, numa tentativa de se economizar esforço em Documentação e Requisitos. O Código era a Documentação, e havia um "Teste de Unidade" para cada Use Case.
A teoria até que faz sentido - é fato que, no primeiro gargalo, a documentação é a primeira vítima porque os recursos são desviados para onde se efetivamente agrega valor ao produto, código. Mas existe uma coisa chamada Requisito Não Funcional, e isto não se documenta com eficácia num Teste de Unidade.
Pior, Testes de Unidade também são código, e portanto acabam duplicando o esforço de programação quando um Requisito Funcional acaba tendo que ser mudado - o que leva à uma resistência dos gestores em admitir mudanças em features já implementadas (afinal, vai custar o dobro!) e... bom... acaba sufocando o principal objetivo da Metodologia, que é a agilidade.
Isso adicionalmente causava um overhead de (estou chutando) 10 a 15% no tempo de processamento dos Testes de Aceitação e, pior, davam uma sensação de falsa segurança - porque a quantidade enorme de pequenos Testes De Unidade (que não testavam o core business da aplicação) que nunca falhavam mascaravam as fragilidades no Controle de Qualidade.
Um exemplo clássico e trágico é a historiazinha que segue:
A Aplicação Web em questão tinha uma estratificação entre os clientes: aqueles que consumiam muito mais conteúdo que geravam (quando o faziam), e os que geravam muito mais conteúdo do que consumiam. Óbvio que era vital para o Product Owner evitar situações (sejam técnicas ou políticas) que pudessem boicotar a facilidade com que o conteúdo pudesse ser consumido, mas principalmente ele precisava à todo custo desemperrar qualquer empecilho à criação deste conteúdo (sem os poucos que geraram conteúdo, não haveria o que consumir pelos demais clientes).
A Aplicação, então, tinha (entre outras, lógico), duas Health Metrics: a quantidade de usuários cadastrados, e a quantidade de conteúdo no sistema.
Parece óbvio. Era óbvio. Mas ainda assim....
No meio daquela mar de Testes de Unidade, ninguém se deu ao trabalho de fazer um Teste que garantisse que as métricas de conteúdo fossem corretamente atualizadas no Painel de Controle do Product Owner. Só isso. :-)
O P.O. tinha na mão as Histórias implementadas, e a informação de que os Testes de Unidade estavam todos sendo executados com 100% de aprovação. E confiou nisso (era responsabilidade da Equipe garantir a integridade dos Testes, não dele!).
Um belo dia, uma crise política qualquer (que, falemos francamente, é cotidiana - todo mundo adora um drama, e a concorrência óbvio que usa isso para fatiar o mercado e tirar o dela), ocorreu uma debandada de usuários. Já havia acontecido este #mimimi antes, e a crise tinha sido superada identificando, pelas métricas, quais grupos de usuários estavam debandando, e então mitigando pontualmente as causas.
Mas desta vez, o P.O. não conseguia acertar a mão. Nada do que ele fazia parecia dar certo. Levou-se umas duas semanas (se a memória não me falha) para se detectar o que estava acontecendo, e neste momento o estrago estava grande o suficiente para comprometer os objetivos estratégicos da empresa com a aplicação.
O que aconteceu é que, por questões de "performance", as métricas de conteúdo não estavam sendo atualizadas automaticamente (ou com a regularidade necessária, não lembro mais ao certo). O P.O. sabia que estava perdendo consumidores (porque estas métricas estavam funcionando), mas como as métricas de conteúdo estavam artificialmente boas, ele concluiu que precisava atuar na captação de consumidores, quando na verdade o problema é que ele precisava desesperadamente trabalhar para evitar o sangramento de produtores!!!
Do meu ponto de vista, a falha aqui foi a absoluta falta de preocupação com os Testes de Integração, necessários para garantir a corretude da implementação das Histórias. Achou-se que os Testes de Unidade eram suficientes, e ninguém empregou esforços para garantir a completude e corretude das Histórias.
O aftermath foi que, por estes e outros motivos, quando eu fui pedir ao gestor minha transferência da equipe (porque, francamente, eu já não confiava mais nela), fiquei sabendo que o P.O. também havia pedido a cabeça da equipe. :-D
O que aconteceu depois é papo para outra oportunidade. Hint: eu consegui o que pedi, mas não da forma que eu desejava! ;-)
Que invenção maravilhosa - todos os mais comuns erros detectados antes mesmo do push.
Ficaram no passado as longas horas de debugging, o tempo desperdiçado escrevendo documentação, os recursos desviados fazendo testes de aceitação antes do deploy.
Só que não. :-)
Há long time ago, in a job far, far away eu fiz parte de um time de desenvolvimento bem interessante. A diversidade de talentos e níveis de experiência era bem alta (o que é bom!!!), mas por outro lado, a consolidação de uma cultura rígida e dogmática num ambiente dito ágil levava regularmente ao uso... pouco ortodoxo... das práticas da metodologia que achavam que estavam aplicando.
Paradoxal? Com certeza! Participei de equipes sob RUP bem mais flexíveis!Uma destas práticas era o Teste de Unidade.
Quase 50% do esforço de desenvolvimento era gasto em Testes de Unidade, numa tentativa de se economizar esforço em Documentação e Requisitos. O Código era a Documentação, e havia um "Teste de Unidade" para cada Use Case.
A teoria até que faz sentido - é fato que, no primeiro gargalo, a documentação é a primeira vítima porque os recursos são desviados para onde se efetivamente agrega valor ao produto, código. Mas existe uma coisa chamada Requisito Não Funcional, e isto não se documenta com eficácia num Teste de Unidade.
Pior, Testes de Unidade também são código, e portanto acabam duplicando o esforço de programação quando um Requisito Funcional acaba tendo que ser mudado - o que leva à uma resistência dos gestores em admitir mudanças em features já implementadas (afinal, vai custar o dobro!) e... bom... acaba sufocando o principal objetivo da Metodologia, que é a agilidade.
Alguns Requisitos são mais baratos de serem mantidos com o trio Documentação, Teste e Código (esta tríplice aliança ainda será discutida neste blog!) - há mais profissionais disponíveis na empresa capacitados nos dois primeiros que no último (pense nisso!).O pessoal chegava à um nível de detalhamento absurdo - fazendo Testes de Unidade para o CRUD no banco de dados! Vá pra porra, se você não confia no BD e/ou no framework (afinal, estes componentes possuem seu próprio ciclo de vida e foram aprovados em algum momento, não?), então você não deve usá-los em produção e ponto final!
Isso adicionalmente causava um overhead de (estou chutando) 10 a 15% no tempo de processamento dos Testes de Aceitação e, pior, davam uma sensação de falsa segurança - porque a quantidade enorme de pequenos Testes De Unidade (que não testavam o core business da aplicação) que nunca falhavam mascaravam as fragilidades no Controle de Qualidade.
Um exemplo clássico e trágico é a historiazinha que segue:
A Aplicação Web em questão tinha uma estratificação entre os clientes: aqueles que consumiam muito mais conteúdo que geravam (quando o faziam), e os que geravam muito mais conteúdo do que consumiam. Óbvio que era vital para o Product Owner evitar situações (sejam técnicas ou políticas) que pudessem boicotar a facilidade com que o conteúdo pudesse ser consumido, mas principalmente ele precisava à todo custo desemperrar qualquer empecilho à criação deste conteúdo (sem os poucos que geraram conteúdo, não haveria o que consumir pelos demais clientes).
A Aplicação, então, tinha (entre outras, lógico), duas Health Metrics: a quantidade de usuários cadastrados, e a quantidade de conteúdo no sistema.
Parece óbvio. Era óbvio. Mas ainda assim....
No meio daquela mar de Testes de Unidade, ninguém se deu ao trabalho de fazer um Teste que garantisse que as métricas de conteúdo fossem corretamente atualizadas no Painel de Controle do Product Owner. Só isso. :-)
O P.O. tinha na mão as Histórias implementadas, e a informação de que os Testes de Unidade estavam todos sendo executados com 100% de aprovação. E confiou nisso (era responsabilidade da Equipe garantir a integridade dos Testes, não dele!).
Um belo dia, uma crise política qualquer (que, falemos francamente, é cotidiana - todo mundo adora um drama, e a concorrência óbvio que usa isso para fatiar o mercado e tirar o dela), ocorreu uma debandada de usuários. Já havia acontecido este #mimimi antes, e a crise tinha sido superada identificando, pelas métricas, quais grupos de usuários estavam debandando, e então mitigando pontualmente as causas.
Mas desta vez, o P.O. não conseguia acertar a mão. Nada do que ele fazia parecia dar certo. Levou-se umas duas semanas (se a memória não me falha) para se detectar o que estava acontecendo, e neste momento o estrago estava grande o suficiente para comprometer os objetivos estratégicos da empresa com a aplicação.
O que aconteceu é que, por questões de "performance", as métricas de conteúdo não estavam sendo atualizadas automaticamente (ou com a regularidade necessária, não lembro mais ao certo). O P.O. sabia que estava perdendo consumidores (porque estas métricas estavam funcionando), mas como as métricas de conteúdo estavam artificialmente boas, ele concluiu que precisava atuar na captação de consumidores, quando na verdade o problema é que ele precisava desesperadamente trabalhar para evitar o sangramento de produtores!!!
Do meu ponto de vista, a falha aqui foi a absoluta falta de preocupação com os Testes de Integração, necessários para garantir a corretude da implementação das Histórias. Achou-se que os Testes de Unidade eram suficientes, e ninguém empregou esforços para garantir a completude e corretude das Histórias.
O aftermath foi que, por estes e outros motivos, quando eu fui pedir ao gestor minha transferência da equipe (porque, francamente, eu já não confiava mais nela), fiquei sabendo que o P.O. também havia pedido a cabeça da equipe. :-D
O que aconteceu depois é papo para outra oportunidade. Hint: eu consegui o que pedi, mas não da forma que eu desejava! ;-)