Confusão necessária e a Heurística Bootstrap

Texto original de: Michael Bolton, disponível aqui
Traduzido por: Rafael Bandeira

Nota do tradutor: Bootstrap significa “se virar com os recursos disponíveis”. Então, em tradução contextual, se vire!

Estou testando uma ferramenta de testes no momento, investigando-a para uma palestra. Os produtores desta ferramenta afirmam que eles têm centenas de milhares de usuários. Alguns comentários positivos aparecem num widget na página oficial do produto de várias pessoas que se dizem ser usuárias.

Já eu não consigo entender nada do produto. Não parece fazer o que deveria. Parece uma completa bagunça. É assustador, frustrante. Eu não sei por onde começar a analisar e como preparar o relatório. Estou confuso. Mas estou bem com isso.

Qualquer teste que valha a pena começa com algum grau necessário de confusão.

Por quê? Porque testes que valem a pena são, primariamente, sobre aprender algo sobre o produto e também aprender sobre como testá-lo em um contexto complexo e incerto. Por natureza, isso é confuso, é normal.

Se o contexto não é nem complexo, nem incerto, e se há poucos riscos, é capaz que você nem sequer precise testar, e uma simples demonstração já seja suficiente. Saber que o produto pode funcionar pode ser suficiente, naquele momento.

É por isso que, para programadores, performar verificações e automatizá-las no nível de unidade faz muito sentido. Essas verificações tendem a endereçar condições específicas, atômicas; são simples de desenvolver, performar e codificar; e provêm feedback rápido sem diminuir a velocidade do desenvolvimento.

Um produto é construído a partir de componentes pequenos e discretos. Através de mudanças pequenas e graduais, vai virando algo muito maior e mais complexo, com componentes que se interagem e comportamentos emergentes que não são triviais.

Um encontro com qualquer coisa não-trivial ao qual você não está familiarizado tende a ser bagunçado e confuso, a princípio. Ao mesmo tempo, trabalhando como testador, você provavelmente está sob a pressão de “fazer tudo certo de primeira” ou “entender tudo já do começo”. Mas ter tudo organizado realmente significa que estamos no fim de algo que estava bagunçado e que estamos no começo da próxima bagunça!

No Rapid Software Testing, chamamos isso de Conjetura Bootstrap:

Qualquer processo importante pra nós que é feito bem e eficientemente começou sendo mal-feito e ineficientemente.

Logo, ter “feito algo direito logo de primeira” provavelmente significa que não estava realmente direito, ou que não foi realmente a primeira vez, ou que foi trivial, ou que você apenas deu sorte.

Ao aprender sobre algo complexo e como testá-lo, há períodos frequentes de confusão. De fato, se estivermos lidando com algo complexo e sentirmos que temos certeza de como testá-lo, isso deveria nos fazer parar e pensar: por que tenho tanta certeza?

Uma confusão necessária é aquela confusão para a qual não temos uma solução algorítmica. Para resolver uma confusão necessária, precisamos explorar um contexto de solução complexo utilizando heurísticas (isso é, meios para resolver um problema que podem funcionar, mas que também podem falhar) e racionalidade limitada (isso é, racionalizar num espaço em que há limites para o que sabemos e o que podemos saber).

Para superar a confusão, precisamos brincar, raciocinar, refletir, fazer experimentos, perder coisas, perguntar muito, errar, ser pacientes. Confusão necessária sempre ocorre durante profunda aprendizagem e inovação.

Muitas vezes, somos treinados em nossas culturas, grupos sociais e nas escolas para negar que estamos confusos. E isso fica pior assim que chegamos no negócio de desenvolvimento de software: aparentar não saber algo é socialmente estranho — quase visto como um pecado dentro dos círculos de trabalho. Confusão pode nos deixar desconfortáveis.

Enquanto pessoa testadora, você poderia simplesmente escrever (ou pior, executar) vários scripts automatizados que verificam um novo produto ou funcionalidade em busca de erros específicos e previsíveis. Se você fizer isso sem explorar o produto e preparar a sua mente, seu teste estará cego para bugs importantes que podem estar lá.

Nenhum conjunto de instruções pode ensiná-lo tudo o que você precisa saber sobre um produto e sobre as diversas formas que as pessoas podem tentar usá-lo. Nenhum procedimento formal pode antecipar como você ou outra pessoa irá experienciar o produto. Nenhum framework de testes irá lidar com comportamentos não-previstos sem que você aprenda como lidar com aquele framework. Nenhuma ferramenta, nenhuma “AI”, pode determinar se o produto está operando corretamente ou se um gerente de produto irá considerar uma barra vermelha como algo que venha a ser um bug importante. Um completo e correto entendimento sobre essas coisas não estão disponíveis antecipadamente.

