Teste Exploratório 3.0

Artigo sobre a história do termo, além de novas percepções e aprendizagens na perspectiva de James Bach e Michael Bolton

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

[Nota dos Autores: outros já argumentaram o mesmo que trazemos aqui: que teste exploratório deve ser chamado somente de teste. De fato, Michael disse isso sobre testes em 2009 e James escreveu um post em 2010 que parece falar algo parecido sobre pessoas testadoras. Aaron Hodder foi bem direto sobre isso em 2011, assim como Paul Gerrard. Apesar de fazer tempo que temos entendido e ensinado que todo teste é exploratório, nós nunca tomamos a iniciativa de parar de usar o termo “teste exploratório”. Ainda hoje, não estamos dizendo que você deva PARAR de usar o termo, apenas que é hora de começarmos a assumir que teste é, por definição, exploratório, em vez de assumir que isso significa teste roteirizado (scripted testing, como casos de teste) que contém um pouco de exploração nele.]

[Segunda Nota dos Autores: algumas pessoas começam a ler esse artigo com uma visão fechada do que nós queremos dizer com a palavra “script”. Não estamos falando de um pedaço de texto! Com “script”, estamos falando de qualquer sistema de controle ou fator que influencie seus testes e está aquém de sua jurisdição (mesmo que temporariamente). Isso inclui instruções em roteiro, mas também significa qualquer forma de instrução ou até mesmo vieses psicológicos que não são instruções.]

Por James Bach e Michael Bolton

No princípio, era o teste. Ninguém fazia distinção entre teste exploratório e roteirizado. O capítulo sobre testes escrito por Jerry Weinberg (1961), em seu livro Computer Programming Fundamentals, descrevia teste como inerentemente exploratório e ele expressou cautela ao formalizar isso. Ele disse “É, com certeza, muito difícil fazer com que máquinas verifiquem o quão bem o programa corresponde às intenções do programador sem dar uma enorme quantidade de informação acerca dessas intenções. Se tivéssemos alguma forma simples de representar essas informações para as máquinas fazerem verificações, poderíamos simplesmente fazer com que as máquinas também escrevessem o código. Não esqueçamos que operações logicamente complexas ocorrem através da combinação de instruções simples executadas pelo computador e não pelo computador logicamente deduzindo ou inferindo aquilo que é desejado”.

Jerry entendeu a distinção entre trabalho humano e trabalho maquinal. Porém, vieram os “formalizadores” e confundiram todo mundo. Os formalizadores — começando oficialmente em 1972 com a publicação do primeiro livro sobre testes, Program Test Methods — focando nas formas de teste, em vez de sua essência. Por “formas”, queremos dizer palavras, imagens, sequências de bits, arquivos, tabelas, fluxogramas e outras formas explícitas de modelagem. Essas são coisas que podemos ver, ler, mostrar, mover de um lugar para outro, contar, guardar, resgatar, etc. É tentador olhar para esses artefatos e dizer “Que haja teste!”, mas teste não é um artefato. Testar, na interseção dos processos mentais e atividades humanas, faz uso de artefatos. Artefatos de teste sem os humanos é como uma clínica médica sem pessoas médicas e enfermeiras: no melhor dos casos, quase que totalmente inútil. No pior, um perigo para as pessoas inocentes que tentarem fazer uso dela.

Não culpamos os inovadores. Na época, eles estavam lidando com ideias novas e atraentes. O céu era o limite! Mas formalização e mecanização rapidamente escapou de seus laboratórios. Conversas levianas sobre “fábricas de teste” e padrões IEEE pobremente desenhados surgiram. Em pouco tempo, toda conversa “respeitável” sobre testes de software era orientada ao uso de roteiros. Teste informal foi taxado de anti-profissional. Os papéis do pensamento, sentimento e comunicação humana perderam importância.

James entrou na briga em 1987 e tentou entender toda a situação. Descobriu, simplesmente observando testes sendo feitos, que testes “ad hoc” funcionavam muito bem para encontrar bugs e testes altamente roteirizados, não. (Notas: não é nossa intenção fazer parecer que essa descoberta foi fácil, porque não foi. O que queremos dizer é que verdades não-óbvias sobre testes estão evidenciadas ao nosso redor, apenas precisamos deixar de lado o que é comumente dito e observarmos cuidadosamente como as pessoas trabalham dia após dia). James passou a escrever e falar sobre suas experiências. Alguns anos como gerente de testes, muitos dos quais passou testando compiladores e outras ferramentas de desenvolvimento, ele descobriu que Cem Kaner cunhou o termo — “teste exploratório” — para representar o oposto do teste roteirizado. Na mensagem original, que coube dentro de algumas poucas páginas, Cem não definiu o termo e malmente o descreveu, mas foi o primeiro a falar diretamente sobre desenhar testes enquanto os performava.

