Neste post iremos complementar um tema que já foi abordado antes, o Testes Exploratórios, para conferir esse artigo clique aqui!
Conversando com pessoas de diferentes perfis técnicos, e de áreas diferentes da TI, sempre surgem algumas dúvidas relacionadas com o quando fazer, como fazer e quem pode fazer, como medir?
Bom, primeiro vamos definir qual é a diferença entre teste estruturado e teste exploratório.
Pela nossa definição oficial de Teste Exploratórios sabemos que é uma abordagem onde o aprendizado, o design do teste e execução acontecem ao mesmo tempo, num modo de Discovery. Como podemos perceber, essa abordagem inclui as atividades core de um processo de teste, apenas não de uma maneira linear e estruturada.
Originalmente o Teste Exploratório era conhecido como Teste Ad-hoc; mas vamos esclarecer o seguinte, exploratório não quer dizer que não deva ter um planejamento mínimo; sempre costumo dizer que para explorar precisamos minimamente ter um mapa e um relógio. O mapa para nos orientar e o relógio para decidir se vale a pena continuar navegando, ou explorando, na mesma direção por mais tempo, ou melhor mudar de rumo. Em um post passado foi falado da técnica de Teste Exploratório baseado em sessão, que tem por objetivo dar estrutura e definir os objetivos de um Teste Exploratório, assim como também definir o time-box para aquela sessão.
Em conversas com diferentes pessoas sempre surge a dúvida de quando fazer e quem pode ou deve fazer Testes Exploratórios, e é disso que gostaria de falar neste post; iniciando pelas principais características que cada uma das abordagens contempla:
É fácil perceber que se você está no início de um projeto ágil, onde os requisitos ainda devem ser descobertos, você não terá insumos suficientes para elaborar um roteiro detalhado; os testes devem iniciar de maneira exploratória, tendo como insumo principal as user stories e protótipos iniciais. Mas esse não é o único cenário em que podemos, ou devemos, executar testes exploratórios; mesmo estando dentro de um projeto híbrido, ou cascata, sabemos que durante a criação de casos de teste nunca conseguimos enxergar todos os cenários a partir de especificações, ou user stories, mais detalhadas. Logo, é importante sempre considerar essa abordagem em todo tipo de projeto, seja de maneira sequencial ou executada ao mesmo tempo com o teste roteirizado.
Para entender na prática, veja um exemplo de como isso é executado na ferramenta do Azure Devops. Uma vez que você solicita para realizar um teste exploratório na user story, a ferramenta identifica que existem critérios de aceite para iniciar o teste. Essa prática é conhecida como Quick feedback.
Quando o teste exploratório finaliza, existe a opção de abrir bug, criar uma task ou criar um caso de teste, o que faz todo sentido pois os testes exploratórios servem também para complementar nossos roteiros estruturados de teste.
Além das opções para criar os work items, a ferramenta também fornece informações da duração da sessão, que é um dos conceitos importantes na execução de Testes Exploratórios.
Enquanto a quem pode executar Testes Exploratórios, nesse contexto apresentado, devemos levar em consideração o grau de experiência do tester, que deve ter conhecimento no domínio do negócio, riscos e na aplicação sendo testada; obtido no mercado ou em releases passadas do mesmo projeto. Outro ponto importante a considerar é que o tester deve usar sua criatividade e intuição para saber onde vale a pena explorar uma aplicação.
Qual é o principal desafio?
Com certeza é o balanceamento entre testes estruturados e testes exploratórios, principalmente nos projetos ágeis ou híbridos; cada projeto é um contexto diferente; esse balanceamento deve ser ajustado com cada nova release e suas entregas, e principalmente suas complexidades funcionais e técnicas. Lembrem que aqui o denominador comum é a cobertura dos testes baseada numa estratégia de escopo, equipe disponível e tempo; por outro lado é importante frisar que independentemente do tipo de projeto, sempre teremos testes que fogem do planejamento original e da execução roteirizada; é a “cegueira atencional” originada pelo fato de estarmos tão focados aguardando “resultados esperados” roteirizados, e planejados com antecedência, que deixamos de enxergar outros cenários e riscos ao redor.
Para entender melhor sobre essa “cegueira atencional” recomendamos assistir a dois vídeos muito importantes: https://www.youtube.com/watch?v=WhL4ntndnrs e também o vídeo The Monkey Business Illusion.
Conhecimento do negócio, criatividade e instinto entram em jogo nessa abordagem de discovery
E aí, o que vocês acham? Qual tem sido sua experiência? Deixem seus comentários, se acharem interessante vamos fazer um terceiro post deste mesmo tema.
Nos siga para mais textos como esse e aproveite para acessar nossas redes sociais abaixo e conferir nossos conteúdos diários!
Linkedin, Instagram, Facebook, Twitter
Conheça nossos serviços em nosso site: www.svlabs.com.br
Jehú Lara Ramos – Gerente Comercial
