DEV Community: Lucas Amaral

Engenharia de Prompts para Massa de Dados: Escalando Testes com Cobertura e Sem Duplicidade utilizando LLMs

Lucas Amaral — Wed, 17 Jun 2026 13:10:19 +0000

O uso de LLMs para a geração de dados sintéticos tornou-se uma estratégia atraente para equipes de QA que precisam escalar suas esteiras de testes. A promessa é tentadora: gerar centenas de registros complexos em segundos. No entanto, na prática, a geração automatizada sem direcionamento técnico introduz um risco crítico: a falsa sensação de cobertura.

Quando submetidas a prompts genéricos (como "gere 50 usuários para teste"), as LLMs tendem a operar dentro de padrões estatísticos previsíveis. O resultado é o efeito "João da Silva": um volume massivo de dados que testa repetidamente o "caminho feliz" (happy path), gerando duplicidade de cenários e deixando lacunas profundas em lógica de negócios complexas e cenários de borda (edge cases).

Para mitigar o viés do modelo e garantir a eficácia dos testes, o QA deve transicionar do papel de mero solicitante para o de orquestrador de cenários, aplicando técnicas tradicionais de teste diretamente na engenharia de prompts. A seguir, analisamos três padrões estruturados de prompts para resolver os problemas de cobertura e duplicidade.

1. O Padrão de Particionamento de Equivalência e Valores Limite

Para garantir cobertura sem inflar a base de dados com registros redundantes, o prompt deve forçar a LLM a aplicar técnicas de design de testes antes da geração do dado final. Esse padrão utiliza a abordagem de cadeia de pensamento (Chain-of-Thought), obrigando o modelo a mapear as classes de equivalência estruturalmente.

Exemplo de Prompt Estruturado:

Defina seu papel: Você é um Engenheiro de QA Sênior especializado em testes de API e validação de regras de negócio.

Contexto do Sistema: Estou testando o endpoint de aplicação de cupons de desconto de um e-commerce. As regras de negócio são:
1. Cupons do tipo "FIXO" exigem valor mínimo de compra de R$ 100,00.
2. Cupons do tipo "PERCENTUAL" aplicam-se a qualquer valor, mas têm teto máximo de desconto de R$ 50,00.
3. Cupons com data de validade expirada devem ser rejeitados.

Sua Tarefa:
1. Identifique e liste em uma tabelaMarkdown todas as Classes de Equivalência (Válidas e Inválidas) e os Valores Limite (Boundaries) para as regras acima.
2. Com base nessa tabela, gere exatamente UM payload JSON para cada cenário identificado. Cada cenário deve isolar uma variável de teste para garantir rastreabilidade.

Restrição: Não gere payloads duplicados para a mesma classe de equivalência. Foque na cobertura mínima necessária para testar todas as ramificações do código.

O que essa abordagem resolve:

Cobertura: Garante que os valores exatos de transição de estado do código (ex: R$ 99,99, R$ 100,00 e R$ 100,01) sejam testados.
Eficiência: Elimina dados redundantes dentro da mesma classe de equivalência, mantendo a suite de testes enxuta e performática.

2. O Padrão de Matriz de Transição de Estados (Contra a Duplicidade Comportamental)

Em sistemas orientados a eventos ou máquinas de estado (como fluxos de pagamento ou processamento de pedidos), os dados de teste precisam refletir a assincronicidade e o histórico do ciclo de vida da entidade. O erro comum é gerar dados que representam apenas o estado final ou inicial estável.

O prompt a seguir utiliza restrição de grafo para forçar a IA a cobrir caminhos de exceção e transições inválidas.

Exemplo de Prompt Estruturado:

Contexto: Sistema de gerenciamento de pedidos com os seguintes estados: [Criado, Pago, Faturado, Enviado, Entregue, Cancelado].

Diretriz de Geração: Gere uma massa de dados de teste em formato CSV que cubra a Matriz de Transição de Estados do sistema. 