Assim surgiu o que chamamos, aqui, de TE 1.0.

(Aqui, você pode encontrar O Histórico de Definições de Teste Exploratório, para uma visão cronologia quanto à nossa terminologia. Está em inglês).

TE 1.0: Rebelião

Testar com e sem um roteiro são experiências diferentes. A princípio, nós fomos atraídos pela qualidade das ideias que surgiram durante testes sem roteiro. Quando fazíamos TE, encontrávamos mais e melhores bugs. Simplesmente parecia uma melhor forma de testar. Não tínhamos descoberto o porquê disso ainda. E assim começou a primeira iteração de teste exploratório (TE) como retórica e uma teoria focada em escapar da “camisa de força” dos roteiros e abrir espaço para “testes melhores”. Nós estávamos encarando a atitude de que “teste ad hoc é incontrolável e não-gerenciável; algo que você não deve fazer”. Lutamos contra essa ideia, considerando que TE, naquele contexto, era uma atividade especial. Então, os paladinos do TE tratavam-no como uma técnica e advogavam pelo uso dessa técnica. “Ponha pra escanteio seus roteiros e olhe para o produto! Interaja com ele! Encontre bugs!”

A maior parte das pessoas ainda veem TE dessa forma: como uma técnica e uma atividade distinta. Mas nós estávamos errados em caracterizá-la dessa forma. Feito assim, nós percebemos, marginalizava e deturpava TE. Era um começo bom, mas continuar pensando dessa forma levava a um beco sem saída. Muitas pessoas hoje, até mesmo as que escreveram livros sobre TE, parecem felizes com essa visão.

A era do TE 1.0 começou a morrer em 1995. Naquela época, havia somente um punhado de pessoas na indústria que ativamente tentavam desenvolver teste exploratório como uma disciplina, apesar do fato de que todos os testadores inconscientemente ou informalmente buscavam e sempre buscaram isso. Para aquelas poucas pessoas, deixar TE no escuro não era satisfatório.

TE 1.5: Explicação

Ao final dos anos 90, uma pequena comunidade de pessoas testadoras na América do Norte (que, eventualmente, virou a comunidade global Dirigida a Contexto [Context-Driven], com alguns mudando para a comunidade de Testes Ágeis) tinha dificuldade em entender as habilidades e processos mentais que constituíam o ofício de testes em geral. Para isso, eles buscaram dois principais ramos de investigação. Um deles era a abordagem humanista de Jerry Weinberg quanto a engenharia de software, combinando pensamento sistêmico com psicologia familiar. A outra era a abordagem de Cem Kaner, que advogava pela ciência cognitiva e racionalismo crítico Popperiano. Esse trabalho logo nos faria refatorar nossas noções de teste roteirizado e exploratório. Por quê? Nosso entendimento quanto às profundas estruturas do teste propriamente dito estava evoluíndo rápido.

Quando James entrou para o ST Labs em 1995, ele se engajou, pela primeira vez, com a ideia de desenvolver uma visão e metodologia para teste de software. Foi quando ele e Cem começaram sua parceira de 15 anos. Foi assim que a metodologia Rapid Software Testing se formou. Uma das grandes inovações nessa trajetória foi a introdução do uso de heurísticas guiadas por palavras como uma forma prática de juntar o pensamento em tempo-real do testador com um compreensivo e subjacente modelo de pensamento voltado a testes. Listas com técnicas de testes e templates de documentação já estavam disponíveis há algum tempo, mas à medida que desenvolvíamos nosso vocabulário e modelos cognitivos para hábeis testes de software em geral, nós começamos a ver teste exploratório de um jeito novo. Começamos a comparar e contrastar as importantes estruturas do teste roteirizado e exploratório e as relações entre eles, em vez de vê-los como atividades que simplesmente pareciam ser diferentes.

Em 1996, James criou a primeira turma de testes chamada “Teste Exploratório”. Ele foi exposto a pensamentos de padrões de design e tentou incorporar esse conhecimento nas aulas. James identificou competências de teste.

