Universidade Federal de Pernambuco Centro de Informtica Graduao em Cincia da Computao

FERRAMENTA DE SUPORTE A UMA METODOLOGIA PARA TESTES EXPLORATRIOS

Trabalho de Graduao

TASE DIAS DA SILVA

ORIENTADOR: ALEXANDRE VASCONCELOS (amlv@cin.ufpe.br)

Recife, junho de 2009

UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMTICA GRADUAO EM CINCIA DA COMPUTAO

TASE DIAS DA SILVA

FERRAMENTA DE SUPORTE A UMA METODOLOGIA PARA TESTES EXPLORATRIOS

TRABALHO DE GRADUAO APRESENTADO GRADUAO EM CINCIAS DA COMPUTAO DO CENTRO DE INFORMTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUESITO PARCIAL PARA OBTENO DO GRAU DE BACHAREL EM CINCIAS DA COMPUTAO.

ORIENTADOR(A): DR. ALEXANDRE VASCONCELOS

RECIFE, JUNHO/2009 ii

Agradecimentos
Agradeo a todos que contriburam de todas as formas para o desenvolvimento deste trabalho de graduao. Ao meu orientador Alexandre Vasconcelos, a minha irm Tarciana, aos meus pais, Fernanda e Luiz, ao meu irmo, minha famlia, Pricles, amigos, como Macarro, ex-colegas de trabalho e colegas de faculdade, minha famlia anfitri com quem morei durante a maior parte do perodo em que este trabalho foi desenvolvido, muito obrigada.

iii

Resumo
Softwares fazem parte de nossas vidas e, muitas vezes, perdas significativas so causadas a pessoas por resultados inesperados de tais programas. Isso pode ser evitado ou minimizado desenvolvendose um produto de qualidade e, para isso, indispensvel a realizao de testes durante o desenvolvimento do software, o que exige um grande esforo e tempo de projeto. Durante os ciclos de desenvolvimento de software de muitas empresas, testes exploratrios so realizados com o objetivo de conhecer o produto e encontrar falhas enquanto o produto estudado, usando as informaes adquiridas para projetar novos e melhores testes. Testes exploratrios so muito teis: quando se sabe pouco a respeito do produto, quando o projeto no contm documentao especificando o sistema ou esta de baixa qualidade ou desatualizada, quando no se tem um processo de testes definido, para complementar um processo de testes definido, ou como parte da preparao de testes de roteiro. Para que esse tipo de teste seja realizado de forma estruturada, existem metodologias de testes exploratrios. Um problema no caso de realizar testes exploratrios, que os passos executados pelo testador enquanto ele navega pela aplicao no so previamente documentados, pois os testes so projetados e executados simultaneamente medida que o testador estuda e aprende sobre o comportamento do software. Apenas o testador, portanto, possui as informaes necessrias para a elaborao do relatrio que reporta os resultados dos testes, como, por exemplo, que funcionalidades ou cenrios foram testados e quais testes passaram. Muitas vezes, algumas dessas informaes so esquecidas pelos testadores que realizam testes exploratrios de forma ad hoc, sem documentar o que foi feito, sem seguir uma metodologia ou procedimento estruturado para testar a aplicao e, por isso, esses testadores no conseguem descrever seus raciocnios por esquecimento e falta de documentao. Entretanto, por meio de utilizao de metodologias existentes para guiar a prtica de testes exploratrios, possvel realizar esses testes de forma estruturada e documentada. Considerando o acima exposto, este trabalho de graduao tem como objetivo aperfeioar uma metodologia existente, chamada de Metodologia para Testes Exploratrios, que sugere passos a serem seguidos para a realizao do teste. Alm disso, tambm proposta uma ferramenta para dar suporte a essa metodologia, auxiliando na reportagem dos resultados dos testes.

Palavras-Chave: teste de roteiro, cenrios de testes, teste de caixa-preta, teste de caixabranca, ciclo de vida de desenvolvimento de software, ciclo de vida de teste, bug, testes exploratrios.
iv

Abstract
Software is involved in our lives and losses are caused to individuals by unexpected results of such programs. This can be avoided or minimized by developing a product with quality and, therefore, it is essential to test the product during software development, which requires a great effort and time of project. During cycles of software development in many companies, exploratory tests are carried out in order to know the product and finding faults while the product is studied, using the information gained to design new and better tests. Exploratory tests are very useful: if you know little about the product, when the project contains no documentation specifying the system or it is of low quality or outdated, when you do not have a testing process, to complement a testing process, or as part of the preparation of scripted tests. In order to perform this type of test in a structured way, there are exploratory testing methodologies. A disadvantage of exploratory testing is that the steps executed by the tester while he navigates through the application are not documented, because the tests are designed and implemented simultaneously as the tester studies and learns about the behavior of the software under test. Only the tester, therefore, knows the necessary information for preparing the report which reports the test results, such as features or scenarios that were tested and which tests passed.

Some of these details are often forgotten by testers who perform exploratory testing on an ad-hoc way, without documenting what was done and without following a structured methodology or procedure to test the application. Therefore, these testers cannot describe their reasoning for forgetfulness and lack of documentation. However, by using existing methodologies to guide the practice of exploratory testing, it is possible to perform these tests in a structured and documented way. Considering the explanation above, this work aims to improve an existing methodology, called the Methodology for Exploratory Testing, suggesting steps to be followed for the test. Moreover, a tool to support this methodology is proposed, assisting in the reporting of test results.

Keywords: scripted test, test scenario, black-box testing, white-box testing, development life cycle, test life
cycle, bugs, exploratpry testing.

Lista de Figuras
Figura 1.1 Os Trs Principais Elementos de uma Metodologia, Fonte: [11] ................................. 4 Figura 1.2 Partio de Equivalncia, Fonte: [15]................................................................................ 6 Figura 1.3 Valores Limites, Fonte: [15] ............................................................................................... 7 Figura 2.1 Guia de Cenrios de Teste, Fonte: [15] .......................................................................... 13 Figura 2.2 Planilha de Execuo, Fonte: [15] ................................................................................... 15 Figura 2.3 Tarefas e entregas do Procedimento de Teste de Funcionalidade e Estabilidade .... 17 Figura 2.4 Definies e Critrios de Avaliao de Funcionalidade e Estabilidade, Fonte: [14] 19 Figura 2.5 Exemplo de Planilha de Sesso, Fonte: [18] .................................................................. 28 Figura 2.6 Grfico das Atividades do Testador, Fonte: [18] .......................................................... 30 Figura 2.7 Quantidade de Sesses por Intervalo de Tempo, Fonte: [18]..................................... 31 Figura 3.1 Comparao entre processos das metodologias da subsees 2.2.2, 2.2.1 e 2.2.4 .... 35 Figura 3.2 Comparao entre tcnicas utilizadas nas metodologias da subsees 2.2.2, 2.2.3 e 2.2.1 .............................................................................................................................................................. 36 Figura 3.3 Diagrama de atividades da Metodologia para Testes Exploratrios ........................... 38 Figura 3.4 reas da Metodologia para Testes Exploratrios suportadas pela ferramenta SMTE41 Figura 3.5 Diagrama de Casos de Uso ............................................................................................... 42 Figura 3.6 Menu da ferramenta SMTE .............................................................................................. 43 Figura 3.7 Definir misso ..................................................................................................................... 44 Figura 3.8 Testar e registrar resultado ................................................................................................ 45 Figura 3.9 Reportar falhas e issues...................................................................................................... 46 Figura 3.10 Modelo Entidade-Relacionamento da ferramenta SMTE .......................................... 47 Figura 3.11 Esquema conceitual da ferramenta SMTE.................................................................... 48

vi

Sumrio
Resumo Abstract 1 Introduo
1.1.1 1.1.2

iv v 1

1.1 Conceitos Bsicos para a Metodologia Proposta ............................................................................ 3

Tcnicas de Testes ....................................................................................................................................... 4 Estratgia de Testes ..................................................................................................................................... 9

1.2 Estrutura do Trabalho de Graduao ............................................................................................... 9 2 Estado da Arte 10 2.1 Introduo .......................................................................................................................................... 10 2.2 Metodologias ...................................................................................................................................... 10
2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.3.1 2.3.2 2.3.3 Metodologia para Testes Exploratrios ................................................................................................. 10 Procedimento de Teste de Funcionalidade e Estabilidade.................................................................. 16 Testes Exploratrios: a prxima gerao ............................................................................................... 21 Gerenciamento de Teste Exploratrio Baseado em Sesso ............................................................... 24 Consideraes............................................................................................................................................. 29 Session-Based Test Management Scan Tool ......................................................................................... 29 Exploratory Test Assistant ....................................................................................................................... 32 Test Explorer Controller .......................................................................................................................... 33

2.3 Ferramentas de Apoio a Testes Exploratrios .............................................................................. 29

Metodologia e Ferramenta Propostas para Testes Exploratrios

34

3.1 Introduo .......................................................................................................................................... 34 3.2 Estudo Comparativo das Metodologias ......................................................................................... 34

3.2.1 3.2.2 3.2.3 3.3.1 3.4.1 3.4.2 Comparao entre os processos das Metodologias .............................................................................. 34 Comparao de Tcnicas utilizadas nas Metodologias ........................................................................ 35 Consideraes............................................................................................................................................. 36 Metodologia para Testes Exploratrios Modificada ............................................................................ 37 Identificao dos passos a serem automatizados.................................................................................. 41 Descrio da ferramenta SMTE .............................................................................................................. 41

3.3 Aperfeioamento da Metodologia ................................................................................................... 37 3.4 Ferramenta Proposta ......................................................................................................................... 40

Concluso e Trabalhos Futuros

49

4.1 Consideraes Finais ......................................................................................................................... 49 4.2 Contribuies ..................................................................................................................................... 49 4.3 Trabalhos Futuros ............................................................................................................................. 50 Referncias ................................................................................................................................................... 51

vii

Introduo

Desenvolver software de qualidade importante porque softwares fazem parte de nossas vidas. Utilizamos softwares em telefones celulares, carros e impressoras, entre outros produtos. Entretanto, a maioria das pessoas j teve uma experincia de um software no funcionar, como, por exemplo, um site da Internet que no foi carregado corretamente. Alm disso, nem todos os sistemas de software possuem o mesmo risco e, portanto, nem todos os problemas causam o mesmo impacto. Falhas em sistemas de software podem causar danos significantes dependendo da criticidade da aplicao [1] . Para o desenvolvimento de um software com qualidade, evitando que perdas significativas sejam causadas a pessoas por resultados inesperados da execuo do software, fundamental a realizao de testes. De acordo com Mller, Thomas, et al. [1] , testar um processo que consiste em todas as atividades do ciclo de vida (tanto estticas como dinmicas) voltadas para o planejamento, preparao e avaliao de produtos de software e produtos de trabalho relacionados, a fim de determinar se eles satisfazem os requisitos especificados e demonstrar que esto aptos para sua finalidade e para a deteco de defeitos. Entende-se por atividades estticas as que no executam o cdigo do programa e, por atividades dinmicas, as que executam o cdigo do programa. Preparao significa a seleo do que ser testado, bem como o projeto dos casos de testes. Entretanto, a realizao de testes exige grande esforo e tempo de projeto [6] . Estudos demonstram que, apesar de os custos com testes representarem 45% do custo de desenvolvimento de um produto, o custo de no testar muito maior, porque o custo da deteco de um erro aps a entrega do produto , no mnimo, 100 vezes maior do que se o mesmo tivesse sido detectado em tempo de definio do sistema [6] . Entretanto, no possvel testar completamente todas as possibilidades e situaes a que uma aplicao pode ser submetida [7] , e, o fato de nenhum defeito ser encontrado no prova de corretude, pois testes apenas mostram a presena de defeitos e reduzem a probabilidade de que defeitos no descobertos permaneam no software. Portanto, para que testes possam ser realizados dentro do cronograma definido em um projeto, necessrio um planejamento efetivo para que os testes possam cobrir a maior rea possvel do software [6] . Uma poderosa abordagem de testes para determinados tipos de software e projeto o teste exploratrio, que definido como sendo, simultaneamente, aprendizagem, design de testes e execuo de testes [8] ; isso significa que os testes no so definidos antecipadamente em um plano de tes1

