Escolar Documentos
Profissional Documentos
Cultura Documentos
Centro de Informtica
Graduao em Cincia da Computao
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
iv
Abstract
Introduo
Estado da Arte
10
34
49
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.
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
Valores Permitidos
Descrio do Produto
De 3 a 50 Caracteres
Classes
<3
3 a 50
> 50
Cenrios
Quantidade de caracteres = 1
Quantidade de caracteres = 20
Quantidade de caracteres = 60
nmero dessa classe. A figura a seguir apresenta a utilizao da tcnica de valores limites para exemplo apresentado anteriormente [15] .
Entrada
Valores Permitidos
Descrio do Produto
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
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.
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
CAMPO
Exemplo
Observaes
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
#$%"&
2. Nmeros negatives
-6
3. Nmeros decimais
6,78
4. Caracteres alfanumricos
5fg7
11
1. Ms inexistente
18/00/2007
2. Data inexistente
32/01/2007
3. Dia negative
-1/01/2007
4. Ms negative
18/-1/2007
5. Ano negative
6. Caracteres alfanumricos
7. Formato invalid
18/1/-2007
dd/mm/2007
18/1/2007
data de amanh
data de ontem
29/02/2008
Formato HH:MM
1. Hora invlida
25:25
2. Minuto invalid
12:67
3. Hora negative
-6:57
4. Minuto negative
13:-8
5. Hora vazia
6. Minuto vazio
7. Formato
:34
15:
12:34:23
exemplo#exemplo.com
sem @
046.567.345-78
3. Barra de rolagem
VALIDAO
USABILIDADE
5. Teclas de atalho
6. Texto tooltip
7. Links de navegao
8. Barra de rolagem
MENSAGEM
NEGCIO
VALIDAO DE FLUXOS
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
SEGURANA
5. Testes de F5/Refresh
Testar a insero de comando SQL
no sistema
Verso:
Tela:
Executor:
Data:
13
Passados: Cenrio(s)
Cenrios
Resultado
Falhos: Cenrio(s)
Exemplo
Total: Cenrio(s)
Resultado
Tempo Total:
Solicitao de Mudana
ID
Resumo
Observaes
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
-6
3. Nmeros decimais
6,78
4. Caracteres alfanumricos
5fg7
CAMPO
18/00/2007
2. Data inexistente
32/01/2007
3. Dia negative
-1/01/2007
4. Ms negative
18/-1/2007
5. Ano negative
6. Caracteres alfanumricos
7. Formato invalid
18/1/-2007
dd/mm/2007
18/1/2007
data de amanh
data de ontem
29/02/2008
Formato HH:MM
1. Hora invlida
25:25
2. Minuto invalid
12:67
3. Hora negative
-6:57
4. Minuto negative
13:-8
5. Hora vazia
6. Minuto vazio
7. Formato
:34
15:
12:34:23
VALIDAO DE OUTROS
CAMPOS
1. Validao do campo email
exemplo#exemplo.com
046.567.345-78
VALIDAO DO CAMPO
(OUTROS)
1. Somente leitura e/ou editveis
14
USABILIDADE
MENSAGEM
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
NEGCIO
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
SEGURANA
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.
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.
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
Funcionalidade
Habilidade do produto de funcionar.
Critrio de Sucesso
Critrio de Falha
2. Qualquer comportamento
incorreto que observado no
produto no prejudica seria-
2. O produto opera incorretamente de uma maneira que prejudica seriamente o seu uso
18
Estabilidade
Habilidade do produto de continuar funcionando, ao longo
do tempo e sobre a sua escala
de utilizao, sem falhar ou
causar falha.
mente o funcionamento do
produto para uso normal
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
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.
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
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
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?
____________________________________________________________________________________
____________________________________________________________________________________
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.
29
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
33
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.
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
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.
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.
38
39
40
Tarefa
Passos
- Definir misso do teste
Design de Teste
Projetar Teste
Execuo de Teste
Executar Testes
Anlise de Teste
Figura 3.4 reas da Metodologia para Testes Exploratrios suportadas pela ferramenta SMTE
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.
42
menu: definir misso, testar e registrar resultado, reportar falhas e issues, gerar planilha de resultados e gerar relatrio.
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.
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
45
47
DESCRIO
|-chave primria-|
CENRIO
ID_CENRIO
DESCRIO
RESULTADO
|-chave primria-|
ID_MISSO
ID_FUNCIONALIDADE
INCONSISTNCIA
ID_INCONSISTNCIA
DESCRIO
|----chave primria----|
TIPO
ID_CENRIO
|--chave estrangeira--|
FUNCIONALIDADE
ID_FUNCIONALIDADE
DESCRIO
RESULTADO
|-chave primria-|
48
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
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.
[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
[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/
[21] Silva, Tase. Trabalho de Graduao em Cincia da Computao pela Universidade Federal
de Pernambuco. http://www.cin.ufpe.br/~tds2/mte
52