Nota: durante esse período, James fazia distinção entre teste exploratório e teste ad hoc — uma distinção que nós não fazemos mais. TE é um processo ad hoc, no sentido usado pelo dicionário: ad hoc significa “destinado a essa finalidade”. Na real, ele buscava distinguir entre teste hábil e inábil, e hoje temos jeitos melhores de fazer isso. Agora, reconhecemos teste ad hoc inábil como TE, assim como cozinhar mal ainda é cozinhar, e dançar mal ainda é dançar. O valor do rótulo “teste exploratório” é simplesmente uma forma descritiva da uma atividade que é, entre outras coisas, ad hoc.

Em 1999, James foi contratado para definir um processo formalizado de testes exploratórios para a Microsoft. A ideia de ter um “processo ad hoc formal” parecia paradoxal e isso incitou um conflito que seria resolvido através de uma série de debates construtivos entre James e Cem. Esses debates levaram ao que chamamos de TE 2.0.

Havia também o processo de fazer com que TE fossem mais amigáveis para a gestão de projetos. Em 2000, inspirado pelo trabalho feito para a Microsoft, James e Jon Bach criaram “Gestão de Testes Baseados em Sessão [Session-based Test Management]” para um grupo na Hewlett-Packard. De certo modo, isso era uma forma generalizada do processo da Microsoft, com o objetivo de criar um alto nível de responsabilidade quanto ao trabalho exploratório informal. GTBS foi planejada para ajudar a defender trabalhos exploratórios dos formalizadores compulsivos que estavam acostumados a modelar testes em termos de casos de teste. Por um lado, GTBS foi bem sucedida em ajudar pessoas a reconhecer que trabalho exploratório era totalmente gerenciável. GTBS ajudou a transformar atitudes a irem de “não faça isso” a “tudo bem, blocos de tempo para testes exploratórios são coisas, da mesma forma que casos de teste são coisas”.

Por volta de 2000, a maior parte do mundo do testes parecia ter ouvido falar de alguma coisa sobre teste exploratório. Estávamos começando a fazer com o mundo fosse seguro para testes melhores.

TE 2.0: Integração

A era do TE 2.0 tem sido longa, baseada em uma percepção chave: o continuum exploratório-roteirizado. Ela é uma barra deslizante onde os testes vão de completamente exploratórios a completamente roteirizados. Todo trabalho de testes se enquadra em algum lugar dessa escala. Entendendo isso, nós paramos de falar de teste exploratório como uma técnica, mas sim como uma abordagem que se aplica às técnicas (ou como Cem gosta de dizer, um “estilo” de teste).

Nós podíamos pensar em testes dessa forma porquê, diferente de dez anos antes, agora nós tínhamos uma rica ideia das habilidades e elementos do teste. Não era mais um ato “criativo e místico” que algumas pessoas nasciam sabendo como fazer “intuitivamente”. Nós víamos teste como algo que envolvia estruturas específicas, modelos e processos cognitivos além da exploração, então sentíamos que podíamos separar a exploração do teste de uma maneira útil. Muito do que nós chamávamos de teste exploratório no início dos anos 90, passamos a chamar de “teste exploratório estilo livre”.

Por volta de 2006, concordamos com uma simples definição de TE, aprendizagem simultânea ao design de teste e execução de teste. Para ajudar a avançar a área, James e Cem criaram um encontro chamado Cúpula de Pesquisa de Teste Exploratório, em Janeiro de 2006 (os participantes eram James Bach, Jonathan Bach, Scott Barber, Michael Bolton, Elisabeth Hendrickson, Cem Kaner, Mike Kelly, Jonathan Kohl, James Lyndsay e Rob Sabourin). Enquanto nos preparávamos para ela, fizemos uma descoberta perturbadora: cada um dos participantes na cúpula concordava com a definição de TE, mas apenas alguns concordavam com o que a definição de fato significava. Esse fenômeno não tinha um nome na época, mas agora é chamado de “concordância superficial” na Comunidade de Testes Dirigidos a Contexto [Context-driven Testing community]. Para combater concordâncias superficiais e promover um melhor entendimento sobre TE, alguns de nós decidiram adaptar uma descrição mais evocativa e descritiva, proposta originalmente por Cem e depois editada por vários outros: “um estilo de teste que enfatiza a liberdade e responsabilidade individual da pessoa testadora para continuamente otimizar a qualidade de seu trabalho ao tratar o design de teste, execução, interpretação do resultado e aprendizagem como atividades mutuamente apoiadoras que seguem em paralelo durante o curso do projeto”. Independentes um do outro, Jon Bach e Michael sugeriram o trecho “liberdade e responsabilidade” da definição.