tes, mas que so dinamicamente projetados, executados e modificados. Por isso, menos preparao (em relao a conhecimento dos requisitos e design prvio dos casos de testes) exigida, e importantes defeitos so encontrados rapidamente, tornando-se mais estimulante intelectualmente para o testador do que a execuo de testes de roteiro [4] . Alm disso, testes exploratrios so muito teis: quando se sabe pouco a respeito do produto, quando o projeto no contm documentao especificando o sistema ou esta de baixa qualidade ou desatualizada, quando no se tem um processo de testes definido, para complementar um processo de testes definido, ou como parte da preparao de testes de roteiro [10] . Entretanto, teste exploratrio tambm possui desvantagens [4] , como por exemplo, os testes executados dependerem da habilidade, experincia e intuio de testadores, e, portanto, podem no ser revisados com antecedncia, rastreados ou facilmente repetidos. Alm disso, pelo fato de os testadores construrem mapas e modelos mentalmente em vez de no papel, as habilidades e conhecimento vo embora junto com eles quando eles deixam o projeto. Muitas vezes, algumas dessas informaes so esquecidas pelos testadores [9] que realizam testes exploratrios de forma ad hoc, sem documentar o que foi feito, sem seguir uma metodologia ou procedimento estruturado para testar a aplicao e, por isso, esses testadores no conseguem descrever seus raciocnios por esquecimento e falta de documentao. Por outro lado, por meio de utilizao de metodologias existentes para guiar a prtica de testes exploratrios, possvel realizar esses testes de forma estruturada e documentada. Teste Exploratrio muitas vezes associado a teste ad hoc, ou seja, muitos testadores encontram falhas acidentalmente, sem terem utilizado nenhum planejamento ou documentao para isso [5] . Apesar disso, ele pode ser e realizado de maneira estruturada e formal por vrias empresas, como, por exemplo, Microsoft e Nortel [8] , atravs de metodologias de suporte a essa tcnica, cujo objetivo encontrar falhas mais difceis de serem descobertas, provenientes de cenrios mais complexos, alm de guiar testadores na realizao de testes exploratrios de forma estratgica. Com o objetivo de minimizar as desvantagens encontradas na utilizao de testes exploratrios, o trabalho apresentado em [15] prope a Metodologia para Testes Exploratrios, que consiste das seguintes fases: planejamento, elaborao de cenrios, execuo de testes e anlise dos testes realizados. A vantagem dessa metodologia em relao s outras a de que ela prov um guia de cenrios de testes que apresenta cenrios utilizados para testar vrias funcionalidades, sendo esse guia dividido em testes de campo, usabilidade, negcio e segurana. Considerando o acima exposto, este trabalho de graduao tem como objetivo aperfeioar a Metodologia para Testes Exploratrios [15] . Para tanto, foram estudadas e analisadas outras meto2

dologias existentes de testes exploratrios e, com essas informaes, foi feito um estudo comparativo entre elas, de acordo com critrios adotados por este trabalho. Esses critrios utilizados na realizao da anlise e do estudo comparativo das metodologias foram escolhidos baseando-se nas definies de conceito de metodologia, apresentado na dissertao de mestrado de Pedro Silva [11] , de tcnicas de testes e de classificao de tcnicas de testes, apresentados no livro Lessons learned in software testing: a context driven approach, de Cem Kaner, et al. [13] . Esses conceitos so apresentados na prxima seo. Alm disso, o trabalho tambm prope uma ferramenta, chamada de SMTE, para dar suporte Metodologia para Testes Exploratrios [15] (aps ela ser aperfeioada), auxiliando na reportagem dos resultados dos testes, entre outras atividades da metodologia. Para isso, so identificadas as necessidades de automao das atividades da metodologia para que a ferramenta SMTE seja definida, e so tambm apresentadas ferramentas existentes no mercado que servem como benchmark para que as funcionalidades da ferramenta SMTE sejam propostas. A prxima seo introduz conceitos relacionados ao termo metodologia para que, durante a anlise de metodologias de testes exploratrios e o estudo comparativo entre elas, a ser feita na subseo 2.2.2 e na seo 3.2, respectivamente, sejam levados em considerao os elementos definidos nesses conceitos. Pelo fato de o contexto em que essas metodologias esto inseridas ser o de testes de software, so introduzidos tambm conceitos sobre testes.

1.1 Conceitos Bsicos para a Metodologia Proposta

O conceito de metodologia (ou mtodo), no contexto de qualquer etapa do ciclo de vida de um projeto de software, consiste de uma agregao de pelo menos trs elementos: tcnicas, processo associado ao mtodo e linguagem padro associada ao mtodo [11] . O processo, nesse caso, suportado por tcnicas com base nessa linguagem padro. Essa linguagem padro associada ao mtodo aqui interpretada como sendo qualquer conceito relevante, uma definio terica sobre qualquer termo tcnico que descrito na metodologia. Por exemplo, na metodologia apresentada na subseo 2.2.2, so definidos os conceitos de funo e de estabilidade, que compem a linguagem padro na qual se baseia a tcnica funcional, tambm apresentada nessa mesma metodologia. O processo associado ao mtodo interpretado, neste trabalho, como sendo o procedimento seguido na metodologia. Tal procedimento pode ser apresentado em forma de con3

juntos de tarefas a serem executadas, como na metodologia apresentada na subseo 2.2.2, ou em fases, como na metodologia apresentada na subseo 2.2.1, em que cada fase composta de atividades a serem realizadas. Tcnica, por sua vez, interpretada como definida no dicionrio [12] , ou seja, o mesmo que prtica. Entretanto, para contextualizar melhor esse conceito neste trabalho, o conceito de tcnica ser discutido na prxima subseo. A Figura 1.1 ilustra esses trs principais elementos de uma metodologia. Na figura, o smbolo de agregao ilustrado entre a metodologia e seus trs elementos representa o fato de uma metodologia consistir de uma agregao desses trs elementos. A seta dupla entre tcnicas e processo associado representa o fato de o processo ser suportado por tcnicas, e a seta que liga tcnicas linguagem associada representa o fato de as tcnicas estarem baseadas nessa linguagem.

Figura 1.1 Os Trs Principais Elementos de uma Metodologia, Fonte: [11]

1.1.1 Tcnicas de Testes

Nesta subseo, apresentado o conceito de tcnica de teste, a definio de algumas tcnicas de testes e uma classificao de tcnicas de testes. Tcnica de teste um procedimento utilizado para derivar e/ou selecionar casos de teste [1] . Caso de teste, por sua vez, um conjunto de valores de entrada (inputs), precondies de execuo, resultados esperados e ps-condies de execuo desenvolvidas para um determinado objetivo ou condio de teste, tais como para exercitar o caminho de um determinado programa ou verificar o atendimento a um requisito especifico [1] . De acordo com Kaner, et al. [13] , existe um sistema de classificao de tcnicas de testes, chamado Five-fold Testing System. Esse sistema afirma que qualquer teste que possa ser realizado pode ser 4

descrito em termos de cinco dimenses: testador, cobertura, problemas potenciais, atividades e avaliao. Testador quem executa o teste. Por exemplo, o teste de aceitao focado em teste por membros do mercado alvo, pessoas que normalmente iro utilizar o produto. Cobertura o que testado (exemplo, em teste funcional, cada funo testada). Problemas potenciais consistem no motivo pelo qual se est testando, ou seja, qual o risco pelo qual se est testando (exemplo, testar em busca de erros de valores extremos). A dimenso de atividades consiste em como testar (exemplo, teste exploratrio). Avaliao consiste em como dizer se o teste passou ou falhou (exemplo, comparao para reconhecimento de um bom resultado). Dessa forma, tcnicas de testes podem ser classificadas em tcnicas baseadas em: testador, cobertura, problemas potenciais, atividades e avaliao. Uma tcnica de teste foca a ateno em uma ou mais dimenses [13] . possvel combinar uma tcnica que foca em uma dimenso com outra que foque em outra dimenso para que seja alcanado o resultado que se deseja. A seguir so apresentadas algumas tcnicas de testes. Teste exploratrio definido por Kaner, et al. [13] como uma tcnica baseada em atividade, em que o testador deve aprender, durante todo o projeto, sobre o produto, seu mercado, seus riscos, e de que formas o produto falhou em testes anteriores. Novos testes so constantemente criados e usados, e eles so mais poderosos do que os mais antigos porque so baseados no aumento do aprendizado contnuo do testador. Teste funcional uma tcnica de teste baseada em cobertura, e consiste em testar a fundo cada funo, uma por uma, at o ponto em que seja possvel afirmar que essa funo est funcionando [13] . Do ponto de vista de teste de caixa-preta, teste funcional foca em comandos e features, coisas que o usurio pode fazer enquanto usa a aplicao. Consistncia heurstica uma tcnica de teste baseada na dimenso de avaliao do sistema de classificao de tcnicas de testes Five-fold Testing System, pois consistncia um importante critrio para avaliar um programa [13] . Inconsistncia pode ser uma razo para reportar um bug, ou pode refletir em uma variao de projeto intencional. As sete principais consistncias, de acordo com Kaner, et al. [13] , so: Consistncia com histria: comportamentos de funes atuais so consistentes com comportamentos passados dessas funes. Consistncia com imagem da organizao: comportamento da funo coerente com uma imagem que a organizao quer projetar. 5

Consistncia com produtos comparveis: comportamento de funo consistente com as funes similares em produtos comparveis. Consistncia com declaraes: comportamento de funo consistente com o que as pessoas falam que ele deve ser. Consistncia com expectativas do usurio: Comportamento de funo consistente com o que se espera que o usurio queira. Consistncia dentro do produto: Comportamento de funo consistente com o comportamento de funes comparveis ou padres funcionais dentro do produto. Consistncia com o propsito: Comportamento da funo est consistente com o propsito aparente. Outras tcnicas de testes utilizadas por metodologias de teste exploratrio apresentadas no prximo captulo so: Partio de Equivalncia (ou anlise de classe de equivalncia) [13] : tcnica que utiliza classes de equivalncia, classes de equivalncia um conjunto de valores de uma varivel que so considerados equivalentes. Casos de testes so equivalentes se eles testarem a mesma coisa, ou seja, se um deles encontrar um bug, o outro tambm encontrar esse mesmo bug. Se um deles no encontrar um bug, o outro provavelmente tambm no encontrar. Caso uma classe de equivalncia tenha sido identificada, pode-se testar apenas um ou dois de seus elementos. Um exemplo da utilizao dessa tcnica o seguinte [15] : em um sistema que contm um cadastro de produtos onde o campo descrio do produto deve conter entre 3 e 50 caracteres, as classes identificadas so a quantidade de caracteres abaixo de trs, a quantidade de caracteres entre 3 e 50 e a quantidade de caracteres acima de 50. A figura a seguir ilustra esse exemplo.
Entrada Descrio do Produto Valores Permitidos De 3 a 50 Caracteres Classes <3 3 a 50 > 50 Cenrios Quantidade de caracteres = 1 Quantidade de caracteres = 20 Quantidade de caracteres = 60

Figura 1.2 Partio de Equivalncia, Fonte: [15] Valores limites (ou teste de fronteira) [13] : tcnica que complementa a tcnica de partio de equivalncia porque elas esto relacionadas da seguinte maneira: caso seja possvel mapear os valores de uma classe de equivalncia em uma linha numrica, os valores limites so o menor e o maior nmero da classe. Essa tcnica testa esses valores limites, e os valores de fronteira das classes vizinhas que so menores do que o menor nmero da classe que est sendo testada, e maior do que o maior 6

nmero dessa classe. A figura a seguir apresenta a utilizao da tcnica de valores limites para exemplo apresentado anteriormente [15] .
Entrada Descrio do Produto Valores Permitidos De 3 a 50 Caracteres Classes <3 3 a 50 > 50 Cenrios Quantidade de caracteres = 2 Quantidade de caracteres = 3 Quantidade de caracteres = 50 Quantidade de caracteres = 51

Figura 1.3 Valores Limites, Fonte: [15] Valores Brancos ou Nulos [15] : consiste em no preencher entradas que so obrigatrias para o sistema. Valores Invlidos e Negativos [15] : dados invlidos so utilizados nas entradas do software. Alguns exemplos disso so: digitar caracteres em campo numricos e digitar nmeros negativos em entradas que devem aceitar apenas nmeros positivos. Algumas vezes os sistemas no permitem digitar valores invlidos e negativos, mas quando se cola tais valores que foram copiados de outro lugar nos campos de entrada, eles so aceitos. Combinao de Dados [15] : so feitas vrias combinaes de dados de entrada. Cada combinao deve produzir um resultado especfico. Nas combinaes podem ser utilizados valores corretos, valores errados, valores invlidos, valor vazio. Elizondo [5] apresenta tcnicas utilizadas em testes exploratrios e as classifica em tcnicas baseadas em entrada e tcnicas baseadas em sada. Essas tcnicas so listadas a seguir. As tcnicas baseadas em entrada so [5] : Mensagens de erros o cdigo fonte mostra todas as mensagens de erro disponveis no produto. Um bug fcil de ser encontrado (que infelizmente acontece muito) erro de escrita e de gramtica na mensagem. Outro bug fcil de ser encontrado surge se for encontrado um cenrio em que uma mensagem de erro no apresentada quando deveria. Mas a idia dessa tcnica exercitar todos os cenrios que provocarem o aparecimento de uma mensagem de erro disponvel. importante que seja sempre apresentada a mensagem correta para cada cenrio testado. Valores vlidos e invlidos A idia testar valores vlidos e invlidos em todos os campos da aplicao. Por exemplo, se existir uma caixa de texto perguntando por idade, tente testar o campo com os valores -1, 0, 12, e 45686. 7

