Testes contínuos vs. Testes tradicionais
Não, esse artigo não é de autoria minha, apenas uma tradução, ou, na verdade, uma adaptação, até porque nem sou tradutor e com alguns comentários meus.
O artigo original é do @Ronald Cummings-John que inclusive me deu permissão, para colocar esse artigo em português e facilitar o debate na minha língua nativa.
Então segue o fio. (inclusive mantive os termos em primeira pessoa, assim como escrito no artigo), os meus comentários serão formatados assim.
“Ouvimos muito o termo ‘teste contínuo’ na indústria de teste de software. É um daqueles bordões que continuam aparecendo, mais e mais vezes.
Mas o que isso realmente significa? E por que isso é útil?
Anteriormente, o teste contínuo era simplesmente visto como o processo de execução de testes automatizados como parte do pipeline de entrega do software.
Em um passado não tão distante eu jurava que era exatamente isso!
Estava claro para mim que o teste contínuo era o ponto principal de muitas dessas pessoas.
Neste artigo, discutirei as principais diferenças entre testes contínuos e testes tradicionais e as escolas de pensamento da comunidade de controle de qualidade em relação aos benefícios de cada método. É minha convicção que o teste contínuo pode ter muitos benefícios interessantes e sua implementação eficaz pode ajudá-lo a obter resultados de qualidade.
Então o que isso significa?
O teste contínuo faz o que diz na lata trata-se de testar continuamente. Isso significa testar software, aplicativos ou sites em todas as fases do seu ciclo de vida. Se você estiver realmente executando um teste contínuo, estará incorporando o teste antes mesmo de uma linha de código ser escrita e até mesmo após o lançamento.
Infelizmente ainda tem muuuita gente que acha que testes ou qualidade de software só se iniciam quando a tarefa chega na coluna de “testing” do quadro Kanban
Isso significa que você está evitando problemas antes que eles aconteçam colocando a qualidade na vanguarda desde o início. As habilidades que você pode usar para testar um aplicativo nos testes tradicionais estão sendo usadas para testar um conceito, ideia ou os designs de estágio inicial que ainda não foram totalmente formados. Isso é semelhante à mentalidade por trás do TDD (Test-Driven-Development).
Essencialmente, você está construindo a testabilidade em seu produto e código, desde o início.
Acho que pra mim essa é a palavra chave desse artigo. Pois tudo pode e deve ser testável tendo como objetivo aumentar,ainda mais, a qualidade das entregas, e inclusive uma das dificuldades que mais sinto é a falta de testabilidade em projetos que partcipo/participei
Dan Ashby escreveu um artigo extremamente perspicaz sobre esse tópico, incluindo um gráfico fantástico para demonstrar o que significa realmente testar continuamente.
Basicamente, significa … você está sempre testando! Mas os testes podem, de fato, começar mesmo antes do planejamento. Dan diz:
“Testar a ideia é vital; investigando para descobrir informações, refatorando a idéia de aprimorá-las e solidificá-las. ”
O que Dan está sugerindo é que a idéia de ‘testar’ não significa necessariamente escrever um script de teste automatizado ou algo semelhante e enviá-lo. Você pode testar uma idéia, discutir possíveis falhas e bugs e resolver problemas antes de iniciar um processo formal de teste tradicional.
Por que não usar apenas os testes tradicionais?
Tradicionalmente, o controle de qualidade e o teste eram considerados uma reflexão tardia executando uma série de testes logo antes do lançamento, no final do ciclo de vida do produto.
O que esse método tradicional significa é que o Product Owner pensa em uma ideia, decide se é viável, a envia à equipe de desenvolvimento para codificar, que a envia à equipe de controle de qualidade para testes antes do lançamento.
Isso parece bastante simples. Mas, de fato, isso significa que o processo de desenvolvimento de software se torna muito linear. Em vez de um processo cíclico, no qual o controle de qualidade está envolvido desde o início, esse método tradicional passa o produto pela linha priorizando a velocidade sobre a qualidade e isso significa que os erros aparecem ao longo do caminho.
Mas a qualidade não pode sofrer em favor da velocidade de lançamento.
É aí que entra o teste contínuo.
Como implementar testes contínuos
Isso pode parecer muito mais trabalho. E para as equipes que precisam de tempo e sob muita pressão para liberar rapidamente, um trabalho extra pode parecer quase impossível. A idéia de testes extras em todas as etapas do ciclo de vida do produto pode envolver até a equipe de engenharia mais esperta do mundo. Porém, os testes contínuos não precisam desacelerar o processo de liberação nem exigir contratações internas caras e extras.
Você pode implementar testes contínuos sem que isso se torne um gargalo.
Então, como você implementa essa técnica efetivamente?
1. Planeje e decida quais testes você está realizando desde o início. Fazer
testes contínuos sem um plano claro só levará à confusão e perda de tempo. Pense em quais testes que o seu produto exige em cada estágio do processo de desenvolvimento. Isso informará quais ferramentas você precisa adquirir, se necessário, e onde sua equipe precisa reorientar seus esforços.
Achei bem interessante o planejamento dos testes voltando a ser uma atividade, prática que, particularmente só fiz quando trabalhava em cascata
Teste apenas o que você precisa para testar
O teste contínuo não significa testes duplicados sem fim e horas de trabalho extra.
Interrompa seu ciclo de liberação e identifique se algum teste repetitivo desnecessário ocorreu antes da implementação do teste contínuo.
Isso garantirá que você não perca tempo e dinheiro em tarefas fúteis.
Menos as vezes é mais
Automatize onde necessário
Isso está relacionado ao ponto dois. Se você estiver executando manualmente o mesmo teste repetidamente, com a mínima necessidade de alterar os scripts de teste: automatize-o. Os testes de automação, quando necessário, irão acelerar drasticamente seu processo de controle de qualidade e permitir que você execute centenas de testes com o toque de um botão.
A automação de teste fornece feedback quase instantâneo e funciona excepcionalmente bem para ‘verificar’ os testes. Isso significa que você pode cortar o trabalho repetitivo e obter resultados rápidos.
No entanto, todas as técnicas de teste manual têm seu lugar, e é essencial no estágio de planejamento que você as incorpore ao seu kit de ferramentas de teste.
Uma mistura de testes automatizados e manuais ajudará você a obter essa cobertura completa de teste que toda equipe de engenharia e controle de qualidade precisa.
Assim eliminando o mito de que testes manuais tem que acabar totalmente.
Configure seus testes
Os testes contínuos podem ser implementados em todas as etapas do seu pipeline de entrega.
Portanto, configure suítes de teste nos pontos principais que você identificar. Podem ser todas as alterações de código, mesclagem ou um novo commit. Use uma combinação de métodos de teste e comece a configurá-los no início do processo de codificação, até a implantação.
Como mencionei anteriormente, além de configurar os conjuntos de testes, pense em como você pode testar idéias, criar testabilidade em seu código e continuar testando muito além do lançamento.
Está ai uma alternativa para acabar com a falta de testabilidade que comentei anteriormente.
Sua estratégia de teste contínuo deve ser como um organismo vivo: sempre mudando, adaptando-se e desenvolvendo aprendizados anteriores.
Por que o teste funciona continuamente
Considero útil a pesquisa realizada pela Capers Jones ao expressar por que esse método funciona.
Jones descobriu que, em um ciclo de lançamento típico, um bug encontrado após o lançamento poderia custar US $ 16.000 ou mais para resolver. Isso é suficiente para dar água nos olhos de qualquer CTO especialmente quando os orçamentos são limitados.
Mas o que Jones descobriu é que os desenvolvedores poderiam ter corrigido o mesmo bug nos estágios iniciais por apenas US $ 25. Basta dar uma olhada no gráfico que ele criou abaixo:
O que este gráfico mostra é que a maior porcentagem de defeitos é introduzida nos estágios iniciais do processo de desenvolvimento. Esses são os bugs mais baratos para corrigir então, por que não os corrigimos mais cedo? Por que não economizar tempo e dinheiro preciosos, mas testando antes que seja tarde demais?
O teste contínuo permite detectar esses bugs frustrantes antes que eles se tornem problemas maiores. É muito importante pensar em qualidade desde o início, para economizar dinheiro, trabalho desnecessário e bugs que causam muitos problemas à sua equipe.
Conclusão
Quando feito corretamente, o teste contínuo garante qualidade no software que você cria, reduz bugs críticos e economiza dinheiro.
Manter o controle de qualidade em mente diminui a probabilidade de um bug enorme e caro ser descoberto antes da data de lançamento e colocar o freio no processo.
Dessa forma, mais testes não são um gargalo, mas, na verdade, uma maneira de construir as bases para lançamentos futuros bem sucedidos.
Qualidade é crucial. E seus clientes sempre esperam isso. Testando cedo e com freqüência, você pode melhorar a qualidade do seu software e encontrar os erros críticos antes de seus clientes.”
Bem, é isso, a conclusão foi perfeita. E pra mim ficou a sensação de que com essas dicas fica mais fácil de enxergar/praticar testes contínuos e para você?