E assim nós chegamos a uma ideia específica e expressiva de exploração e seus papéis em testes. Exploração pode significar várias coisas: vasculhar um espaço, ser criativo, trabalhar sem um guia, fazer coisas que ninguém fez antes, confortar a complexidade, agir espontaneamente, etc. Com o advento do conceito de continuum (que Jon, irmão de James, chamava de “escala de liberdade do testador”) e as discussões da conferência de pares da CPTE, nós percebemos que a maioria das diferentes noções sobre exploração já eram centrais em testes em geral. O que o adjetivo “exploratório” adicionou, e como contrastava com “roteirizado”, era a dimensão de autonomia. Em outras palavras: auto-direcionamento.

As implicações da nova definição ficaram claras nos anos seguintes, e James e Michael ensinaram e consultaram a metodologia Rapid Software Testing. Agora, reconhecemos que com “teste exploratório”, nós estávamos tentando nos referir a um teste rico, competente e que é auto-direcionado. Em outras palavras, em todos os aspectos além de autonomia, um hábil teste exploratório não é distinguível de um hábil teste roteirizado. Apenas autonomia importa, não a documentação, não a deliberação, não o tempo gasto, nem as ferramentas, nem a intenção consciente. Você pode testar com roteiro sem ter nenhum pedaço de papel por perto (teste roteirizado não requer que você siga literalmente um roteiro escrito). Você pode testar com roteiro sem que tenha sido pré-planejado (uma outra pessoa pode estar te dizendo o que fazer em tempo-real à medida que as ideias vão surgindo). Você pode testar com roteiro num piscar de olhos (outra pessoa pode ter acabado de te dar um roteiro ou você pode ter acabado de montar um). Você pode testar com roteiro com ou sem uso de ferramentas (ferramentas alteram a forma de testar, mas não necessariamente a torna mais roteirizada). Você pode testar com roteiro mesmo inconscientemente (talvez você sinta que tem livre escolha, mas seus hábitos e modelos o prendem numa cadeia invisível). A essência de teste roteirizado é que a pessoa testadora não está no controle, mas sim sendo controlado por algum outro agente ou processo. Essa simples e vital ideia nos custou anos para perceber!

Naqueles anos, trabalhamos ainda mais as nossas noções quanto às habilidades especiais do teste exploratório. James e Jon Bach criaram a planilha de referência de Habilidades e Táticas de Exploração para dar mais especificidade e detalhe à resposta para a pergunta “o que, especificamente, é exploratório no teste exploratório?”

Em 2007, outro salto lento estava prestes a acontecer. Começou pequeno: inspirado por um livro chamado The Shape of Actions, James começou a distinguir entre processos que requerem julgamento e sabedoria humana e aqueles que não. Ele os chamava de “sapiente” vs. “não-sapiente”. Isso representava uma nova fronteira para nós: estudo sistemático e desenvolvimento de conhecimento tácito.

Em 2009, Michael ampliou essa noção ao distinguir entre testar e verificar. Teste não tem como ser automatizado, mas verificação pode ser completamente automatizada. Verificar está dentro de testar. De primeira, James fez forte objeção. Por já haver um conceito para teste sapiente, essa distinção era desnecessária. Para ele, verificar era simplesmente teste não-sapiente. Mas, após alguns anos aplicando essas ideias em nossas consultas e treinamentos, nós percebemos (de forma que nenhum de nós tinha notado antes) que verificar e testar era um jeito muito melhor de pensar e falar do que sapiente e não-sapiente. Isso porquê “não-sapiente” soava que nem “estúpido”, logo soava como se estivéssemos condenando verificações ao chamá-la de não-sapiente.

Você percebe como finas distinções linguísticas e mentais podem levar anos para serem trabalhadas? Essas ideias são as ferramentas que precisamos para planejar nossas decisões práticas. Porém, assim como novas drogas no mercado, algumas vezes pode levar anos e muita experiência para entender não apenas os benefícios, mas também os potenciais efeitos colaterais de nossas ideias e termos. Isso pode explicar o por quê que aqueles de nós que atuam no ofício há muito tempo nem sempre pacientes com colegas ou clientes que dão de ombros e nos dizem “isso é apenas semântica”. Faz parte de nossa experiência saber que semântica como essas pode ser a diferença entre comunicação nítida que motiva a ação e disciplina e o frágil conhecimento popular que perde espaço para o próximo enxame de palavras mágicas que surgem para agradar a gestão.

TE 3.0: Normalização

Em 2011, o sociologista Harry Collins passou a impactar tudo pra nós. Começou quando Michael leu Tacit and Explicit Knowledge. Rapidamente, ficamos atraídos pela escrita clara e reflexões brilhantes de Harry. Ele passou vários anos estudando cientistas em ação e suas ideias de como a ciência funciona encaixou perfeitamente com o que vemos na área de testes de software.

