Artigos Interessantes sobre Teste de Software

ARTIGO 1: Teste Exploratório Esclarecido

v.1.3 16/04/2003

James Bach
james@satisfice.com
By Karina Pimentel
karina.dsn@alterdata.com.br

Teste Exploratório de Software é muito poderoso, no entanto ainda não entendido amplamente. Em algumas situações ele pode ser mais na produtivo do que o teste com script, em ordens de magnitude. Todos os testadores praticam alguma forma de teste exploratório, eles simplesmente não criam os testes como um todo. Ainda mais, poucos de nós estudamos esta forma de testar, e este tipo de teste não tem muito respeito na nossa área. Esta atitude está começando a mudar a medida que as empresas procuram métodos mais e mais ágeis e baratos de desenvolvimento de software.

Dentre as coisas mais difíceis de explicar são as que as pessoas já conhecem. Todos nós sabemos como ouvir, como ler, como pensar, e como contar anedotas sobre os eventos das nossas vidas. Como adultos, nós fazemos estas coisas todos os dias. No entanto, o nível destas habilidades, que a maioria das pessoas possui, podem não ser adequadas para algumas situações específicas. Psicólogos devem ser experts em ouvir e advogados experts em leitura, cientistas devem deixar levar seus pensamentos para achar erros e jornalistas devem ser experts em reportar histórias que transcendem as piadas de salão.

Da mesma forma acontece com o teste exploratório (TE): aprender, desenhar os testes e executá-los simultaneamente. Este é um simples conceito. Mas o fato de poder ser descrito numa frase pode parecer com algo que não vale a pena ser descrito. A sua estrutura altamente situacional pode fazer com que ele pareça observação casual, que não tem nenhum tipo de estrutura. É por isso que os livros de teste de software, com algumas exceções, não falam sobre teste exploratório, ou falam apenas para desacreditá-lo como uma prática que não vale a pena.

Teste exploratórios são também conhecidos como "ad hoc" teste. Infelizmente, "ad hoc" é comumente um sinônimo de piegas e de trabalho descuidado. No início dos anos 90 um grupo de metodologistas de testes (que agora se auto intitulam Context-Driven School - Escola Direcionada a Contexto) começaram a usar o termo "exploratório" ao invés de "ad hoc". Com esta nova terminologia, primeiramente publicado por Cem Kaner no seu livro "Testing Computer Software", ele procurou enfatizar o processo do pensamento dominante envolvido no teste sem script, e começaram a desenvolver a prática para transformá-la numa disciplina. De fato, o teste exploratório pode ser disciplinado assim como qualquer outra atividade intelectual. A Microsoft pratica um processo formalizado de teste exploratorio com a finalidade de certificar a compatibilidade de outras aplicações com o Windows e o gerenciamento de testes session-based é um método designado especificamente para fazer teste exploratório auditável e mensurável em larga escala.

Nosso uso do termo teste exploratório não é eufemismo. Nós usamos as palavras no sentido ordinário do dicionário, apenas aplicando ao teste. Nosso uso da palavra "Exploratório" particularmente ecoa o seu uso na geografia, como os exploradores do Royal Geographic Society, nos séculos 18 e 19 se confrontaram com problemas similares desta metodologia.

"Então, para qualificar como exploração, uma jornada tem que ser digna de crédito, tem que envolver esforço e risco, e tem que incluir a inovação da descoberta. Consequentemente, como o jogo cricket, isto é algo difícil de explicar aos que não conhecem. Mas um elemento é absolutamente vital: na verdade isto foi precisamente o que distinguiu a época do descobrimento das épocas anteriores a o que tornou necessário a adoção da palavra "exploração". Isto é simplesmente uma reverência a ciência." - John Keaym The Permanent Book of Exploration

