FEW HICCUPPS

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

Alguns anos atrás, escrevi um artigo para a Better Software Magazine chamado “Testando sem um mapa”. O artigo era sobre identificar e aplicar oráculos, e listava várias dimensões de consistência através das quais poderíamos encontrar ou descrever problemas em um produto. A lista original veio de James Bach.

Testadores comumente dizem que reconhecem um problema quando o produto não “atende às expectativas”, mas isso parece vazio pra mim; uma tautologia. Testadores podem ter mais credibilidade quando eles conseguem descrever de onde suas expectativas vieram. Talvez, surpreendentemente, vários testadores sofram com isso, então vamos ao trabalho.

Expectativas sobre o produto giram em todo de uma consistência desejável entre coisas relacionadas.

• Histórico. Esperamos que a versão atual do sistema seja consistente com versões anteriores.
• Imagem. Esperamos que o sistema seja consistente com a imagem que a empresa queira transparecer, com sua marca ou com sua reputação.
• Produtos Comparáveis. Esperamos que o sistema seja consistente com sistemas que sejam, de alguma forma, comparáveis. Isso inclui outros produtos da mesma linha; produtos competidores, serviços ou sistemas; ou produtos que não estão na mesma categoria, mas processam as mesmas informações; ou processos e algoritmos alternativos.
• Afirmações. Esperamos que o sistema seja consistente com as coisas que pessoas importantes dizem a respeito dele, seja de forma escrita (especificações, documentos de design, manuals, rascunhos num quadro) ou verbalmente (em reuniões, anúncios públicos, conversas de corredor).
• Desejos dos Usuários. Acreditamos que o sistema deva ser consistente com ideias plausíveis que usuários possam ter. (Atualização, 05/Dez/14: costumávamos chamar de “expectativas dos usuários”, mas essas expectativas são tipicamente baseadas em outro oráculo listado aqui, ou no critério de qualidade que é atrelado aos desejos; então nomeamos “desejos dos usuários”. Mais sobre isso aqui.)
• Produto. Esperamos que cada elemento do sistema (ou produto) seja consistente com objetos comparáveis dentro do mesmo sistema.
• Propósito. Esperamos que o sistema seja consistente com algum uso implícito ou explícito a que pode ser sujeitado pelos usuários.
• Estatutos. Esperamos que o sistema seja consistente com leis e regulações que são relevantes ao produto ou ao seu uso.

Eu notei que, em geral, reconhecemos um problema quando observamos que o produto ou sistema está inconsistente com um ou mais destes princípios; esperamos isso do produto, mas quando recebemos aquilo, temos razão para suspeitar de um problema.

(Se eu estivesse escrevendo o artigo hoje, substituiria espera por deseja, pelas razões citadas aqui.)

“Em geral” é importante. Cada um desses princípios é heurístico. Princípios de oráculo são, como todas as heurísticas, falíveis e dependentes de contexto; para serem aplicadas, não seguidas. Uma inconsistência com um destes princípios acima não garante que há um problema; pessoas determinam se algo é ou não um problema ao aplicarem uma variedade de princípios de oráculo e noções de valor. Nossos oráculos podem nos enganar, fazendo com que vejamos um problema que não existe, ou ignorar um problema que existe.

Considerando que um oráculo é uma forma com que reconhecemos um problema, é maravilhoso poder ter uma lista como essas em sua cabeça, de forma que você esteja apto a reconhecer problemas. Parte da razão pela qual pessoas acharam o artigo útil, talvez, é que a lista é fácil de memorizar: as letras iniciais dos princípios foram a palavra HICCUPPS (soluços, em inglês). Histórico, Imagem, Afirmações, Produtos Comparáveis, Expectativas dos Usuários (que foi alterado para “Desejo dos Usuários”), Produto, Propósito e Estatutos.

Com um pouco de memorização, prática e repetição, você pode pegar a lista, colocar em sua cabeça e consultá-la num piscar de olhos. Você pode usar a lista para antecipar problemas ou para enquadrar problemas que você perceber. Outra razão para internalizá-la é ser capaz de transformar o sentimento de que há um problema em uma distinção e descrição explícita de um problema. Você pode melhorar um relatório de bug vago ao referenciá-lo a um princípio específico de oráculo. Um relatório de um testador é mais crível quando pessoas que tomam decisões (gestores, programadores) podem entender claramente porquê o testador acredita que uma observação aponta para um problema.

Fico encantado com a quantidade de vezes que o artigo foi referenciado e ainda mais feliz quando pessoas me dizem que ele as ajudou. Entretanto, o artigo foi publicado há muito tempo e, desde então, James Bach e eu observamos testadores usando outros princípios de oráculo, tanto para antecipar problemas, quanto para descrever os problemas que encontraram. Em meu conhecimento, essa é a primeira vez desde 2005 que qualquer um de nós tenha publicado a lista consolidada de nossos princípios de oráculos fora de nossas aulas, conferências ou conversas informais. Nosso catálogo de princípios agora inclui:

• Estatutos e Padrões. Esperamos que o sistema seja consistente com estatutos, atos, leis, regulações e padrões relevantes a ele. Estatutos, leis e regulações são coordenadas, na maior parte das vezes, por autoridades externas (apesar de haver um significado para “estatuto” que se refere aos atos de corporações ou de seus fundadores). Padrões podem ser mandatórios ou voluntários, explícitos ou implícitos, externos ou internos ao grupo de desenvolvimento.
  Qual a diferença entre Padrões e Estatutos versus Afirmações? Afirmações vêm de dentro do projeto. Para Padrões e Estatutos, a ordem vem de fora. Quando um grupo de desenvolvimento conscientemente escolhe aderir a um determinado padrão, ou quando a lei ou regulação é citada como um requerimento, há uma afirmação que nos permite reconhecer um problema. Adicionamos Padrões quando percebemos que, às vezes, o testador reconhece um potencial problema para o qual nenhuma afirmação explícita foi feita ainda.

