O teste de software realmente vale a pena?

Sim e não. Bem, como em tudo, depende. Neste post, tentarei ilustrar minha experiência com testes como desenvolvedor e depois como fundador de uma startup.

Sobre mim

Oi! Sou Simone, desenvolvedora full-stack e CTO com 15 anos de experiência em codificação em vários setores, incluindo agência da Web, comércio eletrônico, software adulto e empresarial. Nesta postagem de blog, gostaria de compartilhar ideias sobre teste de software e como determinar métodos apropriados para diferentes necessidades e estágios de negócios.

Sou o CTO e cofundador da Bugpilot, uma ferramenta de monitoramento de bugs que ajuda as equipes de SaaS a detectar bugs que escaparam dos processos de desenvolvimento, teste e controle de qualidade.

Introdução

Diferentes tipos de teste

No mundo do desenvolvimento de software, muitas práticas de teste há muito são consideradas essenciais para garantir a confiabilidade e a qualidade dos produtos de software. No entanto, é importante reconhecer que, embora essas metodologias tenham seus méritos, elas também apresentam suas desvantagens.

Esta postagem do blog tem como objetivo iniciar uma conversa e esclarecer os possíveis danos que TDD e QA podem infligir às equipes de software. Ao reconhecer que não existe uma abordagem única para todos e que diferentes negócios e estágios exigem métodos apropriados, podemos começar a navegar pelas complexidades do desenvolvimento de software com mais eficiência.

Reconheço muitas metodologias diferentes, práticas comuns e recomendações sobre teste de software; nesta postagem, concentrei-me principalmente no desenvolvimento orientado a testes e na garantia de qualidade.

Aqui está uma visão geral, caso você não esteja familiarizado com os termos:

TDD

Desenvolvimento orientado a testes (TDD) é um método de desenvolvimento de software que envolve escrever testes automatizados antes de escrever o código. Isso ajuda a detectar problemas no início do ciclo de desenvolvimento, garantindo que o código seja totalmente testado e atenda aos requisitos de negócios. Os desenvolvedores primeiro definem o comportamento esperado de um novo recurso com um teste, depois escrevem o código para passar no teste e, finalmente, otimizam o código por meio da refatoração.

controle de qualidade

Garantia de qualidade (QA) garante que o software atenda aos padrões de qualidade antes do lançamento. Normalmente, um processo manual realizado por um Engenheiro de QA identifica e corrige defeitos por meio de testes manuais e automatizados, como verificação de requisitos funcionais e verificação de desempenho. Isso garante um software confiável e estável que atende às necessidades de negócios e do usuário final.

Algumas perguntas para você!

Meu objetivo com este post é iniciar uma conversa. Não posso deixar de enfatizar que acredito firmemente que os testes são necessários em muitos casos. Pense em aparelhos médicos, software de aeronaves, sistemas de controle, bancos e muito mais, software em uso por bilhões de pessoas, onde a cor de um botão faz uma diferença significativa nos lucros.

O desenvolvimento de software requer um equilíbrio entre estrutura e flexibilidade, e seguir cegamente os princípios de teste sem considerar o contexto pode levar a resultados abaixo do ideal - as bibliotecas de código provavelmente se beneficiam de 99% de cobertura. Mas seu software também precisa de 99% de cobertura?

Eu preparei algumas perguntas. Tente responder sim ou não - por que isso?

• Você realmente precisa testar seus componentes de IU?
• Você precisa de testes E2E para essa funcionalidade de “atualizar foto do perfil”?
• Você falha no controle de qualidade e atrasa um lançamento se houver uma pequena inconsistência entre os designs do Figma e a interface do usuário real? Qual é o limite?
• Devo demitir John por se recusar a escrever testes?

Capítulo 1. Meu caso contra o Test-Driven Development

Desafiando o dogma

O desenvolvimento orientado a testes (TDD) ganhou seguidores quase religiosos. Alguns afirmam que ajuda na saúde mental, e muitas vezes é acompanhado pela crença dogmática de que é o único caminho para o sucesso. Este capítulo visa explorar as desvantagens do TDD e lançar luz sobre a armadilha de rigidez, restrições de tempo e falsa sensação de segurança .