A massa deve conter:
1. Cenários de Fluxo Linear (Transições válidas de ponta a ponta).
2. Cenários de Fluxo de Exceção (Transições válidas de desvio, ex: Criado -> Cancelado).
3. Cenários de Violação de Estado (Transições inválidas que o sistema deve rejeitar, ex: Tentar transicionar de 'Entregue' para 'Cancelado', ou de 'Criado' para 'Enviado' sem passar por 'Pago').

Colunas do CSV necessárias: id_pedido, estado_atual, estado_destino, payload_acao, resultado_esperado (Sucesso/Erro).

Regra estrita: Gere apenas uma linha por combinação única de 'estado_atual' -> 'estado_destino'. Proibido duplicar cenários ideais.

O que essa abordagem resolve:

Prevenção de Duplicidade: Ao mapear a transição como uma chave única (estado_atual + estado_destino), impede-se que a LLM gere múltiplos registros para fluxos comuns, como pedidos padrão que já foram testados.
Testes Negativos: Força a criação de dados para validação de resiliência e tratamento de erros do sistema.

3. O Padrão de Variabilidade Restrita (Negative Prompting)

A entropia das LLMs pode fazer com que elas gerem dados realistas, porém excessivamente homogêneos em sua distribuição (como utilizar sempre a mesma faixa de CEPs ou a mesma demografia). Para evitar que os testes fiquem tendenciosos, aplicamos restrições explícitas de variância e o conceito de Negative Prompting (o que o modelo está proibido de fazer).

Exemplo de Prompt Estruturado:

Tarefa: Gere um lote de 10 perfis de clientes em formato JSON para homologação de um sistema de análise de crédito.

Requisitos de Variabilidade:
1. Idade: Distribua uniformemente entre as faixas etárias de 18-25, 26-45, 46-60 e acima de 65 anos.
2. Localização: Utilize estados das cinco diferentes regiões do Brasil (Sul, Sudeste, Centro-Oeste, Nordeste, Norte).
3. Renda: Inclua variações de renda formal, informal e desempregados.

PROIBIÇÕES (Negative Prompt):
- NÃO utilize nomes fictícios óbvios ou genéricos (ex: "João da Silva", "Fulano de Tal", "Teste 1").
- NÃO repita a mesma combinação de Região e Faixa Etária em registros diferentes.
- NÃO utilize máscaras de documentos (CPF) idênticas ou sequenciais.

O que essa abordagem resolve:

Eliminação de Viés Extrinseco: Garante que validações de front-end ou regras de backend baseadas em localização, ou limites numéricos amplos, lidem com dados semanticamente diversos.
Determinismo Sintático: Reduz a necessidade de sanitização manual posterior dos dados gerados.

Conclusão: A Validação Determinística como Próximo Passo

A engenharia de prompts robusta mitiga a maior parte dos problemas de cobertura e duplicidade na geração de dados sintéticos, mas não elimina a necessidade de validação. Para cenários de larga escala em pipelines de CI/CD, a abordagem ideal combina a geração generativa estruturada (via LLM com os prompts acima) com uma camada de validação determinística.

O ganho de velocidade proporcionado pela IA só se traduz em eficiência real se os dados gerados forem intencionais. O papel do QA, portanto, evolui de escrever dados estáticos para codificar as regras de restrição que governam os modelos gerativos.

No contexto de testes de aplicações baseadas em IA (como testar um LLM, um classificador de machine learning ou um sistema de recomendação), a resposta curta é: depende do tipo de teste, mas na maioria das vezes, a duplicidade estrita (exata) ainda é indesejada. No entanto, a redundância semântica ou a repetição intencional de inputs assume um papel completamente diferente e legítimo do que em softwares tradicionais.

Artigo escrito auxiliado por Google Gemini

Lei de Little e o dimensionamento de Testes de Performance

Lucas Amaral — Wed, 27 May 2026 13:27:28 +0000

Você acabou de implantar uma nova funcionalidade e o seu líder pede para você realizar um teste de carga. O objetivo? Garantir que o sistema aguente 500 requisições por segundo. Você abre uma ferramenta como o JMeter ou o Locust e se depara com a pergunta de um milhão de dólares: “Quantos usuários virtuais eu devo configurar para atingir esse objetivo?”

