Testar e Verificar, Refinados

Tradução literal do artigo que traz importantes distinções de terminologias

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

Esse texto é co-autorado por Michael Bolton. Passamos algumas horas debatendo sobre, basicamente, cada uma das frases. Também agradecemos Ian McCowatt por sua rápida revisão e comentários.

Teste e o uso de ferramentas são dois aspectos característicos da humanidade desde o início dos tempos (não as duas únicas coisas, claro, mas certamente duas dentre várias), mas enquanto teste é uma atividade cerebral e amplamente intangível, o uso de ferramentas é bem visível. Ferramentas viram parte integral de qualquer processo em que são usadas, modificando-o como um todo. Assim, por pelo menos centenas ou milhares de séculos, os humanos mais filosóficos se questionam “foi eu quem fez ou a ferramenta? Sou um guerreiro ou apenas uma plataforma de arremesso de lanças? Um fazendeiro ou empurrador de arado?”. Como Marshall McLuhan uma vez disse, “nós moldamos as ferramentas, que consequentemente nos moldam”.

Essa evolução pode ser um processo traiçoeiro que desafia como definimos a nós mesmos e as coisas ao nosso redor. Nós presenciamos como a industrialização transforma profissionais da marcenaria em fábricas de móveis. Isso pode nos induzir a falar da mudança no papel do montador de móveis, mas certamente não são a mesma coisa. Marceneiros ainda existem — poucos, de fato — , bem longe das fábricas, criando móveis caros e de altíssima qualidade. Ainda há demanda para marceneiros habilidosos, para resolver problemas que as Casas Bahia não conseguem. Essa situação existe nos campos das ciências e medicina, também. Na real, existe em todo lugar: quais são as implicações da evolução do uso de ferramentas no trabalho hábil de humanos? Qualquer pessoa que busque excelência em seu ofício luta para entender o papel adequado das ferramentas.

Sendo assim, não fiquemos surpresos que teste de software, hoje, é um processo que envolve o uso de ferramentas de várias maneiras, e que isso desafia a ideia do que é uma pessoa testadora.

Isso tem sido um problema desde sempre — tem sido parte do meu trabalho e tenho debatido sobre isso desde 1987, e tem material literário sobre assunto desde pelo menos 1961 — , mas algo novo aconteceu: computação móvel e distribuída em larga escala. Sim, isso é novo. Encaro isso como o maior desafio para testes de software da forma que conhecemos desde o advento dos microcomputadores. Por que é um desafio, exatamente? Porquê, somado à complexidade dos produtos e plataformas que têm crescido há décadas, hoje existe um mercado para softwares que são distribuídos e atualizados instantaneamente.

Nós queremos testar o produto muito rapidamente. Como fazemos isso? É tentador dizer “vamos deixar ferramentas fazerem isso!”. Essa conclusão coloca uma enorme pressão nos ombros dos testadores habilidosos e em quem produz essas ferramentas que pessoas testadoras usam. Enquanto isso, pessoas que não são testadoras capacitadas sonham com a industrialização dos testes de software de maneira similar ao que acontece com a marcenaria. Sim, sempre houve essa pressão, em algum nível. Mas agora, rufam-se os tambores da “entrega contínua”, abrindo uma nova frente de guerra.

Acreditamos que um habilidoso trabalho cognitivo não é industrial. Exatamente por isso é mais importante do que nunca o entendimento sobre o que é teste e como ferramentas podem auxiliar essa atividade.

Verificar vs. Testar

Por essa razão, na metodologia do Rapid Software Testing, fazemos distinção entre os aspectos do processo de teste que máquinas conseguem fazer e as coisas que somente humanos capacitados conseguem. Nós alcançamos isso linguisticamente ao adaptar uma palavra comum do vocabulário português “verificar” [checking, em inglês] para se referir ao que ferramentas conseguem fazer [A escolha do “verificar” foi feita pelo tradutor, na falta de melhores conjugações para a palavra “checar”]. Esse paralelo é exatamente o mesmo feito na distinção entre “programar” e “compilar”. Programar é o que humanos programadores fazem. Compilar é o que algumas ferramentas fazem pelo programador, mesmo que o que um compilador faça possa parecer, tecnicamente, exatamente o mesmo que programadores fazem. Pensando bem, ninguém fala em termos de programação automatizada e programação manual. Existe a programação, atividade humana, e existem as demais coisas feitas por ferramentas. Uma vez que uma ferramenta seja criada para fazer algo semelhante, a palavra “programação” nunca é utilizada para descrevê-la.