Como CTO, encontrei colegas que insistiam firmemente no TDD até mesmo para as funções mais triviais. O dogma predominante parecia ser: "Você deve fazer TDD, ou você é um idiota!" Essa crença inabalável no TDD como a única abordagem aceitável muitas vezes me fez questionar meu próprio julgamento e competência. Lembro-me claramente de incidentes em que riam de mim por me recusar a escrever testes para uma função simples de 2 linhas para filtrar um array.

Essa experiência pessoal destacou uma das principais armadilhas do TDD - a armadilha da rigidez. A adesão dogmática a escrever testes primeiro às vezes pode levar a processos rígidos, que podem, por sua vez, impactar o tempo de colocação no mercado de uma empresa e a vantagem competitiva.

É realmente vale a pena o tempo?

Um desafio significativo colocado pelo TDD é a restrição de tempo que ele impõe ao processo de desenvolvimento.

Escrever testes abrangentes para cada parte do código pode consumir muito tempo, especialmente para funções triviais que têm impacto mínimo no sistema geral. Em ambientes de ritmo acelerado, onde iterações rápidas e entrega pontual são cruciais, a sobrecarga adicional de TDD pode retardar o ciclo de desenvolvimento e prejudicar a agilidade.

Acho irracional sempre seguir a abordagem “preciso de 99% de cobertura”. Equilibrar meticulosidade e eficiência é essencial, e há cenários em que uma abordagem de teste mais simplificada pode ser mais apropriada, permitindo iterações mais rápidas e respostas mais rápidas às demandas do mercado.

Além disso, a complexidade e a imperfeição de escrever testes que envolvem interações com dependências externas ou sistemas complexos podem agravar ainda mais as restrições de tempo do TDD.

Como desenvolvedor, posso até dizer que gosto de escrever testes, mas… encontre um CEO que esteja feliz que sua equipe gastou 80% de seu tempo escrevendo testes para códigos que eventualmente serão excluídos.

Os desenvolvedores geralmente precisam criar objetos fictícios ou stubs para simular o comportamento dessas dependências durante o teste. Embora as simulações possam ser ferramentas valiosas para isolar o código e reduzir as dependências, elas também podem introduzir sobrecarga e complexidade adicionais.

A dependência de simulações pode levar a uma representação imperfeita das interações do mundo real, pois pode ser um desafio replicar o comportamento de sistemas externos ou componentes de terceiros com precisão. Isso pode introduzir um nível de incerteza no processo de teste, resultando potencialmente em falsos positivos ou falsos negativos.

Os testes estão passando; Posso ter uma boa noite de sono, certo? Certo?

Os testes estão passando; Eu posso dormir são e salvo!

Há um perigo inerente, mas muitas vezes negligenciado, de confiar apenas em testes - uma falsa sensação de segurança. Embora o teste seja sem dúvida essencial para identificar e prevenir defeitos, não é uma solução infalível.

“Testamos em todos os dispositivos?”

Também é difícil testar todos os casos possíveis. Especialmente no campo do desenvolvimento web, há uma infinidade de fatores que podem afetar a experiência do usuário. Um desses fatores é a diversidade de dispositivos do usuário final, incluindo diferentes tamanhos de tela, resoluções, sistemas operacionais e navegadores. Cada combinação apresenta um conjunto único de desafios que podem afetar a forma como o software funciona e aparece para os usuários.

Considere a vasta gama de dispositivos e configurações: smartphones, tablets, laptops e desktops, rodando em iOS, Android, Windows ou macOS, usando várias versões de navegadores como Chrome, Safari, Firefox, Edge ou Internet Explorer. Cada combinação de dispositivo, sistema operacional e navegador pode renderizar o conteúdo da Web de maneira diferente, e as interações do usuário também podem variar. É virtualmente impossível antecipar e contabilizar todos os dispositivos e configurações possíveis, dificultando a cobertura completa dos testes.

“Eu testei esta IU como se fosse minha avó?”