Se você tentar adivinhar, provavelmente vai derrubar o servidor ou criar um teste que não reflete a realidade. É aqui que entra a Lei de Little , uma fórmula matemática simples que vai se auxiliar no dimensionamento para seus testes de performance de software.

Neste artigo, vamos desmistificar esse conceito, entender o comportamento humano nos testes e mostrar como aplicar tudo isso na prática.

O que é a Lei de Little?

Formulada pelo professor John Little em 1961, essa lei nasceu no contexto da engenharia de produção e teoria das filas (como filas de banco ou supermercados). Ela dita que, em um sistema estável, existe uma relação fixa entre três variáveis:

O número de itens dentro do sistema (Inventário).
A velocidade com que os itens entram e saem (Taxa de transferência).
O tempo que cada item passa lá dentro (Tempo de permanência).

A fórmula matemática oficial é:

Traduzindo para o mundo do Software

Para desenvolvedores, os “itens” são as requisições ou os usuários, e o “sistema” é a nossa aplicação (API, banco de dados, servidor). Reescrevendo os termos para a nossa realidade, temos:

L (Concorrência / WIP): O número médio de requisições sendo processadas simultaneamente no servidor.
λ (Throughput / Vazão): A taxa de sucesso das requisições (ex: requisições por segundo — RPS).
W (Response Time / Tempo de Resposta): O tempo médio que o sistema leva para responder a uma requisição.

Analogia do Restaurante: Imagine um restaurante onde entram 2 clientes por minuto (λ = 2) e cada cliente passa, em média, 30 minutos jantando (W = 30). Quantas pessoas estão dentro do restaurante ao mesmo tempo (L)?

L = 2 x 30 = 60 clientes

Se o restaurante tiver apenas 40 cadeiras, haverá fila na porta! O mesmo acontece com a memória e a CPU do seu servidor.

Expandindo a Fórmula: O Fator Humano e o Think Time

Quando testamos aplicações web, há um detalhe crucial: seres humanos não se comportam como robôs hiperativos. Se você entrar em um e-commerce, você não clica na Home Page e, em 0,001 segundos, clica em um produto. Você entra na página, gasta alguns segundos lendo os destaques, escolhe o produto, lê as especificações e só depois clica em “Adicionar ao carrinho”.

Esse intervalo de tempo em que o usuário está consumindo a informação na tela, pensando ou digitando, sem enviar nenhuma requisição para o servidor , é chamado de Think Time (Z).

Para incluir o comportamento humano no teste de carga, expandimos a Lei de Little para a Lei do Tempo de Resposta do Sistema Central :

Onde:

N = Número de Usuários Virtuais ativos (Concorrência).
X = Throughput desejado (Requisições por segundo).
R = Tempo de resposta do servidor.
Z = Think Time (Tempo de pensamento do usuário).

Por que o Think Time é o herói anônimo do seu teste?

Negligenciar o Think Time é o erro número um de quem está começando em performance. Sem ele, seus usuários virtuais agem como uma “metralhadora de requisições”. As consequências disso são graves:

Superfaturamento Artificial de Carga: Se 100 usuários reais com Think Time geram 20 RPS (visto que passam a maior parte do tempo lendo a tela), esses mesmos 100 usuários virtuais sem Think Time podem gerar 2.000 RPS. Você vai derrubar o servidor e reportar um bug falso, pois esse cenário de estresse não existe no mundo real.
Desperdício de Dinheiro em Nuvem: Ao ver o servidor travar com poucos usuários virtuais, a liderança pode achar que o sistema é fraco e gastar milhares de dólares escalando máquinas na AWS/Azure desnecessariamente.
Simulação Fiel de Recursos: O servidor lida de forma diferente com “100 conexões abertas e ociosas esperando o clique” (consome memória para manter a sessão aberta, mas não CPU) versus “100 conexões processando dados na velocidade máxima”. O Think Time equilibra essa balança.

Como aplicar a Lei de Little em seus Testes de Carga