Enquanto testa, um testador familiarizado com um padrão específico pode notar que o produto não está em conformidade com convenções de UI, com um RFC, ou com um padrão de código informal que não é controlado pelo projeto em si.

Alguma dessas coisas constituiria um problema? No mínimo, seriam um issue, até que os responsáveis pelo produto declarem se o padrão deve ser seguido, violado em alguns pontos ou totalmente rejeitado.

Um testador familiar com os protocolos de auditoria da Anvisa pode reconhecer brechas nas evidências desejadas pelo auditor. Similarmente, um testador familiarizado com os requerimentos nas leis do direito das pessoas com deficiência pode reconhecer problemas de acessibilidade que outros testers podem não ver. Mais ainda, um testador experiente pode usar seu conhecimento da padronização para identificar custos extras associados com a má interpretação do padrão, excessiva documentação ou conformidade desnecessária.

• Explicabilidade. Esperamos que o sistema seja compreensível a tal ponto que possamos articular uma explicação sobre seu comportamento, para nós mesmos e para os outros. Se, enquanto testadores, nós não entendemos o sistema bem o suficiente para descrevê-lo ou se ele exibe comportamentos que não podemos explicar, então temos razão para suspeitar que pode haver um problema de um tipo ou de outro. Por um lado, pode haver um problema no produto que ameace o seu valor. De outro, podemos não saber o suficiente sobre o produto para testá-lo adequadamente. — este é, discutivelmente, um problema maior do que o primeiro. Nosso desentendimento pode levar a desperdício de tempo ao nos fazer reportar não-problemas. Pior, essa confusão pode nos impedir de reconhecer problemas genuínos que estão à nossa frente.
  Aleksander Simic, em uma mensagem privada, sugere que a heurística da explicabilidade se estenda a mais membros do time e não só a testadores. Se uma pessoa programadora não conseguir explicar o código que ela mantém (pior, escreveu), ou se um tipo de desenvolvimento começou algo malmente definido e a confusão está se espalhando no projeto, então temos razão para suspeitar, investigar e reportar um problema. Eu concordo com Aleksander. Qualquer tipo de confusão no produto é uma issue, e issues são placas de petri para bugs.
• Mundo. Esperamos que o produto seja consistente com coisas que sabemos a respeito ou podemos observar no mundo. Muitas vezes, esse tipo de inconsistência nos leva a reconhecer que o produto é inconsistente com seu propósito ou com uma expectativa que poderíamos ter, baseados em nossos modelos e esquemas. Quando estamos testando, não somos capazes de perceber e articular todas as nossas expectativas antecipadamente a uma observação. Algumas vezes, percebemos uma inconsistência com nosso conhecimento sobre o mundo antes sequer aplicarmos algum princípio. Essa heurística pode falhar quando nosso conhecimento sobre o mundo está errado; quando estamos mal-informados ou enganados pela nossa memória. Também pode falhar quando o produto revela algo que antes nós não sabíamos sobre o mundo.

Há mais uma heurística que testadores comumente aplicam enquanto buscam por problemas, especialmente num produto a que não estão familiarizados. Diferente dos anteriores, esta é uma heurística de inconsistência:

• Familiaridade. Esperamos que o sistema seja inconsistente com padrões de problemas familiares. Quando observamos testadores, notamos que eles muitas vezes começam a testar o produto procurando por problemas que já viram antes. Isso dá a essas pessoas um ritmo imediato; enquanto procuram por tipos de bug familiares, eles exploram e interagem com o produto e, ao fazer isso, eles aprendem sobre o mesmo. Iniciar os testes focando em problemas familiares é um jeito rápido e poderoso, mas que pode nos ludibriar. Problemas que são significantes em um produto (por exemplo, estética na interface de usuário de um produto comercial) pode ser menos significante em outro contexto (como uma aplicação desenvolvida para o uso interno em uma companhia). Um produto desenvolvido em um contexto (por exemplo, um em que os programadores performam várias verificações de unidade) pode ter evitado problemas familiares a nós em outros contextos (por exemplo, um em que os programadores são menos diligentes).
  Focar em problemas familiares pode desviar nossa atenção de outros princípios de consistência que são mais relevantes para a tarefa em nossas mãos. Talvez mais importante, uma busca prematura por bugs pode nos distrair de uma atividade crucial nos estágios iniciais de testes: a busca pelos benefícios e funções que irão nos ajudar a construir melhores noções de valor, risco e cobertura, e vão instruir testes mais profundos e elaborados. Note que qualquer padrão de problemas familiares deve, eventualmente, se relacionar a um dos princípios de consistência; se era um problema antes, é porque o sistema foi inconsistente com algum outro oráculo.

Padrões foi o primeiro das novas heurísticas que notamos; aí veio problemas Familiares. Este último ameaçou nosso mnemônico! Por um tempo, eu juntei Padrões com Estatutos, sugerindo que pessoas memorizarem HICCUPPS(F), com aquele F feio vindo no final. Mas, desde então, inserimos Explicabilidade e Mundo, permitindo colocar o F no início e enfatizando a realidade de que testadores comumente começam a buscar por problemas ao procurar por aqueles que já conhecem. Então o novo mnemônico: (F)EW HICCUPPS.

Essa não é uma lista exaustiva. Mesmos se fossemos bestas o suficiente de pensar que temos uma lista exaustiva de princípios de consistência, não conseguiríamos provar que era. Por essa razão, encorajamos testadores a desenvolverem seus próprios modelos de teste, incluindo modelos de consistência para influenciar seus oráculos.