Transformando uma Pergunta em uma Hipótese Testável

• Distinguir uma pergunta bem formada de uma hipótese testável, e explicar por que a segunda não é apenas uma reformulação da primeira.
• Converter uma pergunta diagnóstica ("por que isso está lento?") em uma ou mais hipóteses específicas e verificáveis.
• Identificar as propriedades que tornam uma hipótese testável: especificidade, um mecanismo proposto, e uma diferença observável prevista.
• Gerar múltiplas hipóteses concorrentes para a mesma pergunta e explicar por que isso é normal em vez de um sinal de confusão.
• Reconhecer não hipóteses disfarçadas, afirmações que soam como palpites mas não se comprometem com nada verificável.

Um conceito anterior nesta trilha estabeleceu o que torna uma pergunta bem formada: ela nomeia o que contaria como uma resposta. "Qual dessas três operações domina o tempo de execução sob carga X?" é bem formada exatamente nesse sentido, há um conjunto finito de respostas candidatas (as três operações), e qualquer uma delas, uma vez identificada, resolve a pergunta. Mas uma pergunta bem formada ainda é apenas uma pergunta. Ela diz que formato uma resposta deve ter; não se compromete com nenhuma resposta particular. Saber que a resposta é "uma dessas três operações" não é o mesmo que ter um palpite sobre qual delas, ou por quê. Esse palpite, específico, verificável, e oferecido antes de você olhar para a evidência que o confirmaria ou refutaria, é uma hipótese, e transformar uma pergunta em uma é a etapa sobre a qual este conceito trata.

A distinção importa porque uma pergunta, por si só, não pode ser testada. Você não pode projetar um experimento, escrever um script de profiling, ou rodar uma medição contra "por que isso está lento?", não há nada ali para verificar contra a realidade, apenas uma lacuna que você gostaria de preencher. Uma hipótese preenche essa lacuna com uma afirmação específica: "a lentidão é causada por realocação repetida no loop crítico." Essa afirmação pode ser verificada. Você pode olhar contagens de alocação, você pode pré-dimensionar o buffer e remedir, você pode fazer profiling e ver onde o tempo é de fato gasto. A pergunta dizia que tipo de coisa contaria como resposta (uma operação, uma causa); a hipótese propõe um candidato real e, ao fazer isso, se torna algo sobre o qual evidência pode se pronunciar.

Esta etapa também prepara diretamente o próximo conceito nesta trilha: o critério de demarcação de Karl Popper, como documentado na entrada da Stanford Encyclopedia of Philosophy sobre Popper, sustenta que uma afirmação é científica na medida em que poderia concebivelmente ser mostrada falsa por alguma observação. Esse critério se aplica a hipóteses, não a perguntas, uma pergunta não tem valor de verdade para falsificar, mas uma hipótese tem. Então refinar uma pergunta em uma hipótese também é, implicitamente, o primeiro movimento em direção a tornar seu raciocínio falsificável no sentido de Popper: você não pode perguntar se uma pergunta nua poderia estar errada, mas pode perguntar isso de "a lentidão é causada por realocação repetida," e a resposta é sim, que é exatamente o que a torna digna de teste.

Pergunta vs. hipótese: dois trabalhos diferentes

Uma pergunta define o espaço de respostas aceitáveis sem escolher uma. Uma hipótese escolhe uma, ou uma de uma lista curta, e a enuncia como uma afirmação que poderia acabar sendo certa ou errada. Compare:

• Pergunta: "Qual dessas três operações domina o tempo de execução sob carga X?"
• Hipótese: "As chamadas resize() dentro do loop dominam o tempo de execução sob carga X."

A pergunta é satisfeita por qualquer identificação correta da operação dominante; ela não se compromete com uma de antemão. A hipótese se compromete. Esse comprometimento é o que a torna útil: uma vez que você tem um palpite específico, você sabe exatamente que evidência o apoiaria (profiling mostra resize() consumindo a maior parte do tempo de relógio) e exatamente que evidência o minaria (profiling mostra que o custo dominante está em outro lugar). Uma pergunta sozinha não dá esse alvo.

O processo de refinamento: estreitando o espaço de respostas

Transformar uma pergunta em uma hipótese é um ato de estreitamento, e tipicamente procede através de movimentos reconhecíveis:

1. Comece pela pergunta bem formada, que já nomeia a categoria de resposta (uma operação, uma causa, um valor).
2. Traga qualquer evidência parcial ou conhecimento de domínio que já exista, um stack trace, um flame graph de um profiler, um palpite de já ter visto esse modo de falha antes, para propor um candidato específico em vez de deixar a categoria aberta.
3. Enuncie o candidato como uma afirmação sobre o mundo, não como mais uma pergunta. "É a realocação?" ainda é uma pergunta. "A realocação é a causa" é uma hipótese.
4. Anexe, mesmo que informalmente, como observar a hipótese estar errada se pareceria. Se você não consegue dizer como uma versão falsa de sua afirmação se pareceria, provavelmente você ainda não produziu uma hipótese, veja Equívocos Comuns abaixo.

Isso é um refinamento, não um salto: a hipótese deveria ser rastreável de volta à pergunta que ela responde. Uma hipótese que responde a uma pergunta diferente daquela com que você começou não é progresso, mesmo que aconteça de ser verdadeira sobre algo.

O que torna uma hipótese testável

Três propriedades, na prática, separam uma hipótese testável de um palpite vago:

• Especificidade. "Alguma coisa sobre memória está tornando isso lento" nomeia uma categoria, não uma afirmação. "Chamadas repetidas a resize() dentro do loop respondem pela maior parte do tempo de relógio" nomeia um mecanismo específico e verificável.
• Um mecanismo ou local proposto. Uma boa hipótese diz não apenas que algo é verdade mas onde ou como, qual função, qual recurso, qual interação. Isso é o que permite projetar um teste que mira exatamente aquele mecanismo em vez de uma varredura ampla de tudo.
• Uma diferença observável prevista. Se a hipótese é verdadeira, alguma medição deveria sair diferente do que se fosse falsa. "A realocação é a causa" prevê que pré-dimensionar o buffer para evitar chamadas repetidas de resize() deveria mensuravelmente reduzir o tempo de execução; se pré-dimensionar não faz nada, a previsão falha.

Nenhuma dessas propriedades exige que a hipótese seja correta. Uma hipótese específica, que nomeia mecanismo, e faz previsão que acaba sendo errada ainda é uma boa hipótese, ela fez seu trabalho por ser verificável, e a verificação simplesmente saiu negativa. Esse é um modo de falha diferente de uma hipótese que nunca foi verificável para começar.

Múltiplas hipóteses, uma pergunta

Uma única pergunta bem formada rotineiramente admite várias hipóteses concorrentes, e produzir mais de uma é um sinal de boa prática, não de confusão. Para "qual dessas três operações domina o tempo de execução sob carga X?", é inteiramente razoável manter três hipóteses candidatas simultaneamente, uma por operação, precisamente porque a pergunta nomeou três candidatos e ainda não deu razão para favorecer um. O valor de escrever todas as três explicitamente, em vez de pular direto para uma favorita, é que isso força você a especificar de antemão que evidência distinguiria entre elas, antes de essa evidência estar em mãos. Comprometer-se com uma única hipótese cedo demais, antes de descartar suas concorrentes, arrisca interpretar evidência ambígua como confirmando o único palpite que você já gostava.

Exemplo 1 — um endpoint de API lento sob carga

Pergunta (já bem formada): "Qual dessas três operações, consulta ao banco de dados, serialização JSON, ou renderização de template, domina o tempo de resposta para esse endpoint sob carga concorrente?"

Refinamento para hipóteses. Um flame graph de uma execução de profiling de usuário único mostra a serialização consumindo uma grande fração do tempo de CPU mesmo sem concorrência, que é evidência de domínio que vale a pena incorporar. Isso sugere, mas não prova, uma resposta sob carga. Três hipóteses candidatas, cada uma rastreável à pergunta original:

• H1: "A serialização JSON domina o tempo de resposta sob carga, porque re-serializa o grafo de objeto completo em cada requisição em vez de armazenar em cache uma representação já serializada."
• H2: "A consulta ao banco de dados domina sob carga, porque exaustão do pool de conexões sob concorrência causa filas de consultas."
• H3: "A renderização de template domina sob carga, porque realiza buscas redundantes de sub-template por requisição."

Verificando testabilidade. Cada hipótese nomeia um mecanismo específico (serialização repetida, exaustão de pool, buscas redundantes) e cada uma prevê um observável distinto: H1 prevê que armazenar em cache o payload serializado deveria reduzir o tempo de resposta; H2 prevê que o tempo de resposta deveria se correlacionar especificamente com o tempo de espera do pool, visível em métricas de pool; H3 prevê que o tempo de resposta não deveria melhorar muito com o cache de serialização mas deveria melhorar com cache de buscas de template. Como as três previsões divergem, um único teste de carga com cronometragem por estágio pode, em princípio, distinguir entre todas as três, exatamente o alvo que uma pergunta nua não poderia fornecer.