Como um desenvolvedor Júnior pode usar esse conhecimento no dia a dia? Aqui estão os dois principais casos de uso:

1. Planejando o Cenário de Teste (Sem adivinhação)

Imagine o seguinte cenário passado pelo seu Product Owner (PO): “Precisamos validar se nossa API aguenta 100 requisições por segundo (X). Sabemos que o tempo de resposta atual dela é de 500ms (R = 0,5s) e estimamos que o usuário espera 1,5 segundos (Z) entre as ações.”

Quantos usuários simulados você deve colocar na ferramenta de teste? Vamos aplicar a fórmula expandida:

N = 100 x (0,5 + 1,5)

N = 100 x 2 = 200 usuários virtuais

Pronto! Você descobriu matematicamente que precisa configurar exatamente 200 usuários virtuais para atingir o objetivo de negócio de forma realista.

2. Identificando Mentiras nos Gráficos (Sanity Check)

Ferramentas de teste e painéis de monitoramento (como Grafana) podem falhar ou exibir dados distorcidos se a infraestrutura estiver sobrecarregada. A Lei de Little serve como o seu detector de mentiras.

Imagine que, durante um teste com 100 usuários fixos (N), o tempo de resposta da API (R) de repente dobrou devido a uma lentidão no banco de dados.

Pela matemática da Lei de Little, se o tempo de resposta (R) subiu e o número de usuários (N) permaneceu igual, a taxa de transferência (X) obrigatoriamente precisa cair. Se o seu gráfico mostrar que o Throughput continuou alto, há algo errado com a máquina que está disparando os testes (ela pode estar sem memória e enfileirando os dados localmente).

O Ponto de Inflexão: Quando o sistema satura

A Lei de Little funciona perfeitamente enquanto o sistema está estável. Porém, todo software tem um limite físico (limite de conexões com o banco, threads de CPU, etc.).

Quando esse limite é atingido, o Throughput (X) para de crescer e se estabiliza em um teto. Se você continuar adicionando usuários (N) além desse ponto, o tempo de resposta (R) começará a subir vertiginosamente, pois as novas requisições ficarão presas em uma fila de espera (backlog). O Think Time (Z) funciona aqui como um amortecedor, atrasando o momento em que o sistema atinge esse colapso.

Dica de Ouro: Configurando o Think Time nas Ferramentas

Como humanos não gastam exatamente o mesmo tempo em cada página, você deve evitar usar um valor fixo. Use valores aleatórios ou distribuições estatísticas dentro de uma faixa de tempo. Veja como fazer:

No Locust (Python):
Python

from locust import HttpUser, task, between  

class UsuarioEcommerce(HttpUser):
  # Simula um think time aleatório entre 1 e 5 segundos entre as ações     
  wait_time = between(1, 5)
  @task
  def acessar_home(self):
    self.client.get("/")

No JMeter: Adicione o componente Gaussian Random Timer ou Uniform Random Timer dentro do seu fluxo de requisições.
No Gatling (Java/Kotlin): Use o método .pause(min, max) entre as requisições HTTP.

Conclusão

Para quem está começando, testes de performance podem parecer uma caixa preta cheia de dados aleatórios. A Lei de Little e o entendimento do Think Time trazem clareza e embasamento científico para o seu trabalho, permitindo que você justifique suas configurações de teste para arquitetos e líderes técnicos com segurança.

Da próxima vez que abrir uma ferramenta de teste, lembre-se: Performance não é sobre simular ataques de negação de serviço (DDoS) robóticos, é sobre entender e modelar o fluxo real dos seus usuários.

Referências para se aprofundar:

Little, J. D. C. (1961). A Proof for the Queuing Formula: L = λ x W. Operations Research. (O artigo científico original).
Jain, R. (1991). The Art of Computer Systems Performance Analysis. Wiley. (Considerada a bíblia da análise de performance de sistemas).
Documentação das Ferramentas: Os guias oficiais do Gatling, JMeter e Locust possuem seções ricas detalhando o uso de Timers e Pauses baseados na modelagem de carga de Little.

