TESTES EXPLORATÓRIOS EM SOFTWARE
Recebido em 06/05/2016. Aprovado em 13/07/2016. Avaliado pelo sistema double blind peer review.
Jean Carlos de Abreu1 Flavio Augusto Martino2 Marcos Alexandre Schiavoni3
Resumo. Este relato técnico possui o objetivo de trazer o desenvolvimento de um conceito
dentro da engenharia da computação, metodologia aplicada na empresa Procel Software, que apesar de muito praticado, ainda é conhecido por poucos. A metodologia possibilita a aplicação de teste de software de forma exploratória. O conceito vem oferecer um estilo de teste que enfatiza a liberdade individual. Conclui-se que a responsabilidade do testador de forma isolada na otimização continua concomitantemente na qualidade de seus trabalhos, sendo um fenômeno que se estuda.
Palavras-chaves: Testes; Software; Desempenho.
EXPLORATION IN SOFTWARE TESTING
Abstract. This technical report has the goal of bringing the development of a concept within the computer engineering, methodology applied in Procel Software company, which although very practiced, it is still known by few. The methodology enables software test application in an exploratory way. The concept is to provide a testing style that emphasizes individual freedom. It is concluded that the responsibility of isolation tester optimization continues concurrently in the quality of their work, with a phenomenon that is studied.
Keywords: Testing; Sotware; Performance.
1 INTRODUÇÃO
A empresa Procel Software4 atuante como desenvolvedora de software no ramo de automação comercial, vinha a exatos vinte e quatro anos trabalhando suas aplicações ERP (Enterprise Resource Planning) cliente e servidor sem conhecer e utilizar metodologias de testes de software e controle de qualidade. Na ocasião o mesmo profissional que escrevia os códigos fontes concomitantemente ao gerente de projetos e implantadores realizava a verificação do escopo preliminar e comparava com o produto final. Com o advento da pesquisa encontrou-se dentre as várias opções de testes de software o teste exploratório, o
1
Mestrando em Administração pela Universidade do Vale do Itajaí (UNIVALI). MBA em Gestão de Projetos pela University of California (USA). Professor da Faculdade Estácio de Sá. E-mail: jean@procel.com.br
2
Mestre em Administração pela Universidade de Brasília (UnB). E-mail: flaviomartino@me.com 3
qual trata de uma abordagem que traz de forma é concisa a descrição como aprendizagem simultânea, projeto de teste e execução do teste. Para Sommerville (2005) “Um teste bem sucedido para detecção de defeitos é aquele que faz com que o sistema opere incorretamente e, como consequência, expõe um defeito existente, enfatizando assim um fato importante sobre os testes.”.
O termo “Teste Exploratório” nasceu em 1983 com Cem Kaner, tempo depois o próprio criador define o teste exploratório como "um estilo de teste de software que enfatiza o pessoal liberdade e da responsabilidade do testador individual para otimizar continuamente a qualidade de seu trabalho, tratando teste relacionado com a aprendizagem, projeto de teste, execução de testes e interpretação dos resultados de teste como atividades de apoio mútuo que são executados em paralelo ao longo do projeto ".
Kaner, Bach e Pettichord (2002) demonstram que o teste exploratório deve ser utilizado nas seguintes situações:
• Necessidade em fornecer feedback rápido sobre um novo produto ou serviço; • Necessidade de aprender o produto rapidamente;
• Diversificar os testes e melhorá-los;
• Encontrar o erro mais importante no menor espaço de tempo; • Investigar e isolar um defeito específico;
• Investigar a situação de risco em especial, a fim de avaliar a necessidade de testes com script nessa área.
Com base nessas situações exemplificadas, confrontando com a necessidade da Procel Software o que mais se destaca é encontrar o erro com maior importância no menor espaço de tempo ao mesmo tempo a investigação da situação de risco, em especial buscando a necessidade de testes automatizados. Essa pesquisa relevou que metodologia do teste exploratório é caracterizada por meio de ações muito rápidas e flexíveis, isso é um fator de grande relevância, pois a cultura da empresa até o presente momento não permite mudanças radicais com novos processos e métodos. Assim, corroborando com Kaner, Bach e Pettichord (2002) é possível tentar trazer uma maneira de planejar os testes e documentar sua execução, a fim de saber o que foi testado, o que foi encontrado e quais são as prioridades para os próximos testes, sem obstruir a flexibilidade de testar o produto de forma exploratória.
2 RELATÓRIO TÉCNICO
2.1 Sobre a técnica
Testes exploratórios, são testes dinâmicos os quais não são criados com antecedência, normalmente seguem guias e diretrizes e não um roteiro rígido. São baseados em pensamento estruturado e exploração livre, são altamente adaptativo e flexíveis. No entendimento de Coperland (2004) ‘O aprendizado em paralelo é predominante, em sua execução, lições aprendidas de outros testes e projetos servem de guia orientativo’.
Com base nesse conceito foi criado internamente uma rotina de qualidade que trabalha efetivamente com os testes exploratórios. A figura 1, demonstra o fluxo de trabalho criado para atender os testes exploratórios que atinge não só o setor de testes de software quanto o desenvolvimento, gerencia de projetos, implantação e suporte.
Figura1: Fluxo básico de testes
Fonte: Elaborado pelos autores
Assim outro conceito aplicado na técnica de testes exploratórios é a abordagem mais eficiente e eficaz para testes de software que segundo Petroski (2009) ela produz resultados úteis desde as primeiras horas de testes, e encontra os maiores erros mais rápido do que qualquer outra abordagem. Além disso, ele encontra erros que outras abordagens não vão encontrar em tudo.
Com relação a metodologia, afirma Coperland (2004, p.64) “Os testes exploratórios , cujo a sua história deixou marcado no começo de mil novecentos e noventa, que em muitas vezes tornou-se sinônimo de trabalho desleixado, descuidado.”. Como resultado, um grupo de metodólogos teste começou a usar o termo "exploratória", buscando enfatizar o processo de pensamento dominante envolvido no teste improvisado, e começar a desenvolver a prática em uma disciplina ensinável. Esta nova terminologia foi publicado pela primeira vez pelo autor Cem Kaner em seu livro Software Testing Computer e expandiu em lições aprendidas em teste de software.
Na prática dessa metodologia realizada na empresa, foi observado que a teoria se fez presente no teste exploratório, pois o testador vem projetando casos de testes na medida em que os testes são realizados, e não dias, semanas ou meses antes do início dos testes. No momento de transição de cultura esse fator é de inteira importância pois não tem grandes mudanças no fluxo operacional, além disso, as informações coletadas pelo testador na execução de um conjunto de testes servem de guia para projetar e executar o próximo conjunto de testes. Dessa forma o fluxo que fora criado afim de apoiar na organização do processo sofre alterações com o objetivo de maximizar os resultados conforme figura 2:
Figura2: Fluxo básico de testes V2
Fonte: Elaborado pelos autores
Na prática o conceito se fez presente mostrando que no momento em que o software está sendo testado, o responsável pelo teste aprende coisas que junto com a experiência e criatividade gera novos bons testes para ser executado. Tinkham, e Kaner (2011) afirmam que em vias técnicas, teste exploratório é normalmente considerado como uma caixa preta. Outros consideram um teste de abordagem que pode ser aplicado a qualquer técnica de ensaio, em qualquer fase do processo de desenvolvimento.
Na aplicação do teste exploratório na Procel Software, observou-se que o envolvimento cognitivo do testador é algo de muita importância e a qual chama a atenção para essa metodologia. Uma outra característica do teste exploratório está na responsabilidade do testador para administrar seu tempo. É salutar dizer que testes exploratórios podem ser tão disciplinados como qualquer outra atividade intelectual.
Com objetivo específico o teste exploratório busca entender como o software realmente funciona, e para fazer perguntas sobre como ele irá lidar com casos difíceis e fáceis. A qualidade do teste é dependente da perícia do testador de inventar casos de teste e encontrando defeitos. Quanto mais o testador sabe sobre o produto e diferentes métodos de ensaio, o melhor será o teste releva (STEWART, 1998).
Para que fosse possível registrar a bateria de testes realizados e o conhecimento do testador, foram necessárias algumas adaptações nos itens que comporiam a suíte e os casos de teste disponíveis na ferramenta de gestão de teste. Um ponto importante de se destacar são os registros dos pequenos testes realizados durante a sessão. Estes pequenos testes gerarão históricos de todos os passos realizados pelo testador durante a exploração dos test points, o que será útil na reprodução dos mesmos pelo testador, ou por outra pessoa, em uma nova bateria de execução, ou seja, não será necessário repensar os testes, pois estes já estarão
registrados, a figura 3 mostra uma parte do check-list aplicado em tempo de execução do teste.
Figura3: Check-list básico
Fonte: Elaborado pelos autores
Teste exploratório é mais uma mentalidade ou uma maneira de pensar sobre o teste do que uma metodologia, afirmam Kaner, Bach e Pettichord (2002). Produzir melhores idéias, por meio de grupos de estudos e brainstorming é possível representar a utilidade de bons e novos questionamentos. Uma forma de executar o teste exploratório consiste em descrever o que você vê, reconhecer e gerenciar viés, utilizar ferramentas e meios para facilitar os trabalhos tais quais como formulários check-lis de testes, captura de tela ou vídeo como um registro da sessão exploratória, ou outras ferramentas para rapidamente ajudar a gerar situações de interesse.
2.2 A plicabilidade
Na utilização do teste exploratório, especialistas criam cenários que dependem fortemente do uso do produto, uma espécie de linha de base para utilizar durante seus experimentos. Assim Caetano (2012) em sua publicação mostra que dos testes realizados, em cada linha de base, cada questão respondida corretamente aumenta a confiança no produto/software. Os questionamentos devem seguir critérios previamente determinados, pois
caso isso não aconteça, há uma grande possibilidade de fracassar pois as perguntas normalmente não serão apropriadas para obter o melhor resultado. Teste exploratório foi sempre realizado por testadores qualificados.
Foi observado que na aplicação do teste na Procel Software, as expectativas estavam abertas. Alguns resultados puderam ser previstos e esperados, porém nem todos. Nessa forma de testar um software o profissional que tesou também efetua a configuração, operação, observação e avaliação do produto e seu comportamento. O conhecimento é o fator principal no assunto que remete ao teste exploratório, tal qual é obtido durante a própria execução, já outra situação é a própria propriedade de conhecimento pontual do testador.
A utilização da busca preponderante com foco no resultado, a labuta em busca da qualidade quase que certificando a possível má qualidade no uso e nas rotinas de um produto software é algo que muitas vezes cria um clima não muito agradável, pois o desenvolvedor acredita que com base em seus conhecimentos e técnicas e o tester busca comprovar as falhas ainda não relatadas ou encontradas.
Na implantação da metodologia, observou-se que é praticamente remota a possibilidade da assertividade na utilização de programas que automatizem essa “técnica”. No que tange a parte de documentação a constância dos testes exploratórios em documentar todos os testes realizados apenas para documentar os erros é grande. Durante os testes, profissionais criam casos de teste em conjunto, uns realiza-os, e as outros documentam. Foi assim que desenvolveu-se uma sessão baseada em testes, a qual é um método especificamente desenvolvido para tornar o teste exploratório em algo plenamente mesurável com suporte a possíveis auditorias, e caso seja necessário a probabilidade de atender a situação em grandes proporções.
Na implantação fez nascer a necessidade de alguma ferramenta que controlasse os testes, foi realizado uma busca que tentou encontrar a funcionalidade de impressão de relatórios, o que permite visualizar as informações lançadas durante a execução do teste. Foram poucas ferramentas encontradas. Assim foi criado um software específico com as mudanças realizadas para adaptar ao modelo, as informações presentes no relatório, que foram: A missão do teste; os test points, os riscos, o tempo, o identificador do caso de teste, o autor, sumário, os passos e resultados esperados, ou dúvidas durante o teste, o conhecimento tácito do testador sobre o teste, os requisitos, as palavras-chaves.
No que tange o comportamento do testador, observou-se que o profissional que realiza os testes, se concentra mais em como o software realmente funciona, testadores fazem um planejamento mínimo e máximo de execução do software pelo qual eles ficam na ideia de profundidade sobre a funcionalidade do software, uma vez que o testador começa a focar na visão do software, ele pode tomar decisões para testar novamente se for necessário.
Corroborando com Stewart (1998) “A heurística se faz presente na esfera do teste exploratório, com manuais usados para orientar o que os testers devem fazer em determinadas situações.” Bem como o que não deve ser feito em outras situações sejam elas habituais ou não. Dentro da própria heurística existem situações de lições aprendidas em teste de software, com embasamento em plano de teste e avaliação de heurísticas, teste de funcionalidade geral e estabilidade de procedimentos. Há ainda listas de testes gerais e listas de riscos.
Ao final da execução do teste exploratório, as seguintes informações sobre o módulo testado estarão registradas:
• Casos de testes;
• Requisitos funcionais e não-funcionais (se houver) ; • Registro dos bugs;
Por sim espera-se dos testers que tenham respostas efetivamente rápidas e tratem os problemas importantes com mais rapidez, em suas atribuições eles devem apontar para tipos específicos de falhas, as quais possam ser consistente e com produtos claramente comparáveis.
2.3 Utilização
O teste exploratório é recomendado normalmente nas situações que os requisitos e especificações estejam incompletos, ou nos casos em que houver ausência de um bom escopo com base na falta de tempo em sua elaboração. A técnica pode também ser usada para verificar que o teste anterior, verificaram os defeitos mais importantes afirmam Kaner, Bach e Pettichord (2002).
Na utilização da metodologia na Procel Software observou-se ainda que dentre as vantagens que a técnica traz, existe um ponto a se destacar que é o apontamento para sua utilização, pois erros são encontrados de forma mais rápida, tornando o processo menos moroso e mais assertivo. A utilização do raciocínio indutivo é outro aliado para a utilização do técnica, por meio das lições aprendidas de outros projetos já desenvolvidos, essa mesma situação é utilizada e citada em gerenciamento de projetos com a metodologia PMI (Project Management Institute) no emprego do PMBOK (Project Management Body of Knowledge) artefatos utilizados pela empresa.
A utilização se apresenta também após os testes iniciais, pois na maioria dos erros normalmente são descobertos por meio de algum teste exploratório. Dentre alguns testes existentes podem ser citados os testes de funcionalidades, testes de domínio, testes de stress, teste de cenário, os testes de fluxos, testes de reivindicações, teste de nível usuários, testes de riscos e testes automatizados.
Foi relatado pelos especialistas de testes e confirmado na prática que em situações que dependendo o tipo que necessitem identificar o propósito do projeto ou que careçam de determinação os requisitos e funcionalidades do software, a técnica de testes exploratórios é empregada. Podendo ainda ser utilizada na identificação da limitação do software, nos teste as funcionalidades cuidadosamente com base nos requisitos e quando é preciso criar casos de teste que verificam a consistência do software.
2.4 Por que usar?
Segundo Sommerville (2003, p.377) “Um teste bem sucedido para detecção de defeitos é aquele que faz com que o sistema opere incorretamente, como consequência, expõe um defeito existente”, assim o teste exploratório é especialmente útil em situações de testes complexos, quando pouco se sabe sobre o produto, ou como parte de preparação de um conjunto de testes em script. A regra básica é que o teste exploratório é chamado para qualquer momento, o próximo teste você deve realizar não é óbvio, ou quando você quiser ir além do óbvio. É necessário praticar, porque aumenta a mente do testador e habilidades estratégicas através da exploração e da experiência.
Uma outra razão da utilização está na rastreabilidade, pois todo o conhecimento do teste ficará centralizado na ferramenta de gestão de teste para consultas, reprodução do teste, novos conhecimentos, entendimento da estratégia aplicada pelo testador durante a investigação, entre outras aplicações.
Na ocasião, Petroski (2009) afirma que ‘O ideal, para gerenciar o conhecimento, seria dispor de uma estrutura de fácil interação para trazer os dados cadastrados, bem como a
possibilidade de qualquer usuário contribuir na manutenção do conhecimento introduzido na ferramenta’. Isso só seria possível, caso todos logassem como administradores. A incorporação do mecanismo de busca é uma importante sugestão para a próxima versão da ferramenta.
Na observação da utilização na empresa, foi notório a referencia ao apontamento da necessidade de profissionais experiente para execução dos testes, pois somente os mesmos são capazes de analisar o produto, avaliando riscos. De forma sistêmica o software é explorado com testes críticos, o qual é capaz de analisar e explicar a lógica. Mais um dos fatores que caracterizam o teste exploratório está vinculado a crítica os próprios erros em seus pensamentos, os quais devem necessariamente observar cuidadosamente a distinção entre a observação e a influência.
Foram ainda planejadas nas atividades do setor de teste de software da Procel Software situações de teste onde a eficiência e repetitividade são tão importantes que devemos possuir um script ou automatizá-las. Por exemplo, no caso em que uma plataforma de teste é apenas intermitentemente disponível, tal como um projeto de cliente-servidor, onde existem apenas alguns servidores configurados disponíveis e têm de ser partilhada por meio de testes e desenvolvimento. A logística de tal situação pode ditar que os testes de nós de script cuidadosamente com antecedência para obter o máximo proveito de cada segundo de tempo limitado de execução de testes.
Assim a Procel Software incorporou em algumas rotinas de seus produtos procedures que cuidam dos testes automatizados, Assim o ganho na qualidade de produtividade foi predominante. Deixando para a aplicação alguns pré-testes, dispensando o trabalho humano. A figura 5 apresenta parte do código com a chamada da procedure. Já a figura 6 com base na orientação a objeto as telas ocultas de testes criadas:
Figura5: Código fonte com procedure de testes automatizados
Figura6: Fonte orientado a objeto com testes automatizados.
Fonte: Elaborado pelos autores
Na Procel Software, a técnica foi aplicada em momentos de rotinas críticas ou seja que não podem parar ou até mesmo de sub-rotinas complexas, quando as informações sobre o produtos não são suficientes, ou como parte de preparação de um conjunto de testes em script. A regra básica é esta: o teste é requisitado para qualquer momento ou quando o próximo teste você deve realizar não é óbvio, ou quando você quiser ir além do óbvio. Na minha experiência, que é a maior parte do tempo. Dessa forma, quanto mais o testador sabe este método, melhor ficará o teste, ainda melhor a qualidade do projeto de software será impreterivelmente mais eficaz.
Caetano (2010) destaca pontos a se destacar o porque da realização de utilização dos testes exploratórios, são eles:
Realização de testes quando não existem requisitos;
Realização de testes quando existe pouco tempo disponível;
Realização de testes quando não se conhece o aplicativo a ser testado;
Realização de testes em ambientes pouco testados pelos testes convencionais;
Identificação dos passos para tentar reproduzir um defeito aleatório;
Diagnóstico de comportamentos inesperados;
Investigação de efeitos colaterais;
Investigação de defeitos semelhantes;
Medição de riscos;
2.5 Ferramentas e Rastreabilidade
Entre as ferramentas para apoio na gestão de teste de software, foi encontrada com maior destaque a Testlink tal qual possui um módulo que permite o cadastramento dos requisitos com a finalidade de associá-lo ao caso de teste. A rastreabilidade entre requisitos/casos de teste terá como finalidade a identificação de baterias de testes essenciais de serem executadas na eventual manutenção de um requisito. Sabendo-se quais casos de teste que testarão o requisito alterado, estes serão primeiramente executados em um teste de regressão, outra ferramenta checada foi a Mantis, conforme demonstrado na figura 7.
Figura7: Framework TestLink
Fonte: Elaborado pelos autores
Uma possível limitação encontrada em uma ferramenta de teste chamada Testlink é que a mesma não dispõe de uma pesquisa genérica para que possa buscar os casos de teste cadastrados, independente de seu projeto. A ferramenta possui um mecanismo de busca, mas somente dentro de um projeto específico.
A possibilidade de estabelecer a rastreabilidade entre os artefatos do sistema é um fator que corrobora pela aderência de ferramentas para planejamento e gestão dos testes. Existe a possibilidade de integrar ferramentas de controle de teste software para que seja possível ligar os bugs encontrados aos casos de teste identificados e registrados durante a execução dos testes. Integração de ferramentas como essas promovem a rastreabilidade entre os bugs encontrados e os casos de teste, demonstrado na figura 8.
Figura 8: Framework Mantis
Fonte: Elaborado pelos autores
Para atender sua necessidade específica a Procel Software desenvolveu em sua ferramenta de controle de demandas interna, uma sub-rotina própria que cadastra e controla os testes, e faz as estimativas e estatísticas de forma clara e objetiva conforme as politicas da empresa, a figura 9 ilustra a rotina:
Figura 9: Framework específico CallOrganizer + PRO-Test
A ferramenta específica foi baseada e Mantis, apresentando os itens de testes a cadastrar e depois checar. Com tempo previsto, realizado e liberado para possíveis alterações assim ratificando o uso da metodologia de teste exploratório, a figura10.
Figura 10: Tela da rotina de cadastramento de testes exploratórios
Fonte: Elaborado pelos autores
3 CONCLUSÃO
A faculdade acerca dos testes exploratórios é absolutamente eficaz se aplicado com a finalidade de buscar erros e inconsistências. Porém, se faz necessário um planejamento afim de não permitir que os testes não percam seus objetivos, que é encontrar erros de forma ordenada.
Na Procel Software criou um marco após a implantação da metodologia de testes exploratórios. Hoje se fala “antes ou depois dos testes exploratórios”. O primeiro resultado positivo atingido foi a pesquisa de satisfação realizada pelos clientes, as quais proporcionaram um ganho de 30% no item estabilidade.
A utilização de forma assertiva trouxe retornos significativos a empresa a qual hoje trabalha em torno da qualidade do software/produto. Como consequência menos demandas urgentes e redução de esforços excepcionais. Para trabalhos futuros a empresa necessita
centralizar os esforços no maior gerenciamento dos testes, com o apoio de gráficos e relatórios com linhas de bases diferenciadas, montando diferentes cenários.
Por ser uma prática livre, é absolutamente normal efetuar diversos testes focados em um determinado escopo. A liberdade dessa metodologia não deve ser vinculada a falta de controle e desorganização. Além dos procedimentos adotados como melhores práticas existem software que apoiam a execução dessa prática, permitindo assim que o testador fique concentrado no teste e não apenas no apontamento dos registros.
Com relação as ferramentas de estudadas, os experimentos realizados com pequenos testes que cobriam o test points foram registrados dentro de um caso de teste. Com isso, não foi possível utilizar o recurso de métricas disponível na ferramenta Testlink. Há de se registrar uma limitação encontrada na ferramenta Testlink a qual não suporta pesquisas mais genéricas para que possa buscar os casos de teste cadastrados, independente de seu projeto. Para tanto foi criado uma ferramenta específica ao controle as luzes do entendimento da empresa.
Descrever o que você vê, reconhecer e gerenciar viés, utilizar ferramentas e meios para facilitar os trabalhos tais quais como formulários check-lis de testes fazem parte desse contexto. Essa pesquisa deixou evidente que o ideal para gerenciar o conhecimento, seria dispor de um mecanismo de fácil interação para trazer os dados cadastrados. A incorporação deste mecanismo de busca é uma importante sugestão para a futuras versões da ferramenta.
Por fim o teste exploratório não é burocrático, apenas exigindo do testador a síntese dos passos realizados durante os testes. Com o objetivo de garantir o teste, o responsável pela execução oferece mais assertividade nas atividades inerentes ao teste, utilizando-se de ferramentas que buscam auxiliar na identificação dos testes executados e a descrição dos erros encontrados exigindo esforço significativo da equipe em geral, bem como uma seleção criteriosa dos melhores testadores para a descoberta e publicação dos defeitos encontrados.
REFERÊNCIAS
CAETANO, Cristiano. Testes Exploratórios de A a Z. Disponível em: <http://www.linhadecodigo.com.br/artigo/1102/testes-exploratorios-de-a-a-z.aspx.> Acesso em: 14 nov. 2015.
COPERLAND, Lee. A practitioner's guide to software test design. Norwood: Artech House, 2004.
KANER, Cem; BACH, James; PETTICHORD, Bret. Lessons Learned in Software Testing:
A Context-Driven Approach. New York: Wiley Computer Publishing, 2002.
PETROSKI, Bruno Martins. Geração automática de casos de teste automatizados no
contexto de uma suíte de testes em telefones celulares, 2009. 54f. Monografia (Ciência da
Computação) – Universidade Federal de Santa Catarina, Florianópolis – SC. Disponível em: <http://www.labsoft.ufsc.br/publications/monografia_petroski.pdf.> Acesso em 02 dez. 2015. SOMMERVILLE, Ian.Engenharia de software. São Paulo: Pearson, Addison, 2005.
STEWART, Thomas . Capital intelectual, Rio de Janeiro: Campus, 1998.
TINKHAM, Andy; KANER, Cem. Exploring Exploratory Testing, 2011. Disponível em: <http://www.testingeducation.org/a/explore.pdf.> Acesso em: 15 out. 2015.
TINKHAM, Andy; KANER, Cem. Learning Styles and Exploratory Testing, 2009. Disponível em: <www.testingeducation.org/a/lset.pdf> Acesso em: 11 nov. 2015.