Personas e perfis de usuários adicionam outra camada de complexidade. Seu software pode atingir um público diversificado com diferentes preferências, comportamentos e necessidades de acessibilidade . O teste pode ajudar a descobrir problemas que surgem em cenários típicos, mas pode perder casos extremos ou interações específicas do usuário que se desviam da norma. Por exemplo, usuários com deficiência visual que dependem de tecnologias assistivas podem encontrar desafios de usabilidade que são difíceis de capturar apenas por meio de testes automatizados.

Além das variações técnicas, o contexto do usuário e os cenários do mundo real desempenham um papel crucial na formação da experiência do usuário. Fatores como condições de rede, limitações de largura de banda ou uso simultâneo podem afetar o desempenho e a confiabilidade do software.

Embora os testes possam fornecer um ambiente controlado, eles podem não simular com precisão as diversas condições de rede e padrões de uso que os usuários encontram em suas vidas diárias. Se os testes não podem garantir que seu software funcione bem, eles valem a pena no final do dia?

Capítulo 2. QA e a necessidade de velocidade

Testemunhei em primeira mão os desafios impostos pelas práticas “rígidas” de Garantia de Qualidade, especialmente quando se trata de empresas menores que devem se mover rapidamente para se manterem à frente de seus concorrentes.

Acredito que isso seja especialmente verdadeiro para startups em estágio inicial; é provável que você jogue fora todo o recurso em breve se seus clientes não o estiverem usando. Então, valeu a pena aquela semana inteira de testes e refinamento dos testes de unidade?

Deixe-me compartilhar minhas experiências pessoais e esclarecer os perigos de ser pego pelo perfeccionismo, especialmente quando aspectos visuais ou de apresentação menores se tornam o foco dos esforços de controle de qualidade.

Em minha função anterior em uma startup, enfrentávamos uma batalha constante entre fornecer recursos rapidamente e garantir uma qualidade impecável. Houve casos em que nosso ciclo de lançamento foi atrasado desnecessariamente devido a problemas minúsculos, como uma margem de CSS desalinhada, uma escolha de fonte incorreta ou uma quebra de linha ausente. Embora a atenção aos detalhes seja importante, comecei a questionar o impacto da obsessão por essas imperfeições cosméticas em nossa capacidade de permanecer à frente no mercado.

Um dos riscos do controle de qualidade excessivo é a priorização da perfeição sobre a praticidade. Em nossa busca pela perfeição, muitas vezes nos vimos investindo tempo e recursos significativos para corrigir falhas visuais minúsculas. Isso não é inimigo da produtividade?

Embora seja essencial manter altos padrões, comecei a perceber que dedicar muito esforço a esses detalhes minuciosos pode ser contraproducente, desviando nosso foco da funcionalidade principal e das melhorias na experiência do usuário que realmente importam para nossos clientes.

O perigo tornou-se aparente quando observamos as consequências de uma abordagem de controle de qualidade excessivamente cautelosa. Nossa equipe começou a exibir um comportamento avesso ao risco, optando por um processo de liberação lento e meticuloso. Embora a intenção fosse entregar um produto quase perfeito, inadvertidamente sufocamos a inovação e prejudicamos nossa capacidade de responder rapidamente às demandas dos clientes. Como uma empresa pequena (30 funcionários), contamos com nossa agilidade para iterar rapidamente e superar os concorrentes maiores. No entanto, práticas excessivas de controle de qualidade resultaram em um medo generalizado de “bugs” que nos impediam.

Não deveríamos aceitar a existência de bugs? Quem trabalha erra; se você não trabalhar, você nunca cometerá erros. (Desculpe - citação de futebol)

Capítulo 4. Os clientes podem ser os melhores testadores

As implicações financeiras dos ciclos de liberação prolongada tornaram-se evidentes. Janelas de mercado perdidas, geração de receita atrasada e rotatividade de clientes em potencial começaram a cobrar seu preço. Não podíamos nos dar ao luxo de ser uma pequena empresa com recursos limitados. Precisávamos alavancar nossa agilidade e velocidade para aproveitar as oportunidades e manter uma vantagem competitiva.

