Elevator Pitch
Redução de custos, melhor ciclo de entregas e maior credibilidade para sua marca!
Nessa palestra irei mostrar porque testes de software devem ser encarados como um recurso estratégico para a sua empresa e como escrevê-los.
Description
Porque realizar testes de software?
Todas as vezes que implementamos uma nova funcionalidade, queremos garantir não apenas que ela esteja executando como o esperado mas também que não quebre nada que já foi construído, preservando a integridade do sistema.
Qual a importância de manter tudo funcionando?
Toda vez que encontramos um bug no ambiente de produção, ele representa um custo para a empresa que pode ser expresso de várias maneiras: - Atraso em entregas - Distrações da equipe - Insatisfação dos clientes - Dano à reputação - Perda de receita
Atraso em entregas
Todas as vezes que um bug precisa de ser corrigido, o time de desenvolvimento precisa de parar o que está fazendo e dar atenção para ele. Quando isso acontece, as tarefas de novas features e melhorias técnicas ficam paralisadas, esperando que o bug seja resolvido e consequentemente, o prazo de entrega acaba sendo afetado.
Distrações da equipe
Quando o bug é resolvido e o desenvolvedor precisa de voltar para a tarefa de “feature”, essa troca de contexto não acontece de maneira instantânea e são necessários alguns minutos até que a produtividade e a concentração seja retomada. Resolução de bugs urgentes também fazem com que fiquemos em um estado de alerta, ficando mais ativos e ansiosos. O retorno para um estado calmo e concentrado costuma demorar para acontecer.
Insatisfação do cliente
Os clientes pagam pelos nossos produtos porque têm a expectativa de que nós seremos capazes de resolver uma necessidade que eles tem, que muitas vezes pode ser um problema sério ou um motivo pessoal extremamente relevante. Se um cliente com altas expectativas tenta acessar nosso produto e tem sua experiência frustrada por um bug, ele pode desistir de nós.
Dano à reputação
Um cliente insatisfeito, pode não apenas representar um churn no volume de nosso negócio, mas também espalhar o ponto de vista de sua experiência ruim para pessoas conhecidas. Se coloque no lugar dele: se você estiver querendo usar um novo software de edição de texto por exemplo e você vir uma publicação de uma pessoa que você admira muito reclamando de um bug nessa plataforma, você sentiria vontade de usá-la?
Perda de receita
A perda de receita pode acontecer tanto indiretamente, como através do churn e perca de oportunidades novas de negócio por conta de má reputação, quanto diretamente, quando o usuário não consegue efetuar uma compra. Imagine que você trabalha em uma plataforma de ecommerce e o sistema de checkout está com problema, impedindo que os clientes finalizem suas compras, isso é um impacto direto na receita.
E como reduzir esses custos?
Existem algumas alternativas para reduzir esses custos que vão desde o momento inicial da concepção do software, como na pesquisa de mercado, entrevistas com usuários, foco na experiência e acessibilidade e outros, mas gostaria de falar nesta talk sobre como podemos reduzir esses custos no processo de desenvolvimento, enquanto estamos codando com nossas ides e editores de textos abertos.
Se você está desde o começo e leu o título da palestra, deve suspeitar do assunto que eu quero falar: Testes de Software.
Por que Fazer Testes de Software?
Beleza, entendemos que bugs representam custos para a empresa e que quanto mais demoramos para vê-los, mais caros eles ficam. Mas ainda não entendi porque fazer testes de software? Contratar uma pessoa para fazer esses testes manualmente já não bastaria?
Se tivéssemos que (ou designássemos uma pessoa para) testar todas as funcionalidades de maneira manual, seria cansativo, demorado e extremamente susceptível a falhas.
Pense comigo, imagine os fluxos de trabalho complexos que tem na sua empresa, agora imagine uma pessoa testando todos eles na mão, um por um. Se essa pessoa estiver com fome? Ou se estiver cansada? Isso não impactaria a performance dela na execução dos testes e em lembrar os contextos?
Tudo que boas empresas e bons times querem no final do dia é que as pessoas consigam realizar os seus trabalhos da melhor forma possível, da maneira mais rápida e podendo sair no final do dia desligando o computador sem ter que se preocupar com nada.
Sendo assim, os Testes de Software são uma grande ferramenta que vão nos guiar para a entrega de excelentes resultados e para ter um bom dia-a-dia como pessoas de tecnologia.
Na literatura existe a clássica pirâmide de testes, na qual falamos sobre Testes Unitários, Testes de Integração e Testes End-to-End, mas também existem outros tipos que podem ser bem úteis dependendo do contexto de implementação do seu time: Testes de Arquitetura, Testes de Contrato, Testes de Performance e outros.
Os tipos de testes que irei trazer aqui são os mais comumente utilizados e eu garanto para vocês, se hoje caso vocês não tenham testes na empresa de vocês e optem por começar com o setup que irei apresentar, já estará 1000% melhor do que da versão anterior.
Um pequeno disclaimer aqui é que estou trazendo o setup de testes sobre a ótica do desenvolvimento de micro serviços e sistema distribuídos, mas esse setup pode mudar um pouco de acordo com o contexto de atuação de vocês, beleza?
Testes Unitários
Comentário: O Objetivo aqui é mostrar um pequeno sistema de estoque, com funcionalidades bem simples. O sistema será uma api usando spring boot e um banco de dados relacional. Nessa primeira sessão farei um setup com alguns testes que julgo interessantes realizarmos como unitários
Testes unitários são muito bons para testar escopos isolados e fluxos de negócio específicos (cálculo de fórmulas matemáticas, conversão de arquivos, processamento de áudio, etc) e testar aspectos comportamentais do código (sequência de chamada de métodos, asserção de chamadas).
Porém eles tem uma limitação: não conseguem testar mudança de estados em um banco de dados, não conseguem aferir se uma mensagem foi enviada para um broker e também não garantem a idempotência em sua aplicação.
Então como garantir isso?
Testes de Integração
O objetivo dessa sessão é mostrar como os testes de integração podem garantir que comportamentos essenciais funcionem para nossa aplicação (gestão de transações, controle de concorrência, idempotência e outros).
Os testes de integração servem para testar o maior escopo possível dentro da fronteira de um micro serviço e com eles podemos verificar a interação com diversos componentes de nossa aplicação: annotations, decorators, bancos de dados, brokers de mensagem (e até protocolos como SMTP e SSH se você quiser muito😝).
Considerações finais
Com esses dois tipos de testes, conseguimos ter um alto nível de confiança em nossas aplicações, garantindo que novas funcionalidades serão entregues sem quebrar tudo no ambiente de produção.
Notes
Objetivo
O objetivo dessa palestra é espalhar a palavra da importância da realização do testes em equipes de desenvolvimento. É um assunto que muitas vezes é deixado de lado, não é dada a devida prioridade, mas sinto que todos os desenvolvedores que conhecem o mínimo sobre testes, gostariam de implementá-los em suas equipes. Gostaria de por meio dessa talk, conseguir trazer mais argumentos para o nosso lado tech e quem sabe fazer com que mais equipes tenham testes em seus fluxos de trabalho.
Por que eu?
Olá! Muito prazer, me chamo Tiago Calado, sou desenvolvedor desde 2017 e já passei por algumas empresas ao longo da minha trajetória profissional. Desde que conheci a “palavra” dos testes fiquei fascinado por esse assunto e já cheguei a lutar para realizar essas implementações em algumas equipes que passei. Também gosto muito de espalhar o conhecimento e já fiz uma talk parecida com essa para minha squad de backend em janeiro de 2025.