Agora que Michael e eu temos tido mais de três anos de experiência trabalhando com essa distinção, nós refinamos nossa linguagem ainda mais, com definições atualizadas e uma nova distinção entre verificação humana e verificação maquinal.

Primeiro, observemos testar e verificar. Aqui, propomos novas definições que substituirão as que temos usado ao longo dos anos (estão sujeitas a revisões e comentários de nossos colegas):

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, etc.

Um teste é uma instância do ato de testar.

Verificar é o processo de fazer avaliações aplicando regras de decisão algorítmicas em observações específicas sobre o produto.

Uma verificação é uma instância do ato de verificar.

Notas explicativas:

• “Avaliar” significa fazer julgamento de valor: está bom? Está ruim? Passou? Falhou? O quão bom? O quão ruim?
• “Avaliações”, na forma de um substantivo, refere-se ao produto do ato de avaliar, que, no contexto de “verificar”, é um artefato de alguma maneira, como um pedaço de código ou um arquivo.
• “Aprendizagem” é o processo de desenvolver a mente de alguém através da aquisição de novas informações. Apenas humanos conseguem exercer essa atividade em sua totalidade, da forma como usamos aqui, porque estamos nos referindo ao conhecimento tácito e ao explícito.
• “Exploração” implica dizer que todo teste é inerentemente exploratório. Todo teste é exploratório em algum nível, mas também podem ser estruturados por elementos roteirizados.
• “Experimentação” significa interação com o objeto e observá-lo em operação, mas também significa conduzir “experimentos mentais”, que envolvem puramente interações hipotéticas. Ao falar de experimentação, não negamos, nem rejeitamos outras formas de aprendizagem, estamos apenas tentando expressar que experimentação é uma prática que caracteriza o teste. Também implica dizer que teste é semelhante à prática científica.
• A lista de palavras utilizadas para definir teste não inclui tudo que está envolvido na atividade, mas representa os processos mentais e cognitivos que acreditamos ser os mais característicos e vitais para a definição.
• “Algorítmico” significa que pode ser expressado explicitamente de maneira que uma ferramenta poderia executá-lo.
• “Observações” intencionalmente engloba todo o processo de observar, não só o resultado.
• “Observações específicas” significa que o processo de observação resulta em um artefato (caso contrário, regras de decisão algorítmicas não poderiam operá-las).

E essas definições implicam em algumas coisas:

• Testar engloba verificar (considerando que “verificar” exista), mas verificar não engloba testar.
• É possível testar sem verificar. Um teste pode existir sem uma verificação. Porém verificar é uma parte popular e importante dos testes mais comuns, até mesmo dos mais informais.
• Verificar é um processo que pode, a princípio, ser feito por máquinas em vez de humanos, enquanto testar é um processo que pode ser auxiliado por ferramentas. De qualquer forma, ferramentas podem ser usadas para muito mais que apenas verificações.
• Não estamos dizendo que verificações precisam ser automatizadas, apenas definindo que um aspecto da verificação é que ela pode ser completamente automatizada, enquanto testar é uma atividade intrisecamente humana.
• Testar é uma investigação sem fim — pense em “Sherlock Holmes” — , enquanto verificar é como “checar fake news”, focando em fatos específicos e regras acerca desses fatos.
• Verificar não é a mesma coisa que confirmar. Verificação é usada dessa forma na maior parte das vezes (principalmente durante testes de regressão), mas nós também as imaginamos sendo usadas para des-confirmar algo ou em exploração especulativa (por exemplo, um conjunto de verificações geradas automaticamente que aleatoriamente vasculham um espaço aberto, buscando qualquer coisa que não estivesse lá antes).
• Um problema comum na nossa área é que verificação é confundida com teste. Nosso propósito aqui é reduzir essa confusão.
• Uma verificação é descritível; um teste pode não ser (isso porquê, diferente de verificar, testar envolve conhecimento tácito).
• Uma asserção, no sentido da Ciência da Computação, é um tipo de verificação, mas nem todas as verificações são asserções. E mesmo no caso de serem asserções, pode existir algum código antes dela que faça parte da verificação, mas não faça parte da asserção.
• Essas definições não são julgamentos morais. Não estamos dizendo que verificar é algo inerentemente ruim a se fazer. Pelo contrário, verificar pode ser algo muito importante. Estamos constatando que, para verificação ser considerado algo bom, precisa ocorrer num contexto em que haja um competente processo de testes. Verificar é uma tática dentro do teste.

Esquecer a sapiência?