Valores default Se uma aplicao possui valores default em campos de entrada, delete esses valores e execute a aplicao. Depois, use valores diferentes, e tente usar os valores default novamente. Tipos de dados Para uma caixa de texto que aceita idade, tente valores diferentes de inteiros; tente digitar uma letra para ver se a aplicao consegue lidar com tipos de dados diferentes corretamente. Overflow Se uma caixa de texto aceita inteiros, digite o maior inteiro permitido e veja como a aplicao lida com ele. Mesma entrada vrias vezes Acredite ou no, se voc digita alguma coisa em uma caixa de texto e executa a aplicao, e depois digita a mesma coisa e tenta execut-la novamente, ela pode travar. Muitas aplicaes se comportam dessa forma. Refresh Se existir um boto de refresh em uma aplicao, clique nele vrias vezes. Preencha dados que so armazenados Se uma aplicao armazena dados, preencha um campo cujo dado ser armazenado e tente executar funcionalidades da aplicao que utilizam esses dados. Testar o software de interao Se a sua aplicao faz uso de um servidor, faa com que o servidor pare de funcionar enquanto sua aplicao estiver se comunicando com ele. Corrompa o sistema de arquivos Coisas esquisitas acontecem quando voc corrompe arquivos que esto sendo utilizados pela sua aplicao. As tcnicas baseadas em sada so [5] : Sadas exatas Verifique se computaes matemticas produzem sadas exatas. Forar mudana de propriedades Force mudanas nas propriedades dos componentes de interfaces com o usurio. Pelo fato de tcnicas de testes estarem relacionadas com estratgia de testes, a prxima subseo apresenta informaes a respeito do conceito de estratgia, que tambm ser til para a compreenso da metodologia apresentada na subseo 2.2.3.

1.1.2 Estratgia de Testes

Tcnicas de testes esto relacionadas com estratgia de testes, pois durante a descrio da estratgia de testes que so definidas as tcnicas que sero utilizadas nos testes. Segundo Kaner, et al. [13] , estratgia de teste refere-se ao conjunto de idias que guiam o design de testes por todo o projeto, e um componente importante de um bom plano de testes. Em uma estratgia de teste definido como cobrir o produto para encontrar rapidamente problemas importantes, o que especificamente ser testado, quais tcnicas sero utilizadas para criar testes, e como as falhas so reconhecidas quando elas ocorrem. Para que falhas possam ser reconhecidas, importante o uso de oracles, que so fontes que determinam qual o resultado esperado de um software [20] . A estratgia de teste especifica a relao entre a misso de teste, ou seja, o que testado ou quais problemas esto sendo procurados, e o projeto de teste. Uma boa estratgia de testes : especfica para o produto e para a tecnologia usada, focada em risco (mostrando como o projeto vai analisar o que realmente importa, conectando o processo de teste com a misso no projeto), diversificada (incluindo uma variedade de tcnicas e abordagens) e prtica, ou seja, factvel por quem ir executar essa estratgia, de forma que a estratgia sugerida no seja algo alm das capacidades do projeto [13] . Para se garantir a diversidade de uma estratgia, podem ser selecionadas tcnicas de testes de cada uma das cinco categorias de testes do sistema de classificao de testes aqui apresentado, o Five-fold Testing System.

1.2 Estrutura do Trabalho de Graduao

Alm do captulo introdutrio, este documento composto por mais quatro captulos, cada um apresentado da seguinte forma: Capitulo 2 Apresenta o Estado da Arte e consideraes a respeito de metodologias e ferramentas existentes de testes exploratrios. Captulo 3 Apresenta um estudo comparativo das metodologias de testes exploratrios existente, o aperfeioamento da Metodologia para Testes Exploratrios, e a ferramenta SMTE proposta.

Captulo 4 Apresenta as concluses sobre o trabalho, enfatizando as principais contribuies e

sugestes para trabalhos futuros.

Estado da Arte

2.1 Introduo
Aps a introduo dos conceitos relacionados ao termo metodologia no contexto da etapa de testes do ciclo de vida de um projeto de software no captulo anterior, essencial abordar o estado da arte, tanto de metodologias, como de ferramentas de testes exploratrios existentes hoje na comunidade cientfica e utilizadas por empresas no mercado de trabalho. Este captulo apresenta quatro metodologias. A primeira a metodologia apresentada em um trabalho de graduao, chamada de Metodologia para Testes Exploratrios [15] , que ser aperfeioada neste trabalho de graduao, e para a qual ser especificada uma ferramenta de suporte. A segunda a metodologia apresentada no artigo intitulado Testes Exploratrios: a prxima gerao [5] , a terceira o Procedimento de Teste de Funcionalidade e Estabilidade [14] , que na verdade no considerada explicitamente pelo autor como sendo uma metodologia. Por isso, esse procedimento analisado neste trabalho, que identifica aspectos desse procedimento que caracterizam uma metodologia [11] [13] , de maneira que este trabalho a considera uma metodologia. A quarta metodologia a de Gerenciamento de Teste Baseado em Sesso [18] . Alm disso, este captulo apresenta tambm as seguintes ferramentas de testes exploratrios existentes no mercado: Session-Based Test Management Scan Tool [18] , Exploratory Test Assistent, e Test Explorer Controller [16] . Essas ferramentas servem como benchmark para que as funcionalidades da nova ferramenta sejam propostas.

2.2 Metodologias
2.2.1 Metodologia para Testes Exploratrios
A metodologia de testes exploratrios desenvolvida por [15] , intitulada de Metodologia para Testes Exploratrios, tem como objetivo melhorar os resultados obtidos com a prtica de execuo de testes exploratrios, e sugere passos bsicos para a realizao dessa prtica. Essa metodologia consiste de quatro fases: planejamento, elaborao de cenrios bsicos, execuo e anlise dos resultados. Tal metodologia deve ser utilizada e adequada de acordo com as necessidades de cada organizao que ir utiliz-la, de forma que cada fase deva ser adaptada ou includa, caso seja necessrio. 10

Planejamento a primeira fase da metodologia, em que o plano de teste elaborado com base no plano de projeto. O plano de teste contm as seguintes sees: escopo de testes, cronograma, papis e responsabilidades, estratgia e ambiente. Na seo de escopo de testes, definido o que ser testado, relatando-se os requisitos funcionais e no-funcionais do produto. No cronograma, definido quando e quanto tempo cada fase deve durar. Na seo seguinte, os papis e as responsabilidades dentro da execuo de cada fase do processo so definidos, alm de ser especificado quem da equipe ir assumir cada papel. Na seo de estratgia, so definidas a estratgia e as tcnicas utilizadas para testar determinadas funcionalidades. Por fim, a ltima seo do plano de testes descreve o ambiente necessrio para a execuo dos testes. O plano de teste deve estar sempre consistente com o plano de projeto. Elaborao de testes, a segunda fase da metodologia, baseia-se em um guia (Figura 2.1) que contm uma quantidade de cenrios que se aplica a vrias funcionalidades. Dessa forma, alguns desses cenrios que se apliquem ao teste so selecionados e desenvolvida uma planilha de execuo (Figura 2.2), que definida e apresentada na fase de execuo. Esse guia dividido em testes de campo, usabilidade, negcio e segurana, e contm cenrios que foram elaborados baseando-se em tcnicas tais como: partio de equivalncia, valores-limite, valores brancos ou nulos, valores invlidos e negativos, e combinao de dados, explicadas na subseo 1.1.1. Dessa forma, os cenrios devem ser escolhidos de acordo com as tcnicas que forem mais adequadas para testar as funcionalidades do sistema. Esse guia apresentado na Figura 2.1 a seguir. Guia de Cenrios de Testes
Cenrios VALIDAO DO PREENCHIMENTO DO CAMPO 1. Valor maior que valor limite 2. Valor igual ao valor limite 3. Valor menor que o valor limite 4. Valor igual ao mnimo 5. Valor menor que o valor mnimo CAMPO 6. Em branco (no preenchido) 7. Valor maior que o valor limite (Ctrl + C, Ctrl + V) 8. Espaamento entre caracteres VALIDAO DO CAMPO DO TIPO NMERO 1. Caracteres especiais 2. Nmeros negatives 3. Nmeros decimais 4. Caracteres alfanumricos VALIDAO DO CAMPO TIPO DATA #$%"& -6 6,78 5fg7 Copiar e colar uma quantidade de caracteres maior que a permitida Exemplo VALOR PERMITIDO DE 3 A 50 Quantidade de caracter igual a 51 Quantidade de caracter igual a 50 Quantidade de caracter igual a 25 Quantidade de caracter igual a3 Quantidade de caracter igual a2 Observaes

11

1. Ms inexistente 2. Data inexistente 3. Dia negative 4. Ms negative 5. Ano negative 6. Caracteres alfanumricos 7. Formato invalid 8. Data maior que a atual 9. Data menor que a atual 10. Data final menor que data inicial 11. Ano bissexto VALIDAO DO CAMPO DO TIPO HORA 1. Hora invlida 2. Minuto invalid 3. Hora negative 4. Minuto negative 5. Hora vazia 6. Minuto vazio 7. Formato VALIDAO DE OUTROS CAMPOS 1. Validao do campo email 2. Validao do campo CPF VALIDAO DO CAMPO (OUTROS) 1. Somente leitura e/ou editveis 2. Valor default dos campos 3. Barra de rolagem

18/00/2007 32/01/2007 -1/01/2007 18/-1/2007 18/1/-2007 dd/mm/2007 18/1/2007 data de amanh data de ontem Quando a maior data permitida a atual Quando a menor data permitida a atual Quando existe data de incio de data de trmino

29/02/2008 Formato HH:MM 25:25 12:67 -6:57 13:-8 :34 15: 12:34:23 exemplo#exemplo.com 046.567.345-78 sem @ com valores invlidos

Verificar a ativao da barra de rolagem em campo somente leitura

VALIDAO 1. Validao visual da tela e dos componentes USABILIDADE 2. Texto de ajuda 3. Tecla ENTER 4. Tecla TAB 5. Teclas de atalho 6. Texto tooltip 7. Links de navegao 8. Barra de rolagem 9. Resoluo (800x600 e 1024x768) MENSAGEM 1. Sintaxe 2. Semntica 3. Padro visual Verificar componentes de tela Verificar componentes de tela Troca de foco entre os campos

VALIDAO DE FLUXOS NEGCIO 1. Fluxo bscio 2. Fluxos alternatives 3. Fluxos de excesso 4. Regra de negcio

12

OPES DE PREENCHIMENTO DE CAMPOS 1. Todos os campos obrigatrios vazios 2. Todos os campos obrigatrios preenchidos 3. Primeiro e ltimo campos obrigatrios 4. Apenas 1 campo obrigatrio preenchido 1. Base de dados indisponvel 2. Sesso web expirada 3. Permisso de acesso do Usurio SEGURANA 4. Garantir que o sistema no preserva dados na tela aps operao 5. Testes de F5/Refresh 6. Testes de SQL Injection Testar a insero de comando SQL no sistema Aps incluir um registro

Figura 2.1 Guia de Cenrios de Teste, Fonte: [14]

Execuo a fase seguinte elaborao de testes. Nela, os cenrios de testes presentes na planilha de execuo so executados pelo testador. Pelo fato de tais cenrios serem bsicos, dada ao testador a liberdade para que sejam elaborados e executados outros testes durante essa fase. Os defeitos encontrados durante a execuo so registrados. Pode acontecer de alguns cenrios no serem executados por restries de tempo e recursos, o que requer que haja uma priorizao dos cenrios a serem testados. Dessa forma, aconselha-se testar cenrios cujas funcionalidades envolvidas so mais crticas para o sistema, cenrios que j apresentaram erros e testar tambm os aspectos vitais do sistema, que dependem das caractersticas e dos riscos do sistema. Esses aspectos vitais variam de um sistema para outro. Tais aspectos podem ser: funcional, segurana, desempenho e usabilidade. O guia de testes apresentado anteriormente instanciado para que seja criada uma planilha de execuo, como a apresentada na Figura 2.2, que, alm de conter informaes apresentadas no guia, tambm contm campos a serem preenchidos com informaes sobre a execuo dos testes. Esses campos so: sistema, verso, tela, executor, data e, na rea de resultado, informada a quantidade de cenrios que passaram no teste (passados), quantos cenrios falharam (falhos), total de cenrios (total) e o tempo total da execuo (tempo total). Planilha de Execuo
Sistema: Verso: Tela: Executor: Data:

13