Artigo escrito auxiliado por Google Gemini

Aceleração Logarítmica: Otimizando Esperas Dinâmicas em Testes de Software

Lucas Amaral — Fri, 08 May 2026 12:57:22 +0000

Introdução: O Dilema do Polling

Em testes de software modernos, especialmente na automação de interfaces de usuário (UI) ou testes de ponta-a-ponta (E2E), raramente os eventos acontecem instantaneamente. Um botão pode demorar 2 segundos para aparecer após um clique, um relatório pode levar 30 segundos para ser gerado, ou uma API pode demorar um tempo variável para responder.

Como nossos testes não têm “bola de cristal”, eles precisam esperar. No vocabulário técnico, isso é feito através de Polling : o teste verifica se uma condição é verdadeira (ex: “o botão está visível?”), se não for, ele dorme por um tempo, e tenta novamente, repetindo até o sucesso ou até estourar um tempo limite (Timeout).

O Problema com as Esperas Tradicionais

As estratégias de polling mais comuns sofrem de um compromisso doloroso entre velocidade do teste e carga no sistema.

Espera Fixa (Static Wait): O teste verifica a cada intervalo exato (ex: a cada 1 segundo): Se o evento acontece 100ms após a última verificação, o teste perde 900ms esperando desnecessariamente. Multiplique isso por centenas de testes e sua pipeline torna-se lenta.
Aumento Exponencial (Exponential Backoff): O teste dobra o tempo de espera a cada tentativa (ex: $1s, 2s, 4s, 8s…$). É ótimo para SRE/Redes para evitar sobrecarga (efeito manada), mas em testes, se o evento demorar um pouco mais, o próximo intervalo de espera pode ser giganticamente maior que o necessário, atrasando o feedback final.

O Conceito: Espera em Escala Logarítmica

Propomos uma abordagem diferente para cenários onde sabemos que um evento vai demorar , mas queremos capturá-lo no exato momento em que ele ocorrer.

A ideia central é baseada na percepção humana de tempo em processos longos: quanto mais tempo esperamos, maior é a probabilidade de que o evento esteja prestes a acontecer.

Em vez de desacelerar (como na exponencial) ou manter o passo (como na fixa), a Espera Logarítmica Acelera.

No Início: Quando a chance de sucesso é quase zero, fazemos pollings bem espaçados (ex: a cada 5 segundos) para economizar recursos.
Com o Passar do Tempo: À medida que o tempo avança e a chance de sucesso aumenta, diminuímos o intervalo entre as verificações (ex: $4s, 3s, 2s, 1s, 0.5s$), tornando a busca cada vez mais agressiva.

A Fórmula Explicada (Sem Dor)

A fórmula que define o intervalo de sono é:

(Com uma trava de segurança para não ser menor que um valor mínimo, o Floor).

Vamos torná-la didática:

Pense na fórmula como uma Escada Rolante que Desce :

Initial: É o intervalo mais longo que você quer no começo. Ex: começar esperando 5 segundos entre cada verificação.
Tentativa (Os Degraus): A cada vez que o teste falha, ele desce um degrau. Quanto maior o número da tentativa ($1, 2, 3…$), mais baixo na escada você está.
Tentativa + 1 (O Freio do Logaritmo): Usamos o logaritmo porque ele cresce devagar. Isso garante que a aceleração não seja absurda nas primeiras tentativas, dando tempo ao sistema.
k (A Velocidade da Escada): É uma constante que calculamos automaticamente baseada em quão rápido você quer chegar ao final (o Floor).

Visualizando a Diferença

 5 |*
 4 | *
 3 | *
 2 | *
 1 | *
 0 | *
-1 | **
-2 | ***
-3 | ****
    +--------------------------------
      0 2 4 6 8 10 20

| Tentativa (`x`) | Intervalo (`y`) |
| --------------- | --------------- |
| 0 | 5.00 |
| 1 | 3.27 |
| 2 | 2.25 |
| 3 | 1.53 |
| 5 | 0.52 |
| 6 | 0.14 |
| 7 | -0.20 |
| 10 | -0.99 |
| 20 | -2.61 |