Você pode aprender a testar antecipadamente. Isso irá evitar confusão desnecessária durante o teste. Você pode aprender sobre a tecnologia e o domínio de seu produto antecipadamente, e isso irá evitar confusão desnecessária durante o teste. Você pode aprender sobre uma ferramenta específica antecipadamente, e isso pode te fazer evitar alguma confusão desnecessária durante seus testes também.

Mas você não pode aprender profundamente sobre um novo produto ou funcionalidade antes de encontrá-lo e interagir com ele. A confusão que você sentirá ao aprender sobre o produto é necessária, temporária e saudável.

O segredo é aceitar a confusão; reconhecer que está tudo bem estar confuso. Ao interagir com o produto e com as pessoas envolvidas; ao adquirir experiência; ao praticar novas habilidades e aplicar novas ferramentas, um pouco da confusão desaparece.

Por onde começar

Comece inspecionando o produto. Navegue pelas interfaces — a UI, o terminal, a API. Brinque com ele. Liste as funcionalidades-chave. Crie a silhueta do que está lá para ser testado. Considere quem pode usar o produto, e para o quê. Construa suas ideias sobre como eles podem apreciar o produto e como esse apreço pode ser ameaçado. Pense nos dados que entram, são processados, guardados, acessados, renderizados, mostrados e deletados. O que pode dar de errado com qualquer uma dessas coisas? Como os dados podem ser mal-usados, descaracterizados, excessivamente limitados, insuficientemente limitados, ou simplesmente errados?

E então itere. Siga o mesmo caminho para cada função e funcionalidade, indo cada vez mais fundo à medida que você segue. Talvez escreva alguns pedaços de código para gerar dados ou para analisar os dados de saída. (Você tem trabalhado com um produto há muito tempo? Esse ciclo é fractal*; aplica-se em novas funcionalidades e funções ou para reparos em um produto que você já conhece bem).

*Fractal (não confundir com fração) é uma estrutura geométrica que se repete infinitamente, ficando menor e mais funda a cada iteração (tipo uma espiral)

Ao aprendemos sobre o domínio do produto; ao darmos sentido às coisas; ao desenvolvermos nossos modelos mentais; ao falarmos sobre o produto e os problemas que observamos… mais e mais da confusão desaparece. Isso tudo pode acontecer notavelmente rápido se nos permitirmos um pouco de tempo experienciando, explorando e experimentando o produto. Ironicamente, precisamos deliberadamente requerer e nos dar espaço para espontaneidade. Precisamos ser bravos e abertos o suficiente para ajudar nossas pessoas gestoras a entenderem o quão necessário é esse trabalho — e o quão poderoso pode ser.

Quando abraçamos a confusão e nos debruçamos sobre ela, as coisas começam a ficar mais nítidas, nossos códigos e mapas ficam mais limpos, nossas noções de risco ficam mais afiadas, e ficamos mais bem preparados para procurar por problemas. E assim ficamos mais capazes de encontrar os mais obscuros e perigosos problemas — aqueles que ninguém mais encontrou até então. No começo, entretanto, esse processo começa com a gente tentando se virar.

A Heurística Bootstrap é: começa em confusão, termina em precisão.

Ah… e aquela ferramenta de testes que eu tava testando? Há uma razão para eu estar confuso: há um produto confuso em minhas mãos. O produto é inconsistente com as afirmações de seus produtores. Seu comportamento é inconsistente com seu propósito. Ele parece incapaz de manter seu estado. Ele entrega resultados enganosos. Para quem vê de fora, ele parece ter sido desenhado para entregar a impressão de que testes estão sendo feitos, sem de fato testar nada. Da perspectiva interna de um testador, é surreal, em sua maior parte pelo simples fato de não funcionar.

Então aqui vai uma outra heurística: confusão persistente sobre um produto — uma confusão que nunca vai embora — é comumente um indicador de que há um sério problema com o produto. Se você, pessoa testadora, não consegue entendê-lo, como as pessoas usuárias irão?

Depois de trabalhar com o produto por um pouco mais de uma hora, muita da confusão a que me referenciei acima desapareceu, e posso preparar um relatório confiantemente.

Só há uma única coisa que ainda me deixa confuso:

Como alguém pode ser enganado por uma ferramenta como essa?