Passados: Cenrio(s) Cenrios VALIDAO DO PREENCHIMENTO DO CAMPO 1. Valor maior que valor limite 2. Valor igual ao valor limite 3. Valor menor que o valor limite 4. Valor igual ao mnimo 5. Valor menor que o valor mnimo 6. Em branco (no preenchido) 7. Valor maior que o valor limite (Ctrl + C, Ctrl + V) 8. Espaamento entre caracteres VALIDAO DO CAMPO DO TIPO NMERO 1. Caracteres especiais 2. Nmeros negatives 3. Nmeros decimais 4. Caracteres alfanumricos VALIDAO DO CAMPO TIPO DATA 1. Ms inexistente 2. Data inexistente CAMPO 3. Dia negative 4. Ms negative 5. Ano negative 6. Caracteres alfanumricos 7. Formato invalid 8. Data maior que a atual 9. Data menor que a atual 10. Data final menor que data inicial 11. Ano bissexto VALIDAO DO CAMPO DO TIPO HORA 1. Hora invlida 2. Minuto invalid 3. Hora negative 4. Minuto negative 5. Hora vazia 6. Minuto vazio 7. Formato VALIDAO DE OUTROS CAMPOS 1. Validao do campo email 2. Validao do campo CPF VALIDAO DO CAMPO (OUTROS) 1. Somente leitura e/ou editveis

Resultado Falhos: Cenrio(s) Exemplo

Total: Cenrio(s) Resultado

Tempo Total: Observaes

Solicitao de Mudana ID Resumo

#$%"& -6 6,78 5fg7

18/00/2007 32/01/2007 -1/01/2007 18/-1/2007 18/1/-2007 dd/mm/2007 18/1/2007 data de amanh data de ontem

29/02/2008 Formato HH:MM 25:25 12:67 -6:57 13:-8 :34 15: 12:34:23

exemplo#exemplo.com 046.567.345-78

14

2. Valor default dos campos 3. Barra de rolagem VALIDAO 1. Validao visual da tela e dos componentes 2. Texto de ajuda USABILIDADE MENSAGEM NEGCIO SEGURANA 3. Tecla ENTER 4. Tecla TAB 5. Teclas de atalho 6. Texto tooltip 7. Links de navegao 8. Barra de rolagem 9. Resoluo (800x600 e 1024x768) 1. Sintaxe 2. Semntica 3. Padro visual VALIDAO DE FLUXOS 1. Fluxo bscio 2. Fluxos alternatives 3. Fluxos de excesso 4. Regra de negcio OPES DE PREENCHIMENTO DE CAMPOS 1. Todos os campos obrigatrios vazios 2. Todos os campos obrigatrios preenchidos 3. Primeiro e ltimo campos obrigatrios 4. Apenas 1 campo obrigatrio preenchido 1. Base de dados indisponvel 2. Sesso web expirada 3. Permisso de acesso do Usurio 4. Garantir que o sistema no preserva dados na tela aps operao 5. Testes de F5/Refresh 6. Testes de SQL Injection

Aps incluir um registro

Figura 2.2 Planilha de Execuo, Fonte: [14]

O campo sistema contm qual sistema est sendo testado; no campo verso, a verso do sistema, para que se saiba qual verso do sistema apresentou os erros reportados na planilha; no campo telas, indicada a tela testada; em executor, o nome da pessoa que executou o teste; e no campo data, indicada a data em que os testes foram executados.

15

Cada cenrio da planilha contm os campos: resultado, ID, resumo e observaes. O campo resultado informa se o teste passou ou falhou. ID e Resumo so preenchidos no caso de o teste falhar, com a identificao da solicitao de mudana e o resumo da falha, respectivamente. J o campo de observaes deve ser preenchido caso seja necessria alguma informao extra sobre o teste. Anlise de resultados a fase seguinte nessa metodologia. Nela, os resultados obtidos so analisados e elaborado um relatrio reportando os resultados dos testes, contendo as seguintes sees: cenrios dos testes, resultados e registros de defeitos abertos. A seo de cenrios apresenta os cenrios que foram executados para cada funcionalidade. Na seo de resultados so apresentados os resultados obtidos com a execuo dos testes atravs de grficos que informam: o status dos testes realizados, o percentual de testes que passaram por cenrio de testes e o percentual de testes que falharam por cenrio de teste. J na seo de registro de defeitos, todos os defeitos reportados pelos executores so listados, bem como o nmero, a gravidade e a descrio dos defeitos.

2.2.2 Procedimento de Teste de Funcionalidade e Estabilidade

O Procedimento de Testes de Funcionalidade e Estabilidade [14] foi desenvolvido por James Bach e intitulado General Functionality and Stability Test Procedure. Uma vez que esse Procedimento apresenta tcnicas, processo associado ao mtodo e linguagem associada ao mtodo, este trabalho de graduao o considera como sendo, por definio [11] , uma metodologia. Esse Procedimento de Testes de Funcionalidade e Estabilidade utilizado pela Microsoft para efeito de certificao de compatibilidade de aplicaes com o sistema operacional Windows 2000 [14] . Ele consiste de tarefas especficas, objetivos e entregas que fazem dele um processo sistemtico. Esse conjunto de tarefas interpretado neste trabalho de graduao como sendo o processo associado metodologia, de acordo com o que foi apresentado na seo 1.1. As tarefas especficas so: identificar o propsito do produto, identificar funes, identificar reas de potencial instabilidade, testar cada funo e registrar problemas, e, por fim, projetar e registrar um teste de verificao consistente. Essas tarefas no so seqenciais, de forma que elas sero executadas concorrentemente at que todas sejam finalizadas. As entregas a serem feitas aps a realizao das tarefas so: uma declarao do propsito do produto, um resumo das funes, uma lista de potenciais instabilidades e dados desafi16

adores (dados cujo uso possa provocar instabilidade no produto testado), falhas do produto e anotaes, e um teste de verificao de consistncia [14] . A Figura 2.3 a seguir ilustra essas tarefas e entregas.

Figura 2.3 Tarefas e entregas do Procedimento de Teste de Funcionalidade e Estabilidade

O Procedimento finalizado uma vez que: cada tarefa tiver sido completada, cada dvida ou assunto a ser tratado (problema) tiver sido resolvido ou aceito pelo gerente de teste, toda tarefa tiver sido aceita pelo gerente de teste, e o testador conhecer o suficiente sobre o produto para determinar se ele deveria ou no receber certificao de acordo com os critrios de funcionalidade e estabilidade [14] . Esse Procedimento suportado por tcnicas, embora o termo tcnicas de teste no tenha sido explicitado no mesmo. Por isso, ele foi analisado neste trabalho de graduao e as tcnicas foram sendo identificadas de acordo com as definies e classificaes de tcnicas de testes apresentadas na seo 1.1.1. Foram identificadas duas tcnicas de testes nesta metodologia: teste funcional e consistncia heurstica. Essa identificao foi inferida aps estudar o background e conceitos envolvidos no Procedimento de Teste de Funcionalidade e Estabilidade, os quais so apresentados a seguir. O background e conceitos envolvidos no Procedimento consistem de: definio de funes, forma de identificar tais funes no produto a ser testado, definio da cobertura de testes exigida e critrios de sucesso e de falha quando se est testando a funcionalidade e a estabilidade do produto. Os detalhes so descritos a seguir.

17

O Procedimento organizado atravs de funes. O testador identifica as funes do produto e as classifica em primrias e contribuintes [14] . A prioridade testar o mximo de funes primrias possveis. Uma funo considerada primria se ela puder ser associada ao propsito do produto, e se ela for essencial para esse propsito. Uma funo classificada como contribuinte no caso de ela no ser primria e contribuir para a utilidade do produto [14] . O primeiro ponto chave [14] para determinar se uma funo primria conhecer o propsito do produto, o que requer que haja uma fonte autorizada de informao suficiente da qual se possa deduzir ou inferir esse propsito. O segundo ponto chave saber que a funo essencial, o que depende de conhecimento sobre o usurio, de como a funo trabalha e como outras funes do produto trabalham. A cobertura de teste requerida nesse Procedimento [14] : testar todas as funes que possam ser testadas de forma racional dentro do intervalo de tempo disponvel, testar um conjunto interessante de funes contribuintes (com as quais provavelmente o testador ir se deparar ao testar funes primrias) e testar reas selecionadas de potencial instabilidade. Com relao ao teste de funes primrias, o gerente de teste deve ser informado caso no seja possvel testar alguma funo primria, por falta de tempo ou habilidade para testar [14] . Com relao s reas de instabilidade, que podem ser funes ou conjunto de funes, so escolhidas, em geral, de cinco a dez reas do produto para serem testadas com dados que provavelmente provocaro instabilidade no produto.
O Procedimento [14] define critrios para avaliao do produto no que diz respeito s funcionalidades e estabilidade do mesmo, como apresentado na Figura 2.4 a seguir. Definio Critrio de Sucesso 1. Cada funo primria testada opera de maneira aparentemente consistente com o seu propsito, sem levar em considerao a corretude das sadas da funo 2. Qualquer comportamento incorreto que observado no produto no prejudica seriaCritrio de Falha 1. Pelo menos uma dessas funes parece incapaz de operar de maneira consistente com o propsito 2. O produto opera incorretamente de uma maneira que prejudica seriamente o seu uso 18

Funcionalidade Habilidade do produto de funcionar.

mente o funcionamento do produto para uso normal 3. O produto no atrapalha o funcionamento do Windows 4. O produto no trava, no tem que ser reiniciado e no provoca perda de dados

normal 1. O produto atrapalha o funcionamento do Windows 2. O produto travar, ter que ser reiniciado ou provoca perda de dados

Estabilidade Habilidade do produto de continuar funcionando, ao longo do tempo e sobre a sua escala de utilizao, sem falhar ou causar falha.

3. Pelo menos uma funo pri5. Nenhuma funo primria se mria se torne inopervel dutorna inopervel durante o teste rante o teste

Figura 2.4 Definies e Critrios de Avaliao de Funcionalidade e Estabilidade, Fonte: [14]

O padro de funcionalidade criado para ser o padro mais exigente que possa ser racionalmente verificado por testadores, independentemente de terem familiaridade com o produto e de terem apenas alguns dias para completar o trabalho [14] . A palavra aparentemente, mencionada no primeiro critrio de sucesso de funcionalidade na Figura 2.4, significa aparente para um testador com habilidades de computao ordinrias. O testador no ser necessariamente capaz de dizer que o programa est funcionando corretamente, mas se ele for capaz de dizer que o programa no est se comportando corretamente de uma maneira que seriamente danifica o produto, o produto falha no teste (certificao). Para saber se o produto est seriamente danificado para uso normal, preciso ter noo de como o usurio normal e o que o uso normal [14] . Em muitos casos, o usurio normal pode ser uma pessoa com habilidades de computao bsicas. Em alguns casos, entretanto, o usurio normal ser uma pessoa com atributos, habilidades, ou expectativas que so, de alguma forma, especializadas. Talvez seja preciso, portanto, estudar o domnio do produto ou consultar o vendedor a fim de pensar em um caso em que o produto deva falhar. A fim de executar o teste de estabilidade, ser preciso identificar e resumir os tipos de dados bsicos que podem ser processados pelo produto [14] . Quando as reas de potencial instabilidade forem testadas, ser preciso utilizar esse conhecimento para projetar testes que utilizem entradas desafiadoras. De acordo com o que foi apresentado at agora, este trabalho de graduao realiza algumas inferncias como resultado da anlise desta metodologia que est sendo apresentada nesta subseo. Primeiro, inferido que o Procedimento de Funcionalidade e Estabilidade utiliza a tcnica de teste funcional (subseo 1.1.1) porque ele baseado em funes e tem como objetivo identificar e testar 19

as funes do produto para verificar se as mesmas esto funcionando. inferida tambm a utilizao da tcnica de consistncia heurstica (subseo 1.1.1) porque esse Procedimento considera critrios de sucesso e de falha de funcionalidade e estabilidade do produto, verificando consistncia de acordo com propsito, consistncia com expectativas do usurio e consistncia dentro do produto. Baseando-se nos conceitos e background apresentados, as tarefas do Procedimento so executadas. Para isso, necessrio conhecer detalhes dessas tarefas. A documentao de cada tarefa descrita por uma planilha que contm os seguintes elementos: descrio da tarefa, heursticas, resultados, critrio de sada e perguntas freqentes (FAQs). A descrio da tarefa uma descrio concisa de o que o testador tem que fazer. Heursticas so uma ou mais listas de idias que ajudam o testador a decidir o que fazer e servem para provocar ou focar em um raciocnio. Elas podem ser utilizadas de forma que cada idia seja brevemente lida e considerar as implicaes de tal idia no produto que est sendo testado. No obrigatrio o testador utilizar as heursticas no caso em que nenhuma das idias se aplica. Resultados uma lista de entregas que devem ser feitas uma vez que a tarefa seja concluda, como resultados dessa tarefa. Critrios de sada uma lista de coisas que devem ser verdadeiras para que a tarefa possa ser considerada como concluda, e o testador deve estar preparado para defender a veracidade dos elementos dessa lista. Alguns dos elementos da lista iro requerer algum julgamento subjetivo, mas nenhum deles totalmente subjetivo. As perguntas freqentes uma lista de questes geralmente indagadas por testadores quando se deparam com uma tarefa do procedimento pela primeira vez. A seguir, as descries das tarefas do procedimento em questo so apresentadas com mais detalhes. A tarefa de identificar o propsito do produto consiste em: 1. Revisar o produto e determinar qual servio fundamental ele deve prover. Na medida do possvel, definir o pblico para o produto. 2. Escrever (ou editar) um pargrafo que explica sucintamente a finalidade do produto e o pblico destinado. A tarefa de identificar funes do produto consiste em: 1. Navegar pelo produto e descobrir o que ele faz. 2. Fazer um resumo de todas as funes principais. 3. Registrar funes contribuintes que so interessantes ou relacionadas a funes primrias. 20

