Título:​ ​Definindo​ ​requisitos​ ​de​ ​testes​ ​para​ ​o​ ​teste​ ​exploratório

Contexto​ ​e​ ​Motivação:

O teste de software é uma parte importante do desenvolvimento de software,
que consiste em investigar possíveis falhas no contexto de operação do software, de
acordo com as regras levantadas pela análise de requisitos, identificando a maior
quantidade de erros possíveis, antes que o produto seja disponibilizado aos usuários, a
fim de aumentar sua qualidade. Possui várias estratégias de teste, dentre elas
podemos citar o teste exploratório [1], que é uma estratégia amplamente usada pela
indústria​ ​dado​ ​os​ ​seus​ ​benefícios​ ​a​ ​curto​ ​prazo.
O teste exploratório consiste em um procedimento de testes que destaca as
habilidades do testador, em conjunto com a liberdade pessoal e o seu senso de
responsabilidade, de modo a aperfeiçoar seu trabalho, levando em consideração que o
aprendizado sobre o objeto alvo dos testes, o projeto de testes, a execução e a
interpretação dos resultados são completivos entre si e desempenhados
simultaneamente ao longo da realização do projeto [2], em outras palavras, testes
exploratórios são dinâmicos na execução, projeção e aprimoramento e são baseados
na criatividade, experiência, intuição e julgamento do testador. De acordo com
SWEBOK [1], teste exploratório é a técnica de testes mais praticada, podemos atribuir
algumas razões para isso, como por exemplo, a rapidez que um software pode ser
testado em sua totalidade utilizando essa técnica, entretanto, apesar dos benefícios,
essa técnica também traz consigo uma desvantagem, o chamado débito técnico, em
que​ ​seu​ ​acúmulo​ ​pode​ ​ser​ ​sentido​ ​de​ ​uma​ ​forma​ ​negativa​ ​a​ ​longo​ ​prazo.
Apesar dos seus benefícios, alguns trabalhos apontam para o débito técnico
relacionado aos testes exploratórios [3]. Segundo Shah et al os testes exploratórios,
caracterizam-se por testes com a finalidade de obter um aspecto (o rápido feedback),
ao mesmo tempo que ignora, conscientemente ou não, outros aspectos que poderão
reaparecer mais tarde, como por exemplo maior carga de retrabalho e custo. Neste
trabalho Shah et al também realizaram uma análise sistemática da literatura no que
tange os efeitos do teste exploratório sobre o débito técnico, a fim de coletar evidências
sobre sua vulnerabilidade. Dessa forma, foi categorizado um conjunto de fragilidades
como fontes de débito técnico, as quais geram problemas residuais, tais como: (i) a
falta de planejamento de teste, que implica em uma falta de controle sobre o teste
realizado, aumentando a probabilidade de testes repetidos e negligenciamento da
execução de testes importantes; (ii) a falta de definição de casos de testes, os testes
são executados sem defini-los nem documenta-los, resultando em um maior custo de
testes de regressão; (iii) a dificuldade de avaliação do resultado do teste, para validar a
correção da funcionalidade é necessário se basear nos próprios julgamentos do
testador pois não há uma documentação formal ou oráculo, isso implica em mais
defeitos residuais aumentando os custos de manutenção; (iv) a falta de documentação,
um guia de testes que cobre informações sobre a preparação para os testes,
planejamento, requisitos, logs e relatórios, basicamente apenas erros de testes são
reportados dificultando o rastreamento do que foi testado e o que não foi e
consequentemente dificultando a fase de manutenção; e (v) por último, temos a alta
dependência humana, principalmente relacionado aos dois últimos tópicos, a
efetividade de testes exploratórios é altamente dependente da experiência do testador,
o​ ​que​ ​causa​ ​na​ ​totalidade​ ​do​ ​software​ ​uma​ ​exatidão​ ​de​ ​teste​ ​não-uniforme.
Na prática, a soma desses problemas residuais no futuro pode causar um
impacto bastante negativo se não for controlado ou amenizado. Uma possível solução
para esse problema seria o uso da estratégia de testes baseados em requisitos de
testes ou critérios de cobertura bem definidos [4], no qual casos de testes são gerados
a partir de um conjunto de requisitos de testes ​- ​os quais consistem em elementos
específicos de um artefato de software que um caso de testes deve cobrir, ou seja,
condições que determinado software deve satisfazer [5] ​- de modo a estruturar e
realizar​ ​o​ ​teste.

