QA House

Recentemente no trabalho tive de criar uma apresentação-treinamento sobre teste exploratório. Assim que recebi o pedido pensei: “Ué, mas qual o segredo? Você entra na aplicação, começa a testar o que achar necessário, sem seguir roteiro, sem nada, pra que treinamento sobre isso?”. Depois comecei a pesquisar sobre o assunto e vi que, se tentarmos resumir a definição, podemos sim usar a minha primeira ideia, mas dessa forma deixaríamos de lado muita informação importante e, eu diria, até essencial sobre testes exploratórios. Então se você está aqui, você provavelmente não caiu no erro que cometi, definindo sem antes pesquisar. Na sequência do post você pode conferir tópicos interessantes sobre o assunto. ;-) Definição O BSTQB (Brazilian Software Testing Qualifications Board) define testes exploratórios como "técnica de modelagem de teste informal na qual o testador controla ativamente a modelagem dos testes já que estes são realizados e utilizam as informações obtidas durante o test

Em muitas organizações, os testes começam muito tarde no processo de desenvolvimento de um software. Muitas vezes, começam tão tarde que o produto é lançado com uma quantidade irrisória de testes executados. Para solucionar esse problema, muitas empresas estão começando a adotar testes como um 'mal necessário'. Como contraste a esse panorama, o RUP modifica a abordagem de testes, distribuindo a mesma no decorrer do ciclo de desenvolvimento do software, agregando valor ao invés de arcar com custos excessivos decorrentes da ausência de testes. No post anterior , justificamos a pergunta 'por que testar cedo e com frequência?' com o gráfico de custos. A seguir vocês podem ver um gráfico similar, retirado do site da IBM (detentora da metodologia RUP): Muitas pessoas ainda veem a disciplina de Testes como algo secundário, por que isso acontece? Talvez porque não esteja diretamente ligado ao desenvolvimento do software e por isso é muitas vezes deixado para o final, depois do