4. Encaminhar quaisquer funes que o testador no sabe como classificar ou que incapaz de testar para o Gerente de Teste. A tarefa de identificar reas de potencial instabilidade do produto consiste em: 1. medida que o produto explorado, atentar para funes que parecem mais provveis do que a maioria de violar os padres de estabilidade. 2. Selecionar de cinco a dez funes ou grupos de funes para realizar teste de instabilidade. Voc pode selecionar funes contribuintes, caso elas paream ter grandes chances de falhar, mas instabilidade em funes primrias mais importante. 3. Determinar o que poderia ser feito com as funes que poderia potencialmente desestabilizlas. Pensar em grandes e complexas, ou desafiadoras entradas. 4. Listar as reas de instabilidade selecionadas, juntamente com o tipo de dados ou estratgias que sero utilizados para testar essas reas. A tarefa de testar cada funo e registrar problemas encontrados no produto consiste em: 1. Testar todas as funes primrias possveis dentro do intervalo de tempo disponvel. 2. Testar todas as reas de potencial instabilidade identificadas. 3. Testar um conjunto interessante de funes contribuintes. 4. Registrar qualquer falha encontrada. 5. Registrar quaisquer notas sobre comportamentos encontrados do produto. Notas so comentrios sobre comportamentos preocupantes exibidos pelo produto, mas que no so falhas. Por fim, a tarefa de projetar e registrar um teste de verificao de consistncia tem por objetivo registrar um procedimento para exercitar as funes primrias mais importantes do produto para garantir que o produto se comporta consistentemente em outras plataformas e configuraes do Windows.

2.2.3 Testes Exploratrios: a prxima gerao

Essa metodologia apresenta tcnicas de testes exploratrios pesquisadas e desenvolvidas pelo profissional da Microsoft, David G. Elizondo, apresentada no Starwest 2008, em seu artigo Testes Exploratrios: a prxima gerao (Exploratory Testing: The Next Generation) [5] . Esse artigo descreve 21

novas abordagens para testes exploratrios que so suportadas por automao, bem como informaes que os testadores precisam para explorar; explica tambm como levantar informaes, como usar essas informaes para encontrar mais bugs de maneira mais eficaz e demonstra uma metodologia exploratria rpida e direta de encontrar bugs de forma no-acidental [17] . Segundo Elizondo [5] , o conceito de testes exploratrios compe-se de quatro partes: Freestyle testing, Recorded testing, Guided testing e Assisted testing. Freestyle testing definido como sendo um teste ad-hoc, que pode ser executado por qualquer pessoa que dispe de tempo e energia para testar o produto sem conhecer o cdigo da aplicao (teste de caixa preta) ou ter um planejamento ou uma documentao para consultar ao testar o software [5] . Recorded testing apresentado como sendo um freestyle testing, com a diferena de que so gravados vdeos de como a aplicao se comporta ao ser testada [5] . Tais vdeos proporcionam vantagens interessantes em relao ao freestyles testing. Por exemplo, o vdeo gravado pode ser utilizado para elaborao de novos cenrios de testes, criao de diagramas que podem ser utilizados para identificar novos caminhos de cdigos a serem testados, ou at para ser usado como evidncia de que o bug existe, de forma que o desenvolvedor analisar o cenrio exato, com os passos que o testador executou para encontrar o bug. Assisted testing o que Elizondo [5] chama de o futuro do teste. Em diferentes tcnicas, o testador interage com a aplicao, analisa a aplicao, aprende com ela, e segue em sua busca por novos bugs. Isso parece um processo que pode ser automatizado. Se a histria se repete todo o tempo, e pesquisas provam que desenvolvedores cometem sempre os mesmos erros, ento ferramentas, que vo ajudar o testador a encontrar bugs que so sempre criados em aplicaes de todos os tipos, podem ser criadas. Imagine um testador navegando por uma aplicao que contm vrias caixas de texto que aceitam diferentes tipos de dados. Um exemplo de assisted testing pode ser uma ferramenta que, em tempo real, detecta o tipo de dado suportado pela caixa de texto (e os limites que ela suporta) e, baseado nisso, sugere dados com os quais se pode testar essa aplicao. Isso ir mostrar que uma simples caixa de texto apresenta um nmero infinito de entradas (ou casos de testes) possveis. Mas sabe-se tambm que existe uma teoria por trs de testar com certas entradas. Se isso for automatizado, dado aos testadores o poder de exercitar cdigo baseando-se na histria aprendida por testadores do mundo inteiro. Guided Testing, por sua vez, definido como sendo um tipo de teste que foca em uma estratgia para encontrar bugs difceis de serem descobertos de maneira ad hoc, e onde est centrada a 22

idia da metodologia [5] . Guided Testing possui trs componentes que so utilizados para desenvolver a melhor estratgia (conceito de estratgia definido na subseo 1.1.1) a ser utilizada: experincia com teste, experincia com projeto e documentao. Experincia com testes a habilidade adquirida pelo profissional, proveniente de conhecimento obtido durante o perodo de tempo dedicado prtica de testar aplicaes. Quanto mais novos softwares um profissional testa, mais idias ele tem de como e de o que testar. O testador, segundo [5] , capaz de acelerar seu processo de aquisio da experincia identificando e utilizando as tcnicas certas. Essas tcnicas so apresentadas separadamente em dois grupos, baseando-se no livro How to Break Software, de James Whittaker: tcnicas baseadas em entradas e tcnicas baseadas em sadas. Experincia com projeto o conhecimento documentado por profissionais enquanto trabalham em um projeto, como, por exemplo, bugs j encontrados e informaes sobre cdigo fonte. Essa experincia tambm inclui relacionamentos entre os profissionais, pois, quanto mais os testadores interagem com os desenvolvedores da aplicao testada, mais eles descobrem os erros que os desenvolvedores costumam cometer ao programar. Esses conhecimentos tornam-se, portanto, histricos que podem ser utilizados para fazer regresso e encontrar bugs em novos componentes. Documentao refere-se a documentos utilizados durante o ciclo de desenvolvimento do software, tais como o de arquitetura e projeto e o cdigo da aplicao. Isso ajuda a guiar o testador porque oferece informaes ricas de como o software ir trabalhar, se interage com outras aplicaes, entre outras que auxiliam na visualizao de cenrios de testes interessantes. Utilizar documentao para definir a estratgia do teste significa conhecer os detalhes do software, como, por exemplo, arquitetura, projeto e cdigo da aplicao. Existem duas tcnicas que podem ser utilizadas para descobrir bugs utilizando-se o cdigo da aplicao: code churning e code coverage. Code churning consiste em partes do cdigo que sofreram modificaes, sejam elas linhas de cdigo adicionadas, deletadas ou modificadas de uma verso do cdigo fonte para outra. A tcnica consiste em testar essas partes de cdigo, as quais provavelmente apresentaro defeitos. Code coverage a medida do grau de cdigo fonte que est sendo testado. O interessante de saber essa informao que estatsticas mostram quais partes do cdigo dead code, quais partes ainda no foram testadas e que no esto sendo cobertas, por exemplo, por testes automticos e, portanto, devem ser exercitadas atravs de testes manuais.

23

A combinao dessas informaes apresentadas nessa metodologia feita pelo testador, de acordo com sua necessidade, para criar uma estratgia de teste e atacar o software que se deseja testar.

2.2.4 Gerenciamento de Teste Exploratrio Baseado em Sesso

Testes exploratrios so utilizados para se encontrar bugs mais rapidamente e de forma otimizada e, para isso, o planejamento de testes precisa ser continuamente reajustado para que se possa focar nas reas de risco do produto mais promissoras [18] . Isso inclui tambm minimizar o tempo disponvel para documentao, o que causa problemas quanto a reportar o que foi feito durante a explorao do produto. Entretanto, preciso conhecer essas informaes para que se saiba o que foi testado, o que foi encontrado e quais so as prioridades para os prximos testes. Muitas vezes os testadores no conseguem se lembrar e expressar com detalhes essas informaes, e tambm no documentam o que fazem em detalhes para no perder a flexibilidade de testar o produto de forma exploratria. Para que os testadores pudessem reportar e organizar o trabalho sem obstruir a flexibilidade e a capacidade de fazer descobertas importantes por acaso (que o que faz um teste exploratrio til), Jonathan Bach desenvolveu um mtodo suportado por uma ferramenta, chamado de Gerenciamento de Teste Baseado em Sesso [18] . A primeira coisa que Jonathan Bach percebeu quando estava tentando reinventar o gerenciamento de teste exploratrio foi que testadores fazem muitas coisas durante o dia alm de testar. Para monitorar testes, seria preciso encontrar uma forma de distinguir teste de qualquer outra coisa. Foi quando nasceram as sesses. Sesso, no caso, seria a unidade bsica do trabalho de teste, um bloco ininterrupto, revisvel e objetivo de um esforo de teste. Ser objetivo significa que cada sesso associada a uma misso o que testado ou quais problemas esto sendo procurados. Ininterrupto significa ausncia de emails, reunies, conversas ou ligaes telefnicas. Revisvel significa que um relatrio, chamado de planilha de sesso, produzido e pode ser examinado por uma terceira parte, como o gerente de testes, e prov informaes sobre o que aconteceu. Cada sesso dura mais ou menos 90 minutos. O tempo no marcado rigorosamente porque um bom teste mais importante do que o tempo que foi gasto para se testar. Se uma sesso dura perto de 45 minutos, ela chamada de sesso curta. Se ela demorar mais que du24

as horas, chamada de sesso longa. Por causa de reunies, emails, e outras atividades importantes, esperado que cada testador realize no mais que trs sesses em um dia normal. O que especificamente acontece em cada sesso depende do testador e da misso da sesso. Por exemplo, o testador pode ser alocado para analisar uma funo, ou procurar um problema particular, ou verificar um conjunto de bugs consertados. Cada sesso interrogada. Para novos testadores, o interrogatrio acontece o mais cedo possvel depois que a sesso termina. medida que os testadores vo ganhando experincia e credibilidade no processo, essas reunies demoram menos tempo, e possvel at cobrir vrias sesses de uma vez s. O objetivo principal do lder de teste entender e aceitar o relatrio da sesso. Outro objetivo prover feedback e treinamento ao testador. Aps desenvolver um entendimento estrutural atravs dos interrogatrios de o quanto pode ser feito em uma sesso de teste, e atravs do rastreamento de quantas sesses so realmente realizadas em um determinado perodo de tempo, adquirida a habilidade de estimar a quantidade de trabalho envolvido em um ciclo de teste e prever quanto tempo o teste vai durar mesmo sem o trabalho ter sido planejado em detalhes. Teste exploratrio pode parecer uma tarefa grande e complexa, mas na verdade um aglomerado de sub-tarefas que vo aparecendo e desaparecendo na medida em que elas so realizadas. preciso saber que tarefas sero executadas em uma sesso sem que seja feito um relatrio muito cheio de informaes, porque coletar dados de testes de forma muito detalhada consome muita energia que deveria ser utilizada na realizao dos testes. Para saber sobre as tarefas realizadas no teste, exigido que os testadores reportem essas tarefas de forma bem geral. As sesses de teste so divididas em trs tipos de tarefas: design e execuo de testes, investigao e reportagem de bug, e setup da sesso. Elas so chamadas de mtricas TBS (Task Breakdown). Depois, exigido que os testadores estimem uma proporo relativa de tempo que eles passam em cada tarefa. Design e execuo de teste significa navegar pelo produto e procurar problemas. Investigao e reportagem de bug o que acontece quando o testador se depara com um comportamento que parece ser incorreto. Setup da sesso qualquer outra coisa que os testadores fazem para que as duas primeiras

25