Assim como uma estrela fica obscura no espectro visível da luz, mas começa a brilhar quando a luz vai sumindo, a simples idéia do teste exploratório vai se tornando interessante e complexa quando vista pelo espectro da habilidade. Considere o xadrez. Os procedimentos para se jogar xadrez são bem menos interessantes do que as habilidades me si. Ninguém fala de quão maravilhosamente Emmanuel Lasker seguiu os procedimentos do xadrez quando ele derrotou Steinitz em 1984 e se tornou o campeão mundial. Os procedimentos do xadrez permanecem constantes, são apenas as escolhas que mudam, e as habilidades dos outros jogadores que darão o próximo passo. O que faz com que o teste exploratório seja interessante, e na minha opinião profundamente importante, é que quando um testador tem a qualidade de ESCUTAR, LER, PENSAR e REPORTAR, rigorosamente e efetivamente, sem o uso das instruções sem script, os resultados do teste exploratório podem ser muitas vezes mais produtivos (em termo de revelar informações vitais) do que o modelo utilizando o script. Se eu pudesse novamente desenhar uma analogia histórica, o espetacular sucesso da expedição de Lewis e Clark é um excelente exemplo do papel da habilidade em explorar.

"Lewis era um pensador diplomático e comercial, Clark era o negociador. Lewis, que foi para a Filadélfia especialmente para pesquisar botânica, zoologia e navegação celestial, era o cientista especialista. Clark o engenheiro e geógrafo assim como o mestre das fronteiras... Ambos foram homens de grande inteligência e de inteligências distintas. Em toda a história anterior da exploração dos Estados Unidos da América, não há nenhuma outra pessoa que possa ser citada como tão inteligente quanto estes dois." - Bernard De Voto, The Journals of Lewis e Clark.

Agora, deixe me voltar a fronteira por um momento. Obviamente, os testes de scripts podem ser eficientes, por muitas razões claras. Você pode ter requerimentos contábeis específicos, e talvez alguns testes tenham que ser executados exatamente da mesma forma, todas as vezes, com o objeitvo de servir como referência. O teste exploratório não vai de encontro com a idéia de script. Em alguns contextos, você será bem sucedido em atingir o objetivo da missão do seu teste com o uso do script, em outros contextos, sua missão será cumprida através da habilidade de criar e melhorar os testes a medida que os executa. Eu percebi que na maioria das situações meus objetivos são alcançados através de um mix do uso de script e uso de exploratório.

A Definição de Teste Exploratório

Eu já tentei achar varias definições para Teste Exploratório. Dentre todas as definições a que eu e meus amigos mais gostamos foi:

"O Teste Exploratório é: aprender, desenhar e executar o teste simultâneamente."

Em outras palavras, teste exploratório é qualquer teste que se amplia (aumenta o escopo) de tal forma que o testador controla ativamente o design dos testes á medida que eles são executados e usa a informação obtida enquanto testa para desenhar novos e melhores testes.

Nesta visão do teste exploratório, virtualmente todos os testes executados por testadores humanos são exploratórios em determinado grau. Esta visão faz com que o teste exploratório seja visto como um processo de pensamento infundidido pelo que todos os bons testadores fazem, e é encontrado através de uma continuidade entre o teste puramente de script, prescrito completamente em avançar em cada detalhe, e puramente teste exploratório onde cada idéia de teste surge no momento da execução do teste em si. Devido a esta continuidade, surge a questão: "Vc está fazendo teste exploratório?", que poderia ser melhor colocada da seguinte forma: "De que forma e em que grau o seu teste é exploratório?"

Pelos motivos pelos quais este artigo foi escrito, quando eu falo teste exploratório e não o qualifico, eu quero falar do teste que é puramente exploratório, assim como o teste que é puramente de script. Em outras palavras, o teste que substancialmente satisfaça a definição acima. Quando eu falar do teste exploratório sem script, direção eu chamarei de Teste Exploratório Freestyle.

O Teste Exploratório é uma prática profundamente situacional