Estudando o trabalho de Harry e de seus colegas, aprendemos como falar sobre a diferença entre conhecimento tácito e explícito, o que nos permitiu reconhecer o que pode e o que não pode ser transformado em um roteiro ou outros tipos de artefatos. Ele fez distinção entre comportamento (o que pode ser observado, descrito em questão de aspectos de uma atividade) e ações (comportamentos com intenção) (que inspirou a distinção que James fez entre teste sapiente e não-sapiente). Ele destrinchou as diferenças entre ações mimeomórficas (ações que queremos copiar e performar da exata mesma forma todas as vezes) e ações polimórficas (ações que precisam variar para se conformar com as condições sociais); ao fazer isso, ele nos ajudou a identificar as ramificações e os limites do poder da automatização. Ele escreveu um livro (com Trevor Pinch) sobre como o conhecimento científico é construído; outro (com Rob Evans) sobre expertise; e outro sobre como cientistas decidem avaliar um específico resultado experimental.

O trabalho de Harry nos ajudou a estruturar outras ideias que coletamos ao longo do caminho.

• as ideias de McLuhan sobre mídias e ferramentas;
• O trabalho de Karl Weick sobre encontrar sentido;
• As noções de tempo de Venkatesh Rao, por sua vez, nos levou às noções de James C. Scott quanto a legibilidade;
• A compreensão (trazida a nós por uma inocente pergunta feita por um testador na Barclays Bank) que o “continuum exploratório-roteirizado” é, na real, o “continuum da formalização”. Em outras palavras, formalizar uma atividade é torná-la mais roteirizada;
• A compreensão quanto à importante diferença entre teste espontâneo e deliberado, que é sobre o grau de reflexão exercida pela pessoa testadora (não é a mesma coisa que exploratório vs. roteirizado, que se trata do grau de autonomia);
• O conceito de “testador responsável” (definida como a pessoa testadora que carrega responsabilidade total e pessoal pela qualidade de seu trabalho);
• O advento da vital distinção entre verificar e testar, que substituiu a necessidade de falar sobre “sapiência” em nossa retórica quanto a testes de software;
• A subsequente redefinição do termo “testar” dentro das terminologias do Rapid Software Testing para fazer com que as coisas ficassem mais explícitas.

Sobre o último tópico

TE 3.0, como um termo, é um pouco paradoxal porque estamos trabalhando, dentro da metodologia Rapid Software Testing, por nada menos que a completa depreciação do termo “teste exploratório”.

Sim, estamos aposentando o termo após 22 anos. Por quê?

Porquê, agora, definimos todo teste como exploratório. Nossa definição de teste agora é essa:

Testar é o processo de avaliar o produto aprendendo sobre ele através de experienciação, exploração e experimentação, o que envolve, em algum nível: questionar, estudar, modelar, observar, inferir, verificar saídas, etc.

Onde teste roteirizado se enquadra, então? Com “roteiro”, estamos falando de qualquer sistema de controle ou fator que influence seu teste e está aquém da sua escolha (mesmo que temporariamente). Isso não se refere apenas especificamente a instruções dadas a você e que precisam ser seguidas. Seus vieses psicológicos roteirizam você. Sua ignorância roteiriza você. Sua cultura organizacional roteiriza você. As escolhas que você faz e nunca questiona roteirizam você.

Ao definir todo teste como exploratório, roteirizar se torna um coadjuvante em nosso ofício; um elemento potencialmente útil, mas estrangeiro ao teste, um que pode ser interessante de debater e ser aplicado como uma tática em situações específicas. Uma excelente pessoa testadora não deve ser complacente ou desdenhosa quanto a roteiros, não mais que um lenhador deva ser complacente ou desdenhoso quanto a equipamento pesado. Essas coisas podem ajudar ou arruinar você, mas nenhum profissional sério pode ignorá-las.

Você está testando? Então você já está fazendo teste exploratório. Está testando com roteiro? Se fizer de maneira responsável, então você está fazendo teste exploratório com roteiro (e talvez com verificações). Se você estiver apenas testando com roteiro, então você está fazendo nada além de uma verificação desmotivada, e nós diríamos que você nem sequer está testando. Você está tentando agir como uma máquina, não como uma pessoa testadora responsável.

TE 3.0, em uma frase, é o rebaixamento da roteirização para uma técnica e a promoção do teste exploratório para, simplesmente, teste.