tarefas sejam realizadas, incluindo tarefas como configurao de equipamento, localizao de materiais, leitura de manuais, ou escrita de relatrio da sesso. exigido tambm que os testadores reportem a poro do tempo de teste que eles passaram nas misses associadas s sesses, e a poro do tempo de teste que eles passaram em oportunidades, que qualquer teste que no se adqe misso da sesso. Uma vez que se est sendo realizado teste exploratrio, preciso lembrar e incentivar testadores a divergir um pouco da misso caso eles se depararem com um problema que no faz parte da misso, mas que parea importante. Alm das mtricas TBS, existem mais trs importantes partes da planilha de sesso: bugs, issues e notas. Bugs so preocupaes sobre a qualidade do produto. Issues so questes ou problemas relacionados ao processo de teste ou ao projeto de forma geral. Notas so registros de qualquer outra coisa, como, por exemplo, idias para casos de teste, listas de funes, ou qualquer coisa relacionada ao teste que ocorre na sesso. A sesso inteira consiste das seguintes sees: misso da sesso (incluindo uma declarao da misso e reas a serem testadas), nome do testador, data e hora de incio, mtricas TBS (Task Breakdown), arquivos de dados, notas do teste, issues e bugs. A Figura 2.5 a seguir apresenta um exemplo de uma sesso:
____________________________________________________________________________________ ____________________________________________________________________________________ __________________ MISSO ----------------------------------------------Analisar a funcionalidade Mapmaker do menu View e apresentar um relatrio sobre as reas de risco potencial. #REAS OS | Windows 2000 Menu | View Estratgia | Teste Funcional Estratgia | Anlise Funcional START ----------------------------------------------5/30/00 03:20 pm TESTADOR ----------------------------------------------Jonathan Bach

26

TASK BREAKDOWN ----------------------------------------------5 #DURAO curta # DESIGN E EXECUO DE TESTE 65 # INVESTIGAO E REPORTAGEM DE BUG 25 #SETUP DA SESSO 20 #MISSO VS. OPORTUNIDADE 100/0 ARQUIVOS DE DADOS ----------------------------------------------#N/A NOTAS DE TESTE ----------------------------------------------Eu cliquei em cada item do menu abaixo, mas foquei mais no comportamento do zoom com vrias combinaes de elementos do mapa exibidos. View: Tela de Bem-Vindo Navegador Mapa de Localizao Legenda Elementos do Mapa Nveis de Highway Nveis de rua Diagrama de Aeroportos Zoom In Zoom Out Nvel do Zoom (Nveis 1-14) Previous View Riscos: - Exibio incorreta de um elemento do mapa. - Exibio incorreta devido a interrupo quando a tela est sendo pintada novamente. - CD pode estar ilegvel. - Verso antiga do CD pode estar usada. - Alguma funo do produto pode no funcionar em um certo nvel de zoom. 6 BUGS ----------------------------------------------#BUG 1321 Ampliar faz voc colocar o CD 2 quando voc chega a um certo nvel de granularidade (nvel de nome de rua) - mesmo que o CD 2 j se encontre no driver. #BUG 1331 Ampliar rapidamente resulta em os nomes das ruas no serem renderizados. #BUG <no_anotado>

27

Instabilidade com velocidade do CD baixa ou baixo vdeo RAM. Ainda est sendo investigado. ISSUES ----------------------------------------------#ISSUE 1 Como saber quais detalhes devem aparecer nos nveis de zoom? #ISSUE 2 No tenho certeza de como o mapa de localizao deve funcionar. Como os usurios devem interagir com ele? ____________________________________________________________________________________ ____________________________________________________________________________________

Figura 2.5 Exemplo de Planilha de Sesso, Fonte: [18]

As tabelas de breakdown (Task Breakdown), listadas na Figura 2.5, contm os nmeros de breakdown das tarefas para cada planilha de sesso. Essas tabelas so normalizadas de forma que os dados de todas as planilhas de sesses possam ser combinados. As mtricas indicam qual parte do trabalho foi gasto com a misso em cada uma das tarefas TBS, qual parte de sesses foram gastas com oportunidades, e quanto tempo (em unidades de sesso) foi gasto em trabalho no-relacionado com sesso. A ltima mtrica obtida assumindo que um dia de trabalho normal inclui 5.333 sesses normais se testadores no fizerem nada alm de sesses. Monitorando quem estava em servio na equipe de teste, e em quais dias, possvel saber o nmero mximo terico de sesses que podem ser executadas em um dado perodo de tempo do calendrio. subtrado o nmero de sesses que ocorrem atualmente, e dada a quantidade total de trabalho que no relacionado a sesses. Esse clculo no preciso, mas ele preciso o suficiente para o propsito de ter uma idia de quanto teste efetivamente realizado durante o dia. Essas mtricas ajudam a estimar e prever melhor do que antes coisas como a curva de aprendizagem dos testadores, os efeitos de adicionar um novo testador a um time estabelecido, e o impacto na produtividade de testar um produto mais testvel versus um menos testvel. Por exemplo, digamos que uma equipe de teste esteja realizando trs sesses de testes por dia, em mdia, e um novo testador acrescentado equipe. Uma vez que testadores sero interrompidos pela necessidade de proverem treinamento, eles faro menos (ou menores) sesses do que antes, ou eles gastariam mais tempo em teste de oportunidade (uma vez que dar assistncia a um testador em outra sesso uma forma de trabalho de testes norelacionado misso). No incio, interrogar o novo testador demora mais tempo. Os efeitos aparecero nas mtricas. Outra coisa simples que pode ser feita com mtricas organizar em grficos todas as sesses de teste ao longo do tempo at a data de entrega.
28

Embora essas mtricas possam proporcionar uma melhor visibilidade e percepo sobre o que estamos fazendo em nosso processo de testes, importante perceber que o processo de teste baseado em sesso e as mtricas associadas a ele poderiam ser facilmente distorcidas por um gerente de teste confuso ou tendencioso, ou p um testador que no relate o teste da forma que ele realmente foi feito. O uso eficaz de mtricas e planilhas de sesso exige a permanente conscientizao sobre o potencial para esses problemas.

2.2.5 Consideraes
Esta seo apresentou metodologias utilizadas para dar suporte prtica de testes exploratrios. Essas metodologias sero comparadas e analisadas no prximo captulo para que essa comparao seja utilizada como base para as modificaes a serem feitas na metodologia para a qual a ferramenta SMTE, proposta neste trabalho de graduao, dar suporte. A seguir, apresentado o estado da arte de ferramentas de apoio a testes exploratrios.

2.3 Ferramentas de Apoio a Testes Exploratrios

2.3.1 Session-Based Test Management Scan Tool
Session-Based Test Management Scan Tool uma ferramenta que d suporte Metodologia de Gerenciamento de Testes Baseado em Sesso [18] . Um importante ingrediente nessa abordagem de gerenciamento de teste baseado em sesso o formato da planilha da sesso: cada relatrio provido de um formato de texto em tag, e armazenado em um repositrio com todos os outros relatrios. Esses relatrios so posteriormente escaneados por uma ferramenta que foi desenvolvida para quebr-los em seus elementos bsicos, normalizlos e resumi-los em tabelas e mtricas. Usando essas mtricas, possvel monitorar de perto o progresso de um teste, e fazer relatrios instantneos para a gerncia, sem ter que requisitar uma reunio equipe. De fato, colocando essas planilhas, tabelas e mtricas de sesses online, os clientes do projeto podem at ter acesso instantneo s informaes que eles desejam. Por exemplo, o grfico da Figura 2.6 a seguir mostra que os testadores esto usando apenas um tero do tempo deles realmente testando, o que corresponde, em mdia, a duas sesses por dia, em vez de trs. Uma vez que o grfico representa dois meses de trabalho, ele sugere que exista algum tipo de obstculo que impede os testadores de trabalharem usando capacidade total.

29

Figura 2.6 Grfico das Atividades do Testador, Fonte: [18]

A Figura 2.7 a seguir permite que se tenha uma idia de quantas sesses se espera realizar durante o tempo que resta no projeto. Os dados da semana mais recente sugerem que a taxa de teste est acelerando.

30

Figura 2.7 Quantidade de Sesses por Intervalo de Tempo, Fonte: [18]

Descrio do Suporte Automatizado ao Mtodo de Gerenciamento de Testes Baseado em Sesso As planilhas de sesses so escaneadas por uma ferramenta desenvolvida em Perl. A ferramenta executa oitenta verificaes de sintaxe e consistncia. Por exemplo, se um arquivo de dados referenciado em uma planilha de sesso, a ferramenta garante que o arquivo foi armazenado em um diretrio de arquivos apropriado. A sesso da misso na planilha de sesso apresentada na Figura 2.5 permite a incluso de keyword de rea de teste especfica (por exemplo, a keyword Menu | View) de forma que cada sesso pode ser associada a elementos de uma matriz de teste utilizada na gerao de tabelas descritas no prximo pargrafo. Os valores vlidos dessas keywords so armazenados em um arquivo separado a fim de reduzir erros de digitao, pois em vez de as keywords serem digitadas ou criadas no momento em que so digitadas, elas j estaro pr-definidas nos arquivos e s precisaro ser utilizadas. A sada do scanner um conjunto de tabelas de texto que ajuda a contar a estria do projeto de teste. Cada tabela de texto est em um formato delimitado apropriado para importao para o Excel para formatao e anlise. O scanner produz as seguintes tabelas: Notas de teste: contm sesses de notas de teste, por ID da sesso. Bugs: registro de bugs, por ID do bug e ID da sesso. Issues: registro de issue, por ID da issue e ID da sesso. Missso: declarao da misso e keywords das reas, por ID da sesso. Arquivos de dados: Nomes de arquivos de dados, por ID da sesso. Breakdowns da sesso: Mtricas da sesso, por ID da seso Breakdowns da cobertura: Mtricas da sesso, por keyword da rea. Breakdowns do testador: Mtricas da sesso, por nome do testador. Breakdowns do dia: Mtricas da sesso, por dia.
31

Sesses de ToDo: Planilhas de sesses incompletas. A tabela de sesses de ToDo um mtodo utilizado para agilizar o trabalho dos testadores. Uma sesso de ToDo criada por um testador e contm apenas a misso do teste, estando todas as outras sesses em branco. Quando os testadores terminam uma sesso, eles olham a pasta de planilhas, escolhem uma planilha de ToDo e executam a sesso com aquela misso. A tabela de ToDo gerada pela ferramenta uma lista de planilhas de ToDo que esto atualmente na pasta de planilhas de sesso. Essa lista chama de hopper. A ferramenta possui tambm uma funcionalidade de busca, que permite rapidamente localizar, apresentar na tela e imprimir qualquer planilha de sesso que possui uma string especfica. Essa ferramenta importante porque o cliente pode pedir, a qualquer momento, para ver os dados por traz das mtricas e o resumo dos relatrios.

2.3.2 Exploratory Test Assistant

Exploratory Test Assistent uma ferramenta utilizada para dar suporte execuo de testes exploratrios de maneira que o testador possa realizar anotaes enquanto testa [18] . As anotaes podem ser registradas em um arquivo de texto e no quadro de edio (clipboard). Aps esse registro, a ferramenta formata as anotaes e gera um relatrio final do teste, de acordo com os templates definidos pelo usurio. A ferramenta no fica visvel durante todo o tempo em que o teste est sendo realizado, pois so utilizados atalhos de teclado que fazem com que ela seja apresentada na tela na medida em que isso se fizer necessrio. Aps a realizao das anotaes, as mesmas so salvas e utilizado mais um atalho para que a ferramenta no permanea visvel. Por ainda ser um prottipo, a Exploratory Test Assistent ainda possui muitos bugs, problemas de usabilidade, poucos atalhos de teclado, e muitas funcionalidades ainda permanecem no-implementadas. O criador disponibiliza a ferramenta para quem quiser us-la e/ou implementar mais funcionalidades. Ela possui templates para dar suporte aos relatrios de teste baseados em sesso de Jonathan Bach [18] . Uma lista do tipo drop down mostra o template que est sendo utilizado em um determinado momento (No-formatado, Bug, Nota, Risco, Task Breakdown, Issue, Misso).
32

2.3.3 Test Explorer Controller

Test Explorer Controller uma sute de quatro ferramentas de teste de software: TestExplorer (utilizada para criar e executar testes), Administrator (cria e gerencia projetos e usurios), Issue Manager (gerencia issues), e Analyzer (gera relatrios e grficos) [16] . Test Explorer Controller tambm d suporte Metodologia de Gerenciamento de Testes Baseado em Sesso [18] . A aplicao TestExplorer permite que o usurio crie e execute testes manuais para as aplicaes que estiverem sendo por eles testada atravs de teste exploratrio de duas formas: com a ferramenta sendo completamente transparente, ou realizando gravao em um estilo interativo. Alm disso, os testes podem tambm ser escritos antecipadamente e depois executados. A aplicao Administrator permite que administradores de projetos controlem atividades de diferentes projetos, criem e deletem projetos, escrevam e designem misses, gerenciem os campos de usurio definidos e o contedo de todas as listas dropdown, e que gerenciem os usurios. Testes tambm podem ser deletados. A aplicao Issue Manager permite que os usurios gerenciem todas as issues do projeto, sejam elas criadas atravs dos testes ou de outra forma. Issues podem ser criadas, deletadas, monitoradas, gerenciadas e reportadas. A aplicao Analyzer permite que o usurio crie relatrios e grficos a partir das vrias mtricas coletadas automaticamente durante o teste e no processo de gerenciamento de issue.

33

Metodologia e Ferramenta Propostas para Testes Exploratrios