Exemplo 2 — teste de integração intermitente

Pergunta: "O que causa esse teste de integração específico falhar em aproximadamente 1 a cada 20 execuções de CI, e a falha se origina no próprio teste ou no serviço que ele exercita?"

Refinamento para hipótese. Em vez de parar em "é intermitente, algo está errado," que não nomeia mecanismo e não prevê nada, o refinamento olha os logs de falha: toda falha registrada mostra a asserção do teste rodando antes de a escrita assíncrona do serviço ter sido concluída. Essa observação apoia uma hipótese específica: "O teste falha intermitentemente porque afirma sobre o resultado da escrita antes de a etapa de persistência assíncrona do serviço ter terminado, e a corrida só é perdida sob o agendamento mais lento e mais variável do CI."

Por que isso é testável e a versão vaga não era. "É intermitente" não prevê nada, nenhum experimento poderia mostrá-la falsa, porque não se compromete com nenhum mecanismo que uma medição poderia mirar. A hipótese refinada prevê que inserir uma espera explícita pela conclusão da etapa de persistência deveria levar a taxa de falha em direção a zero, e que retardar artificialmente o caminho de escrita do serviço (para ampliar a janela de corrida) deveria aumentar a taxa de falha. Ambas são previsões concretas e verificáveis; uma versão dessa hipótese que acabasse sendo falsa (digamos, a taxa de falha permanecesse a mesma depois de adicionar a espera) mostraria claramente o palpite errado, exatamente a propriedade que uma afirmação nua de "é intermitente" não tem.

• Reformular a pergunta com mais palavras não é uma hipótese. "Está lento porque algo no código é ineficiente" soa mais específico que "por que isso está lento?" mas não se compromete com nada que uma medição pudesse verificar, não nomeia um mecanismo nem prevê nenhuma observação particular. Uma hipótese genuína nomeia uma causa candidata, não um sinônimo para "há uma causa."
• Uma hipótese não precisa estar correta para ser boa. A qualidade de uma hipótese é julgada por se é específica e verificável, não por se acaba sendo verdadeira. Uma hipótese precisa que é refutada pelos dados ainda fez trabalho útil, eliminou um candidato e estreitou a busca; uma vaga que não pode ser nem confirmada nem refutada não fez nenhum.
• Uma pergunta produzir várias hipóteses é normal, não um sintoma de não entender o problema. Manter múltiplos candidatos nomeados abertos ao mesmo tempo, cada um rastreável de volta à mesma pergunta, é prática padrão, é o estreitamento prematuro para uma única favorita, antes de a evidência distingui-las, que tende a enviesar a interpretação posterior dos resultados.
• Uma hipótese não é o mesmo que um conserto. "Adicionar um cache ajudaria" é uma ação proposta, não uma afirmação sobre o que atualmente é verdade. A forma de hipótese é uma afirmação sobre a causa atual do comportamento observado ("realocação repetida está atualmente causando a lentidão"), que é aquilo sobre o qual a justificativa de um conserto deveria se apoiar, propor o conserto primeiro e fazer engenharia reversa de uma hipótese para corresponder a ele arrisca ajustar o palpite à solução desejada em vez de à evidência.

Uma pergunta bem formada nomeia a categoria em que uma resposta deve cair; uma hipótese é uma afirmação específica e verificável que escolhe uma resposta candidata (ou uma lista curta delas) antes de a evidência ser examinada. O refinamento de uma para a outra exige especificidade, um mecanismo ou local nomeado, e uma diferença observável prevista, propriedades que juntas tornam uma afirmação algo sobre o qual um teste pode de fato se pronunciar, em contraste com uma pergunta nua, que nada pode testar diretamente. Uma única pergunta frequentemente sustenta várias hipóteses distintas e concorrentes de uma vez, e escrevê-las todas explicitamente, em vez de se comprometer cedo com uma favorita, evita que evidência posterior seja lida seletivamente. Este refinamento também é o primeiro passo necessário em direção ao próximo conceito nesta trilha: apenas uma hipótese, não uma pergunta, pode ser questionada se é falsificável.