Se você segue nosso trabalho, sabe que damos importância à sapiência. Um processo sapiente é um que requer um humano suficientemente capacitado para performá-lo. Entretanto, nos múltiplos anos que passamos usando o termo, notamos ser quase impossível dar a entender que um processo não-sapiente (um que não requer um humano capacitado, mas que pode envolvê-lo mesmo assim) é um processo estúpido para pessoas estúpidas. Isso porque a palavra “sapiência” soa parecido com “inteligência”. Alguns de nossos colegas são bem contrários às nossas discussões quanto a processos não-sapientes por conta desse desentendimento. Sendo assim, sentimos que é hora de aposentar o uso desse termo.

Verificação Humana vs. Verificação Maquinal

Apesar de que sapiência é um rótulo problemático, ainda assim precisamos fazer distinção entre o que humanos e ferramentas fazem. Então, em adição à distinção entre testar e verificar, nós também distinguimos a verificação humana da maquinal. Isso pode parecer confuso, a princípio, porque verificação é algo que, por definição, pode ser feita por máquinas. É perdoável pensar que verificação humana seja a mesma coisa que verificação maquinal. Mas não é. Não tem como ser.

Na verificação humana, humanos estão tentando seguir um explícito processo algorítmico. No caso das ferramentas, entretanto, elas não estão apenas seguindo o processo, elas se tornam o processo. Humanos são incapazes de incorporar tal algoritmo. Aqui está um experimento mental que prova isso: diga a qualquer humano para seguir uma série de instruções. Faça com que essa pessoa aceite. Agora, observe o que acontece se você fizer com que seja impossível que essa pessoa consiga completar as instruções. Seres humanos não irão simplesmente ficar sentados até que morram de fome ou sede; irão parar o que estão fazendo, mudar algo ou sair do processo por completo. E é assim que você sabe que aquela humana — o tempo inteiro — incorporou bem mais do que apenas aquele processo que aceitou seguir. Será sempre assim, se estivermos falando de pessoas comuns ou até mesmo com uma mínima capacidade cognitiva. Qualquer procedimento que humanos pareçam estar seguindo, eles estão sempre fazendo alguma outra coisa simultaneamente. Humanos estão constantemente interpretando e ajustando suas ações de uma maneira que máquinas não conseguem. É inevitável.

Humanos conseguem fazer ações motivadas; ferramentas conseguem apenas exibir um comportamento programado (leiam o brilhante livro The Shape of Actions, de Harry Collins e Martin Kusch, para uma explicação completa do porquê de ser assim). O ponto é: você pode definir uma verificação com facilidade, mas uma pessoa irá sempre fazer algo a mais durante essa verificação — assim como algo a menos, em algumas maneiras — do que uma ferramenta programada para executar o mesmo algoritmo.

Por favor, entenda que é preciso darmos um papel robusto ao uso de ferramentas em testes de software. Enquanto trabalhamos por um futuro em que haja um contexto de testes hábeis, poderosos e eficientes, é necessário prestar atenção cuidadosamente tanto ao lado humano, quanto ao lado mecânico dessa equação. Ferramentas podem nos ajudar de várias maneiras, muito além da automatização de verificações [nota do tradutor: há diferença entre automação e automatização]. Mas, para isso, elas precisam necessariamente estar num papel de suporte a humanos habilidosos; o uso não-capacitado de ferramentas pode ter consequências terríveis.

Você pode estar pensando o porquê da gente não simplesmente chamar a verificação humana de “teste”. Na real, nós chamamos. Tenha em mente que tudo isso está acontecendo dentro da esfera de teste. Verificação humana é parte de teste. Entretanto, nós achamos que quando humanos tentam explicitamente restringir seus pensamentos aos aspectos de uma verificação — mesmo que falhem em fazer isso completamente — , se torna uma estratégia específica e restrita de teste e não toda a atividade de teste. Isso merece um rótulo próprio dentro da esfera de teste.

Com tudo isso em mente e com a intenção de desfazer a confusão, afiar nossa percepção e promover colaboração, vamos revisitar o que é verificar:

Verificar é o processo de fazer avaliações aplicando regras de decisão algorítmicas em observações específicas sobre o produto.

A partir disso, identificamos três formas de verificação:

Verificação humana é uma tentativa de verificação onde humanos coletam observações e aplicam regras a elas sem a mediação por ferramentas.

Verificação maquinal é o processo de verificar onde máquinas coletam informações e aplicam regras sem mediação humana.

Verificação humano-máquina é uma tentativa de verificação onde humanos e ferramentas interagem para coletar observações e aplicar regras.

Para explicar isso de maneira mais detalhada, seria necessário falar sobre exemplos específicos. Procure por eles numa postagem futura. Enquanto isso, te convidamos a comentar sobre esse artigo.