Observação importante:

a função começa a produzir valores negativos após algumas tentativas, porque o logaritmo continua crescendo.

Para evitar isso em cenários reais (retry/backoff/cooldown), normalmente usa-se um piso mínimo:

Intervalo = max(Minimo, Initial - k * log(Tentativa + 1))

Exemplo de Uso em Python

import pytest
import time
import math
from typing import Callable

class LogarithmicWait:
    def __init__ (
        self, 
        timeout: float = 30.0, 
        initial_interval: float = 3.0, 
        floor_interval: float = 0.5, 
        acceleration_point: int = 15
    ) -> None:
        """
        Initializes the logarithmic waiter.
        :param timeout: Maximum time to wait in seconds.
        :param initial_interval: Starting delay between polls.
        :param floor_interval: Minimum delay between polls (maximum speed).
        :param acceleration_point: How many attempts until we reach the floor_interval.
        """
        self.timeout = timeout
        self.initial_interval = initial_interval
        self.floor_interval = floor_interval

        # Calculate the decay constant based on the desired acceleration curve
        # (Initial - Floor) / log(N + 1)
        self.k = (initial_interval - floor_interval) / math.log(acceleration_point + 1)

    def until(self, condition: Callable[[], bool]) -> bool:
        """
        Polls the condition function until it returns True.
        """
        start_time = time.monotonic()
        attempt = 1

        while time.monotonic() - start_time < self.timeout:
            if condition():
                return True

            # Decay logic: interval decreases as 'attempt' increases
            interval = max(
                self.floor_interval, 
                self.initial_interval - self.k * math.log(attempt + 1)
            )

            time.sleep(interval)
            attempt += 1

Conclusão: Benefícios e Limitações

Onde ela tem mais sucesso?

Processos Assíncronos Longos: Geração de PDFs pesados, processamento de vídeos, backups, ou provisionamento de infraestrutura em nuvem.
Testes de CI/CD em Escala: Em pipelines com milhares de testes parallelism, a economia de recursos nos primeiros segundos de cada teste pode reduzir drasticamente o custo e a carga da infraestrutura de teste.

Benefícios

Feedback Snappy: O teste termina quase imediatamente após o sucesso real, eliminando o “tempo morto” do polling fixo.
Carga Eficiente: Não bombardeia o sistema desnecessariamente no início.

Limitações

Eventos Rápidos: Para elementos de UI que aparecem em menos de 1 segundo, esta abordagem é desnecessariamente complexa; a espera fixa tradicional do Selenium/Playwright é melhor.
Complexidade de Configuração: Requer que o QA entenda a natureza do processo para configurar bem o Initial e o Floor. Se o Initial for muito alto, você pode perder tempo no começo de um evento que poderia ter sido rápido.

A Espera Logarítmica não é uma bala de prata, mas é uma ferramenta de engenharia refinada para QAs que buscam otimização de alto nível e precisão em cenários complexos.

“Me ajude a te ajudar”: Usando o gist

Lucas Amaral — Wed, 20 May 2020 19:23:37 +0000

Para quem está iniciando ou mesmo pessoas experientes em desenvolvimento de software, mais cedo ou mais tarde, você precisará compartilhar trechos do seu código com alguém. Por que? Seja para exemplificar uma solução legal, seja para tirar uma dúvida com a comunidade ou compartilhar uma informação em formato de texto qualquer.

O gist é uma ferramenta do GitHub feita para esses compartilhamentos ou nas palavras do GitHub: Compartilhar código, notas ou trechos de código instantaneamente. Ainda com as mesmas capacidades de um repositório normal de receber forks, comentários, etc…

Para acessar seus gists, basta estar logado na sua conta do GitHub e no dropdown onde tem a sua foto de perfil e selecionar “Seus gists” (Your gists)

Listando os seus gists

Não tem nenhum ou nunca usou? Sem problemas. Vamos criar nosso primeiro gist.

Criando um gist

Criando um novo gist