3.1 Introduo
Este captulo compara as metodologias apresentadas no captulo anterior e, com base nessa comparao, apresenta as modificaes propostas na metodologia para a qual a ferramenta proposta neste trabalho de graduao dar suporte. Alm disso, a ferramenta proposta neste trabalho de graduao tambm apresentada.

3.2 Estudo Comparativo das Metodologias

Todas as metodologias aqui apresentadas possuem como objetivo guiar o teste de produtos de software utilizando prticas de testes exploratrios e, para isso, as mesmas sugerem a utilizao de tcnicas de testes. Portanto, tcnicas e processos sero utilizados como critrios de comparao das metodologias. No entanto, a metodologia apresentada no artigo Testes Exploratrios: A prxima gerao [5] , na subseo 2.2.3, no apresenta de forma explcita um processo a ser seguido, e a metodologia de Gerenciamento de Teste Exploratrio Baseado em Sesso [18] , apresentada na subseo 2.2.4, no apresenta de forma explcita as tcnicas utilizadas. Assim, sero comparados os processos das trs metodologias apresentadas nas sesses 2.2.1, 2.2.2 e 2.2.4, e as tcnicas utilizadas pelas trs metodologias apresentadas nas sees 2.2.1, 2.2.2 e 2.2.3. Portanto, tcnicas e processos sero utilizados como critrios de comparao das metodologias.

3.2.1 Comparao entre os processos das Metodologias

O processo utilizado no Procedimento de Teste de Funcionalidade e Estabilidade consiste, como apresentado na subseo 2.2.2, na execuo das seguintes tarefas: identificar o propsito do produto, identificar funes, identificar reas de potencial instabilidade, testar cada funo e registrar problemas, e, por fim, projetar e registrar um teste de verificao consistente. A Metodologia para Testes Exploratrios, apresentada na subseo 2.2.1, consiste na realizao das seguintes fases: Planejamento, Elaborao de Cenrios, Execuo e Anlise de resultados. J a metodologia de Gerenciamento de Teste Exploratrio Baseado
34

em Sesso, apresentada na subseo 2.2.4, consiste das seguintes tarefas: design e execuo de testes, investigao e reportagem de bug, e setup da sesso. De acordo com a definio de cada fase e tarefa apresentadas nas subsees 2.2.1, 2.2.2 e 2.2.4, pode-se observar que existem relaes entre algumas delas. A tarefa de identificar funes e a de identificar reas de potencial instabilidade do produto est relacionada com a fase de planejamento, pois essas tarefas listam justamente o que ser testado, ou seja, o escopo dos testes. Na tarefa de design e execuo, em 2.2.4, realizado um estudo do produto, mas no so definidas especificamente que funes e reas de instabilidade devem ser identificadas. A tarefa de testar cada funo e registrar problemas est relacionada com a fase de execuo, em 2.2.1, e tambm com a tarefa de design e execuo, em 2.2.4, pois onde os testes so executados e as falhas encontradas so registradas. A diferena que, na tarefa descrita em 2.2.2, os testes so executados sem que sejam documentados projetos de teste ou cenrios de testes elaborados para essa execuo. Sabe-se apenas o que ser testado e os critrios de sucesso e falha do teste. J a fase de execuo seguida da de elaborao de cenrios, de forma que o testador j tem uma idia de como testar por causa do Guia de Cenrios de Testes. Existe documentao tambm na fase de design e execuo descrita em 2.2.4, na seo de descrio da misso do teste, bem como das reas testadas do produto. A Figura 3.1 a seguir apresenta uma visualizao da comparao entre os processos das metodologias.

Figura 3.1 Comparao entre processos das metodologias da subsees 2.2.2, 2.2.1 e 2.2.4

3.2.2 Comparao de Tcnicas utilizadas nas Metodologias

Aparentemente, em nenhuma das trs metodologias utiliza-se tcnicas de testes em comum, com exceo das de combinao de dados e de valores invlidos que so utilizadas
35

tanto pela metodologia apresentada em Testes Exploratrios: A prxima gerao, (subseo 2.2.3), como pela Metodologia para Testes Exploratrios (subseo 2.2.1). Durante a fase de execuo da Metodologia para Testes Exploratrios, sugerido que sejam testadas funcionalidades crticas, cenrios que j apresentaram erros e garantir aspectos vitais do sistema. A prtica de testar funcionalidades crticas e garantir aspectos vitais do sistema possui semelhana com o teste funcional que realizado na metodologia desenvolvida por Bach Procedimento de Teste de Funcionalidade e Estabilidade (subseo 2.2.2) uma vez que esse teste funcional consiste em testar funes primrias do sistema que, pela definio apresentada na subseo 2.2.2, podem ser interpretadas como aspectos vitais do sistema e funcionalidades crticas. J a sugesto de testar cenrios que j apresentaram erros assemelha-se questo de experincia com projeto apresentada na metodologia desenvolvida por Elizondo Testes Exploratrios: A prxima gerao (subseo 2.2.3) uma vez que sugerido que a estratgia de teste seja desenvolvida com base em conhecimentos documentados pelo profissional, como bugs j encontrados. A Figura 3.2 a seguir apresenta uma visualizao da comparao entre as tcnicas utilizadas nas metodologias.

Figura 3.2 Comparao entre tcnicas utilizadas nas metodologias da subsees 2.2.2, 2.2.3 e 2.2.1

3.2.3 Consideraes
Durante essa seo, foram comparadas metodologias que puderam contribuir para a anlise da Metodologia para Testes Exploratrios que est sendo utilizada nesse trabalho de
36

graduao. Para isso, foi necessrio analisar todas essas metodologias e comparar, na medida do possvel, seus aspectos. Como conseqncia desse estudo, foi aperfeioada a Metodologia para Testes Exploratrios de forma que as modificaes foram feitas em aspectos concretos de metodologias j existentes utilizadas para o mesmo propsito. Essas modificaes sero apresentadas na prxima seo.

3.3 Aperfeioamento da Metodologia

Com base nos conceitos e estado da arte apresentados neste trabalho de graduao, as fases da Metodologia para Testes Exploratrios [15] passaram a ser chamadas de atividades. Cada atividade da metodologia aperfeioada possui uma tarefa relacionada ( atividade), para a qual foram definidos explicitamente, de forma mais detalhada, os passos a serem executados a sua realizao. A fase de Elaborao de cenrios passou a ser a atividade de Design de Teste, uma vez que, alm da elaborao de cenrios, definida tambm a misso do teste. Durante a execuo de testes em geral, importante que pelo menos trs informaes sejam registradas: o que foi testado, como foi testado e o que foi encontrado, para que seja possvel identificar as prioridades para os prximos testes. Isto ser includo na nova metodologia apresentada neste trabalho e no apresentado na Metodologia para Testes Exploratrios [15] , apesar de o guia, mencionado em 2.2.1, ajudar nessa documentao, uma vez que apresenta possveis cenrios. Entretanto, esses cenrios so genricos e para se ter as trs informaes citadas anteriormente preciso que os registros sejam realizados em forma de features ou funcionalidades do produto que foram testadas. A seguir detalhada a nova verso da Metodologia para Testes Exploratrios.

3.3.1 Metodologia para Testes Exploratrios Modificada

A metodologia proposta neste trabalho uma agregao de um processo de testes e tcnicas de testes que do suporte a esse processo. O propsito dessa metodologia testar um produto de software utilizando-se prticas de testes exploratrios de forma estruturada. Essa metodologia consiste em um processo composto de quatro atividades: planejamento, design de testes, execuo e anlise. Essas atividades proporcionam a realizao de testes ex37

ploratrios de forma estruturada, uma vez que so definidas tarefas especficas, objetivos e entregas. Planejamento a primeira atividade a ser realizada para que sejam estabelecidos cronograma, alocao da equipe, ambiente, escopo de testes e a estratgia de testes a ser utilizada. As atividades de design e execuo so realizadas em paralelo, pelo fato de testes exploratrios serem, por definio, a realizao simultnea de design de testes e execuo. Em seguida, realizada a atividade de anlise para apurar os resultados dos testes e reportar mtricas. A Figura 3.3 a seguir apresenta as atividades da Metodologia para Testes Exploratrios aperfeioada e como elas se relacionam.

Figura 3.3 Diagrama de atividades da Metodologia para Testes Exploratrios

A atividade de Planejamento consiste na tarefa de elaborao de um plano de testes com base no plano de projeto do produto. Para realizar essa tarefa, necessrio seguir os passos:

38

- Estudar o produto: consiste em navegar pelo produto a fim de conhec-lo, identificar o propsito do produto, identificar funcionalidades, ou seja, o que o produto faz para atingir o seu propsito, e identificar quais dessas funcionalidades so crticas. - Definir escopo e estratgia: procurar registro de bugs anteriores, erros que programadores costumam cometer, usar o conhecimento obtido pelo estudo do produto (propsito e funcionalidades crticas) e a experincia com testes de outros softwares para selecionar o escopo do teste. Baseando-se nessas informaes, identificar as tcnicas a serem utilizadas para testar as funcionalidades selecionadas. Para reconhecer falhas, preciso que se utilize um oracle, que pode ser encontrado em documentos que descrevem o comportamento do produto, ou pode ser utilizada a experincia do testador. - Definir ambiente de teste: define o ambiente necessrio para a execuo dos testes. - Definir cronograma: define quanto tempo vai durar cada atividade do processo de teste. - Definir papis e responsabilidades: define quem vai executar quais atividades no processo de testes. A atividade de Design de Teste consiste na tarefa de projetar testes, em que so definidas misses e cenrios para a realizao do teste. Para realizar essa tarefa, necessrio seguir os passos: - Definir misso do teste: definir o que ser testado ou quais problemas esto sendo procurados. Descrever as funcionalidades que so testadas nessa misso. - Definir cenrios de testes: para definir cenrios de testes, pode-se utilizar o guia de cenrios ou pode-se elaborar novos cenrios de testes utilizando-se tcnicas sugeridas na definio da estratgia de testes. - Elaborar planilha de execuo de testes: utilizando-se o guia de testes, cria-se a planilha de execuo que uma instncia do guia. Caso novos cenrios sejam criados, eles devem ser includos na planilha.

39

A atividade de Execuo de Teste exercita e verifica funcionalidades do produto de acordo com a misso estabelecida e os cenrios selecionados ou criados. Para realizar essa tarefa, necessrio seguir os passos: - Executar cenrios da planilha: os cenrios da planilha de execuo so executados para atingir a misso de teste estabelecida, testando-se as funcionalidades envolvidas e comparando os comportamentos observados com os comportamentos que o produto deve apresentar, de acordo com oracles utilizados, como documentos encontrados, experincia do testador ou heursticas. - Reportar falhas ou issues: registrar falhas e issues encontradas durante os testes. Falhas so comportamentos no esperados do produto de acordo com o oracle utilizado para comparao com o comportamento esperado do produto. Issues so problemas que o testador acredita que possa ser uma falha, mas que no existe informao suficiente para comprovao de que o comportamento do produto no est correto. A atividade Anlise de Teste consiste na elaborao do relatrio de testes, informando cenrios executados por funcionalidade, resultados, e defeitos encontrados. Para realizar essa tarefa, necessrio seguir os passos: - Reportar cenrios por funcionalidade das misses dos testes: apresentar cenrios que foram executados para cada funcionalidade das misses dos testes - Reportar resultados dos testes: apresentar resultados dos testes atravs de porcentagens dos que passaram e falharam por cenrio de teste. - Relatar defeitos encontrados: apresentar defeitos que foram encontrados, informando a quantidade, gravidade e descrio.

3.4 Ferramenta Proposta

Esta seo apresenta a especificao da ferramenta SMTE para dar suporte Metodologia para Testes Exploratrios. So apresentadas as atividades da metodologia envolvidas na automao, bem como tarefas e passos que so executados pelo engenheiro de testes que

40

recebero suporte da ferramenta. Alm disso, a ferramenta descrita em termos de casos de uso, interfaces grficas com o usurio, e modelagem do banco de dados.

3.4.1 Identificao dos passos a serem automatizados

Para dar suporte Metodologia para Testes Exploratrios proposta neste trabalho de graduao, foi especificada a ferramenta SMTE, que objetiva automatizar e auxiliar passos de tarefas das seguintes atividades da Metodologia: Design, Execuo e Anlise de Teste. A Figura 3.4 apresenta os passos das tarefas das atividades aos quais a ferramenta SMTE d suporte. So eles: definir misso do teste, definir cenrios de testes, elaborar planilha de execuo de testes, reportar falhas ou issues, reportar cenrios por funcionalidade das misses dos
testes, reportar resultados dos testes e relatar defeitos encontrados. Atividade Tarefa Passos - Definir misso do teste Design de Teste Projetar Teste - Definir cenrios de testes - Elaborar planilha de execuo de testes Execuo de Teste Executar Testes - Reportar falhas ou issues - Reportar cenrios por funcionalidade das misses dos testes Anlise de Teste Elaborar relatrio de testes - Reportar resultados dos testes - Relatar defeitos encontrados
Figura 3.4 reas da Metodologia para Testes Exploratrios suportadas pela ferramenta SMTE