Proposta​ ​de​ ​Trabalho

De acordo com o que foi apresentado anteriormente, observamos que existem
problemas inerentes à realização dos testes exploratórios . Estes problemas dificultam
diretamente a atividade de gerência da atividade de testes deste tipo. Uma possível
solução para minimizar as causas negativas desse contexto seria definir requisitos de
testes. Dessa forma, o trabalho proposto consiste na criação de uma ferramenta que
permita a definição de requisitos de testes, e monitoramento da execução dos testes
exploratórios​ ​para​ ​saber​ ​se​ ​os​ ​mesmos​ ​atingiram​ ​os​ ​requisitos​ ​definidos.

Metodologia
A​ ​seguinte​ ​metodologia​ ​deve​ ​ser​ ​ ​seguida​ ​neste​ ​trabalho:
T1-​ ​Estudo​ ​dos​ ​conceitos​ ​de​ ​teste​ ​de​ ​software,​ ​principalmente​ ​em​ ​testes​ ​exploratórios;
T2​ ​-Entrevistas​ ​com​ ​testados​ ​exploratorios​ ​para​ ​investigar​ ​sua​ ​rotina​ ​de​ ​trabalho;
T3- Levantamento de ferramentas de apoio ao teste exploratório, ferramentas de mind
map​ ​e​ ​estruturação​ ​do​ ​conhecimento;
T4 - Especificar os requisitos, modelar, implementar e testar a ferramenta de apoio à
definição​ ​e​ ​checagem​ ​de​ ​requisitos​ ​de​ ​cobertura​ ​para​ ​testes​ ​exploratórios;
T5- Realizar um estudo de caso, aplicando a ferramenta proposta no contexto de uma
empresa da área de desenvolvimento de software, de modo a avaliar os benefícios e
limitações​ ​dela.

Referências​ ​Bibliográficas
[1] Guide to the Software Engineering Body of Knowledge, Maio 2001,
http://www.swebok.org/documents/Trial_1_00/Trial_Version1_00_SWEBOK_Guide.pdf
[2] A.Tinkham, C. Kaner ― “Exploring Exploratory Testing”, em “Improving the
Education​ ​of​ ​Software​ ​Testers”,​ ​2003,​ ​http://www.testingeducation.org/a/explore.pdf.
[3] S. Muhammad Ali Shah, M. Torchiano, A. Vetro, M. Morisio ― “Exploratory testing
as​ ​a​ ​source​ ​of​ ​testing​ ​technical​ ​debt”,​ ​em​ ​“IT​ ​Professional”,​ ​Torino,​ ​Italia,​ ​2013.
[4] C. Pecheur, F. Raimondi, and G. Brat, ―A formal analysis of requirements-based
testing,‖ em “Proceedings the international symposium on Software testing and
analysis”,​ ​Chicago,​ ​EUA,​ ​2009,​ ​pp.​ ​47–56.
[5] P. Ammann, J. Offutt ―Introduction to Software Testing, em “Cambridge University
Press:​ ​New​ ​York”,​ ​Nova​ ​York,​ ​EUA.,​ ​2008.
[6] C. Caetano ― Testes exploratórios (parte 1): Introdução, em “Qualister”, Brasil, jan
2017,​ ​http://www.qualister.com.br/blog/testes-exploratorios-parte-1-introducao.