Um gist é composto de uma descrição, arquivos com nome (e extensão, importante para receber um highlight em palavras reservados) e corpo. E se é público ou secreto (nessa segunda opção, todos que tiverem o link terão acesso).

Vamos usar um problema de automação de testes usando Ruby, RSpec e Cucumber para exemplificar nosso primeiro gist. Iniciaremos postando nosso arquivo de Steps, para alguém ver o que pode estar dando errado. Ao final, o gist será criado e o link disponível para compartilhamento.

Acrescentando arquivos a um mesmo gist

Com frequência, você precisa exibir mais de um trecho de código ou arquivo para compartilhar o cenário completo para a análise de terceiros. No nosso cenário, vamos incluir o arquivo .feature . Basta editar o seu gist selecionando a opção “Adicionar arquivo”

Adicionando arquivo

Seguindo os mesmos passos anteriores, adicionamos o novo arquivo, o que dará a seguinte cara para nosso gist:

gist com um segundo arquivo

Para finalizar o cenário, vamos adicionar ao gist nosso Gemfile assim nossos colegas podem ter uma visão mais apurada de como está rodando nossa aplicação.

Conclusão

Use o gist para ajudar aos outros colegas, instrutores e até o StackOverflow a ajudarem você. Acesse esse link para visualizar como ficou nosso gist no final.

Estou cansado de encontrar bugs

Lucas Amaral — Wed, 30 Oct 2019 19:33:15 +0000

Este texto é uma tradução livre do artigo original “I’m Tired of Finding Bugs” de Alan Page

Venho atuando na área de testes de software por mais de 13 anos e estou cansado de encontrar bugs. Não é que eu considere que encontrar bugs não tem importância — Eu prefiro muito mais encontrar antes que o cliente o faça. Certamente, também, não estou cansado de testar, no entanto, o objetivo de testar não é encontrar bugs. O testador é responsável por exercitar a aplicação, o produto, reportar informações e muitas outras atividades. Encontrar bugs é um efeito colateral.

Estou cansado de testadores encontrarem muitos defeitos que deveriam ter sido encontrados muito mais cedo, ou mesmo nem ser introduzidos na aplicação. Nós encontramos muitas issues muito tarde no ciclo de vida do produto e deixamos com que muitos bugs cheguem até o usuário final. Eu não quero mais encontrar bugs, quero preveni-los de acontecer.

Eu não quero mais encontrar bugs, quero preveni-los de acontecer.

Leio muito sobre testes de software, mas livros, blogs, artigos e outros materiais parecem focar primordialmente em abordagens para encontrar bugs. Técnicas populares como testes exploratórios ou suposição de erros (error-guessing), podem ser ferramentas efetivas, mas seu foco é em “Encontrar”. Estas e outras abordagens que primariamente pretendem descobrir erros que já estão no código estão tentando alcançar qualidade através de testes. Em outras palavras, tentam “testar a qualidade de um produto.”

Quase todos os livros de engenharia de software tem um gráfico que demonstra como o custo de corrigir erros aumenta quanto mais tarde o erro demora a ser encontrado no ciclo de desenvolvimento do software. Se todos concordam com isso, por que não estamos fazendo mais para encontrar bugs mais cedo? Muitas equipes de engenharia estão começando a envolver testes (e testers) mais cedo no ciclo de desenvolvimento, e acredito que esse seja um bom movimento. Já ouvi os gritos de “vamos direcionar/empurrar a qualidade para cima” (“Let’s drive quality upstream!”) por anos, mas continuo achando que não estamos próximo o suficiente.

Como podemos alcançar níveis mais altos de qualidade e encontrar menos bugs nos estágios mais avançados do desenvolvimento? A maioria dos esforços para “direcionar a qualidade para cima” envolvem a revisão de especificações pelos testers a fim de criar casos de testes ou modelos a partir das especificações ou protótipos iniciais. Estas são abordagens, certamente melhores que esperar o código ser “jogado por cima do muro” para o time de testes. No entanto uma solução consideravelmente melhor seria prevenir que os bugs aconteçam. Com o crescimento da complexidade dos softwares, alguns bugs são inevitáveis — mas a maioria é evitável.