3.4.2 Descrio da ferramenta SMTE

O usurio da ferramenta SMTE o engenheiro de teste que, aps realizar a atividade Planejamento da metodologia, precisa iniciar a atividade de Design e Execuo de Teste e, em seguida, realizar a atividade de Anlise de Teste. Ao iniciar as atividades Design e Execuo de Testes, o engenheiro precisa descrever a primeira misso do teste, as funcionalidades relacionadas a essa misso, e cenrios apropriados para esse teste. Uma vez que a misso do teste, bem como cenrios e funcionalidades a serem testados j esto definidos, pode-se iniciar a execuo do teste, registrando os cenrios
41

que passaram e falharam, medida que o produto explorado. Caso o produto apresente alguma inconsistncia durante a execuo de um cenrio de teste, uma falha ou issue reportada, de forma que o engenheiro deve descrever a inconsistncia, classificar como falha ou issue e determinar a gravidade. Aps o cumprimento da misso de teste, uma nova misso definida, de acordo com a estratgia e o escopo do teste definido na atividade Planejamento. Uma vez que as atividades Design e Execuo de Testes estiverem concludas, a atividade Anlise de Teste iniciada. O engenheiro de teste deve elaborar um relatrio contendo o resultado dos testes, defeitos encontrados e os cenrios testados por funcionalidade das misses dos testes. Considerando-se essas necessidades do engenheiro de teste para realizar o seu trabalho durante a utilizao da metodologia proposta, foram analisados requisitos para ferramenta SMTE. Essa anlise resultou no diagrama de casos de uso apresentado na Figura 3.5. Foi identificada a necessidade de modelagem de onze casos de uso: definir misso, inserir, listar e remover funcionalidade, inserir, listar e remover cenrio, registrar resultado do teste, reportar falhas e issues, gerar planilha de execuo e gerar relatrio.

Figura 3.5 Diagrama de Casos de Uso

As telas da ferramenta ilustram como a realizao desses casos de uso concretizada. A Figura 3.6 ilustra a interface grfica inicial da ferramenta, exibindo o contedo da barra de

42

menu: definir misso, testar e registrar resultado, reportar falhas e issues, gerar planilha de resultados e gerar relatrio.

Figura 3.6 Menu da ferramenta SMTE

A interface grfica apresentada na Figura 3.7 ilustra como so realizados os seguintes casos de uso: definir misso, inserir, listar e remover funcionalidade, inserir, listar e remover cenrio. Para definir uma misso, basta descrever o que ser testado ou quais problemas esto sendo procurados no campo de texto indicado pelo label Misso:. As funcionalidades testadas nessa misso podem ser registradas uma por uma, digitando-se a descrio da funcionalidade no campo de texto indicado pelo label Funcionalidade: e, em seguida, clicandose no boto Inserir. O boto Remover deve ser utilizado apenas no caso de uma funcionalidade ter sido inserida incorretamente. De forma anloga, um cenrio cadastrado digitando-se a descrio do cenrio no campo de texto indicado pelo label Cenrio: e, em seguida, clicando-se no boto Inserir ao lado desse campo. Os cenrios inseridos podem ser os pr-definidos no Guia de Testes, bem como criados pelo engenheiro de teste, de acordo com o que for apropriado para cumprir a misso de teste. O boto Remover associado a cenrio serve para o mesmo propsito do boto Remover associado funcionalidade. A-

43

ps concluir a etapa de definio da misso de teste e dos cenrios a serem utilizados, importante salvar para que todos os dados sejam armazenados.

Figura 3.7 Definir misso

Uma vez que se sabe qual a misso do teste, as funcionalidades e os cenrios a serem testados, a execuo iniciada. A Figura 3.8 apresenta a interface grfica de testar e registrar resultado, ilustrando como realizado o caso de uso de registrar resultado do teste. Ao iniciar a execuo, o engenheiro de teste seleciona o cenrio que est testando e a funcionalidade associada, registrando o resultado que indica se o teste passou ou falhou, de acordo com o comportamento do produto testado.

44

Figura 3.8 Testar e registrar resultado

Na medida em que inconsistncias forem sendo descobertas durante a execuo dos testes, os cenrios que falharam (ou que o engenheiro acha que falharam, mesmo sem ter certeza) devem ser reportados e a inconsistncia deve ser descritas em detalhes. Alm disso, importante classificar a inconsistncia como falha ou issue, de acordo com o que foi definido na metodologia. A Figura 3.9 ilustra a interface grfica com a qual o usurio interage ao realizar esse caso de uso de reportar falhas e issues.

45

Figura 3.9 Reportar falhas e issues

Os casos de uso de gerar planilha de execuo e gerar relatrio so ilustrados na Figura 3.6, uma vez que o que o usurio interage com a interface apenas selecionando a opo de gerar planilha e gerar relatrio. Descrio do minimundo A ferramenta composta por quatro entidades: Misso: representa as misses de testes e possui uma propriedade: descrio. Cenrio: representa cenrios de testes e possui duas propriedades: descrio e resultado. Funcionalidade: representa funcionalidades do software que est sendo testado e possui uma propriedade: descrio. Inconsistncia: representa uma falha ou issue que foi encontrada durante o teste e possui trs propriedades: descrio, tipo (se uma falha ou se uma issue) e gravidade. As entidades relacionam-se da seguinte forma: Uma misso contm um ou mais cenrios. Um ou mais cenrios testam uma funcionalidade.
46

Um cenrio gera zero ou mais inconsistncias. Modelo ER

Figura 3.10 Modelo Entidade-Relacionamento da ferramenta SMTE

Esquema conceitual em notao de diagrama de classe UML

47

Figura 3.11 Esquema conceitual da ferramenta SMTE

Esquema do banco de dados relacional da ferramenta SMTE MISSO

ID_MISSO DESCRIO

|-chave primria-| CENRIO

ID_CENRIO DESCRIO RESULTADO ID_MISSO ID_FUNCIONALIDADE

|-chave primria-| INCONSISTNCIA

ID_INCONSISTNCIA DESCRIO

|--------------chave estrangeira -------------|

TIPO

ID_CENRIO

|----chave primria----| FUNCIONALIDADE

ID_FUNCIONALIDADE DESCRIO

|--chave estrangeira--|

RESULTADO

|-chave primria-|

48

Concluso e Trabalhos Futuros

Neste captulo, sero apresentados as consideraes finais, as principais contribuies e os possveis trabalhos futuros.

4.1 Consideraes Finais

Este trabalho de graduao abordou necessidades de testes de software para a obteno de um produto de qualidade e, para isso, props uma metodologia e uma ferramenta para serem utilizadas no caso de os testes realizados em um produto serem do tipo testes exploratrios. A fim de apresentar e definir a metodologia e a ferramenta propostas, foram introduzidos os conceitos bsicos para o entendimento da metodologia proposta, e foi apresentado o estado da arte tanto de metodologias como de ferramentas existentes para dar suporte realizao de testes exploratrios. Com base no estado da arte, a Metodologia para Testes Exploratrios foi aperfeioada, levando-se em considerao vrios aspectos das metodologias existentes. Alm disso, a ferramenta SMTE foi proposta neste trabalho, levando-se em considerao ferramentas desenvolvidas para dar suporte a testes exploratrios.

4.2 Contribuies
Este trabalho de graduao contribui com uma metodologia, disponvel em http://www.cin.ufpe.br/~tds2/mte, e uma ferramenta de suporte a realizao de testes exploratrios. A Metodologia para Testes Exploratrios proposta neste trabalho resultado de um estudo profundo de metodologias j existentes. Dessa forma, os aspectos das metodologias estudadas que so considerados de grande utilidade para serem inseridos na metodologia aperfeioada, devem contribuir para uma melhor forma de execuo de testes de forma exploratria. Alm disso, para que essa forma seja ainda mais eficiente, foi especificada a ferramenta SMTE, que d suporte utilizao dessa metodologia.
49

4.3 Trabalhos Futuros

Como trabalho futuro, sugerido que o desenvolvimento da ferramenta SMTE seja concludo e que se realize um estudo de caso para que a ferramenta seja aperfeioada, objetivando adequar cada vez mais essa ferramenta s necessidades de seus usurios, os engenheiros de testes.

50

Referncias
[1] Mller, Thomas, et al. Sobre o Quadro Internacional de Certificao de Teste de Software
(ISTQB). Site do Quadro Internacional de Certificao de Teste de Software (ISTQB). [Online] 2007. http://www.istqb.org/downloads/syllabi/SyllabusFoundation.pdf.

[2] Bach, James. Sobre a Empresa: Satisface, INC. Site da Satisface, INC. [Online] 16 de Abril de
2003. http://www.satisfice.com/articles/et-article.pdf.

[3] Bourque, P. e Dupuis, R. Guide to the Software Engineering Body of Knowledge (SWEBOK). Los Alamitos, CA, Estados Unidos da Amrica : s.n., 2004. [4] Santamaria, Marina Gil. Sobre o site de recursos on-line StickyMinds.com. StickyMinds.com.
[Online] 2007. http://www.stickyminds.com/getfile.asp?.

[5] Elizondo, David Gorena. Sobre site de recursos on-line StickyMinds.com. StickyMind.com.
[Online] 2 de Outubro de 2008. [Citado em: 20 de Maio de 2009.] https://www.stickyminds.com/sitewide.asp?ObjectId=14514&Function=DETAILBROWSE& ObjectType=CP&sqry=*Z(SM)*J(MIXED)*R(relevance)*K(simplesite)*F(exploratory+testing %3A+next+generation)*&sidx=0&sopp=10&sitewide.asp?sid=1&sqry=*Z(SM)*J(MIXED)*R( relevance)*K(si

[6] Viana, Virginia. Um Mtodo para Seleo de Testes de Regresso para Automao.
Dissertao de Mestrado pelo Centro de Informtica da UFPE. 2006.

[7] Graham, Doroty, et al. Foundations of Software Testing: ISTQB Certification. London : Thomson
Learning, 2007. ISBN.

[8] Bach, James. Sobre a Empresa: Satisface, INC. Site da Satisface, INC. [Online] 16 de Abril de
2003. http://www.satisfice.com/articles/et-article.pdf.

[9] Sobre a Empresa: Satisfice Inc. Site da Stisfice Inc. [Online] [Citado em: 23 de Maio de 2009.]
http://www.satisfice.com/sbtm/index.shtml.

[10] Sobre a Empresa: Satisfice Inc. Site da Satisfice Inc. [Online] [Citado em: 23 de Maio de 2009.]
http://www.satisfice.com/articles/what_is_et.shtml.

[11] Silva, Pedro Luciano Leite. Um Processo para Seleo de Metodologias de

Desenvolvimento de Software. Dissertao de Mestrado pelo Centro de Informtica da UFPE. 2003.

[12] Dicionrio Priberam da Lngua Portuguesa. [Online] [Citado em: 23 de Maio de 2009.]
http://www.priberam.pt/dlpo/dlpo.aspx.

[13] Kaner, Cem, Bach, James e Pettichord, Bret. Lessons learned in software testing: a context driven
approach. New York : John Wiley & Sons, Inc., 2002. ISBN.

[14] Bach,

James. General Functionality and Stability Test Procedure, 1999, http://www.satisfice.com/tools/procedure.pdf, [Online] [Citado em: 9 de Maro de 2009.] 51

[15] Rbia, Diana. Desenvolvendo uma Metodologia para Testes Exploratrios. Trabalho de
Graduao pelo Centro de Informtica da UFPE. 2007

[16] TestExplorer. http://testexplorer.com/ [Online] [Citado em: 17 de Maio de 2009.] [17] StickyMinds.com.
http://www.stickyminds.com/sitewide.asp?function=search&kind=simplesite&tt=SRCHBOX &tth=Y&freetext=exploratory+testing%3A+next+generation&submit.x=0&submit.y=0, [Online] [Citado em: 18 de Maio de 2009.]

[18] Bach, Jonathan. Sobre a Empresa: Satisfice Inc. Site da Satisfice Inc. [Online] Novembro de
2000. [Citado em: 27 de Maio de 2009.] http://www.satisfice.com/articles/sbtm.pdf.

[19] Richardson, Alan. Sobre a Empresa: Compendium Developments. Blog Evil Tester. [Online]
Janeiro de 2009. [Citado em: 13 de Maio de 2009.] http://www.eviltester.com/index.php/2009/01/15/exploratory-test-assistant-a-tool-forrecording-your-exploratory-testing-notes/

[20] DAmorim, Marcelo. Disciplina de Graduao do Centro de Informtica da UFPE. Teste e

Depurao de Software. Aula [Citado em: Junho de 2009.] http://www.cin.ufpe.br/~damorim/teaching/testing/2008.1/slides/01-o-que-eh-testes.ppt

[21] Silva, Tase. Trabalho de Graduao em Cincia da Computao pela Universidade Federal
de Pernambuco. http://www.cin.ufpe.br/~tds2/mte

52