O tempo gasto no aperfeiçoamento de pequenos detalhes precisava ser equilibrado com a necessidade de iteração rápida e capacidade de resposta do mercado. Adiar, adiar e adiar cada lançamento até termos “mais certeza” de que tudo funciona; o envio às terças-feiras tornou-se a opção preferida. Por que enviar na segunda-feira se podemos levar mais um dia para testar tudo?

Embora o teste ajude a identificar e prevenir defeitos, é igualmente importante adotar o feedback do usuário como uma fonte valiosa de informações. As experiências, preferências e sugestões dos usuários podem fornecer insights que vão além do que os testes sozinhos podem revelar. Podemos criar um produto centrado no usuário que atenda às suas expectativas, promovendo um ciclo de feedback com os usuários, ouvindo ativamente suas necessidades e incorporando suas contribuições ao processo de desenvolvimento.

Em vez de depender apenas de testes internos extensivos, envolver os usuários no processo de teste pode ser altamente benéfico. Os primeiros testes do usuário, como testes beta ou estudos de usabilidade, permitem que cenários do mundo real e interações do usuário sejam observados.

Essa abordagem centrada no usuário ajuda a identificar pontos problemáticos, problemas de usabilidade e problemas imprevistos que podem não ser detectados apenas por meio de testes internos. Incorporar esse feedback desde o início pode melhorar muito a experiência e a satisfação do usuário.

Infelizmente, testemunhei pessoalmente um forte “desequilíbrio” em muitas equipes de software. Aqui está uma pergunta para você: o controle de qualidade deve falhar devido a uma inconsistência de interface do usuário? Com que frequência o controle de qualidade deve falhar?

Capítulo 5. “Os usuários sairão se encontrarem um bug!”

A pesquisa destaca consistentemente o impacto negativo da funcionalidade quebrada na retenção de usuários. Fomos informados de que muitos estudos mostram que os usuários têm menos probabilidade de continuar usando um produto se encontrarem bugs, travamentos ou erros frequentes que atrapalham sua experiência.

De acordo com uma pesquisa da Qualitest , 88% dos usuários abandonarão um aplicativo após apenas uma ou duas ocorrências de baixo desempenho. Essas descobertas enfatizam o papel crítico que a estabilidade funcional desempenha na retenção de usuários e na construção de engajamento de longo prazo.

Quando os usuários encontram uma funcionalidade quebrada, isso diminui sua confiança no produto e na equipe de desenvolvimento por trás dele. Mesmo que os problemas sejam eventualmente resolvidos, os usuários podem desenvolver uma percepção negativa e relutar em retornar. Os usuários podem perder a confiança em um site ou aplicativo se experimentarem repetidamente erros ou falhas funcionais.

Mas… isso ainda é verdade em 2023?

Bugs estão por toda parte, e todos nós sabemos que software livre de bugs pode nunca existir .

Os usuários podem encontrar bugs de tempos em tempos, e é importante distinguir entre bugs menores e problemas críticos de funcionalidade. Hoje em dia, os usuários podem ser mais indulgentes com pequenos bugs que não afetam significativamente sua experiência geral. Em nossa opinião, os usuários aprenderam a aceitar os bugs como inevitáveis no desenvolvimento de software; insetos fazem parte do nosso dia a dia.

No entanto, quando se trata de funcionalidade principal quebrada que impede sua capacidade de usar o software conforme pretendido, os usuários provavelmente serão menos tolerantes e poderão buscar alternativas.

Bugs B2B são mais dolorosos (ou não?)

Em cenários B2B, a funcionalidade quebrada pode ter consequências graves para os usuários e seus negócios. Isso pode resultar em cronogramas de projetos atrasados, prazos perdidos e até mesmo uma perda financeira de US$ 440 milhões .

Quanto ao software de consumo, os usuários corporativos podem ficar frustrados e irritados ao encontrar bugs que os impedem de realizar seu trabalho. Sua lealdade a um produto de software está intimamente ligada à sua confiabilidade e capacidade de ajudá-los a ter sucesso em suas responsabilidades profissionais. Baixa confiabilidade deve ser igual a rotatividade mais alta.