Bugs existem porque alguém cometeu um erro: A pessoa escrevendo os requisitos pode ter esquecido um detalhe, um desenvolvedor pode ter cometido um erro de escrita ou uma chamada errada a uma biblioteca pode ter sido feita. Erros humanos podem ser prevenidos? Certamente sim. Shigeo Shingo, um engenheiro industrial japonês inventou o conceito de Poka-yoke (“evitando erros inadvertidos”). Em uma planta industrial, poka-yoke pode ser implementado introduzindo uma sinalização em uma peça que corresponda unicamente a outra de encaixe, de tal forma que se evite consumo de tempo com posicionamento ou encaixes errados.

Todos os dias, eu encontre dúzias de sistemas aplicados para prevenir erros humanos. O fusível de um equipamento elétrico previne que haja uma sobrecarga no meu equipamento e se inicie um incêndio. A pia do banheiro possui um pequeno buraco para evitar a água de transbordar. Meu exemplo favorito é o meu novo carro que não tranca se a chave estiver dentro.

Técnicas de prevenção são, da mesma forma, aplicáveis a software. Certa vez trabalhei em um projeto no qual registrei uma porção de erros em vários componentes que usavam uma função de uma biblioteca incorretamente. O erro era fácil de acontecer e não provocava uma bug trivial, mas causava um memory leak que ocasionava um erro de performance considerável. Após detectar o problema, escrevi um script para verificar todas as ocorrências do mesmo erro no código fonte. Uma vez que esses bugs foram documentados, adicionei esse script a uma lista de verificações a serem feitas quando um desenvolvedor adiciona código à aplicação. Se não evitei a primeira ocorrência desse bug, por outro lado, com o script, demos um jeito desse bug nunca mais voltar a aparecer na aplicação. Mais adiante, por causa das verificações realizadas, os desenvolvedores aprenderam a usar corretamente a função da biblioteca.

Após o sucesso dessa iniciativa, sempre que encontrávamos um bug que poderia ser detectado automaticamente através de códigos, escrevíamos uma rotina e transformávamos a detecção em uma prevenção adicionado essa rotina à lista de verificações. Quando o produto foi lançado, existiam dezenas de scripts de verificação prevenindo centenas de bugs.

Técnicas de prevenção não precisam ser ferramentas. Recentemente estava trabalhando em um projeto no qual havia uma quantidade relevante de erros relacionados a projeto/arquitetura num time de uma área específica. Não conseguiria eliminar os erros através de uma detecção automática, no entanto, estava convencido de que uma revisão de código informal teria percebido estes erros. Mostrei os erros ao gerente da área e ele concordou com minha avaliação. Logo depois ele iniciou a requerer revisão de código para todas as novas alterações de projeto. Após isso, vi pouquíssimos erros de projeto daquele time. Melhor ainda, outros erros que eu não teria encontrado também foram prevenidos.

Prevenção de defeitos definitivamente exige investigação da causa raiz do bug. Existem muitas formas de determinar a origem de um incidente, no entanto tive um grande sucesso usando uma estratégia muito mais simplificada de análise. A melhor parte da minha técnica é agir como uma criança de 3 anos de idade, perguntando tantos “Porquês” quantos forem necessários para chegar ao ponto no qual posso aplicar a técnica de prevenção: Por que esse bug aconteceu? Por que essa função em particular foi usada? Por que foi possível que essa função fosse usada incorretamente? Por que esse erro não foi pego no Code Review? Posso garantir que essas perguntas irão desvendar uma técnica de prevenção para cada bug, e cada técnica de prevenção que você encontrar e implementar reduzirá significantemente os erros que você irá encontrar em momentos posteriores.

Software continuará a ter bug nos anos vindouros. Posso aceitar esse fato, mas não posso aceitar o grande número de bugs que permitimos — e esperamos — que os testadores encontrem. Se queremos levar Qualidade a sério, é tempo de nos cansarmos de encontrar bugs e começar a preveni-los de acontecer em primeiro lugar.