Teste de software, começando do começo…
Teste de software: o truque mágico que os desenvolvedores usam para fingir que seus aplicativos são infalíveis.
Na prática, é a arte de vasculhar um mar de código em busca de erros e falhas, e torcer para que o software finalmente atenda às expectativas dos usuários.
Não subestime a importância desse processo…
Apesar de ser uma dor de cabeça, ele é essencial.
Um teste bem feito pode salvar seu software de se tornar um caos absoluto, evitando bugs que poderiam comprometer a segurança dos dados ou transformar o sistema em um verdadeiro campo de minas.
E não se engane, testar é mais do que um ritual: é uma forma de garantir que seu produto não seja uma piada.
Sem testes, você só tem uma promessa vazia de qualidade.
Uma visão geral sobre testes de software
É bom lembrar que garantir que um software funcione sem um único erro é tão possível quanto encontrar um unicórnio no seu quintal.
Afinal, os softwares têm mais estados, fórmulas e algoritmos do que você pode contar, e à medida que o projeto cresce e mais pessoas entram em cena, a bagunça só aumenta.
No mundo ideal, deveríamos testar todas as combinações possíveis do software, mas…
Isso é impossível — a não ser que você tenha uma máquina do tempo e anos a fio para gastar.
Por que os erros aparecem?
Bem, a especificação pode estar errada ou incompleta, ou talvez contenha requisitos que seriam impossíveis até para o supercomputador mais avançado.
A implementação também pode ser um desastre, como um algoritmo que decide por conta própria que seu software deve transformar suas fotos em um slideshow de gatos.
No fim das contas, uma falha é o resultado de um ou mais defeitos, e geralmente não é culpa do azar.
Curiosidades irrelevantes…
O primeiro “bug” documentado no software foi encontrado em 1947 por Grace Hopper, quando um inseto decidiu se hospedar no computador dele.
E assim, o termo “bug” se popularizou.
O teste de software pode ser manual, onde pessoas dedicam seu tempo para encontrar falhas, ou automatizado, onde ferramentas assumem o papel de detetives implacáveis.
Existem vários tipos de testes, como testes de unidade, integração, sistema e aceitação, cada um com seu próprio objetivo de descobrir onde o software pifa.
E a qualidade de software? Onde é que ela entra nesta bagunça?
Falando de qualidade, temos a famosa norma ISO 9126, que lista atributos como Funcionalidade, Confiabilidade e Usabilidade…
Porque, claro, se você não souber o que é um software de qualidade, as normas internacionais estão aqui para te lembrar.
Para medir se o software está funcionando bem, comparamos com especificações, outros softwares semelhantes, versões anteriores, expectativas do cliente, leis, e qualquer outra coisa que possa ter sido esquecida na última reunião.
O processo de verificação checa se o software foi feito “corretamente” (ou seja, de acordo com as especificações).
Já a validação confirma se ele está “correto” (ou seja, se atende às necessidades do cliente que são muitas e sempre em evolução).
E, claro, para desenvolver um software de qualidade, você precisa de uma metodologia sólida.
Sem ela, é como construir um castelo de areia sem um balde e uma pá — e ninguém quer ver o resultado disso.
Contudo, na vida real, as empresas de desenvolvimento são pressionadas a entregar software logo.
E isso pode desestabilizar até a metodologia mais bem planejada.
A demanda por softwares de qualidade não vai sumir, mas a pressão para entregar no prazo só aumenta.
Melhorar os processos de engenharia de software é fundamental, e um bom ponto de partida é adotar modelos recomendados por entes internacionais.
Modelos como SW-CMM, SE-CMM, ISO/IEC 15504 e, claro, o famoso CMMI são bem populares.
Eles ajudam a garantir que seus processos de desenvolvimento não sejam um caos completo.
Por fim, os testes são a cereja do bolo.
Eles são uma parte crítica de qualquer metodologia de desenvolvimento, mas muitas vezes são feitos de qualquer jeito.
Afinal, por que se preocupar com uma tarefa essencial quando você pode simplesmente correr contra o relógio?
Segundo um estudo do NIST de 2002, os defeitos custam à economia dos EUA cerca de 59,5 bilhões de dólares anualmente.
E adivinhe?
Mais de um terço desse custo poderia ser evitado com uma infraestrutura de teste de software mais eficiente.
Precisamos levar a sério essa história de testes…
Os princípios fundamentais do teste de software segundo Myers (2004)
Em primeiro lugar, Myers afirma que um caso de teste de software deve definir claramente a saída esperada.
Afinal, não queremos que o critério de sucesso seja interpretado de forma tão ampla quanto um mapa do tesouro.
É essencial analisar a saída do teste de software com o mesmo rigor que você analisaria a sua conta de luz.
Nada de achar que “quase certo” é bom o suficiente.
Os casos de teste de software não devem se limitar a verificar apenas condições inválidas.
Eles também devem testar as condições válidas, pois é sempre divertido ver se algo funciona como deveria, além de conferir se é um completo fiasco.
Myers também sugere algo revolucionário: usar pessoas e organizações diferentes para implementar e verificar o software.
Isso porque, aparentemente, ter uma visão destrutiva (a dos testadores, que só querem encontrar falhas) é diferente de ter uma visão construtiva (a dos programadores, que querem fazer a especificação funcionar).
Além disso, Myers é contra a criação de testes descartáveis, que são tão úteis quanto uma cola que seca antes de você terminar o trabalho.
A qualidade dos testes tende a piorar com o tempo, especialmente se eles forem feitos às pressas.
Em vez disso, ele sugere o teste de regressão que é uma maneira de quantificar a evolução do software ao repetir testes antigos.
Assim, você pode ver claramente como o software está se saindo ao longo do tempo.
E, claro, Myers revela um truísmo: a probabilidade de erros em um trecho de código é proporcional à quantidade de erros já encontrados.
Os erros tendem a se agrupar como festas inesperadas.
Certos trechos de código são mais propensos a erros do que outros.
É uma forma chique de dizer que algumas áreas são como terrenos minados prontos para explodir na sua cara.
Os melhores métodos e técnicas de teste de software
Quando se trata de testar software, há uma infinidade de técnicas que você pode usar.
Apesar das diferenças entre linguagens e paradigmas, todas essas técnicas têm um objetivo em comum: encontrar falhas.
Quando se trata de desenvolver software, a qualidade não vem de graça.
É preciso testar, e testar bem. Entre os métodos mais comuns, você encontrará:
Teste de unidade
A primeira linha de defesa, onde cada pedacinho do código é examinado isoladamente.
Se uma função ou classe não funcionar como deveria, este é o lugar para pegar o erro.
Frameworks como JUnit e NUnit são os heróis dessa fase.
Teste de integração
Aqui, o teste de software foca na interação entre diferentes módulos.
Se o seu software fosse uma orquestra, esse seria o ensaio geral para garantir que todos os músicos toquem em harmonia.
Métodos como “top-down” e “bottom-up” ajudam a verificar essa integração.
Teste de sistema
O teste final para conferir se o sistema, como um todo, está funcionando.
É como fazer um check-up completo para garantir que o software esteja pronto para o grande show – ou seja, a entrega ao cliente.
Teste de software é, no fim das contas, uma necessidade amarga, mas fundamental, para evitar que seu produto se transforme em um fiasco.
Caixa-branca
Teste de caixa-branca, também conhecido como “teste estrutural” ou “teste do programador que tem tempo demais”.
Este método mergulha no código-fonte como se fosse um detetive particular em um filme noir.
Aqui, você não se preocupa apenas com se o software está funcionando ou não.
Você está cavando fundo para analisar cada condição, fluxo de dados, ciclo e caminho lógico.
É quase como fazer uma auditoria em um livro de contabilidade, mas, em vez de números, você está lidando com lógica e estruturas de controle.
Os casos de teste de software são criados para cobrir todas as variações possíveis do código.
Se um trecho de código é um campo minado de potenciais falhas, o teste de caixa-branca é como um mapa para evitar as explosões.
Uma ferramenta popular para isso é o JUnit, ideal para testar classes e métodos em Java.
Apesar de alguns desenvolvedores acharem que os ganhos com esse tipo de teste de software são quase imperceptíveis, lembre-se de que, em um ambiente de produção, até os menores problemas podem se multiplicar e causar grandes estragos.
Caixa-preta
Agora, se você acha que se preocupar com o código-fonte é coisa de gente que gosta de complicar a vida, o teste de caixa-preta é para você.
Também conhecido como “teste funcional” ou “teste que finge que não há um código-fonte”, essa técnica foca apenas no comportamento externo do software.
É como testar um carro sem saber o que está acontecendo no motor.
Você só se importa com se o carro anda e se os faróis acendem quando você gira a chave.
Os testes são baseados em dados de entrada e saída, e o objetivo é garantir que o software se comporte conforme as especificações.
Idealmente, você testaria todas as possíveis entradas, mas na prática, isso seria um trabalho para uma equipe de robôs.
Então, você escolhe um subconjunto representativo de entradas.
O Particionamento de Equivalência e a Análise de Valor Limite são métodos usados para otimizar a cobertura dos testes sem precisar testar todos os possíveis dados.
Caso contrário, você estaria fazendo testes tão extensivos que pareceriam um jogo de Sudoku sem fim.
Caixa-cinza
O teste de caixa-cinza é o tipo que gosta de andar no meio-termo.
Ele mistura a análise do código (caixa-branca) com o teste das entradas e saídas (caixa-preta).
O testador tem acesso a alguns detalhes internos do software, mas ainda testa o sistema como um usuário final.
É como saber onde estão os interruptores da luz e, ainda assim, avaliar se a iluminação é adequada para uma festa.
Esse método pode envolver engenharia reversa e análise de estruturas internas, mas o foco está em garantir que as entradas produzam as saídas esperadas.
Se você gosta de saber um pouco mais sobre o que está testando, mas ainda quer deixar algum mistério no ar, o teste de caixa-cinza é a técnica para você.
Regressão
O teste de regressão é o tipo de teste que nunca parece se cansar.
Sempre que há uma nova versão do software ou um novo ciclo de desenvolvimento, você aplica todos os testes anteriores novamente.
É como revisar todos os capítulos de um livro antes de entregar o manuscrito final, só que para software.
A ideia é garantir que novas alterações não tenham destruído funcionalidades que já estavam funcionando bem.
A automação pode ajudar aqui nesses testes repetitivos com a eficiência de um robô programado para não reclamar.
Teste de aceitação
Vamos lá, o teste de aceitação é onde um grupo seleto de usuários finais faz de conta que é um dia normal e testa o sistema para ver se ele faz o que deveria.
É o teste de software formal para decidir se um sistema atende aos requisitos e se o cliente está pronto para aceitá-lo ou não.
É a validação final, seja pelo comprador, pelo usuário ou por algum terceiro, usando dados ou cenários que podem ser totalmente reais ou apenas um teatrinho.
Isso pode incluir uma gama de testes, desde funcionais e de configuração até recuperação de falhas, segurança e desempenho.
Uma verdadeira festa de testes para garantir que o sistema não seja um desastre total.
Teste de operação
Aqui, a coisa muda de figura: o teste de software é feito pelos administradores do ambiente onde o sistema ou software vai finalmente entrar em ação.
Isso é só para sistemas que a organização controla, com acesso interno ou externo.
Nesta fase, é preciso fazer simulações para garantir que a transição para o ambiente de produção seja tranquila.
Envolve testes de instalação, simulações com backups dos bancos de dados e por aí vai.
E não se esqueça…
Se o novo sistema estiver substituindo o antigo, você tem que garantir que ele vai manter o suporte ao negócio, porque se não, é melhor se preparar para o caos.
Técnicas não funcionais
Por fim, temos as técnicas não funcionais que verificam aspectos do software que não são sobre suas funções principais.
É como verificar a durabilidade e a usabilidade de um produto, em vez de apenas ver se ele funciona.
Técnicas como teste de desempenho e carga garantem que o software possa lidar com grandes quantidades de dados e tempos de processamento exigidos.
O teste de usabilidade, por outro lado, avalia se a interface é amigável e fácil de usar.
Já o teste de confiabilidade checa se o software é seguro e pode se recuperar de falhas sem perder a compostura.
Essas técnicas são importantes para garantir que o software não apenas funcione, mas também se comporte de maneira adequada em situações reais e sob condições adversas.
Afinal, ninguém quer usar um software que desmorona ao menor sinal de estresse.
Os testes Alpha, Beta e Gama
Alpha
O teste de software alpha é a etapa em que a aplicação é jogada para alguns usuários seletos depois do desenvolvimento, mas antes da entrega.
O diferencial?
O desenvolvedor está por perto, observando tudo de camarote.
Os usuários vão tentando usar o sistema e anotando erros e problemas, enquanto o desenvolvedor espera que esses erros sejam bem documentados para ele poder corrigi-los.
É a hora em que você descobre se seu software é um desastre ou só um pouquinho quebrado.
Beta
Depois que a fase alpha termina, chegamos ao glorioso teste de software beta.
Aqui, o software é disponibilizado para um grupo restrito de usuários, mas sem o desenvolvedor por perto para supervisionar.
Isso significa que o software vai para um ambiente onde o desenvolvedor não tem controle algum.
Os usuários testam a aplicação, encontram problemas e os reportam.
Com base nos feedbacks, os engenheiros de software vão fazendo ajustes e correções, tentando transformar o software em algo que o público geral possa, finalmente, usar sem lançar um caos total.
Gama
E então chegamos ao teste de software gama, onde o produto, já “mal testado”, é finalmente lançado para o mercado.
Isso mesmo, os usuários finais têm acesso a uma aplicação que provavelmente está cheia de erros.
Em vez de corrigir os problemas antes do lançamento, os bugs são consertados enquanto a aplicação está em uso.
A ideia é que os usuários sejam as cobaias, e os problemas vão sendo corrigidos conforme aparecem.
Uma verdadeira diversão para os primeiros usuários, que podem se sentir mais como beta testers involuntários.
O início e o fim dos testes…
O ciclo de vida dos testes tem cinco fases: Planejamento, Preparação, Especificação, Execução e Entrega.
Planejamento
Aqui, você vai criar a Estratégia de Teste e o Plano de Teste com base nos requisitos.
É onde você promete que vai fazer um bom trabalho, antes de realmente começar a fazer qualquer coisa.
Preparação
Agora é hora de preparar o Ambiente de Teste – leia-se: montar toda a parafernália necessária (equipamentos, pessoal, ferramentas de automação, e aquela montanha de dados para testar).
A ideia é garantir que tudo esteja pronto para os testes, sem surpresas desagradáveis, como um servidor que decide cair no meio do processo.
Especificação
Nesta fase, você vai elaborar e revisar casos de testes e roteiros de testes.
Você está criando o roteiro do drama, onde cada passo do teste de software é meticulosamente planejado para garantir que nada seja esquecido, ou pelo menos para fingir que você tem tudo sob controle.
Execução
Aqui, os testes realmente acontecem e você anota os resultados.
É o momento em que o planejamento e a preparação se encontram com a realidade e você descobre se seu software é um gênio ou um fiasco.
Entrega
Finalmente, a fase de Entrega, onde o projeto é concluído e toda a documentação é finalizada e arquivada.
É quando você coloca um laço na caixa e espera que ninguém perceba os detalhes que ficaram de fora.
A “papelada” dos testes de software
Durante o processo de teste, você vai gerar vários artefatos.
O caso de teste de software é uma referência a um requisito, incluindo pré-condições, eventos, uma série de passos, dados de entrada, saída de dados, resultado esperado e resultado obtido.
Se a série de passos for complexa, pode ser que você crie um procedimento separado para ela.
O roteiro de teste de software é a combinação de um caso de teste, um procedimento de teste e os dados do teste.
Uma coleção de casos de teste de software é chamada de suíte de teste, que geralmente inclui instruções detalhadas e objetivos, além de uma descrição da configuração do sistema.
Por fim, o plano de teste de software é o documento que especifica como todos esses elementos devem ser organizados e executados.
As ferramentas de ‘qualidade’ de software sem papo de vendedor
Aquelas maravilhas super caras que prometem transformar seu caos em ordem.
Se você acha que pode garantir a qualidade do seu software sem essas ferramentas, pense de novo.
Cada uma tem seu próprio truque, mas no fundo, elas são apenas um meio de você acreditar que está no controle.
Critérios para não comprar uma solução rolha
Escolher uma ferramenta de qualidade é quase como escolher um par de sapatos: se você errar, vai andar mal e acabar com os pés doloridos.
Aqui está o que considerar:
Facilidade de uso
A ferramenta deve ser tão intuitiva quanto possível, porque sua equipe provavelmente não tem tempo para decifrar manuais intermináveis enquanto o prazo está se aproximando.
Compatibilidade
Certifique-se de que a ferramenta se encaixa como uma luva com as tecnologias e linguagens que você está usando.
Caso contrário, você pode acabar com um grande quebra-cabeça de compatibilidade.
Relatórios e métricas
A capacidade de gerar relatórios e métricas não é apenas um capricho.
É a sua única chance de convencer a todos que o software está realmente pronto.
Ferramentas de teste de software mais usadas
Aqui estão exemplos das ferramentas de qualidade de software que fazem você se sentir como se estivesse fazendo algo significativo:
Selenium
Uma ferramenta de automação de testes de interface de usuário.
É como um robô que faz o trabalho chato por você, mas cuidado com as falhas que ele pode ignorar.
JIRA
Não é só para gerenciamento de projetos, mas também promete ajudar no controle de qualidade.
É o lugar onde você pode registrar todos os problemas e depois ignorá-los habilmente.
SonarQube
Analisa e mede a qualidade do código-fonte, pois você precisa de uma ferramenta para te lembrar que seu código pode ser um desastre, mesmo quando você tenta disfarçar.
No final das contas, essas ferramentas são indispensáveis para dar uma aparência de controle e qualidade, mesmo que você saiba que sempre haverá algo que vai escapar das garras da perfeição.
Pedro Londe
Palestrante e autor do livro “O que diabos é Gig Economy?: Como ter várias fontes de renda e aproveitar ao máximo todas as suas habilidades”
You completed certain fine points there. I did a search on the theme and found the majority of people will agree with your blog.
Enjoyed studying this, very good stuff, thankyou.