No entanto, aprendi que nem sempre é o caso. Depois que uma organização inteira adota uma tecnologia, é fácil fazer com que toda a empresa mude para uma solução concorrente? Improvável.

O comércio eletrónico tem (mais) desafios de fidelização.

No e-commerce, os usuários têm inúmeras alternativas prontamente disponíveis na ponta dos dedos. Como usuário, seu trabalho a ser feito é muito claro. Você precisa comprar um aspirador de pó. Se o aplicativo da Amazon travar, quanto tempo antes de você tentar o próximo aplicativo em sua gaveta?

Funcionalidade quebrada ou bugs podem levar a carrinhos de compras rapidamente abandonados, diminuição permanente da satisfação do cliente e perda de oportunidades de negócios.

Capítulo 6. TDD e QA são a única solução?

Obviamente, não. Embora os testes desempenhem um papel crucial na identificação e prevenção de alguns defeitos, existem medidas adicionais que podem ser tomadas para minimizar o impacto dos bugs nos usuários. Aqui estão algumas abordagens que estudei:

Monitoramento e Rastreamento de Erros

A implementação de sistemas robustos de monitoramento e rastreamento de erros permite a identificação proativa e a resolução de problemas. O monitoramento em tempo real pode ajudar a detectar anomalias, problemas de desempenho e erros, permitindo uma correção imediata antes que afetem vários usuários. O rastreamento de erros permite a captura de detalhes do erro e ajuda a priorizar as correções de bugs com base em seu impacto nos usuários.

Ferramentas como Sentry , Rollbar , Bugsnag e Bugpilot ajudam as equipes a detectar automaticamente erros de codificação e sessões problemáticas de UX, para que as equipes possam resolver os problemas de forma proativa.

Feedback e suporte do usuário

Incentivar ativamente e coletar feedback do usuário fornece informações valiosas sobre problemas de usabilidade, bugs e áreas para melhoria. Resolver prontamente os problemas relatados pelo usuário e fornecer suporte demonstra um compromisso em resolver problemas e manter uma experiência positiva do usuário.

Ferramentas como Canny , Hotjar e Bugpilot ajudam as equipes a coletar feedback de seus usuários com facilidade.

Documentação e educação do usuário

Documentação clara e abrangente e materiais de educação do usuário podem ajudar os usuários a navegar pelo software de forma eficaz e minimizar o risco de erros induzidos pelo usuário. Fornecer recursos que explicam problemas comuns e etapas de solução de problemas capacita os usuários a resolver problemas menores de forma independente.

No Bugpilot, usamos uma página Notion para manter toda a nossa documentação. Fácil e gratuito.

Conclusão

O teste atua como uma medida preventiva crucial, identificando problemas no início do processo de desenvolvimento. Testes completos, incluindo testes de unidade, testes de integração e testes de ponta a ponta, ajudam - até certo ponto - a detectar bugs e garantir a estabilidade e a funcionalidade do software. Mas testes excessivos e processos muito rígidos provavelmente prejudicarão a empresa a longo prazo.

No entanto, erros podem ocasionalmente escapar da rede de teste, apesar de nossos melhores esforços. Portanto, é igualmente importante ter estratégias de mitigação em vigor. Ao implementar soluções de mitigação, as equipes de software podem detectar e corrigir rapidamente os erros, minimizando seu impacto sobre os usuários e resolvendo rapidamente quaisquer problemas que surjam.

Reconhecendo que nenhum software pode estar totalmente livre de bugs , é essencial criar um ambiente que encoraje o feedback do usuário e forneça um suporte eficaz ao cliente. Ao ouvir ativamente os relatórios dos usuários e abordar prontamente suas preocupações, as equipes de software podem manter um relacionamento positivo com seus usuários e promover a confiança e a lealdade.

tl;dr

Não exagere. Você provavelmente não precisa de 99% de cobertura de teste de unidade. Envie rápido.