A 15ª Mesa Redonda DFTestes teve como Testes exploratórios, a discussão teve 21 respostas e 9 participantes, sendo eles: eu, Shmuel Gershon, Lorena Lyra, Carolina Souza, Renato dos Santos, Sarah Pimentel, Felipe Silva, Elias Nogueira e Aderson Bastos.
Abaixo faço um “resumo” da mesa redonda, lembrando que quem quiser conferí-la na íntegra, é só acessar esse link.
Quais os objetivos do teste exploratório?
Segundo o Shmuel Gershon:
Descobrir nova informação sobre o sistema (sistema inclui o aplicativo, o ambiente, o cliente) de modo a facilitar decisões de negócio (normalmente relacionadas a risco).
Ha! Agora ficou com cara de descrição de livro, ou seja, ninguém entende ou se identifica com ela :). Em palavras mais claras, o objetivo é explorar, chegar a áreas novas no nosso sistema através de perguntas, e assim aumentar o conhecimento do sobre o mesmo.
O Felipe Silva deu a sua opinião dizendo:
Na minha opinião o objetivo de um teste exploratório é ir além do que está escrito, é explorar a aplicação, tentar achar coisas obscuras (geralmente defeitos) e saber como o sistema se comporta em situações que anteriormente não tinha sido imaginadas apenas lendo o requisito.
Na minha opinião os principais objetivos são:
- Aprender;
- Encontrar falhas utilizando a criatividade, liberdade e inocência, percorrendo caminhos que não foram percorridos pelos testes elaborados com as técnicas de modelagem de teste;
- “Explorar é ir além do conhecido”.
Por que os testes exploratórios são importantes?
De acordo com a definição que o Shmuel fez, no tópico anterior, ele justifica a importância dos testes exploratório dizendo:
São importantes porque são um modo de descobrir informação essencial para tomar decisões com convicção justificada.
Para o Felipe Silva:
São importantes por serem fáceis de se conduzir, agregarem valor ao conhecimento que se tem sobre o sistema e por acabar encontrando defeitos que não seriam pegos pelo caso de teste, sem falar que são rápidos de serem executados, e faze-los no inicio dos testes ajuda identificar rapidamente quase ou todos os erros que poderiam impactar a execução dos testes e outros óbvios, isso tudo apenas nas primeiras horas de testes, o que demoraria mais para ser revelado seguindo-se o script do caso de teste.
A minha justificativa principal da importância do TEs é porque eles são mais humanos do que lógico. Quando testamos sistemas que serão utilizados por seres humanos, eles são de extrema importância para encontrar falhas, além é claro que podem ser uma ótima alternativa para aprender sobre o sistema, principalmente quando estamos testando sistemas legados e/ou com documentação desatualizada/escassa.
Quem deve fazer testes exploratórios?
Para o Shmuel todos podem fazer testes exploratórios, exceto o computador:
Eu, você. O testador, o líder da equipe, o gerente da equipe. O programador, seu líder e seu gerente. O product owner, o representante do cliente, o cliente.
No meu parecer, dentre todos os personagens envolvidos no desenvolvimento do produto, o único que não faz testes exploratórios é o computador. 🙂 Ele tem importante papel auxiliar, no entanto, o testador tem uma vantagem: ele é o único pago para fazer isso durante a maior parte do seu dia. Mais do que tempo, isso lhe dá consciência do processo, o que lhe permite se aperfeiçoar, e fazer testes melhores livres de preconceitos e e com cobertura mais abrangente.
Concordo com o que o Shmuel disse, todos, exceto o computador devem fazer testes exploratórios.
Quando fazer testes exploratórios?
De acordo com o Shmuel:
Devem ser feitos bem no comecinho do desenvolvimento, e continuar quanto necessário, às vezes até o fimzinho do desenvolvimento. Durante todo o tempo em que novas informações podem influenciar o negócio.
O Felipe Silva disse:
Eu diria que obrigatoriamente no início da build, e como dito pelo Shmuel: “Durante todo o tempo em que novas informações podem influenciar o negocio.”
Podemos usar alguma ferramenta para auxiliar os testes exploratórios?
O Shmuel respondeu dizendo:
Definitivamente! Não dá pra fazer testes sem ferramentas! As ferramentas são variadas, algumas são intelectuais (como as heurísticas) e outras são em software (como uma automação). Algumas são individuais (como uma planilha usada para comparações) e outras colaborativas (como as notas de sessão).
O Felipe Silva deu a sua resposta dizendo:
Sim, por exemplo um checklist ou qualquer outra ferramenta citada pelo Shmuel… (hehe, O Shmuel foi tão detalhista nas respostas dele que não sobra muito o que falar 🙂
Concordo com o que o Shmuel e o Felipe disseram e acredito que podemos usar desde planilhas para armazenar observações, (lembre-se que você é um explorador) até ferramentas para geração de massa de dados.
Qual “estilo” usar: livre ou baseado em sessões?
O Shmuel deu a sua opinião dizendo:
De minha experiência, acho que um estilo livre E baseado em sessões.
As sessões não são o único modo de organizar os testes, mas são um modo muito prático. Outras pessoas/empresas podem preferir usar um plano de testes preparado previamente (pleonasmo?). Outras podem preferir trabalhar “na fé e confiança”, que também serve. Cada caso deve escolher o método que serve para a equipe, para o cliente e para os recursos.
O Felipe Silva acrescentou:
Só acrescentado ao que o Shmuel disse, que eu concordo, depende também do “papel” que irá executar o teste, para alguns papéis podem ser mais efetivos o livre do que o baseado em sessões e vice-versa.
Na minha opinião não é preciso usar um “estilo” só, como disse no começo do e-mail, depende da sua situação, às vezes, não temos muito tempo para ficar explorando e já sabemos quais áreas e que o que precisamos explorar mais. Em outros momentos, podemos não ter no que basear as nossas sessões, e aí o “estilo” livre acaba se tornando a única opção.
Abaixo, segue duas perguntas feitas pela Lorena Lyra.
Eu pensava que os teste exploratórios deveriam ser apenas realizados por pessoas que conhecem o sistema ou, ao menos, a função que vai ser executado o teste. Pergunto, até onde isso é verdade?
A Carolina Souza respondeu dizendo:
Acredito que testes exploratórios podem e devem ser realizados também por pessoas que não conhecem o sistema em sua totalidade, pois será através desta navegação sem roteiro pré-definido que os erros poderão ser detectados. Todos já tivemos a experiência de encontrar erros “por acidente”, quando tínhamos um objetivo e esbarramos em bugs no percurso.
O Shmuel disse:
Qualquer teste exploratório é realizado por pessoas que não conhecem o produto, pois o objetivo desses testes é esse mesmo conhecimento.
Quem tem mais conhecimento prévio do produto podera explorar áreas diferentes, pois já tem as ferramentas e a base necessárias para explorar espaços diferentes (software trata em espaços multidimensionais).
Concordo com a Carolina, aliás, o que ela descreveu eu chamaria de um teste exploratório com modo usuário habilitado 🙂
Recentemente tive que criar testes automatizados para um sistema Web, que eu mal conhecia (tinha visto ele há mais de 2 anos atrás), o que fiz? Testes exploratórios para conhecer o sistema, registrando num mapa mental a exploração.
Quanto mais experiência no ramo de teste a pessoa tiver, melhor vai ser o desempenho dele(a) ao fazer o teste exploratório?
O Elias Nogueira respondeu a pergunta e ainda compartilhou um pouco da sua experiência:
É um mix, experiência do testador conta, mas o mais importante é começar a ter o entendimento do negócio e criar os testes exploratórios para ganhar esse conhecimento e explorar novas possibilidades de utilização…
A forma de Testes Exploratórios para validações de campos, limites, etc… já é requisito obrigatório para aprender pequenas regras de negócio do sistema, que você tem que fazer.
O maior ganho é tu focar em conhecer o negócio em sí num nível mais alto.
Em todos os projetos de automação que eu participo, o teste exploratório é o primeiro a ser feito, e isso faz todo o sentido.
Eu geralmente recebo toda a documentação do cliente (regras de negócio, casos de teste, etc…) e isso ajuda no entendimento do sistema.
De quebra com a execução do teste exploratório eu consigo medir qual a qualidade do sistema frente a bugs e aumentar a cobertura de teste, removendo todos os problemas que possam também aparecer antes que eu inicie a automação de fato.
Abaixo, segue duas perguntas feitas pelo Renato dos Santos.
Ao testar um software que não possui nenhuma documentação, eu considero sendo um teste exploratório ou um “Testa ai!”?
A Sarah Pimentel explicou que:
Em um artigo do James Bach eu vi ele falando do Cem Kaner como o primeiro a usar esse nome “Testes Exploratórios” para essa técnica. E ele mesmo disse que era uma substituição ao termo “ad hoc”. No fundo, é ad hoc mesmo, só que esse é um termo comumente relacionado a algo bagunçado. Não é tão “testa ai” porque o ideal é que as pessoas envolvidas nesse processo tenham experiência no negócio ou na tecnologia para saber o que estão fazendo. Não é chamar o sobrinho e dizer “brinca aí um pouquinho”.Mas também se direcionarmos muito o teste deixa de ser exploratório. Perguntei ao Rex Black em uma apresentação dele sobre risk based testing o que ele achava se utilizar a análise de riscos para direcionar o trabalho de teste exploratório, por exemplo, dizer para a equipe explorar mais determinada área e ele defendeu que isso estaria minando o potencial do teste exploratório, que o melhor dessa técnica é a aplicação da experiência e da criatividade mesmo de quem está conduzindo esse teste.
O Felipe Silva comentou a resposta da Sarah dizendo:
Depende o tipo de teste, acho que você pode ter 3 situações, as duas que você já disse e a terceira seria um teste funcional “comum”. Se a pessoa testa sem saber o que está testando e sem ter expectativas de resultados, isso é um “Testa ai!”, se a pessoa testa sem saber o que está testando (sem um roteiro), mas sabe os resultados esperados, isso é um teste exploratório, já se a pessoa testa com um objetivo (roteiro, caso de teste, etc) sabendo os resultados esperados, isso é um teste funcional.
A chave da minha linha de pensamento é que você não necessariamente precisa ter alguma documentação (algo escrito) para saber os resultados esperados, da mesma forma você não precisa ter requisito para escrever um caso de teste, depende do quão é fácil obter as informação diretamente com pessoas.
Neste caso, o teste exploratório irá justamente te ajudar a conhecer o sistema, e a partir do conhecimento adquirido você poderá começar a elaboração dos casos de testes.
O Aderson Bastos palestrou sobre isso no BRATESTE do ano passado, contando sobre uma experiência, onde a utilização de testes exploratórios, foi fundamental para o sucesso do projeto de teste: https://qualidadebr.wordpress.com/2009/03/13/cobertura-brateste-2009-2-dia/
Para ser teste exploratório deve ler alguma documentação, para saber os resultados esperados?
O Felipe Silva respondeu dizendo:
Eu acho bom ler sim, sempre fazemos testes exploratórios no inicio de nossos testes, se o ator não ler nada só vai encontrar erros “grossos”, mas se antes da release ser liberada para teste o ator já tiver lido a documentação, além de encontrar os erros “grossos” vai encontrar alguns mais específicos também, só acho que um teste exploratório não deve ser baseado em documento (roteiro escrito, caso de teste, etc) pois explorar é ir além do conhecido.
Na minha opinião não, pois quando vamos iniciar um teste exploratório, no máximo sabemos o que iremos explorar, o como e os resultados esperados, são informações que não são necessárias, uma vez que a presença delas descaracteriza o caráter de exploração.
Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.
Fique por dentro das novidades, assine o feed do QualidadeBR.
Saiba mais
Segue abaixo, algumas publicações que foram referenciadas sobre o assunto, durante a mesa redonda:
Exploratory Testing Explained – James Bach
Risk Based Testing: What it is and How You Can Benefit – Rex Black
Webinar da RBCS: Risk Based Testing – Sarah Pimentel
A Tutorial in Exploratory Testing – Cem Kaner
Exploratory Test Automation: Investment Modeling as an Example – Cem Kaner
Parabéns pelo post!
Eita mesa que parecia ser simples, mas deu o que falar hein.. rs
Abraços,
– Felipe da Silva
Nossa! Isso me ajudou bastante num trabalho que fiz!
Valeu!
Pingback: Lista com todas as Práticas Ágeis | André Faria Gomes
Pingback: Testes Exploratórios | Qualidade de Software