Dogfooding encontrou o gap que mil testes não viram: tentamos contratar dentro do nosso próprio OS

A suíte estava verde. Cada endpoint respondia, cada registro salvava, cada página renderizava no tempo que deveria. Por todo número que rastreávamos, o sistema funcionava. Então tentamos fazer algo que uma empresa de verdade faz numa terça-feira qualquer, adicionar uma pessoa a ele, e andamos direto para fora da borda do mapa. Havia um botão para convidar. Não havia nada do outro lado de aceitar. A nova pessoa conseguia logar e ficar de pé numa sala onde nenhum trabalho era endereçado a ela, porque tínhamos construído um sistema que conseguia fazer o trabalho e esquecido de construir a parte onde alguém novo chega para fazê-lo.

Mil testes tinham rodado naquela manhã. Nenhum deles jamais tinha tentado ser o novo contratado.

Essa é a lição inteira, e o resto deste post é por que ela não é um rodapé constrangedor mas a forma mais confiável que conhecemos de encontrar o que está de fato quebrado. Você não descobre o que está faltando testando o sistema. Você descobre vivendo dentro dele.

A coisa para a qual os testes são estruturalmente cegos

Aqui está o modelo em que todo engenheiro confia, e deveria: você escreve testes que afirmam que o sistema faz o que você pediu. O email de convite envia. O registro persiste. A página carrega no tempo. Verde significa que o comportamento que você especificou é o comportamento que você obteve. É o melhor detector de mentiras que temos, e nunca lançaríamos sem ele.

Mas olhe de perto o que essa frase assume. Um teste só consegue checar os comportamentos que você pensou em nomear. Ele é uma memória perfeita da sua própria imaginação, e um branco total em todo lugar onde sua imaginação não foi.

O fluxo de novo-contratado não estava falhando num teste. Ele não tinha teste, porque ninguém tinha imaginado o momento. Tínhamos testes para enviar um convite e testes para armazenar um usuário e testes para renderizar o dashboard, cada um verde, cada um verdadeiro. A coisa que estava faltando vivia na costura entre eles: o que essa pessoa supostamente faz no dia um, e como o sistema lhe entrega seu primeiro pedaço de trabalho de verdade? Nenhuma asserção cobre uma pergunta que ninguém fez.

Esse é o ponto cego estrutural, e ele não tem nada a ver com quão bons são seus testes. Um milhão a mais deles, todos passando, não teria pego isso. Eles estavam todos olhando para dentro, confirmando as partes que já tínhamos imaginado. O gap estava na parte que não tínhamos.

A correção ingênua: escreva mais testes

A resposta óbvia a “um teste não pegou isso” é “escreva mais testes”. Adicione cobertura para onboarding. Afirme que a nova pessoa vê uma tarefa. Feche o buraco e siga em frente. Parece rigoroso, e foi a jogada que buscamos primeiro.

Não funciona, e a razão é humilhante.

Para escrever o teste que teria pego isso, teríamos precisado já saber que o fluxo estava faltando. O teste é downstream do insight, não uma fonte dele. Só conseguimos afirmar “o novo contratado vê sua primeira tarefa” depois de termos sentido a ausência dessa tarefa, depois de termos sido as pessoas confusas logando na sala vazia. Escrever mais testes endurece o mapa que você já desenhou. Não faz nada sobre o território que você nunca percorreu. Você pode passar um ano subindo a cobertura de alta para mais alta e nunca uma vez tropeçar no continente faltante, porque cobertura mede quão completamente você checa o que imaginou, não se sua imaginação estava completa.

Mais testes tornam um sistema conhecido mais confiável. Eles são impotentes para revelar um desconhecido. Isso não é uma falha do teste, é a definição do que o teste é.

Nosso jeito: torne-se o seu próprio usuário pior-onboardado

Então paramos de tentar testar nosso caminho até o gap e fizemos a única coisa que de fato o traz à tona. Tentamos viver dentro do sistema como as pessoas para quem o construímos, não como os engenheiros que sabiam cada atalho, mas como um estranho encontrando-o pela primeira vez.

A ideia-chave é simples. Você não descobre o que está faltando testando o sistema, você descobre vivendo dentro dele.

Viver dentro dele significa usar o produto para rodar a operação de verdade, com a fricção de verdade, onde o custo de uma peça faltante cai sobre você em vez de sobre um usuário que você nunca vai conhecer. Quando tentamos fazer onboarding de uma nova pessoa e batemos na sala vazia, isso não foi um bug report registrado por um tester checando uma caixa. Foi uma parede na qual andamos enquanto tentávamos fazer trabalho de verdade, que é o único tipo de parede que te conta a verdade. Um tester pergunta “o botão funciona?”. Alguém vivendo dentro do sistema pergunta “cliquei no botão, e agora, o que eu supostamente faço, e por que não tem nada aqui?”.

Essa segunda pergunta é a que os testes não conseguem gerar, porque ela vem da intenção, não da especificação. O usuário tem um objetivo que atravessa dez features que a suíte de testes checa uma de cada vez, e o objetivo é onde as costuras aparecem. Cada feature passa. A jornada através delas se parte ao meio.