Vc já montou algum quebra-cabeças? Caso a sua resposta seja sim, vc já praticou teste exploratório. Considere o que acontece neste processo. Você escolhe uma peça e então começa a procurar no amontoado das outras peças, alguma que de alguma forma se conecte com a que você escolheu. Cada passada de olho numa nova peça é um CASO DE TESTE. (esta peça se conecta com a outra peça? Não? Que tal se eu virá-la? Bem quase combinam, mas agora a figura é que não combina...") Vc pode decidir montar o seu quebra-cabeças de forma mais rigorosa, talvez por juntar todas as peças da borda primeiro, ou juntar as peças que tem o formato parecido, ou ainda agrupá-las de acordo com alguns atributos da figura na frente da caixa. Ainda, vc consegue imaginar como seria montar um roteiro e documentar todos os casos de teste da montagem do quebra-cabeça antes de vc começar a juntar as peças dele? Ou antes de ter informações do tipo de figura que será formada através da montagem?

Quando eu monto um quebra-cabeça, eu mudo a forma de montá-lo a medida que eu vou conhecendo as peças e vejo o formato da figura. Se eu notar que existe uma área bem grande de uma determinada cor, talvez eu decida achar todas as peças desta cor e juntá-las numa única pilha. Se eu notar que algumas peças tem um formato peculiar, eu também irei colocá-las juntas numa outra pilha. Se eu trabalhar num único tipo de teste por um tempo, eu posso decidir trocá-lo por um outro tipo de teste para refrescar a minha mente. Se eu verificar que tenho um grande bloco de peças montadas, eu posso optar por mudar para outra parte do quebra-cabeça para ver onde esta parte se conecta com todo o resto. Ás vezes eu me pego montando de uma forma muito desorganizada, e quando isso acontece, eu posso voltar atrás, analisar a situação e adotar um plano de ataque mais específico. Perceba como o processo flui, e como ainda assim ele permanece contínuo, a cada momento, sob controle do montador. Isto não é muito parecido com a forma como podemos testar um software também? Caso sim, então talvez você não concordaria que seria absurdo para nós, montar cuidadosamente uma documentação do processo desta linha de raciocínio anteriormente? Reduzir todas as atividades realizadas para apenas uma, não iria diminuir o ritmo do seu trabalho?

Esta é uma lição comum de quebra-cabeças: "the puzzle changes the puzzling". Os detalhes do quebra-cabeça, a medida que aparecem durante o processo de montagem, vão mudando as suas táticas para montá-lo. Esta verdade é o coração de qualquer investigação exploratória, assim como para o teste, desenvolvimento, ou até mesmo pesquisa científica e trabalho de detetive.

Que tipo de fatores afetam o teste exploratório? Veja alguns deles:

- a missão do projeto do seu teste
- a missão de uma sessão de teste em particular
- o papel do testador
- o testador (habilidades, talentos e preferências)
- as ferramentas disponíveis e a forma de utilizá-las
- o tempo disponível
- os dados e materiais disponíveis
- a ajuda disponível de outras pessoas
- os requisitos necessários para o teste
- com o que os clientes do testador se preocupam
- a estratégia do teste em ação
- o status de outros esforços de teste do mesmo produto
- o produto em si:
- a interface
- o comportamento
- o status presente de execução
- os defeitos
- a testabilidade
- o objetivo
- o que o testador sabe sobre o produto:
- o que acabou de acontecer no teste anterior
- os problemas já conhecidos
- os problemas que já existiram
- os pontos fortes e os fracos
- as áreas de risco e a magnitude dos riscos já alertados
- as recentes mudanças
- a observação direta dele
- os rumores sobre ele
- a natureza dos usuários e o comportamento deles
- como o produto deveria funcionar
- como ele é integrado como outros
- de que forma ele é parecido ou diferente de outros produtos
- o que o testador gostaria de saber sobre o produto

Ao invés de perguntar quais os testes são sugeridos a serem executados, testadores exploratórios perguntam: QUAL É O MELHOR TESTE QUE EU POSSO EXECUTAR NESTE MOMENTO? Cada uma das considerações acima, pode influenciar nos tipos de testes necessários. Estes fatores mudam constantemente durante o curso do projeto do teste, ou até mesmo momento a momento da execução do teste. O poder do teste exploratório pode ser otimizado durante o processo do teste em si, deferente do script, porque eles não mudam, e tendem a ficar menos eficazes ao passar do tempo. Eles falham por inúmeras razões, mas a razão
principal é: uma vez que você executa um script de teste uma vez e não ache problemas, a chance de encontrar problemas da segunda vez que executá-lo, na maioria das circunstâncias, serão substancialmente menores do que se você executar um novo teste ao invés dele.

Praticando Teste Exploratório

A estrutura externa do TE é suficientemente fácil de descrever. Durante um período de TEMPO, o TESTADOR interage com um PRODUTO para completar a MISSÃO do teste, e REPORTAR os resultados. Aí então vc tem os elementos externos básicos do teste exploratório: tempo, testador, produto, missão e reportar. A missão é completa através de um ciclo contínuo do nosso alinhamento com a missão, levantando questões sobre o produto, que se fossem respondidas, nos ajudariam a completar satisfatóriamente nossa missão, desenhando testes para responder a estas questões, e executando os testes para achar as respostas. Caso nossos testes não respondam satisfatóriamente as perguntas a estas questões, então nós devemos ajustá-los e continuar tentando (em outras palavras, explorando). Nós devemos estar prontos para reportar nosso status e resultados a qualquer momento.

Uma sessão de teste exploratório geralmente começa com um documento(charter), que explica a missão e talvez algumas das táticas que serão usadas. O documento pode ser escolhido pelo testador, ou com o aval do supervisor ou gerente de testes. Algumas vezes o documento é escrito, em algumas organizações, os casos de testes e os procedimentos são documentados tão vagamente que eles servem apenas aos testes exploratórios.

Veja aqui alguns exemplos de documentos de testes para DecideRight, um produto de análise de decisão:

- Explore e analise os elementos do produto DecideRight. Produza um rascunho de teste de cobertura.
- Identifique e teste todos os pontos do manual do DecideRight. (alguns imprimem o manual e simplesmente marcam um X a cada item testado)
- Defina os workflows do DecideRight e tente cada um deles. Os fluxos devem representar cenários realísticos de uso e devem cobrir coletivamente cada função primária do produto.
- Nós devemos entender a performance e confiabilidade características do DecideRight a medida que a complexidade das decisões aumentam. Comece com um único cenário e coloque-o numa escala de acordo com o número de opções e fatores até que pareca que a aplicação vai "dar pau" ou graciosamente prevenirá o usuário do risco de continuar aumentando o processamento.
- Teste todos os campos que permitam entrada de dados (você conhece a rotina: funcionalidade, stress e limites, por favor)
- Analise o formato do cenário de arquivos de DecideRight e determine o comportamento da aplicação quando estes elementos são manipulados programaticamente. Teste simulando erros e faça de forma a copiar patologicamente o cenário dos arquivos.
- Teste a interface de usuário contra os padrões de interface do Windows.
- Existe alguma forma de corromper o cenário dos arquivos? Como nós saberemos que está corrompido?
- Teste a integração com aplicações externas, especialmente o Microsoft Word.
- Determine a análise de algoritmos experimentando e reproduzindo-o em Excel. Depois, use esta planilha para testar DecideRight em cenários de decisões complexas.
- Rode DecideRight abaixo de AppVerifier e reporte qualquer erro.

Se vc achou algum destes charters ambíguos, eu não ficarei surpreso. Eles tem o objetivo de reportar a missão de uma sessão de teste claramente, porém de forma suscinta a testadores que já foram treinados com as expectativas, vocabulário, técnicas e ferramentas usadas pela organização. Lembre-se, no teste exploratório nós usamos nossas habilidades ao máximo, ao invés de parar para representar cada ação num formulário escrito.

No teste exploratório Freestyle, o único resultado oficial obtido de uma sessão de TE é um grupo de erros. Nas sessões de teste gerenciadas, cada sessão de TE também resulta num grupo de erros, porém, com notas escritas que são revisadas pelo supervisor de teste. Isto também pode resultar em aumentar o material de testes ou novos dados de testes. Se você pensar nisso, a maior parte dos procedimentos de teste existentes, provavelmente foram criados através de um processo de algum tipo de TE.

Os acessórios externos, entradas e saídas para teste exploratório valem a pena ser olhadas, mas a estrutura interna do teste exploratório que mais importa é o que acontece dentro da mente do testador. Este é o lugar onde o teste exploratório é bem sucedido ou falha; onde o excelente explorador se distingue do amador. Este é um assunto complexo, mas existem alguns pontos básicos:

- Design do Teste: um testador exploratório é primeiramente e fundamentalmente um test designer. Qualquer pessoa pode desenvolver um teste acidentalmente, mas um excelente testador exploratório é capaz de montar testes para explorar o produto sistematicamente. As habilidades requeridas como a de analisar um produto, avaliar os riscos, usar ferramentas e pensar de forma crítica, dentre outras.

- Observação cuidadosa: Testadores exploratórios excelentes são observadores mais cuidadosos do que novatos, ou para este propósito, experientes testadores de script. O testador de script precisa apenas observar o que o script manda que ele observe. O testador exploratório deve observar QUALQUER coisa não usual e misteriosa. Além disso, testadores exploratórios também dever estar atentos para distinguir observação de interferência, mesmo sob pressão, por medo eles admitem presunções preconceituosas para não enxergarem testes importantes ou o comportamento do produto.

- Pensamento crítico: testadores exploratórios excelentes são capazes de revisar e explicar a sua lógica, olhando os erros no seu próprio pensamento. Isto é especialmente importante no momento de reportar o status de uma sessão de teste exploratório, ou investigação de um defeito.

- Diversas idéias: Testadores exploratórios excelentes produzem mais e melhores idéias do que os novatos. Eles podem fazer uso da eurística para alcançar estas idéias. Eurísticas são esquemas como guias, checklists comuns, menemonicos ou regras de "thumbs". O Satisfice Heuristic Test Strategy Model (www.satisface.com/tools/satisfice-tsm-4p.pdf) é um exemplo de um grupo de eurísticas para uma geração rápida de diversas idéias. James Whittaker and Alan Jorgensen's "17 ataques" é um outro exemplo. A diversidade de temperamento dos testadores e suas bagagens num time podem ser controladas por testadores exploratórios através do processo de brainstorming para produzir melhores idéias.

- Recursos Sofisticados: Testadores exploratórios excelentes constroem um profundo inventário de ferramentas, fontes de informação, dados de teste e amigos para desenhar testes baseados nisto. Enquanto testam, eles permanecem alertas para oportunidades de aplicar estes recursos nos testes a qualquer momento.

Gerenciando o Teste Exploratório

Em muitas organizações, é importante diferenciar o gerente de teste e o supevisor de testes. O Gerente de Testes geralmente tem autoridade de contratar e despedir e outras responsabilidades administrativas, ao contrário do supervisor de testes que é focado apenas nas estratégias e táticas dos testes. Para o objetivo de discutir gerenciamento de teste exploratório, eu irei usar o termo supervisor de testes, mesmo que um gerente de testes também possa preencher ou ocupar esta função.

Teste exploratório Freestyle pode ser gerenciado de duas formas: delegando ou participando. Usando a delegação, o supervisor de testes irá especificar a documentação. Então os testadores partem por si mesmos para desenhar e executar os testes para preencher os requisitos da documentação e reportam o que acharam. Na prática, um testador em particular geralmente é nomeado permanentemente para testar um conjunto de componentes, para que os benefícios do projeto venham de uma curva ininterrupta de aprendizado. Os resultados do teste executdo pode ser verbal ou escrito. Cem Kaner sugere reuniões regulares com os testadores para discutir o progresso dos testes, pelo menos uma vez por semana.

O gerenciamento por delegação essencialmente trata cada testador como um executivo que gerencia o valor do se próprio tempo. Assim como com os executivos, testador que não ganhou credibilidade como um testador produtivo e responsável não recebe muitas tarefas importantes, ao invés disto, fica restrito a pequenas sessões de teste exploratório para ser avaliado. Ser um supervisor de testadores exploratórios significa ser um treinador de agentes criativos semi-independentes.

Gerenciar através de participação significa que os testes serão supervisionados ao lado do resto dos testadores. Na prática, isto é melhor para supervisores que já tenham por outro lado delegado sua administração para pessoas que cumpriram com as responsablidades delegadas a elas. A participação permite ao supervisor direcionar a estratégia em tempo real e demonstrar continuamente o comportamento que ele espera do time. Uma vez que o gerente de testes é o responsável final pela performance do time, a participação o coloca numa excelente posição para cumprir com a sua responsabilidade. Muitas das preocupações sobre o potencial perigo de confusão e ineficiência do teste durante o TE tendem a desaparecer quando o supervisor de testes está intimamente envolvido no teste.

A maioria dos supervisores de testes usarão algum tipo de cobertura de testes para ajudá-los a organizar os esforços do teste. Este guia pode tomar a forma de uma cobertura de testes sob forma de matriz, lista de riscos, ou até mesmo a antiga lista de A FAZER(To Do List).

O teste exploratório em grupo pode ser extremamente poderoso. Pela experiência de muitos supervisores de testes que já tentaram fazer isso, verificaram que a energia social das pessoas trabalhando juntas, á procura de erros no mesmo equipamento, na mesma hora, geralmente trazem mais e melhores ideias que do que uma mesma pessoa trabalhando sozinha. Uma forma de organizar o time do teste exploratório, é colocar os testadores em pares e deixá-los compartilhar uma única máquina enquanto testam. Uma outra maneira que eu já fiz é deixar um testador "pilotando" o teclado enquanto vários outros observam e comentam. Se o testador que está no teclado descobrir um problema ou tiver alguma dúvida que precisa ser pesquisada, um dos observadores pode sair dali para investigar o erro usando uma outra plataforma de teste... Isto deixa o testador que está pilotando o teste livre para continuar na mesma linha de pensamento do teste com menos distrações. Este método funciona especialmente como uma ferramenta "arrasa quarteirão" para centralizar os esforços de testes fora da rotina ou para treinar os testadores de acordo com a tecnologia do produto ou ensiná-los os métodos de fazer design de testes.

Onde o Teste Exploratório se encaixa

Em geral, TE é próprio em situações onde ainda não é óbvio o próximo passo a ser dado, ou quando vc quer ir além dos testes óbvios. Mais específicamente, TE Freestyle se encaixa em qualquer uma das situações abaixo:

- vc precisa dar um feedback rápido de um novo produto ou recurso
- vc precisa aprender rapidamente sobre o produto
- vc já testou usando scripts, e busca diversificar o teste
- vc quer encontrar um único erro mais importante num curto período de tempo
- vc quer verificar o trabalho de um outro testador fazendo uma breve e independente investigação.
- vc quer investigar e isolar um defeito particular
- vc quer investigar o status de um risco em particular, para pode avaliar a necessidade de scripts de testes nesta área.

TE Freestyle a parte, TE se encaixa em qualquer lugar onde o teste não é completamente ditatório antecipadamente. Isto inclui todas as situações abaixo:

- improvisar nos scripts de teste
- interpretar instruções de testes vagas
- produzir análise e plano de testes
- Melhorar testes já existentes
- escrever novos scripts
- fazer testes de regressão baseado em erros antigos e já reportados
- testar baseado na leitura do manual e checar cada item

O Teste Exploratório é poderoso pelo fato de como o fluxo da informação é revertido da execução do teste para o redesign do teste. Caso exista uma situação onde o loop de feedback é fraco, ou onde o loop é particularmente longo, moroso ou caro, o o teste exploratório perde este poder. Entáo temos que voltar e aplicar o teste cuidadoso com script. Um outro lugar onde devemos usar o teste com script é quando o teste que estamos fazendo é de alguma forma controverso ou onde existe um assunto alto grau de gerenciamento ou aprovação do cliente. Mas não se acomode em fazer testes fracos porque isto irá agradar os auditores. Considere usar uma combinação estratégica de teste exploratório e scriptado, e tenha o melhor dos dois mundos.

Teste Exploratório em ação

Uma vez eu tive a missão de testar um Editor de Fotos bastante popular em 4 horas. Minha missão era ver como o programa
se comportava contra os específicos standards do Programa de Certificação de Compatibilidade do Microsoft Windows. O procedimento de como seria feito este teste estava determinado como Teste Exploratório Formal. Meu objetivo era encontrar
violações de requisitos de compatibilidade, sendo que todos estes requisitos estavam claramente documentados para mim.

Com este material esclarecedor na mão, eu inciei meus testes. Aplicando uma das mais simples eurísticas de exploração. Eu escolhi começar por navegar pelos menus da aplicação, indo em todos eles. Enquanto fazia isso, eu comecei a desenhar um rascunho das funções primárias do produto. O que mais tarde se tornaria a base do relatório, do que eu testei e do que eu não testei mais tarde.

Eu notei que a função Save As continha um grupo de controles sofisticados que permitiam que o usuário optasse por diversos
atributos de qualidade da imagem. Como eu não sabia nada dos aspectos técnicos de qualidade de imagem, eu me senti despreparado para testar estas funções. Então, ao invés de testá-las eu comecei a fazer uma lista destes assuntos para perguntar ao meu cliente se eu poderia estender o tempo de teste, para poder estudar e preparar uma documentação sobre qualidade de imagem e bolar uma estratégia de teste. Tendo feito minhas anotações, eu prossegui navegando através dos menus.

Uma estratégia básica de Teste Exploratório é ter um plano geral de ataque, mas se permita desviar dele por curtos períodos
de tempo. Cem Kaner chama esta estratégia de princípio do City-Tour. As pessoas que estão num city-tour saem do ônibus
ocasionalmente para ver algum lugar. A chave é não perder o city-tour completamente e nem dormir no ônibus. Minha primeira
vontade de sair do ônibus no teste dos menus aconteceu quando eu encontrei uma caixa de diálogo no programa que me permitia controlar a quantidade de memória utilizada pelo aplicativo. Isto imediatamente me deu uma idéia(este tipo de
idéias são encorajadas no teste exploratório. Como um dos requisitos de compatibilidade do Windows era estabilidade, eu
achei que seria útil configurar o programa para usar o mínimo de memória, e então utilizei funções que precisavam intensivamente de memória. Então eu configurei a barra de slide para usar 5% de memória e fui em propriedades da imagem
e alterei o tamanho da imagem para 100 polegadas ao quadrado. "It's a big canvas". Então eu preenchi o canvas com pontos
brilhantes e fui ao menu de efeitos tentar ativar alguns dos efeitos gráficos especiais.

Certo, agora vem uma parte importante: Eu escolhi um efeito "ripple"(que alterna) e "bam", o aplicativo imediatamente mostrou uma mensagem de erro me informando que não existia memória suficiente para esta operação. Este é um comportamento
bastante interessante, porque estabelece um padrão. Deste ponto em diante eu tenho uma nova espectativa: uma função tem
que se auto proteger, para não ser executada, caso não exista memória suficiente para ela. Este é um perfeito exemplo de
como, no teste exploratório, o resultado de um teste incluencia no próximo, porque daí em diante eu decidi tentar outros
efeitos para ver se os recursos restantes se comportariam da mesma forma. Veredito? Nenhum dos outros recursos que eu
testei se comportaram da mesma forma. Ao invés disso, eles iriam congelar por 5 minutos, fazendo algo que não consegui
ver, além do hd ficar parado. Eventualmente uma janela de erro pulava "Error 32: Sorry this error is fatal." e o aplicativo
"dava pau"

Este é um bom resultado, mas eu senti que o teste não seria completo(testadores exploratórios fazem grandes esforços em
antecipar as questões que os seus clientes perguntarão mais tarde)a não ser que eu configurasse o uso da memória para o
maior valor permitido, para usar o máximo de memória possível. Para minha surpresa, ao invés de ter o Erro 32, o sistema
operacional inteiro congelou. O Windows 2000 não deveria fazer isto. Este foi um problema muito mais sério do que um simples "dar pau".

Neste ponto do processo, eu tinha gasto ao redor de 30 minutos de 4 horas que eu tinha, e já tinha achado um problema
que desqualificaria o aplicativo por cetificação de compatibilidade. Esta era a boa notícia. A má notícia era que eu tinha perdido minhas notas quando o sistema congelou. Depois de reiniciar o computador, eu decidi que já tinha aprendido o suficiente de teste stress e voltei a navegar nos menus.

Eu uso esta hitória sobre testes como um exemplo de teste poderoso e disciplinado. Eu posso relatar o que eu cobri e o que
eu encontrei. Eu posso descrever o resultado do teste como o resultado da missão dele. E também foi um teste que eu consigo reproduzir, ou pelo menos repeti-lo tanto quanto os testes scriptados, por que em todos os momentos eu segui uma idéia coerente do que eu estava tentando testar e como eu estava tentando testar. De como as idéias surgiram para mim ao longo do do caminho, ao invés de tê-las através de um documento, não é material. Eu espero que você perceba que isto é totalmente diferente de um teste não sistemático. Seria um teste "ad hoc" se eu não conseguisse relatar a história dos meus testes, não conseguisse lembrar o que eu testei ou qual era a estratégia do meu teste, ou ainda não conseguisse reportar o meu teste relativa a minha missão.

A produtividade do Teste Exploratório

Não existem números razoáveis nem estudos válidos relativos a produtividade dos testes exploratórios comparados com os testes com script. Tudo o que temos são relatos de algumas pessoas. Aqui estão algumas das minhas histórias.

Eu tenho ministrado aulas de testes onde testadores exploratórios, testam usando um sistema que automaticamente documenta os seus testes, já fizeram design e executaram centenas de testes exploratórios. Então, quando desafiados a escrever um procedimento de teste que se possa repetir no mesmo período de tempo, cada pessoa é instruída a escrever apenas um. Voce pode argumentar que o procedimento de teste que se pode repetir foi melhor de algumas formas do que o teste exploratório. Talvez seja, talvez não. Pessoalmente, eu sinto que a rotina dos testes com script são muito menos produtivas do que os testes exploratórios.

Eu já supervisionei times em testes de aplicativos que já tinham sido testados através de testes com scripts, e acharam problemas dramáticos nestes aplicativos. Em um caso, sem nenhuma preparação ou material de testes, demoraram apenas 10 minutos de "crash" uma "network appliance" de tal forma que o hd teve de ser reformatados. Verdade, não levou mais de 10 minutos para investigar e isolar o problema, no entanto, o problema também teria sido encontrado num teste com script, assumindo que o problema foi encontrado logo de cara.

Eu ajudei a uma grande empresa a iniciar um time de teste exploratório em um departamento cercado por testadores de script. Eles acharam que as pessoas de teste exploratório, que não estavam incumbidas pela manutenção associada aos artefatos de teste, eram capazes de ter mais idéias e rumores sobre os riscos. Eles acharam mais erros, e erros mais importantes. Três anos depois e o time ainda estava lá.

Uma pessoa chegou a mim numa conferencia e disse que utilizou teste exploratório numa grnde companhia de telefonia. Ele disse que o time dele ia de projeto em projeito, e o motivo pelo qual ele foi permitido a continuar com o seu trabalho foi devido os números mostraram que o time dele achou quatro vezes mais problemas dentro de um período de testes do que o time de testadores com scripts.

Estas histórias contadas aqui não provam nada. Eu as adicionei para chamar a sua atenção. A verdade é, produtividade depende de uma série de fatores. Então, trabalhe trabalhe utilizando o teste exploratório e aprenda das sua própria experiência.

O teste exploratório pode ser descrito como teste marcial da mente. É como você lida com um produto que se colocar a sua frente e te desafia a um duelo de testes. Bem, você não se tornará faixa preta lendo livros. Você tem que praticar. Feliz prática!