Quando você trata sua própria fricção como o sinal, o gap deixa de ser um constrangimento e se torna a coisa mais valiosa que você encontrou a semana toda. A sala vazia não foi uma falha em lançar. Foi um fluxo que agora sabíamos que devíamos à próxima pessoa de verdade, descoberto pelo custo de uma tarde em vez de um cliente perdido.

Por que um OS especialmente precisa ser vivido

Isso importa mais para alguns softwares que para outros, e importa mais para o tipo que estamos construindo.

Uma ferramenta de propósito único tem uma superfície pequena. Você consegue imaginar cada caminho por um app de cronômetro, então testar-como-você-imaginou te leva a maior parte do caminho. Mas um sistema operacional para rodar uma empresa não é uma ferramenta que você abre e fecha. É o lugar onde o trabalho vive, pessoas, tarefas, decisões, os handoffs entre elas, a chegada no dia um e a saída de alguém-acabou-de-partir. Seu valor está no tecido conjuntivo, e tecido conjuntivo é exatamente o que testes unitários não conseguem ver, porque toda unidade passa em isolamento enquanto a coisa que está quebrada é o espaço entre elas.

Pense na diferença entre testar uma porta e viver numa casa. Você consegue verificar que a porta abre, fecha e tranca, tudo verde. Você só descobre que não há corredor atrás dela tentando andar para algum lugar.

O gap de contratar-uma-pessoa era um corredor faltante. A porta funcionava perfeitamente.

Um OS é em sua maioria corredores. As features são a parte fácil; as formas como elas se conectam numa vida que alguém possa de fato viver são a parte difícil, e elas são invisíveis para qualquer um que só checa as portas. A única forma de encontrar o corredor faltante é tentar ir de um cômodo a outro carregando algo de verdade, que é dizer, viver lá. É por isso que nos tornamos os primeiros habitantes de cada andar que construímos, antes de pedir a qualquer outro para se mudar.

Um teste pergunta se a porta abre. Viver dentro do sistema pergunta se há um cômodo do outro lado.

Por que isso é uma disciplina, não uma confissão

Seria fácil ler tudo isso como “lançamos algo incompleto”. Essa não é a lição, e reformulá-la importa, porque a falha aqui é universal, ela acontece com todo time que constrói um sistema rico o suficiente para ser vivido.

Todo produto suficientemente conectado tem gaps que seus criadores não conseguem ver de dentro das próprias suposições. A pergunta nunca é se eles existem. É se você os encontra andando para dentro deles você mesmo, no seu próprio tempo, ao seu próprio custo, ou se o seu cliente os encontra primeiro, no dia em que estava contando com você. Dogfooding não é penitência por trabalho incompleto. É o lugar mais barato possível para levar o golpe.

Então fizemos disso uma regra em vez de um reflexo. Antes de um fluxo ser real, alguém do time tem que viver a jornada inteira de ponta a ponta, chegar como a nova pessoa, fazer o trabalho, bater na costura, nomear a fricção em voz alta. A fricção se torna a próxima coisa que construímos, não a próxima coisa pela qual pedimos desculpas. A sala vazia virou um fluxo de onboarding em dias, não porque um teste ficou vermelho, mas porque um humano foi procurar sua primeira tarefa e não encontrou nada, e esse nada foi mais alto que qualquer asserção falhando.

A disciplina é continuar se movendo mais fundo. Todo andar que terminamos, tentamos viver um andar acima. Os gaps ficam um passo à frente das pessoas a quem de outra forma os lançaríamos.

A virada

Continuamos voltando ao momento na sala vazia, não o fluxo faltante, mas a sensação dele. A confusão pequena e específica de ser uma pessoa que tinha acabado de receber acesso a um sistema e não fazia ideia do que supostamente deveria fazer com ele. Nenhum teste jamais teria sentido isso, porque senti-lo requer querer algo que o software ainda não consegue te dar.

Esse querer é a parte que você não consegue automatizar. Uma suíte checa se o sistema faz o que declaramos. Ela não consegue checar se o sistema é bom de se estar dentro, se chegar parece entrar num time ou parece acordar num escritório vazio com as luzes apagadas. O único instrumento que mede isso é um ser humano tentando viver um dia de verdade através do produto e notando, no estômago, onde ele esfriou. Nossas melhores descobertas de features não vieram de um dashboard. Elas vieram de um de nós ficando quietamente frustrado enquanto tentava usar nossa própria coisa, e se recusando a olhar para o outro lado.

Importar-se o suficiente para ser o seu próprio usuário pior-onboardado, para buscar sua própria fricção em vez de contorná-la, não é algo que você consiga instalar. É uma postura. E é a que encontra o gap que mil testes não viram.

---

É isso que estamos construindo na Apollo Space: um sistema operacional dentro do qual temos que estar dispostos a viver antes de pedir a qualquer outro. No dia em que o nosso próprio onboarding nos deixou de pé numa sala vazia, o sistema estava tecnicamente perfeito e quietamente invivível, e a única razão de sabermos a diferença é que fomos procurá-la nós mesmos. Se o teste mais honesto que você consegue rodar é tentar fazer o seu próprio trabalho dentro do seu próprio produto, achamos que todo time deveria ser corajoso o suficiente para falhar nele primeiro.