universidade estadual de maringÁ centro de …mestrado/diss/2013/carmizini.pdf · ao padre...
TRANSCRIPT
UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA
DEPARTAMENTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
MARCELO ANDERSON CARMIZINI
Uma abordagem de testes para aplicações móveis
Maringá 2013
MARCELO ANDERSON CARMIZINI
Uma abordagem de testes para aplicações móveis
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação do Departamento de Informática, Centro de Tecnologia da Universidade Estadual de Maringá, como requisito parcial para obtenção do título de Mestre em Ciência da Computação. Orientadora: Profa. Dra. Elisa Hatsue Moriya Huzita
Maringá 2013
Dedico esta dissertação à MINHA FAMÍLIA: meu pai Ivo, minha mãe Jandira e meu irmão Geovane, por todo o esforço, amor, carinho e compreensão.
AGRADECIMENTOS
Ao meu querido Deus por tantas graças e bênçãos recebidas. Ao Padre Reginaldo
Manzotti pelas belíssimas palavras de amor e carinho, que renovaram e aumentaram a minha
Fé em Jesus Cristo durante as piores tribulações. A todos os Santos e Anjos.
Aos meus pais – Ivo Carmizini e Jandira Natalina Foiato Carmizini – por todo o amor,
incentivo e suporte; ao meu irmão – Geovane Luis Carmizini – pelos momentos de
descontração e apoio; à minha noiva – Gilmara Dias Galvão – pelo amor, carinho e
compreensão; aos meus avós – Jose Carmizini “Béppi” (in memorian) e Rosa Iatzac (in
memorian).
As minhas vizinhas e amigas – Sra. Izidoria e Sra. Cecília – por todo o carinho e as
orações (e também pelos pedaços de bolo); aos meus padrinhos e tios – Sr. Gutemberg e Sra.
Lila Dantas; Sr. Olides Foiato e Família; Sr. Miguel Carmizini e Família. As famílias
Carmizini (Carmisin, Carmesini, Carmezini, Carmisini) e Foiato (Foiatto).
Aos professores: Dr. Clodis Boscarioli, Dr. Evando Carlos Pessini e Dra. Giani Carla
Ito, que acreditaram em mim, recomendando-me a este programa de pós-graduação.
A minha orientadora Profa. Dra. Tania Fatima Calvi Tait por me aceitar no programa
de pós-graduação e depositar a sua confiança em mim, além das orientações e ensinamentos.
A Profa. Dra. Elisa Hatsue Moriya Huzita pelas conversas, dicas e orientações. A Maria Inês
Davanço pelas conversas e orientações, além da disposição em esclarecer as dúvidas sobre as
entregas de documentos.
A todos os professores do Departamento de Informática (DIN-UEM) que contribuíram
direta ou indiretamente com a minha formação, de modo especial: Prof. Dr. Ademir
Constantino, Prof. Dr. Airton Polidorio, Prof. Dr. Dante Alves Medeiros Filho, Prof. Dr.
Donizete Bruzarosco, Prof. Dr. Edson Alves de Oliveira Junior, Prof. Dr. Franklin Cesar
Flores, Profa. Dra. Itana Gimenes, Profa. Dra. Luciana Martimiano, Prof. Dr. Nardênio
Martins, Prof. Dr. Ronaldo Augusto de Lara Gonçalves, Prof. Dr. João Angelo Martini (in
memorian).
A todos os amigos e amigas de mestrado, de modo especial: Eliane Becker (pelas
viagens, conversas e orientações), André Ortoncelli (pela camaradagem e hospedagem),
Landir Saviniec, Daiane Piccolo, Fábio Splendor, Renato Peterman, George Oliveira,
Euclides Matusse (pelas conversas e discussões sobre Engenharia de Software e Gestão de
Projetos de Software), Rafael Vivian (pelas dicas, orientações e por me apresentar a banda
Blackberry Smoke), Carlos Beleti, André Dias Martins, Sidgley (pelas dicas e orientações),
Guilherme da Costa Silva, Elder, Juliano Foleiss, André D’Amato que de alguma forma
contribuíram para a realização deste trabalho.
A todos os amigos e amigas de Datacoper, de modo especial: Éder Machado,
Leonardo Favaro, Marcelo Gimenes, Paulo Rogério Antiquera, Alan Bruch, Luiz Valter
Ferreira Filho, Jeferson Mombach de Sousa, Cleiton Siqueira, Leonardo Queiroz (meu
compadre), Márcio Lunardi Joris, Eduardo Frighetto, Rodrigo Tomazeli, Marcelo Borth,
Fábio Blank, Danyel Duarte, Vicente, Marlon Ramon, Thiago Alexandre Lenz, Jarissom,
Denny Boechat, Pablo Machado, Tininha, Sr. Sidnei Terribele e Sr. Cezar Bernardon.
A todos os amigos e amigas de Unipar, de modo especial: Prof. Angelo Sucolotti,
Prof. Robison Meinerz (meu compadre), Profa. Dra. Sueli Poppi Borba, Prof. William
Pelissari, Prof. Dr. Luiz Fernando, Prof. Alisson Chiquitto, Prof. Roni Shigueta.
Ao Sr. Emerson Rios (iTeste) pela prontidão em responder vários questionamentos
sobre a dissertação, mesmo não me conhecendo pessoalmente.
Ao Prof. Dr. Edmundo Sérgio Spoto (INF/UFG) por fazer parte da banca e contribuir
com este trabalho.
A Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), a
Fundação Araucária (FA) e ao Grupo de Pesquisa em Gerenciamento de Projetos de Software
(GPGPS).
“Nossa alma espera no Senhor,
porque ele é nosso amparo e nosso escudo;
Nele, pois, se alegra o nosso coração,
em seu santo nome confiamos;
Seja-nos manifestada, Senhor, a vossa misericórdia,
como a esperamos de vós.” (Sl 33, 20-22)
Uma abordagem de testes para aplicações móveis
RESUMO
A rápida evolução do hardware dos dispositivos móveis e a demanda exponencial por
aplicações são características que desafiam as organizações a fornecer produtos de software
que satisfaçam as reais necessidades dos usuários de tais dispositivos e, também, serem
corretos, seguros e confiáveis. Embora as aplicações móveis sejam desenvolvidas em
plataformas e linguagens já existentes, os desenvolvedores não possuem, muitas vezes,
familiaridade com o ambiente móvel, o qual apresenta características particulares como:
autonomia, conectividade e sensibilidade ao contexto. Dessa forma, o objetivo desta
dissertação é apresentar uma abordagem de testes para aplicações móveis, chamada TM-
Aplic, visando estabelecer uma metodologia que combine boas práticas de planejamento,
projeto e execução de testes. Além disso, a abordagem TM-Aplic considera as
particularidades das aplicações móveis em termos de tarefas, artefatos e papéis, de maneira
que auxilie na identificação de falhas e contribua com a qualidade do produto. A abordagem
proposta tem como elementos principais: a definição de um processo de testes apoiado pelo
modelo de maturidade MPT.BR e a identificação de requisitos para testes de aplicações
móveis. Para avaliar a viabilidade da abordagem TM-Aplic utilizou-se os princípios da
engenharia de software experimental.
Palavras-chave: Aplicação Móvel. Processo de Teste de Software. Testes de Aplicações
Móveis.
An approach for testing mobile applications
ABSTRACT
The rapid evolution of the hardware of mobile devices and the exponential demand for
applications are characteristics that challenge organizations to deliver software products that
meet the real needs of the users of such devices, and also being correct, secure and reliable.
Although mobile applications are developed on existing platforms and languages, developers
do not have, many times, familiarity with the mobile environment, which presents particular
characteristics such as autonomy, connectivity and context awareness. Thus, the purpose of
this dissertation is to present an approach to testing for mobile applications, called TM-
Applic, aiming establish a methodology that combines best practices in planning, design and
execution of tests. In addition, the TM-Applic approach considers the particularities of mobile
applications in terms of tasks, artifacts and roles, so to assist in identifying faults and
contribute to product quality. The proposed approach has as its main elements: the definition
of a testing process maturity model supported by MPT.BR and identification of requirements
for testing mobile applications. In order to assess the approach TM-Aplic, the principles of
experimental software engineering were used.
Keywords: Mobile Application, Software Testing Process, Testing of Mobile Applications.
LISTA DE QUADROS
Quadro 3.1. Exemplo de um catálogo de dispositivos homologados ....................................... 96
Quadro 4.1. Relatório de análise do produto .......................................................................... 111
Quadro 4.2. Relatório de objetivos do teste............................................................................ 112
Quadro 4.3. Relatório da estratégia de testes.......................................................................... 113
Quadro 4.4. Relatório da equipe de testes .............................................................................. 113
Quadro 4.5. Relatório do ambiente de testes .......................................................................... 114
Quadro 4.6. Plano de testes .................................................................................................... 114
Quadro 4.7. Observações gerais do teste ................................................................................ 117
Quadro 4.8. Caso de teste – CASO01 .................................................................................... 118
Quadro 4.9. Caso de teste – CASO02 .................................................................................... 119
Quadro 4.10. Caso de teste – CASO03 .................................................................................. 119
Quadro 4.11. Relatório de execução ....................................................................................... 120
Quadro 4.12. Registro de incidente – INCI01 ........................................................................ 120
Quadro 4.13. Registro de incidente – INCI02 ........................................................................ 121
Quadro 4.14. Relatório de acompanhamento de incidentes – ACOM01 ............................... 123
Quadro 4.15. Relatório de acompanhamento de incidentes – ACOM02 ............................... 123
Quadro B.1. Template para o relatório de análise do produto ................................................ 184
Quadro B.2. Template para o relatório de objetivos do teste ................................................. 185
Quadro B.3. Template para o relatório da estratégia de testes ............................................... 186
Quadro B.4. Template para o relatório da equipe de testes .................................................... 187
Quadro B.5. Template para o relatório do ambiente de testes ................................................ 188
Quadro B.6. Template para o plano de teste .......................................................................... 189
Quadro B.7. Template para as observações gerais do teste .................................................... 190
Quadro B.8. Template para os casos de teste ......................................................................... 192
Quadro B.9. Template para o relatório de execução do teste ................................................. 193
Quadro B.10. Template para o registro de incidente .............................................................. 194
Quadro B.11. Template para o relatório de acompanhamento de incidentes ......................... 196
LISTA DE FIGURAS
Figura 1.1. Etapas da metodologia de desenvolvimento .......................................................... 28
Figura 2.1. Características e subcaracterísticas de qualidade (adaptada de Guerra e Colombo,
2009) ......................................................................................................................................... 32
Figura 2.2. Fases do teste de software ...................................................................................... 35
Figura 2.3. Cadeia de eventos para a falha do software (adaptada de Crespo et al., 2009) ..... 37
Figura 2.4. Custo dos defeitos (Graham e Van Veenendaal, 2008) ......................................... 37
Figura 2.5. Componentes do processo de testes de software (Crespo et al., 2010a) ................ 39
Figura 2.6. Processo de teste de software (adaptada de Mao e Zhang, 2007) .......................... 40
Figura 2.7. Importância do monitoramento, controle e replanejamento do teste ..................... 41
Figura 2.8. Níveis de maturidade e principais áreas de processo do modelo TMMi (Van
Veenendaal, 2008) .................................................................................................................... 43
Figura 2.9. Fatores que definem o ambiente móvel ................................................................. 57
Figura 2.10. Processo de testes para empresas de pequeno porte (adaptada de Rodrigues,
Pinheiro e Albuquerque, 2010) ................................................................................................. 71
Figura 3.1. Composição da abordagem TM-Aplic ................................................................... 75
Figura 3.2. Subprocessos da abordagem TM-Aplic (adaptado de Dias Neto e Travassos, 2006
e Rodrigues, Pinheiro e Albuquerque, 2010) ........................................................................... 76
Figura 3.3. Diagrama da abordagem TM-Aplic ....................................................................... 78
Figura 3.4. Diagrama de atividades – Analisar produto de teste .............................................. 85
Figura 3.5. Diagrama de atividades – Definir objetivos do teste ............................................. 88
Figura 3.6. Diagrama de atividades – Definir estratégia de teste ............................................. 91
Figura 3.7. Diagrama de atividades – Definir equipe de teste .................................................. 94
Figura 3.8. Comparação entre um ambiente estático e dinâmico ............................................. 95
Figura 3.9. Diagrama de atividades – Definir ambiente de teste .............................................. 97
Figura 3.10. Diagrama de atividades – Estabelecer plano de teste ........................................... 98
Figura 3.11. Diagrama de atividades – Planejar os artefatos e dados .................................... 100
Figura 3.12. Diagrama de atividades – Identificar casos de teste ........................................... 103
Figura 3.13. Diagrama de atividades – Executar teste ........................................................... 104
Figura 3.14. Diagrama de atividades – Reportar incidentes ................................................... 106
Figura 3.15. Diagrama de atividades – Acompanhar incidentes ............................................ 107
Figura 4.1. Emulador Android 2.1 .......................................................................................... 110
Figura 5.1. Análise das respostas em relação a mediana e a moda ........................................ 138
Figura 5.2. Respostas dos participantes em relação ao nível de conhecimento em aplicação
móvel e teste de software........................................................................................................ 139
Figura 5.3. Análise das respostas dos participantes em relação ao nível de conhecimento em
aplicação móvel ...................................................................................................................... 139
Figura 5.4. Análise das respostas dos participantes em relação ao nível de conhecimento em
teste de software ..................................................................................................................... 139
Figura 5.5. Respostas dos participantes em relação a tarefa analisar produto de teste .......... 140
Figura 5.6. Análise das respostas em relação a tarefa analisar produto de teste .................... 140
Figura 5.7. Respostas dos participantes em relação a tarefa estabelecer objetivos do teste ... 141
Figura 5.8. Análise das respostas em relação a tarefa estabelecer objetivos do teste ............ 141
Figura 5.9. Respostas dos participantes em relação a tarefa definir estratégia de teste ......... 142
Figura 5.10. Análise das respostas em relação a tarefa definir estratégia de teste ................. 142
Figura 5.11. Respostas dos participantes em relação a tarefa definir equipe de teste ............ 143
Figura 5.12. Análise das respostas em relação a tarefa definir equipe de teste ...................... 143
Figura 5.13. Respostas dos participantes em relação a tarefa definir ambiente de teste ........ 144
Figura 5.14. Análise das respostas em relação a tarefa definir ambiente de teste .................. 144
Figura 5.15. Respostas dos participantes em relação a tarefa estabelecer plano de teste ....... 145
Figura 5.16. Análise das respostas em relação a tarefa estabelecer plano de teste ................ 145
Figura 5.17. Respostas dos participantes em relação a tarefa planejar os artefatos e dados .. 146
Figura 5.18. Análise das respostas em relação a tarefa planejar os artefatos e dados ............ 146
Figura 5.19. Respostas dos participantes em relação a tarefa identificar casos de teste ........ 147
Figura 5.20. Análise das respostas em relação a tarefa identificar casos de teste .................. 147
Figura 5.21. Respostas dos participantes em relação a tarefa executar testes ........................ 148
Figura 5.22. Análise das respostas em relação a tarefa executar testes .................................. 148
Figura 5.23. Respostas dos participantes em relação a tarefa reportar incidentes .................. 149
Figura 5.24. Análise das respostas em relação a tarefa reportar incidentes ........................... 149
Figura 5.25. Respostas dos participantes em relação a tarefa acompanhar incidentes ........... 150
Figura 5.26. Análise das respostas em relação a tarefa acompanhar incidentes .................... 150
Figura 5.27. Respostas dos participantes em relação aos artefatos presentes na abordagem . 151
Figura 5.28. Análise das respostas em relação aos artefatos presentes na abordagem........... 151
Figura 5.29. Respostas dos participantes em relação a qualidade do produto........................ 152
Figura 5.30. Análise das respostas em relação a qualidade do produto ................................. 152
Figura A.1. Diagrama da abordagem TM-Aplic .................................................................... 174
Figura B.1. Arquivo de validação para o relatório de análise do produto .............................. 184
Figura B.2. Arquivo de validação para o relatório de objetivos do teste ............................... 185
Figura B.3. Arquivo de validação para o relatório da estratégia de testes ............................. 186
Figura B.4. Arquivo de validação para o relatório da equipe de teste .................................... 187
Figura B.5. Arquivo de validação para o relatório do ambiente de testes .............................. 188
Figura B.6. Arquivo de validação para o relatório de observações gerais do teste ................ 191
Figura B.7. Arquivo de validação para o caso de teste........................................................... 192
Figura B.8. Arquivo de validação para o relatório de execução do teste ............................... 193
Figura B.9. Arquivo de validação para o registro de incidente .............................................. 195
Figura B.10. Arquivo de validação para o relatorio de acompanhamento de incidente ......... 196
LISTA DE TABELAS
Tabela 2.1. Características de qualidade (NBR ISO/IEC 9126-1, 2003) ................................. 32
Tabela 2.2. Níveis e áreas-chave do modelo TPI (Koomen e Pol, 1999) ................................. 44
Tabela 2.3. Níveis de maturidade, áreas de processo e tarefas do modelo MPT.BR (adaptada
de Furtado et al., 2012 e SOFTEX, 2011) ................................................................................ 49
Tabela 2.4. Relação entre as áreas de processo dos modelos TMMi, MPT.BR e a norma
ISO/IEC 29119-2 (Rios, 2013) ................................................................................................. 55
Tabela 2.5. Correlação entre a gestão de projetos de software tradicional e aplicação móvel
(adaptada de Andrade et al., 2012) ........................................................................................... 62
Tabela 2.6. Características de avaliação de qualidade do dispositivo móvel e suas
funcionalidades ......................................................................................................................... 64
Tabela 2.7. Trabalhos relacionados .......................................................................................... 68
Tabela 2.8. Requisitos de testes para aplicações móveis (adaptada de Dantas et al., 2009) .... 69
Tabela 3.1. Resumo das principais características que compõe a abordagem TM-Aplic ........ 75
Tabela 3.2. Objetos utilizados para compor o diagrama (adaptado de Bizagi, 2013) .............. 77
Tabela 3.3. Serviços do dispositivo móvel ............................................................................... 82
Tabela 3.4. Principais riscos e planos de mitigação ................................................................. 83
Tabela 3.5. Principais características consideradas para compor a estratégia de testes para
aplicações móveis ..................................................................................................................... 89
Tabela 3.6. Estratégia de testes para aplicações móveis........................................................... 89
Tabela 3.7. Matriz de responsabilidades e tarefas (adaptada de Cristalli e Moreira Filho, 2011)
.................................................................................................................................................. 92
Tabela 5.1. Níveis de concordância das variáveis dependentes ............................................. 131
Tabela 5.2. Níveis de concordância das variáveis independentes .......................................... 131
Tabela 5.3. Respostas coletadas sobre o perfil dos participantes ........................................... 135
Tabela 5.4. Respostas coletadas sobre a viabilidade da abordagem TM-Aplic ..................... 136
Tabela 5.5. Cálculo da mediana e moda das respostas coletadas ........................................... 137
Tabela A.1. Objetos utilizados para compor o diagrama ....................................................... 174
Tabela A.2. Tarefa: analisar produto de teste ......................................................................... 175
Tabela A.3. Tarefa: estabelecer objetivos do teste ................................................................. 175
Tabela A.4. Tarefa: definir estratégia de teste ........................................................................ 176
Tabela A.5. Tarefa: definir equipe de teste ............................................................................ 176
Tabela A.6. Tarefa: definir ambiente de teste ........................................................................ 177
Tabela A.7. Tarefa: estabelecer plano de teste ....................................................................... 177
Tabela A.8. Tarefa: planejar os artefatos e dados................................................................... 178
Tabela A.9. Tarefa: identificar casos de teste ......................................................................... 178
Tabela A.10. Tarefa: executar testes ...................................................................................... 179
Tabela A.11. Tarefa: reportar incidentes ................................................................................ 179
Tabela A.12. Tarefa: acompanhar incidentes ......................................................................... 179
LISTA DE ABREVIATURAS E SIGLAS
A Avançada
ACOM Acompanhamento
AET Automação da Execução do Teste
AMBI Ambiente
AQP Avaliação da Qualidade do Produto
B Básica
BPMN Business Process Modeling Notation
CASE Computer-Aided Software Engineering
CEP Controle Estatístico do Processo
CMMI Capatibility Maturity Model integration
CoHo Controle de Horários
CRIT Critério
DIN Departamento de Informática
Dn Doutorando
Dr Doutor
EC Especialização Completa
EI Especialização Incompleta
ENCE Encerramento
EQUI Equipe
ES Engenharia de Software
ESE Engenharia de Software Experimental
ESTR Estratégia
EXEC Execução
FDT Fechamento do Teste
GB Gigabyte
GDD Gestão de Defeitos
GDF Gestão de Ferramentas
GDQ Garantia da Qualidade
GPRS General Packet Radio Service
GPS Global Positioning System
GPT Gerência de Projetos de Teste
GRT Gerência de Requisitos de Teste
GSM Global System for Mobile Communications
ID Identificador
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electrical and Electronics Engineers
INCI Incidente
ISO International Organization for Standardization
iTeste Instituto de Teste de Software
M Moderada
MAT Medição e Análise de Teste
MB Megabyte
MMS Multimedia Messaging Service
Mn Mestrando
MP3 MPEG-1/2 Audio Layer 3
MPS.BR Melhoria do Processo de Software Brasileiro
MPT.BR Melhoria do Processo de Teste Brasileiro
Ms Mestre
N Nenhuma
OGT Organização do Teste
OMG Object Management Group
PET Projeto e Execução de Teste
PIN Personal Identification Number
PLAN Plano
PROD Produto
RAM Random Access Memory
RUP Rational Unified Process
SC Superior Completo
SI Superior Incompleto
SMS Short Message Service
SQL Structured Query Language
SR Sem Resposta
TAP Testing Assessment Program
TDA Teste de Aceitação
TER Treinamento
TES Teste Estático
TIM Testing Improvement Model
TMap Test Management Approach
TMMi Testing Maturity Model integration
TNF Teste Não-Funcional
TOM Test Organization Maturity Model
TPI Test Process Improvement
TSM Testability Support Model
UEM Universidade Estadual de Maringá
VoIP Voice over Internet Protocol
Wi-Fi Wireless Fidelity
WLAN Wireless Local Area Network
SUMÁRIO
Introdução ............................................................................................................................... 24
1.1. Contextualização.................................................................................................... 24
1.2. Justificativa ............................................................................................................ 25
1.3. Objetivos ................................................................................................................ 27
1.4. Metodologia de Desenvolvimento ......................................................................... 28
1.5. Organização do Trabalho ....................................................................................... 29
Revisão Bibliográfica .............................................................................................................. 30
2.2. Considerações Iniciais ........................................................................................... 30
2.3. Qualidade de Software ........................................................................................... 31
2.4. Teste de Software .................................................................................................. 34
2.5. Processo de Teste de Software .............................................................................. 38
2.5.1. Modelos de Melhoria de Processos de Teste de Software ..................................... 42
2.5.1.1. Testing Maturity Model integration (TMMi) ................................................... 42
2.5.1.2. Test Process Improvement (TPI) ...................................................................... 44
2.5.1.3. Testing Improvement Model (TIM) .................................................................. 46
2.5.1.4. Melhoria do Processo de Teste Brasileiro (MPT.BR) ...................................... 47
2.5.1.5. ISO/IEC 29119 .................................................................................................. 53
2.5.1.6. Relação entre Áreas de Processo dos Modelos de Teste de Software .............. 54
2.6. Ambiente Móvel .................................................................................................... 56
2.6.1. Contexto Móvel ..................................................................................................... 57
2.6.1.1. Dispositivos Móveis .......................................................................................... 58
2.6.2. Usuário de Dispositivo Móvel ............................................................................... 59
2.6.3. Aplicação Móvel .................................................................................................... 60
2.6.3.1. Tipos de Aplicações Móveis ............................................................................. 61
2.7. Testes de Aplicações Móveis................................................................................. 63
2.8. Engenharia de Software Experimental (ESE)........................................................ 67
2.9. Trabalhos Relacionados ......................................................................................... 68
2.9.1. Descrição e Análise dos Trabalhos Relacionados ................................................. 68
2.10. Considerações Finais ............................................................................................. 72
Abordagem TM-Aplic ............................................................................................................ 73
3.1. Considerações Iniciais ........................................................................................... 73
3.2. Composição da Abordagem ................................................................................... 74
3.3. Estrutura da Abordagem ........................................................................................ 76
3.4. Descrição das Tarefas ............................................................................................ 79
3.4.1. Planejamento de Teste ........................................................................................... 79
3.4.1.1. Analisar Produto de Teste ................................................................................. 80
3.4.1.2. Estabelecer Objetivos do Teste ......................................................................... 85
3.4.1.3. Definir Estratégia de Teste ................................................................................ 88
3.4.1.4. Definir Equipe de Teste .................................................................................... 91
3.4.1.5. Definir Ambiente de Teste ................................................................................ 94
3.4.1.6. Estabelecer Plano de Teste ................................................................................ 97
3.4.1.7. Planejar os Artefatos e Dados ........................................................................... 98
3.4.2. Projeto e Execução de Teste ................................................................................ 100
3.4.2.1. Identificar Casos de Teste ............................................................................... 101
3.4.2.2. Executar Testes ............................................................................................... 103
3.4.2.3. Reportar Incidentes ......................................................................................... 105
3.4.2.4. Acompanhar Incidentes .................................................................................. 106
3.5. Considerações Finais ........................................................................................... 108
Exemplo de Aplicação da Abordagem TM-Aplic .............................................................. 109
4.1. Considerações Iniciais ......................................................................................... 109
4.2. Cenário ................................................................................................................. 109
4.3. Planejamento de Testes........................................................................................ 110
4.3.1. Analisar Produto de Testes .................................................................................. 110
4.3.2. Estabelecer Objetivos do Teste ............................................................................ 112
4.3.3. Definir a Estratégia de Testes .............................................................................. 113
4.3.4. Definir Equipe de Testes ..................................................................................... 113
4.3.5. Definir Ambiente de Testes ................................................................................. 114
4.3.6. Estabelecer Plano de Testes ................................................................................. 114
4.3.7. Planejar os Artefatos e Dados .............................................................................. 117
4.4. Projeto e Execução de Testes .............................................................................. 118
4.4.1. Identificar Casos de Teste .................................................................................... 118
4.4.2. Executar Testes .................................................................................................... 119
4.4.3. Reportar Incidentes .............................................................................................. 120
4.4.4. Acompanhar Incidentes ....................................................................................... 123
4.5. Considerações Finais ........................................................................................... 124
Estudo Experimental de Viabilidade da Abordagem TM-Aplic ...................................... 125
5.1. Considerações Iniciais ......................................................................................... 125
5.2. Definição do Estudo Experimental ...................................................................... 126
5.3. Planejamento do Estudo Experimental ................................................................ 128
5.3.1. Contexto Global ................................................................................................... 128
5.3.2. Contexto Local..................................................................................................... 129
5.3.3. Treinamento ......................................................................................................... 129
5.3.4. Projeto Piloto ....................................................................................................... 129
5.3.5. Participantes ......................................................................................................... 129
5.3.6. Instrumentação ..................................................................................................... 130
5.3.7. Variáveis Dependentes ........................................................................................ 130
5.3.8. Variáveis Independentes ...................................................................................... 131
5.3.9. Análise Qualitativa .............................................................................................. 132
5.3.10. Capacidade Aleatória ...................................................................................... 132
5.3.11. Classificação em Bloco ................................................................................... 132
5.3.12. Mecanismos de Análise .................................................................................. 132
5.3.13. Validade Interna .............................................................................................. 132
5.3.14. Validade Externa ............................................................................................. 133
5.3.15. Validade de Conclusão ................................................................................... 133
5.4. Execução do Estudo Experimental ...................................................................... 133
5.4.1. Seleção dos Participantes ..................................................................................... 133
5.4.2. Instrumentação ..................................................................................................... 133
5.4.3. Procedimentos do Participante ............................................................................ 134
5.4.4. Execução .............................................................................................................. 134
5.5. Análise e Interpretação dos Resultados do Estudo Experimental ....................... 137
5.5.1. Validação dos Dados ........................................................................................... 137
5.5.2. Estatística Descritiva e Análise ........................................................................... 137
5.6. Avaliação de Validade do Estudo Experimental ................................................. 153
5.7. Considerações Finais ........................................................................................... 155
Conclusões ............................................................................................................................. 156
6.1. Propósito da Pesquisa .......................................................................................... 156
6.2. Contribuições ....................................................................................................... 157
6.3. Dificuldades e Limitações ................................................................................... 157
6.4. Trabalhos Futuros ................................................................................................ 158
Referências ............................................................................................................................ 159
Apêndice A - Estudo Experimental de Viabilidade da Abordagem TM-Aplic:
Instrumentação ..................................................................................................................... 169
A.1. Considerações Iniciais ......................................................................................... 169
Apêndice B - Templates para os Artefatos .......................................................................... 183
B.1. Considerações Iniciais ......................................................................................... 183
B.2. Relatório de Análise do Produto .......................................................................... 184
B.3. Relatório de Objetivos do Teste .......................................................................... 185
B.4. Relatório da Estratégia de Teste .......................................................................... 186
B.5. Relatório da Equipe de Teste ............................................................................... 187
B.6. Relatório do Ambiente de Teste .......................................................................... 188
B.7. Estabelecer Plano de Teste .................................................................................. 189
B.8. Planejar os Artefatos e Dados .............................................................................. 190
B.9. Identificar Caso de Teste ..................................................................................... 192
B.10. Executar Teste ..................................................................................................... 193
B.11. Reportar Incidentes .............................................................................................. 194
B.12. Acompanhar Incidentes ....................................................................................... 196
24
Introdução
1.1. Contextualização
Segundo Myers (2004), o teste atua como a principal atividade para fornecer software de
qualidade, além de garantir que o produto alcance as especificações e as características
básicas de um software profissional. No entanto, durante o processo de desenvolvimento de
um produto de software vários obstáculos podem surgir, os quais contribuem para que haja
algum desvio e a qualidade seja suspeita, principalmente quando o contexto do software
impõe limitações diferentes das tradicionais, como é o caso das aplicações móveis.
Aplicações móveis são produtos de software desenvolvidos para operar em
dispositivos móveis, e apresentam características diferenciadas em relação às tradicionais, tais
como os fatores inerentes do ambiente móvel, que são: contexto móvel, usuário de dispositivo
móvel e aplicação móvel (Ballard, 2007; Muccini, Di Francesco e Esposito, 2012).
As organizações enfrentam grandes desafios relacionados ao fornecimento de
aplicações móveis que sejam de real valor para as pessoas e empresas, no que se refere ao
comportamento correto e sem falhas, sem perda de dados ou serviços e não interfiram em
outras aplicações e/ou serviços já existentes no dispositivo (Mizouni et al., 2009, She,
Sivapalan e Warren, 2009).
1
Capítulo
25
A preocupação com a qualidade das aplicações móveis se deve a evolução do
dispositivo móvel a partir de um aparelho de comunicação grande e desconfortável, para uma
forma compacta e poderosa, que ocorreu durante os últimos vinte anos. Essa evolução
resultou no desenvolvimento de aplicativos e serviços que oferecem vantagens significativas
para os seus usuários, como, portabilidade, localização e acessibilidade (Nayebi, Desharnais e
Abran, 2012), resultando na abordagem tecnológica recente que mais rapidamente se
difundiu, utilizada por mais de 60% dos brasileiros (Machado e Freitas, 2009).
Além disso, devido à agregação de um conjunto de importantes componentes que se
tornaram parte integrante da vida diária das pessoas (por exemplo: telefone, Internet,
computador, cartão de crédito e televisão), o dispositivo móvel é capaz de atingir proporções
gigantescas sobre a humanidade, apresentando um alcance maior que o carro, televisão, e
Internet, além de impulsionar o sucesso dos dispositivos móveis (Fling, 2009).
Dessa forma, o contexto desta dissertação é a apresentação de uma abordagem de
testes para aplicações móveis, chamada TM-Aplic, que visa apoiar na melhoria da qualidade
do produto de software, por meio de uma metodologia sistemática que combine boas práticas
de planejamento, projeto e execução de testes com as necessidades e particularidades das
aplicações móveis.
A abordagem TM-Aplic compõe o projeto de pesquisa M-Aplic, o qual apresenta uma
abordagem de gerenciamento de projetos de software para aplicações móveis. As pesquisas
são realizadas pelos membros do Grupo de Pesquisa em Gerenciamento de Projetos de
Software (GPGPS) do Departamento de Informática (DIN) da Universidade Estadual de
Maringá (UEM), com o financiamento da Fundação Araucária (FA).
1.2. Justificativa
As ferramentas e técnicas que têm sido usadas para auxiliar o desenvolvimento de softwares
tradicionais (desktop), não satisfazem as necessidades das aplicações móveis. Ou seja, em vez
de aplicar técnicas específicas para o desenvolvimento de aplicações móveis, muitas
indústrias têm “miniaturizado” versões de aplicativos desktop para os dispositivos móveis,
ocasionando vários problemas, principalmente relacionados com a usabilidade, uma das
principais razões da insatisfação do usuário (Mizouni et al., 2009).
Aproximadamente 50% dos 200 (duzentos) novos aplicativos disponibilizados
diariamente para o iPhone (dispositivo móvel desenvolvido pela empresa Apple), não atingem
um nível suficiente de aceitação pelos usuários e são retiradas da loja já nos primeiros meses a
partir do lançamento (Ickin et al., 2012).
26
Além disso, o crescimento exponencial do mercado de aplicações móveis impõe
atenção especial aos aspectos relacionados à qualidade das aplicações, pois as mesmas não
estão livres de erros, e a dificuldade de atualização após o software ser disponibilizado é
maior do que nos tradicionais, enfatizando ainda mais a necessidade de novas abordagens de
Engenharia de Software que considere as particularidades das aplicações e, portanto,
contribuir para a melhoria da qualidade do produto final (Kim, Choi e Wong, 2009; Muccini,
Di Francesco e Esposito, 2012).
De acordo com o Relatório Mundial de Qualidade (Capgemini, Sogeti e Hewlett-
Packard, 2012), a velocidade de adoção e proliferação dos dispositivos móveis são fatores que
surpreenderam as empresas, contribuindo para que não priorizassem de forma suficiente as
particularidades das aplicações móveis, no que se refere a considerar os fatores do ambiente
móvel durante as atividades de teste. Somente 31% das empresas entrevistadas efetuam testes
nas aplicações móveis desenvolvidas, afirmando serem mal preparadas devido à falta de
ferramentas apropriadas, processos ou conhecimentos e acesso limitado aos dispositivos.
Dantas et al. (2009) afirmam que, 85% dos profissionais não utilizam uma
metodologia de testes específica para testar as aplicações móveis, dificultando a padronização
dos testes, além de não contemplar todas as características particulares das aplicações.
Portanto, as equipes de teste devem repensar suas estratégias e prioridades, de modo que o
planejamento de teste considere as questões inerentes do ambiente móvel, como: memória,
processamento, tela, bateria, capacidade de armazenamento, usabilidade, funcionalidade e
mobilidade dos usuários, antes do projeto e execução dos testes.
Dessa forma, acredita-se que a busca constante por aplicações cada vez mais
funcionais é um negócio em constante crescimento, pois as empresas não devem apresentar ao
mercado aplicativos que apresentem falhas e/ou problemas de usabilidade. No entanto,
garantir a qualidade das aplicações não é uma tarefa trivial, pois envolve uma grande
variedade de dispositivos e recursos.
27
1.3. Objetivos
Esta dissertação teve como objetivo principal elaborar a abordagem TM-Aplic, que visa
estabelecer uma metodologia que combine boas práticas de planejamento, projeto e execução
de testes com as particularidades das aplicações móveis, em termos de tarefas, artefatos e
papéis, de maneira que contribua para a qualidade do produto no que se refere à identificação
de falhas.
Dessa forma, para atingir o objetivo principal desta dissertação, os seguintes objetivos
específicos são previstos:
Identificar as particularidades das aplicações móveis no que se refere às características
relacionadas aos fatores inerentes do ambiente móvel;
Definir e caracterizar as áreas de processo de planejamento, projeto e execução do
teste, bem como as respectivas tarefas, artefatos e papéis, de acordo com as diretrizes
definidas pelo Nível 1 (um) de maturidade do modelo MPT.BR;
Representar a abordagem proposta de forma que possibilite o entendimento e a
aplicação, além de fornecer material organizado sobre o teste de aplicações móveis; e
Avaliar experimentalmente a abordagem TM-Aplic com relação à viabilidade para ser
utilizada como uma metodologia de testes em empresas que desenvolvem aplicações
móveis.
A principal contribuição da abordagem TM-Aplic é fornecer à equipe de testes
diretrizes para apoiar a execução das tarefas que estão de acordo com o Nível 1 (um) de
maturidade do modelo MPT.BR, considerando os fatores inerentes do ambiente móvel, como:
contexto móvel, usuário de dispositivo móvel e aplicação móvel, visando a identificação de
falhas e, consequentemente, a melhoria da qualidade do produto.
28
1.4. Metodologia de Desenvolvimento
A metodologia de desenvolvimento da dissertação é composta pelas etapas de revisão
bibliográfica, definição da abordagem, estudo experimental de viabilidade e redação. Na
Figura 1.1 são apresentadas as etapas e subetapas da metodologia de desenvolvimento.
Figura 1.1. Etapas da metodologia de desenvolvimento
29
A revisão bibliográfica da presente dissertação envolve conceitos sobre qualidade
software, teste de software, processos de testes de software, os fatores inerentes do ambiente
móvel, teste de aplicações móveis, engenharia de software experimental e trabalhos
relacionados. Após a revisão bibliográfica iniciou-se a definição da abordagem que
compreende a proposta desta dissertação. As principais atividades dessa etapa foram: a
identificação dos elementos que compõem a abordagem, o refinamento dos elementos para a
definição da estrutura principal e, a definição e apresentação dos componentes (subprocessos,
tarefas, papéis e artefatos) fundamentados pelo modelo de maturidade MPT.BR. Por fim, a
etapa do estudo experimental de viabilidade que verifica se a abordagem TM-Aplic satisfaz
os quesitos de viabilidade e a redação que consiste na escrita da dissertação e do artigo, bem
como a respectiva defesa da dissertação e submissão do artigo para eventos da área.
1.5. Organização do Trabalho
Neste capítulo foram apresentados o contexto no qual esta dissertação está inserida, sua
motivação, seus objetivos e a metodologia de desenvolvimento. O Capítulo 2 apresenta os
conceitos básicos sobre qualidade de software, teste de software, processo de testes de
software, ambiente móvel e testes de aplicações móveis que norteiam esta dissertação. O
Capítulo 3 descreve e especifica a abordagem TM-Aplic. O Capítulo 4 apresenta uma
aplicação da abordagem por meio de uma prova de conceito. O Capítulo 5 apresenta um
estudo experimental com o objetivo de identificar a viabilidade da abordagem aplicada à
indústria. No Capítulo 6 estão apresentados o propósito desta dissertação, os resultados e
contribuições, as dificuldades e limitações e os trabalhos futuros.
30
Revisão Bibliográfica
2.2. Considerações Iniciais
A abordagem TM-Aplic em contextos organizacionais necessita de uma fundamentação
teórica baseada em conceitos sólidos relacionados principalmente a qualidade da aplicação
móvel. Dessa forma, este capítulo apresenta uma revisão bibliográfica sobre os tópicos
relevantes da abordagem proposta no Capítulo 3:
Qualidade de Software (norma NBR ISO/IEC 9126-1);
Teste de Software (técnicas, fases, objetivos e eventos);
Processo de Teste de Software (normas, modelos de melhoria e metodologias de
testes);
Ambiente Móvel (contexto móvel, usuários de dispositivos móveis e aplicação
móvel);
Testes de Aplicações Móveis (características de qualidade para as aplicações móveis);
Engenharia de Software Experimental (avaliar experimentalmente a abordagem); e
Trabalhos Relacionados (base para o desenvolvimento da abordagem).
2
Capítulo
31
Os tópicos abordados estão relacionados à base que fornece subsídios para o
desenvolvimento da abordagem TM-Aplic, a qual foi baseada nos trabalhos de Dantas et al.
(2009) e Rodrigues, Pinheiro e Albuquerque (2010), apresentados e discutidos na Seção 2.9
(Trabalhos Relacionados).
2.3. Qualidade de Software
A Qualidade de Software é uma das áreas da Engenharia de Software que visa satisfazer às
expectativas do usuário, no que se refere a garantir que as especificações (explícitas) e
necessidades do cliente (implícitas) estejam presentes no produto final, por meio de processos
de desenvolvimento. A satisfação com o produto está relacionada com seu desempenho e com
a ausência de defeitos, erros ou falhas. Portanto, a satisfação com o produto é alcançada
quando as necessidades do cliente são supridas, e o produto se comporta como esperado
(Guerra e Colombo, 2009).
Sob esse aspecto, a norma NBR ISO/IEC 9126-1 é uma tradução da norma ISO/IEC
9126-1, e propõe características que um software deve possuir, bem como as
subcaracterísticas para incentivar o uso na prática dessa norma de qualidade de produto de
software. Ou seja, a norma abrange a totalidade das características de um produto de software,
que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas (NBR
ISO/IEC 9126-1, 2003).
Assim, a norma fornece um modelo, no qual 6 (seis) amplas categorias de
características de qualidade são definidas, cada qual com as suas subcaracterísticas, conforme
apresentada na Figura 2.1.
32
Figura 2.1. Características e subcaracterísticas de qualidade (adaptada de Guerra e
Colombo, 2009)
A norma NBR ISO/IEC 9126-1 foi estabelecida com a intenção de apoiar a aplicação
das 6 (seis) características de qualidade em uma avaliação de produto de software (Guerra e
Colombo, 2009). Na Tabela 2.1 são apresentadas as definições de cada característica de
qualidade.
Tabela 2.1. Características de qualidade (NBR ISO/IEC 9126-1, 2003)
Características Definições
Funcionalidade
Conjunto de atributos que evidencia a existência de um conjunto de funções e suas
propriedades especificadas. As funções são as que satisfazem às necessidades explícitas
ou implícitas.
Confiabilidade Conjunto de atributos que evidencia a capacidade do software de manter seu nível de
desempenho sob as condições estabelecidas durante um período de tempo definido.
Usabilidade
Conjunto de atributos que evidencia o esforço necessário para utilizar o software, bem
como o julgamento individual desse uso por um conjunto explícito ou implícito de
usuários. Entende-se por usuários aqueles que utilizam software interativo, ou seja,
operadores, usuário final e usuários indiretos, que estão sob a influência ou dependência
do uso do software.
Eficiência Conjunto de atributos que evidencia o relacionamento entre o nível de desempenho do
software e a quantidade de recursos usados, sob as condições estabelecidas.
Manutenibilidade Conjunto de atributos que evidencia o esforço necessário para fazer modificações
especificadas no software.
Portabilidade Conjunto de atributos que evidencia a capacidade do software de ser transferido de um
ambiente para outro.
Qualidade
NBR ISO/IEC 9126-1
FuncionalidadeAdequação, Acurácia, Interoperabilidade, Confo
rmidade, Segurança de Acesso
ConfiabilidadeMaturidade, Tolerância a
Falhas, Recuperabilidade, Conformidade
UsabilidadeInteligibilidade, Apreensibilidade, Operatividade,
Atratividade, Conformidade
EficiênciaComportamento em relação ao Tempo e aos
Recursos, Conformidade
ManutenibilidadeAnalisabilidade, Modificabilidade, Estabilidade, T
estabilidade, Conformidade
PortabilidadeAdaptabilidade, Capacidade para ser
Instalado, Conformidade, Capacidade para Substituir, Coexistência
33
Vale ressaltar que, para a avaliação da qualidade de produtos de software, deve-se
definir um processo de avaliação que seja responsável por fornecer passos, guias e requisitos
a serem seguidos. Por exemplo, a norma NBR ISO/IEC 14598, que oferece uma visão geral
dos processos de avaliação de produtos de software.
Assim, na busca por software de qualidade, diversos modelos foram criados para
aperfeiçoar o desenvolvimento. Por exemplo, o CMMI (Capatibility Maturity Model
integration), um modelo de melhoria de processo que aborda um conjunto de níveis de
maturidade e de práticas genéricas e/ou específicas utilizadas em conjunto (CMMI, 2006); e o
MPS.BR (Melhoria de Processo de Software Brasileiro), que apresenta 7 (sete) níveis de
maturidade e trata exclusivamente de processos de software das empresas Brasileiras, em
conformidade com o CMMI e com as normas ISO/IEC 12207 (Processo de Desenvolvimento
de Software) e ISO/IEC 15504 (evolução da norma ISO/IEC 12207) (SOFTEX, 2007, Weber
et al., 2004).
Ambos os modelos possuem restrições sobre a qualidade do software produzido
(CMMI no Nível 2 (dois) e MPS.BR no Nível F) e, portanto, exigem que a atividade de teste
seja aplicada, a fim de garantir que o produto atenda os requisitos mínimos (CMMI, 2006;
SOFTEX, 2007, Weber et al., 2004).
No entanto, fazer com que o software funcione conforme os requisitos funcionais
solicitados pelo usuário e obedecendo as características básicas de um software profissional,
aparentam serem condições triviais, mas durante o processo de desenvolvimento vários
obstáculos são encontrados, por exemplo, enganos cometidos pelos analistas de negócio,
analistas de sistemas e desenvolvedores, ou seja, todos podem contribuir para que haja um
desvio e não se alcance a qualidade almejada.
No Nível 3 (três) do CMMI e Nível E do MBS.BR, o conhecimento adquirido sobre a
qualidade de software é centralizado e começa a ser difundido pela corporação. A empresa
passa a ter a preocupação de realizar verificações para aumentar a chance de encontrar
defeitos enquanto o software estiver sendo implementado (CMMI, 2006; SOFTEX, 2007,
Weber et al., 2004).
Segundo Pressman (2011), mesmo que uma equipe experiente faça uso das melhores
práticas de garantia de qualidade durante o processo de desenvolvimento de software, ainda é
esperado que os usuários finais encontrem falhas que não foram identificadas durante as
atividades de teste. Portanto, o teste de software deve ser um processo planejado e gerenciado,
de forma a garantir que os requisitos especificados e os itens de qualidade definidos estejam
em conformidade.
34
2.4. Teste de Software
Durante a produção de um software, é necessário saber se o produto está de acordo com os
requisitos especificados e, também, se obedece às normas de qualidade. O teste de software é
a atividade de executar um software com o objetivo de encontrar diferenças entre os
resultados obtidos e os resultados esperados. É importante ressaltar que, o teste de software
visa agregar valor ao produto desenvolvido, elevando a qualidade e a confiabilidade,
desvendando e eliminando erros (Guerra e Colombo, 2009).
Farrell-Vinay (2008) apresenta algumas técnicas que podem ser aplicadas ao longo do
teste de software, cada qual utilizada em etapas específicas do teste. São elas:
Teste Funcional: também conhecido como teste de “caixa-preta”, pode ser aplicado a
qualquer unidade do software ou no sistema como um todo, pois não requer
conhecimento de como ele foi construído. A especificação do software é o suficiente
para estabelecer os critérios e os requisitos de teste;
Teste Estrutural: também conhecido como teste de “caixa-branca”, faz uso das
características da implementação para a geração dos critérios e dos requisitos de teste,
ou seja, a perspectiva interna do software é considerada;
Análise Dinâmica: técnica que utiliza todo o tipo de artefato executável, utilizado
durante o desenvolvimento para determinar os casos de teste; e
Análise Estática: técnica utilizada antes da integração do sistema, não necessita a
execução propriamente dita do produto. Ou seja, pode ser aplicada em qualquer
produto intermediário do processo de desenvolvimento.
O teste de software apresenta características e finalidades diferenciadas, variando de
acordo com cada fase do ciclo de vida do software. De acordo com Myers (2004) e Crespo et
al. (2009), as principais fases ou níveis do teste de software são caracterizados como:
Teste de Unidade: o teste de unidade ou teste unitário é efetuado pelos próprios
desenvolvedores, e apresenta como finalidade validar se as unidades individuais do
sistema (procedimento, função, método ou classe) estão de acordo com o planejado;
Teste de Integração: o teste de integração pode ser efetuado tanto por
desenvolvedores como pelos testadores e tem por finalidade identificar falhas na
integração das unidades. Ou seja, identificar falhas durante a interatividade das
unidades; e
35
Teste de Sistema: o teste de sistema é realizado por testadores e tem por finalidade
avaliar a interação global de todos os componentes de acordo com os requisitos
especificados.
Na Figura 2.2 é apresentada uma analogia com a intenção de demonstrar a diferença
entre as 3 (três) fases descritas:
Figura 2.2. Fases do teste de software
Além das fases apresentadas, o teste de software possui mais 2 (dois) níveis: teste de
aceitação e teste de regressão; apresentados a seguir:
Teste de Aceitação: o teste de aceitação é realizado por um conjunto de usuários
finais, e apresenta por finalidade verificar se o software atende os requisitos
especificados, bem como às necessidades do cliente, antes da implantação efetiva do
software; e
Teste de Regressão: realizado após o desenvolvimento de alguma melhoria ou
reparação no software, com a intenção de determinar se a alteração impactou de forma
negativa em outros aspectos do programa;
36
O teste de software pode ser aplicado de várias formas, variando de acordo com o
objetivo que se deseja atingir. De acordo com Myers (2004), os principais objetivos do teste
de software são:
Teste de Estresse: submeter o software a altas cargas e esforços e, monitorar o seu
comportamento;
Teste de Usabilidade: avaliar o impacto do fator humano no momento de manusear o
software, no que se refere à facilidade interação;
Teste de Desempenho: avaliar variações de tempo de resposta e taxas de transferência
sob certas condições de configuração do software;
Teste de Carga: avaliar o comportamento do software quando submetido a grandes
volumes de dados; e
Teste de Segurança: simular situações que desestruture as verificações de segurança
do software.
Além dos objetivos apresentados, inúmeros outros testes podem ser encontrados, por
exemplo: teste de instalação, teste de armazenamento, teste de configuração, teste de
conversão, teste de instabilidade, teste de confiabilidade, teste de recuperação, teste de
manutenção. Todas as categorias apresentadas podem ser exploradas na realização do projeto
de casos de teste (Myers, 2004).
Em relação ao teste de software, algumas terminologias devem ser padronizadas, tais
como as terminologias de erros, que estão divididas em: engano, defeito, erro e falha. O
engano (mistake em inglês) é o resultado incorreto de uma ação humana, por exemplo, uma
ação incorreta tomada pelo desenvolvedor, introduzindo um defeito. O defeito (fault ou
defect) é um passo, processo ou definição de dados incorretos, por exemplo, uma instrução ou
comando incorreto produzindo um erro. O erro (error) é a diferença entre o valor obtido e o
valor esperado. Ou seja, qualquer estado intermediário incorreto ou resultado inesperado na
execução do programa constitui um erro e, por fim, a falha (failure), que é a produção de uma
saída incorreta com relação à especificação (comando imperfeito, incompleto, ausente ou
extra no software). Ou seja, a consequência do erro (Crespo et al., 2009; Radatz, Geraci e
Katki, 1990).
Na Figura 2.3 é apresentada a cadeia de eventos que se inicia com um engano e que
pode se propagar até resultar em uma falha do software.
37
Figura 2.3. Cadeia de eventos para a falha do software (adaptada de Crespo et al., 2009)
Vale ressaltar que a atividade de teste é uma das principais atividades do ciclo de vida
do desenvolvimento de software e, como o desenvolvimento é uma atividade complexa que
envolve pessoas e processos, se torna suscetível ao engano. O engano pode ser introduzido no
software durante várias fases do projeto, por exemplo, durante o levantamento de requisitos,
codificação ou integração do software. A falta de comunicação e a carência de treinamento
entre as pessoas envolvidas no projeto também são motivos que justificam a necessidade de
testes entre e durante as fases de desenvolvimento de um software.
De acordo com Graham e Van Veenendaal (2008), a correção da falha de um software
pode custar até 100 (cem) vezes mais após o lançamento do produto se comparado com a
correção de um erro no início do desenvolvimento. Assim, quanto mais cedo um erro for
encontrado, mais barato é a sua correção. Sob esse aspecto, pode-se concluir que o custo de
encontrar e corrigir defeitos aumenta, consideravelmente, ao longo das etapas do ciclo de vida
do software, pois dependendo do nível da falha, torna-se inviável a correção devido ao alto
custo. Assim, na Figura 2.4 é apresentada uma relação entre a variável custo e tempo.
Figura 2.4. Custo dos defeitos (Graham e Van Veenendaal, 2008)
38
Enfim, a qualidade se tornou um dos principais aspectos relacionados à indústria
mundial de software, e está, diretamente, associada às atividades de teste de software, pois o
teste visa aprimorar a qualidade de um software por meio da sua execução controlada, com a
intenção de desvendar defeitos, independente da metodologia de desenvolvimento utilizada,
contribuindo para a redução de custos, manutenção corretiva e garantindo que os requisitos
sejam implementados conforme especificados (Myers, 2004).
Diante das técnicas, fases e objetivos, o teste de software deve ser conduzido por meio
de um processo, pois envolve uma série de atividades, executadas para cumprir um propósito
específico e produzir um produto tangível com base em uma determinada entrada (Mette e
Hass, 2008). Dessa forma, as atividades e recursos de teste devem ser gerenciados e pensados
de forma estratégica, pois é uma maneira eficiente de expor os pensamentos sobre o que e por
que está sendo testado.
Sob esse aspecto, a próxima Seção aborda importantes conceitos relacionados aos
processos de teste de software.
2.5. Processo de Teste de Software
Segundo Mette e Hass (2008), desde cozinhar uma refeição até o desenvolvimento de um
software, tudo é guiado por processos, os quais consistem da realização de uma série de
tarefas que visa cumprir um propósito específico e produzir um produto tangível com base em
uma determinada entrada. O real objetivo de um processo é realizar as tarefas, a fim de
estimular o pensamento, as discussões, os experimentos, as tomadas de decisões, as
documentações, de modo que os processos possam ser monitorados e melhorados. Os
documentos gerados no processo não são o principal objetivo, e sim apenas a maneira de
representar que o objetivo do processo foi cumprido.
Um processo deve sempre especificar as entradas, listas de atividades e descrição das
saídas. Ou seja, deve apresentar um conjunto de passos parcialmente ordenados, constituídos
por atividades, métodos, práticas e transformações, utilizadas para atingir um objetivo. Este
objetivo geralmente está associado a um ou mais resultados finais, que são os produtos
resultantes da execução do processo (Crespo et al., 2010a; Humphrey, 1989).
De acordo com a definição de processo, o teste de software deve ser considerado como
tal, utilizado para testar um produto de software, definido entre os seguintes principais
componentes: entradas, mecanismos e agentes, restrições e condições e saídas (Crespo et al.,
2010a). Além disso, um processo de testes de software engloba diferentes partes interessadas
39
no processo de desenvolvimento, tais como: desenvolvedores, equipe de garantia de
qualidade, gerentes de projeto, coordenadores de equipe e usuários finais (Pressman, 2011).
Na Figura 2.5 são apresentados os componentes de um processo de testes de software
e como eles se relacionam.
Figura 2.5. Componentes do processo de testes de software (Crespo et al., 2010a)
O primeiro componente do processo de testes refere-se às entradas, ou seja, todas as
informações necessárias para a execução do teste do software, tais como: informações do
software, especificação de requisitos, estratégia de testes, plano de projeto, informações sobre
como o teste está progredindo. Os mecanismos e agentes são as equipes de teste, as técnicas
de teste aplicadas, os procedimentos de teste e as ferramentas. As restrições e condições
referem-se aos cronogramas, custos, confiabilidade requerida e critérios de aceitação. As
saídas são os resultados, produtos da execução das atividades, tais como: software testado,
defeitos revelados, nível de confiabilidade atingido, qualidade desejada, relatório de progresso
e especificação de teste (Crespo et al., 2010a; Mette e Hass, 2008).
É importante ressaltar que o teste de software é uma atividade prática combinada com
teorias, tecnologias, ferramentas e gestão. Entre estes 4 (quatro) aspectos importantes, a
gestão das atividades de teste desempenha um papel de destaque no projeto de software e não
deve ser ignorado (Mao e Zhang, 2007).
Processo de Testes de Software
Restrições e Condições
Entradas
Mecanismos e Agentes
Saídas
40
Dessa forma, o teste de software deve ser gerenciado respeitando 4 (quatro) principais
subprocessos: i) planejamento do teste, ii) projeto do teste, iii) execução do teste e iv)
conclusão do teste; conforme apresentado na Figura 2.6.
Figura 2.6. Processo de teste de software (adaptada de Mao e Zhang, 2007)
O planejamento do teste é o subprocesso inicial do processo de testes de software e
está relacionado diretamente com a definição do documento plano de teste. O gerente de
testes responsável pelas tarefas que compõem o planejamento deve reunir no plano de testes
as informações relacionadas com: análise de risco do produto do teste, objetivos do teste,
estratégia do teste, estimativas, esforço e custo, orçamento e cronograma, recursos humanos,
ambiente de teste, artefatos gerados e desempenho. O nível de formalismo e detalhes
apresentados no plano de teste depende de alguns fatores, como a maturidade do processo de
testes em uma determinada organização (Crespo et al., 2010a; SOFTEX, 2011).
Após a definição do plano de testes, os subprocessos projeto e execução do teste
envolvem tarefas relacionadas à identificação e execução de casos de testes e reportar e
acompanhar incidentes. Antes da execução do teste, torna-se necessário saber o que está
sendo verificado, quais as entradas, procedimentos e resultados que devem ser produzidos e
como o teste deve ser executado. Os testadores executam os testes verificando o resultado
obtido e comparando com os resultados esperados. Caso divergências sejam percebidas entre
o resultado esperado e o obtido, incidentes identificados devem ser registrados e reportados
para os responsáveis. O incidente deve ser analisado e acompanhado até a sua correção e
encerramento. A conclusão do teste está relacionada com a correção dos incidentes e da
evolução da qualidade do produto, até o fechamento do processo (Mao, Zhang, 2007;
SOFTEX, 2011).
41
Além dos subprocessos apresentados (planejamento, projeto, execução e conclusão), o
teste deve ser constantemente monitorado, controlado e replanejado, para que a execução
ocorra de forma controlada. A partir do momento que desvios forem identificados, ações
corretivas devem ser tomadas e o planejamento revisto. Sob esse aspecto, a norma ISO/IEC
29119 estabelece, na segunda parte (Processo de Teste), um processo específico para
controlar e monitorar o teste.
Dessa forma, na Figura 2.7 é apresentado, de forma cômica, como o teste sofre um
estreitamento, caso o processo não apresente um monitoramento e controle adequado das
atividades realizadas, a fim de não perder espaço e cumprir com o que foi planejamento no
início do projeto (Mette e Hass, 2008).
Figura 2.7. Importância do monitoramento, controle e replanejamento do teste
(Mette e Hass, 2008)
A disciplina de teste demanda tempo e recursos e, por isso, deve ser planejada e
monitorada com o intuito de organizar quem faz o que, quando e o que vai ser obtido de
resultado. Além disso, o Gerente de Teste deve estar envolvido com grupos de avaliação e
certificação, analistas de negócio, desenvolvedores, gerentes de projeto, equipes de garantia
de qualidade, equipes de segurança, testadores, enfim, todos os envolvidos no projeto de
desenvolvimento, a fim de que haja um maior envolvimento das equipes, contribuindo para o
aperfeiçoamento do processo de testes (Farrell-Vinay, 2008).
42
Vale ressaltar que, a falta de documentação por parte da equipe de análise e
desenvolvimento é uma das grandes causas de estresse e fadiga nos responsáveis pelas
atividades de teste. A equipe de testes deve ter boas informações sobre o que está sendo
produzido e quais os critérios de aceitação para um bom funcionamento do software.
2.5.1. Modelos de Melhoria de Processos de Teste de
Software
As atividades de testes são responsáveis por altos percentuais de custos nos projetos de
software, o que corresponde de 30 a 40% do custo total do projeto. Diante disso, é evidente a
grande dificuldade das empresas com relação à intenção de diminuir os gastos com defeitos
de software e aumentar a produtividade das equipes de testes (Van Veenendaal, 2008).
Com a intenção de auxiliar as empresas a conduzir suas atividades de teste, os
modelos: Testing Maturity Model integration (Van Veenendaal, 2008), Test Process
Improvement (Koomen e Pol, 1999), Testing Improvement Model (Ericson, Subotic e Ursing,
1997), Melhoria do Processo de Teste Brasileiro (SOFTEX, 2011) e a norma ISO/IEC 29119,
são alguns exemplos de recomendações para aprimorar o processo de teste das organizações e
contribuir para a maturidade das atividades.
2.5.1.1. Testing Maturity Model integration (TMMi)
O modelo de maturidade de teste TMMi é o modelo mais conhecido e utilizado na Europa e
Estados Unidos, composto por 2 (dois) principais componentes: o modelo de maturidade e o
modelo de avaliação. O TMMi é um modelo detalhado para a melhoria do processo de testes
mantido pela TMMi Foundation (Van Veenendaal, 2008) e complementa o modelo CMMI
(Capability Maturity Model Integration).
O modelo é constituído de etapas ou níveis por meio dos quais uma organização
submete seu processo de teste para evoluir de um nível ad hoc e não gerenciado, para níveis
gerenciados, definidos, medidos e otimizados. Cada nível de maturidade, com exceção do
nível Inicial 1 (um), tem uma estrutura composta por um conjunto de metas de maturidade, os
limites e as realizações necessárias para um determinado nível (Jacobs, Van Moll e Stokes,
2000; Van Veenendaal, 2008).
Há 5 (cinco) níveis no modelo TMMi que prescrevem uma hierarquia de maturidade e
um caminho evolutivo para a melhoria do processo de teste. Cada nível tem um conjunto de
áreas de processo que uma organização necessita implementar para atingir a maturidade a esse
nível. O Nível 1 (um) do modelo é denominado Inicial, e as atividades de teste são realizadas
43
de forma ad hoc e não gerenciadas. O Nível 2 (dois) é denominado Gerenciado, e apresenta
áreas de processo relacionadas com o ambiente de teste, execução e projeto de teste, controle
e monitoramento, planejamento do teste, estratégia e política de teste. O Nível 3 (três) é
denominado Definido, e apresenta áreas de processo relacionadas com revisões em pares,
testes não funcionais, integração e ciclo de vida do teste, programas de treinamento e
organização do teste. O Nível 4 (quatro) é denominado Medido, e apresenta áreas de processo
relacionadas com revisões em pares avançadas, evolução da qualidade do software e medições
de teste. O Nível 5 (cinco) é denominado Otimização, e apresenta áreas de processo
relacionadas com controle de qualidade, otimização do processo de teste e prevenção de
defeitos. Na Figura 2.8 é apresentada a evolução e os níveis de maturidade do modelo TMMi
(Van Veenendaal, 2008).
Figura 2.8. Níveis de maturidade e principais áreas de processo do modelo TMMi (Van
Veenendaal, 2008)
44
2.5.1.2. Test Process Improvement (TPI)
O modelo de Melhoria do Processo de Teste (TPI) foi desenvolvido com base no
conhecimento prático e experiências de desenvolvimento do processo de teste em 1997 por
Koomen e Pol, e apresenta semelhança aos modelos Capability Maturity Model Integration
(CMMI, 2006) e Test Maturity Model integration (Van Veenendaal, 2008). O modelo TPI
fornece subsídios para a evolução da maturidade do processo de teste das organizações e
sugere métodos de melhoria controláveis, por meio de uma matriz, que inclui um total de 20
(vinte) áreas de atuação (Key Area Cornerstone) e 4 (quatro) níveis (Jung, 2009; Koomen e
Pol, 1999).
O modelo visa aprimorar a maturidade do processo de teste e, para isso, sugere
métodos sequenciais de melhoria. Para atribuir um determinado nível ao processo de teste, um
ou mais pontos de exigência são atribuídos a cada nível. Se o processo de teste passar por
todos os pontos de controle de determinado nível, então o processo é classificado a esse nível,
auxiliando a definir passos para a melhoria dos processos de teste.
Além do mapeamento da situação atual do processo de teste, as áreas-chave e os níveis
podem ser utilizados para definir a situação desejada e, quais os passos necessários para
atingir determinado nível. Ou seja, a forma como as áreas-chave são organizadas dentro de
um processo de teste determina a maturidade do processo. Sugestões de melhoria foram
adicionadas ao modelo para auxiliar o processo de teste a atingir determinado nível de
maturidade. Vale lembrar que, o modelo TPI fornece referências para determinar os pontos
fortes e fracos do processo de teste atual e auxilia na formulação de ações específicas para a
melhoria do processo de teste (Koomen e Pol, 1999).
Na Tabela 2.2 é apresentada uma matriz que reúne as 20 (vinte) Áreas-Chave e os 4
(quatro) Níveis que compõem o modelo. O Nível A é o primeiro a ser executado, seguido
pelos Níveis B, C e D.
Tabela 2.2. Níveis e áreas-chave do modelo TPI (Koomen e Pol, 1999)
Áreas-Chave/ Níveis
A B C D
Estratégia de Teste
Estratégia de teste
simples para testes
de alto nível
(funcionalidades
essenciais e mais
importantes)
Estratégia de teste
combinada para
testes de alto nível
(baseados em
riscos)
Estratégia
combinada para
testes de alto e
baixo nível
Estratégia
combinada para
todos os testes
Continua
45
Áreas-Chave/ Níveis
A B C D
Modelo de Ciclo de
Vida
Planejamento,
Especificação e
Execução
Planejamento,
Preparação,
Especificação,
Execução e
Conclusão
-- --
Quando se
envolver?
Conclusão do
sistema Início do sistema
Início da definição
dos requisitos Início do projeto
Estimativa e
Planejamento
Realizar a
estimativa e o
planejamento
Planejamento e
Estimativa
Comprovada
(monitorar)
-- --
Técnicas de
Especificação de
Teste
Técnicas Informais Técnicas Formais -- --
Técnicas de Teste
Estático Inspeção de Testes Checklists -- --
Métricas Métricas - Produto Métricas - Processo Métricas - Software Métricas -
Organização
Ferramentas de
Teste
Ferramentas de
Controle e
Planejamento
Ferramentas de
Análises e
Execução
Automação
Extensiva do
Processo de Teste
--
Ambiente de Teste Gerenciado e
Controlado
Ambiente de teste
adequado
Ambiente adaptável
e flexível as
mudanças
--
Ambiente de
Trabalho
Adequado
(infra-estrutura
necessária)
-- -- --
Comprometimento
e Motivação
Atribuição de
Orçamento e
Tempo
Teste integrado
com o projeto
Engenheiro de
Teste --
Funções de Teste e
Treinamento
Testadores e
Gerentes de Teste
Gerência e suporte
ao processo de
testes, documentos
e infra-estrutura
Garantia de
Qualidade Formal --
Escopo da
Metodologia Projeto Específico
Organização
Genérica
Organização
Otimizada --
Comunicação Comunicação
Interna
Comunicação do
Projeto
Comunicação com
a Organização
sobre a Qualidade
do Processo de
Teste
--
Relatórios Defeitos
Progresso (status
do teste e
produtos),
atividades (custos e
tempo, marcos),
defeitos com
prioridade
Riscos e
Recomendações
justificadas com
métricas
Recomendações
sobre a Melhoria
do Processo de
Software
Continua
46
Áreas-Chave/ Níveis
A B C D
Gerenciamento de
Defeitos
Gerenciamento
interno de Defeitos
Gerenciamento de
Defeitos com
flexibilidade
Gerenciamento de
Defeito - Projeto --
Gerenciamento de
Artefatos
Gerenciamento
interno dos
documentos
Gerenciamento
Externo dos
Objetos e Base de
Teste
Artefatos
Reutilizáveis
Rastreabilidade
entre os requisitos e
os casos de teste
Gerenciamento do
Processo de Teste
Planejamento e
Execução
Planejamento,
Execução,
Monitoramento e
Ajustes
Monitoramento e
Ajustes na
Organização
--
Avaliação Técnicas de
Avaliação
Estratégia de
Avaliação -- --
Teste de Baixo
Nível
Ciclo de Vida -
planejamento,
escrita e execução
Técnicas de Caixa-
Branca
Estratégia (baseado
em riscos, técnicas
formais e
informais)
--
2.5.1.3. Testing Improvement Model (TIM)
O Modelo de Melhoria de Teste (TIM) é composto por 2 (dois) componentes principais: i)
estrutura que consiste em níveis e áreas-chave; e ii) processo de avaliação. O modelo TIM
possui 4 (quatro) níveis de melhoria e 5 (cinco) áreas-chave. Cada área-chave é responsável
por uma melhoria específica para as atividades de teste. Para cumprir os objetivos de uma
área-chave, deve-se passar pelas 4 (quatro) etapas de melhoria (Ericson, Subotic e Ursing,
1997).
Iniciando do nível mais básico para o mais complexo, os níveis de melhoria do modelo
TIM são:
Base:
o Padronização de documentos;
o Políticas;
o Procedimentos;
o Metodologias e métodos; e
o Teste funcional básico.
Custo Eficiente:
o Custo mínimo de retrabalho e manipulação de mudança;
o Teste rápido e sistemático;
o Realização das tarefas no "caminho certo"; e
o Mínimo de retrabalho em artefatos existentes.
47
Redução de Riscos:
o Suporte para todos os níveis de gestão;
o A detecção de erros de risco; e
o Cronograma baseado em riscos e utilização de recursos.
Otimização:
o Gerenciar testes correspondentes a política de qualidade da organização;
o Mudança cultural no sentido da prevenção e melhoria contínua;
o O teste é totalmente integrado com o ciclo de vida do projeto; e
o As decisões são baseadas em fatos.
As 5 (cinco) áreas-chave que fazem parte do modelo TIM são: Organização,
Planejamento e Controle, Casos de Teste, Artefatos e Revisões. O planejamento é uma parte
importante do projeto de testes, pois sem os objetivos claramente definidos e as estratégias
traçadas, os recursos podem ser gastos de maneira errada. O controle é necessário, a fim de
monitorar o progresso das atividades que estão sendo realizados. Todos os testes devem ser
realizados com base nos casos de teste especificados antes da execução. A elaboração e
seleção de casos de teste são aspectos importantes do teste de software, pois impacta
diretamente no esforço exigido. Os artefatos são os procedimentos de testes reais que são
executados, os conjuntos de dados que são usados para executar os testes e a documentação
de apoio, além da gestão de configuração e o uso de ferramentas. Por fim, o termo revisão é
utilizado como um nome genérico, abrangendo todas as técnicas que envolvem leitura ou
inspeção visual de documentos de software (Ericson, Subotic e Ursing, 1997).
2.5.1.4. Melhoria do Processo de Teste Brasileiro (MPT.BR)
O MPT.BR é um modelo para a melhoria do processo de teste, desenvolvido para apoiar a
condução das atividades de testes das organizações Brasileiras que desenvolvem produtos de
software, por meio de áreas de processos e suas respectivas práticas. O modelo proporciona o
aumento da qualidade dos produtos de software por meio da melhoria contínua dos processos
de testes, atribuindo níveis de maturidade aos processos. De acordo com Furtado et al. (2012),
os principais objetivos do modelo MPT.BR, são:
Tornar-se um modelo de referência para a definição e institucionalização do processo
de teste em organizações;
Contribuir para a melhoria contínua do processo de teste de software de acordo com os
objetivos organizacionais e níveis de maturidade desejada;
48
Fornecer uma base para a avaliação e, identificar o nível de maturidade que está
presente nas organizações, e
Coletar as melhores práticas e estruturá-las de acordo com os níveis de complexidade
e de maturidade associados.
O modelo MPT.BR consiste em dois principais componentes: i) Modelo de Referência
(documento que apresenta a estrutura principal, as áreas de processo e as práticas do modelo),
e ii) Guia de Avaliação (documento que inclui o processo de avaliação e instruções sobre a
avaliação de uma organização que está baseada no modelo MPT.BR).
Com exceção do modelo MPT.BR, nenhum dos modelos apresentados anteriormente
possui representantes no Brasil, o que eleva o custo da implementação e dificulta a sua
prática. Assim, o modelo MPT.BR apresenta 5 (cinco) níveis de maturidade que representam
a evolução do processo de teste de uma organização (Furtado et al., 2012; SOFTEX, 2011).
Os níveis são:
Nível 1 (Parcialmente Gerenciado) - representa o primeiro patamar de maturidade de
uma organização. Ele contém o mínimo que uma organização precisa para demonstrar
que a disciplina de teste é aplicada nos projetos e que esta aplicação ocorre de forma
planejada e controlada;
Nível 2 (Gerenciado) - a aplicação do processo de teste na organização possui maior
visibilidade. O escopo do projeto passa a ser controlado pelo processo de gestão de
mudanças, padrões são definidos e os processos são monitorados e controlados;
Nível 3 (Definido) - processos padrões de teste são adotados, a garantia da qualidade é
instituída de modo a auxiliar a definição dos processos, são definidas
responsabilidades para a organização do teste e um programa de medição é implantado
na organização. O ciclo de vida do teste é integrado ao ciclo de vida do
desenvolvimento, o teste estático e de aceitação são formalizados e procedimentos
sistemáticos são aplicados para o fechamento do teste;
Nível 4 (Prevenção de Defeitos) - estabelece a prevenção de defeitos e melhoria
sistemática da qualidade do produto. A organização deve desenvolver um processo de
gestão, no qual os defeitos encontrados são acompanhados e ações proativas são
tomadas para evitar que novos defeitos sejam originados pelas mesmas causas. Uma
análise de risco dos atributos não-funcionais do produto e atividades de teste não-
funcional é executada para minimizar estes riscos e também é realizada uma análise
49
para determinar a eficácia do teste e a determinação com dados objetivos do nível de
qualidade do produto; e
Nível 5 (Automação e Otimização) – o último nível do modelo estabelece um processo
de melhoria contínua e automação do teste, no que se refere a uma abordagem
sistemática para automação da execução do teste, além de um processo sistemático
para seleção e adoção de ferramentas CASE (Computer-Aided Software Engineering).
Na Tabela 2.3 são apresentados os níveis de maturidade, as áreas de processo e as
respectivas tarefas que compõem o modelo MPT.BR.
Tabela 2.3. Níveis de maturidade, áreas de processo e tarefas do modelo MPT.BR (adaptada
de Furtado et al., 2012 e SOFTEX, 2011)
Níveis de
Maturidade
Áreas de
Processo Práticas
Nível 1 -
Parcialmente
Gerenciado
GPT - Gerência de
Projetos de Teste
GPT1 - Realizar análise de risco do produto
GPT2 - Estabelecer objetivos do teste
GPT3 - Definir estratégia de teste
GPT4 - Definir o escopo do trabalho para o projeto de teste
GPT5 - Estabelecer estimativas de tamanho
GPT6 - Definir o ciclo de vida do projeto de teste
GPT7 - Estimar o esforço e o custo
GPT8 - Estabelecer e manter o orçamento e o cronograma do projeto
GPT9 - Identificar riscos do projeto
GPT10 - Planejar os recursos humanos
GPT11 - Planejar o ambiente de teste para o projeto
GPT12 - Planejar os artefatos e dados do projeto
GPT13 - Estabelecer indicadores de desempenho de teste
GPT14 - Estabelecer o Plano de Teste
GPT15 - Revisar e obter compromisso com o Plano de Teste
GPT16 - Monitorar o projeto
GPT17 - Gerenciar o envolvimento dos stakeholders
GPT18 - Executar revisões em marcos do projeto
GPT19 - Analisar e registrar os problemas identificados
GPT20 - Estabelecer e acompanhar ações corretivas até a sua
conclusão
PET - Projeto e
Execução de Teste
PET1 - Identificar casos de teste
PET2 - Executar casos de teste
PET3 - Reportar incidentes
PET4 - Acompanhar incidentes
Continua
50
Níveis de
Maturidade
Áreas de
Processo Práticas
Nível 2 -
Gerenciado
GRT - Gerência de
Requisitos de Teste
GRT1 - Obter o entendimento dos requisitos
GRT2 - Obter o comprometimento com os requisitos
GRT3 - Gerenciar as mudanças dos requisitos
GRT4 - Manter a rastreabilidade bidirecional dos requisitos
GRT5 - Identificar inconsistência entre requisitos, planos do projeto
e produtos de trabalho
GPT - Gerência de
Projetos de Teste
(evolução)
GPT21 - Definir critérios de entrada e saída do teste
GPT22 - Definir critérios de suspensão e reinício do teste
GPT23 - Monitorar critérios de entrada, saída, suspensão e reinício
do teste
GPT24 - Monitorar defeitos
GPT25 - Planejar e conduzir revisões de qualidade do produto
PET - Projeto e
Execução de Teste
(evolução)
PET5 - Estabelecer padrões de documentação de casos de teste
PET6 - Estabelecer padrões de documentação de incidentes
Nível 3 -
Definido
FDT - Fechamento
do Teste
FDT1 - Empacotar ativos de teste
FDT2 - Limpar ambiente de teste
FDT3 - Identificar lições aprendidas
FDT4 - Consolidar dados de teste
GDQ - Garantia da
Qualidade
GDQ1 - Avaliar processos e produtos de trabalho
GDQ2 - Comunicar e resolver questões
GDQ3 - Estabelecer registros
MAT - Medição e
Análise de Teste
MAT1 - Definir objetivos de medição de teste
MAT2 - Estabelecer e documentar medidas
MAT3 - Especificar procedimentos de medição
MAT4 - Coletar, analisar e comunicar dados de medição
MAT5 - Armazenar dados de medição
OGT - Organização
do Teste
OGT1 - Definir a estrutura organizacional do teste
OGT2 - Estabelecer um Grupo de processo de teste de software
OGT3 - Definir processos padrão de teste
OGT4 - Definir guias e critérios de adaptação do processo
OGT5 - Estabelecer a biblioteca de artefatos de processo de teste
OGT6 - Coletar informações e implementar ações de melhoria
OGT7 - Identificar perfis de teste
OGT8 - Definir planos de carreira de teste
OGT9 - Integrar ciclos de vida de teste e desenvolvimento
OGT10 - Estabelecer e manter a Estratégia Organizacional de Teste
TDA - Teste de
Aceitação
TDA1 - Selecionar produtos
TDA2 - Definir critérios de aceitação
TDA3 - Definir papéis e responsabilidades
TDA4 - Definir plano de aceitação
TDA5 - Preparar ambiente para aceitação
TDA6 - Conduzir testes de aceitação
TDA7 - Avaliar condições de aceitação
Continua
51
Níveis de
Maturidade
Áreas de
Processo Práticas
TES - Teste
Estático
TES1 - Identificar produtos de trabalho e tipos de revisão
TES2 - Definir critérios de revisões
TES3 - Conduzir revisões
TES4 - Analisar dados de revisões
TES5 - Conduzir análises estáticas
TRE - Treinamento
TRE1 - Definir um programa de treinamento organizacional
TRE2 - Prover treinamentos
TRE3 - Registrar treinamentos
TRE4 - Avaliar a efetividade de treinamentos
GPT - Gerência de
Projetos de Teste
(evolução)
GPT26 - Gerenciar dados de teste
GPT27 - Verificar aptidão do ambiente de teste
GPT28 - Gerenciar incidentes de ambiente
PET - Projeto e
Execução de Teste
(evolução)
PET7 - Aplicar técnicas de projeto (design) de teste
Nível 4 -
Prevenção de
Defeitos
AQP - Avaliação da
Qual. do Produto
AQP1 - Identificar demanda de qualidade do produto
AQP2 - Definir objetivos quantitativos de qualidade do produto
AQP3 - Definir abordagem para acompanhar a qualidade do produto
AQP4 - Medir a qualidade do produto
AQP5 - Analisar objetivos de qualidade
GDD - Gestão de
Defeitos
GDD1 - Determinar causas de defeitos
GDD2 - Definir ações corretivas
GDD3 - Avaliar efetividade
TNF - Teste Não-
Funcional
TNF1 - Realizar análise de risco não-funcional
TNF2 - Projetar teste não-funcional
TNF3 - Conduzir teste não-funcional
OGT - Organização
do Teste (evolução)
OGT11 - Identificar oportunidades de reuso
OGT12 - Reusar ativos de teste
Nível 5 -
Automação e
Otimização
AET - Automação
da Execução do
Teste
AET1 - Definir objetivos do regime de automação
AET2 - Definir critérios para seleção de casos de teste para
automação
AET3 - Definir um framework para automação de teste
AET4 - Gerenciar incidentes de teste automatizado
AET5 - Verificar aderência aos objetivos de automação
AET6 - Analisar retorno sobre investimento na automação
CEP - Controle
Estatístico do
Processo
CEP1 - Estabelecer objetivos de desempenho de processos
CEP2 - Selecionar processos
CEP3 - Estabelecer medidas de desempenho de processos
CEP4 - Estabelecer baselines de desempenho de processos
CEP5 - Estabelecer modelos de desempenho
GDF - Gestão de
Ferramentas
GDF1 - Identificar necessidade de ferramentas
GDF2 - Selecionar ferramentas
GDF3 - Conduzir projeto piloto
GDF4 - Selecionar gurus de ferramentas
GDF5 - Definir estratégias de implantação de ferramentas
GDF6 - Implantar ferramentas
52
Além das práticas específicas apresentadas, os Níveis 1 (um) e 2 (dois) do modelo
MPT.BR apresentam algumas Práticas Genéricas (PG), são elas:
Nível 1 (um):
o PG1 - Atingir os resultados definidos;
o PG2 - Estabelecer política organizacional;
o PG3 - Planejar a execução do processo;
o PG4 - Identificar e disponibilizar recursos;
o PG5 - Definir responsabilidade e autoridade; e
o PG6 - Prover treinamento.
Nível 2 (dois):
o PG7- Controlar produtos de trabalho;
o PG8 - Monitorar e controlar o processo; e
o PG9 - Fornecer visibilidade do processo para a gerência superior.
Segundo Furtado et al. (2012), a maioria das organizações que implantaram o modelo
MPT.BR estão nos níveis iniciais de maturidade. No entanto, percebe-se que o modelo está
contribuindo para a melhoria dos processos de testes e, consequentemente, da qualidade do
produto. Além disso, os responsáveis pelas organizações apresentaram feedbacks positivos em
relação aos resultados obtidos com o modelo, mostrando interesse em continuar aprimorando
a maturidade dos processos. Assim, apesar do MPT.BR apresentar uma base estável, ele ainda
é recente e necessita de resultados relacionados principalmente com os níveis de maturidade 2
(dois), 3 (três), 4 (quatro) e 5 (cinco), no que se refere a avaliação e aperfeiçoamento do
modelo.
Segundo o site oficial do MPT.BR1, até Agosto 2012, apenas 15 (quinze) empresas
passaram pelo processo de avaliação em todo o território Brasileiro, sendo 8 (oito) do estado
de Pernambuco (PE). De acordo com as informações coletadas junto ao Comitê Gestor do
MPT.BR, uma empresa está implementando o Nível 3 (Pernambuco) do modelo e outra o
Nível 1 (Paraná), e possivelmente, no final do ano de 2012, 17 (dezessete) empresas estarão
certificadas no modelo MPT.BR. O porte dessas empresas varia entre aquelas com áreas de
teste bem reduzidas até áreas muito grandes, como o Departamento de Informática do Sistema
Único de Saúde (SUS) do Ministério da Saúde – DATASUS do estado do Rio de Janeiro
(RJ).
1 http://www.mpt.org.br/
53
2.5.1.5. ISO/IEC 29119
Além dos modelos apresentados (TMMi, TPI, TIM e MPT.BR), encontra-se em processo de
elaboração pela International Organization for Standardization (ISO) a norma ISO/IEC
29119 que define um modelo padrão para o processo de teste de software nas organizações,
dividida em 4 (quatro) partes principais: Parte 1 (Conceitos e Definições), Parte 2 (Processo
de Teste), Parte 3 (Documentação de Teste) e Parte 4 (Técnica de Teste).
Vale ressaltar que, a norma ISO/IEC 29119 não será um modelo de maturidade. Ou
seja, a norma não estabelece um caminho de melhoria, mas apenas define os processos
necessários para o teste de software. Assim, de acordo com o site oficial da norma2, as
principais partes envolvidas apresentam as seguintes características:
Parte 1 (Conceitos e Definições - ISO/IEC 29119-1) – refere-se a uma visão geral dos
conceitos envolvidos ao longo do ciclo de vida do teste, a fim de padronizar um
vocabulário para a documentação envolvida. Os tópicos abordados são: introdução ao
teste de software, o papel da verificação e validação, teste exaustivo, teste de software
no contexto organizacional e projeto, o processo de testes, processo de teste genérico
no ciclo de vida do sistema, manutenção contínua, testes baseados em riscos, objetivos
do teste, técnicas de teste;
Parte 2 (Processo de Teste - ISO/IEC 29119-2) – refere-se a um processo genérico de
teste que pode ser utilizado em qualquer projeto de desenvolvimento de software ou
ciclo de vida de testes, incluindo várias camadas do processo: processo de teste
organizacional, processo de planejamento de teste, processo de controle e
monitoramento do teste, processo de conclusão do teste, processo de teste dinâmico,
processo de implementação e projeto de teste, processo de manutenção e configuração
do ambiente de teste, processo de execução do teste e processo para reportar incidentes
de teste;
Parte 3 (Documentação de Teste - ISO/IEC 29119-3) – baseou-se na norma IEEE 829
– Documentação de Teste e refere-se a documentação necessária durante o ciclo de
vida do teste de software, incluindo: políticas de teste organizacional, estratégia de
teste organizacional, plano de teste, relatório de progresso de teste, relatório de
conclusão de teste, especificação do projeto de teste, especificação de casos de teste,
especificação de procedimentos de teste, requisitos de dados de teste, requisitos do
2 http://www.softwaretestingstandard.org/
54
ambiente de teste, relatório do ambiente de teste, resultados de teste, relatórios de
execução e incidentes de teste; e
Parte 4 (Técnicas de Teste - ISO/IEC 29119-4) – baseou-se no padrão BS-7925-1/2
desenvolvido pela Testing Standards Working Party3 e refere-se às técnicas de testes
utilizadas ao longo do ciclo de vida do teste, como as técnicas de teste baseadas em
especificações (caixa-preta) e técnicas de teste baseadas em estruturas (caixa-branca).
Além disso, a norma define tipos de testes relacionados com a qualidade, tais como:
teste de acessibilidade, teste de compatibilidade, teste de conversão, testes funcionais,
testes de interoperabilidade, testes de manutenibilidade.
Vale lembrar que, a norma ISO/IEC 29119 será o padrão mundial de documentação de
testes, pois se trata de uma evolução da norma IEEE 8294. No entanto, a norma ainda está em
processo de desenvolvimento e pode sofrer alterações, por isso deve ser utilizada com cautela
(Rios, Cristalli e Moreira Filho, 2011).
Segundo SOFTEX (2011), além dos modelos e normas apresentados referentes à
melhoria dos processos de testes, também é possível encontrar na literatura outros modelos,
por exemplo: Testability Support Model (TSM), Testing Assessement Program (TAP), Testing
Assessment Program (TAP), Test Organization Maturity (TOMTM), Maturity Model for
Automated Software Testing, Modelo de Melhoria de Teste (MMT).
2.5.1.6. Relação entre Áreas de Processo dos Modelos de
Teste de Software
Conforme apresentado na Seção anterior (2.5.1 Modelos de Melhoria de Processos de Teste
de Software), os modelos apresentados disponibilizam várias áreas de processo e suas
respectivas práticas que devem ser cumpridas para alcançar um determinado objetivo. Sob
esse aspecto, o Instituto de Teste de Software (iTeste) estabeleceu uma relação das áreas de
processo dos modelos de maturidade TMMi, MPT.BR e a norma ISO/IEC 29119-2, com a
intenção de apresentar a equivalência das áreas de processo entre os modelos. Na Tabela 2.4 é
apresentada a relação entre as áreas de processo dos modelos descritos neste capítulo.
3 http://www.testingstandards.co.uk/ 4 http://standards.ieee.org/findstds/standard/829-1983.html
55
Tabela 2.4. Relação entre as áreas de processo dos modelos TMMi, MPT.BR e a norma
ISO/IEC 29119-2 (Rios, 2013)
MPT.BR TMMi ISO/IEC 29119-2
Gerência de Projetos de Teste
(GPT) Planejamento de Teste Planejamento de Teste
Projeto e Execução de Teste
(PET) Projeto e Execução de Teste
Projeto e Implementação de Teste; Execução de Teste; Relatar Incidente de Teste;
Gerência de Requisitos de
Teste (GRT) -- --
Fechamento do Teste (FDT) -- Fechamento de Teste
Garantia da Qualidade (GDQ) Controle de Qualidade --
Medição e Análise de Teste
(MAT) Medição de Teste --
Teste de Aceitação (TDA) -- --
Teste Estático (TES) Revisão --
Treinamento (TRE) Programa de Treinamento de
Teste --
Avaliação da Qualidade do
Produto (AQP) Avaliação da Qualidade do Produto
--
Gestão de Defeitos (GDD) Prevenção de Defeito --
Teste Não-Funcional (TNF) Teste Não-Funcional --
Organização do Teste (OGT) Organização de Teste --
Automação da Execução do
Teste (AET) -- --
Controle Estatístico do
Processo (CEP) Otimização do Processo de
Teste --
Gestão de Ferramentas (GDF) -- --
Gerência de Projetos de Teste
(GPT) Monitoramento e Controle de Teste
Monitoramento e Controle
Continua
56
MPT.BR TMMi ISO/IEC 29119-2
Gerência de Projetos de Teste
(GPT) Ambiente de Teste
Estabelecer e Manter o
Ambiente de Teste
-- Política e Estratégia de Teste Processo Organizacional de
Teste
Gerência de Projetos de Teste
(GPT) Ciclo de Vida e Integração de Teste
--
Gerência de Projetos de Teste
(GPT) Revisão Avançada --
De acordo com a relação das áreas de processo apresentadas na Tabela 2.4, é possível
observar que o modelo MPT.BR não apresenta processos de suporte para as áreas
relacionadas com políticas de teste e processo organizacional do teste. Observa-se que o
modelo TMMi não apresenta suporte para as áreas de gerência de requisitos de teste,
fechamento de teste, testes de aceitação, automação da execução do teste e gestão de
ferramentas. A norma ISO/IEC 29119-2 não oferece suporte para as áreas relacionadas com
gerência de requisitos de teste, garantia de qualidade, medição e análise de teste, teste de
aceitação e estático, treinamento, avaliação da qualidade do produto, gestão de defeitos, teste
não-funcional, organização do teste, automação da execução do teste, controle estatístico do
processo, gestão de ferramentas.
2.6. Ambiente Móvel
Com o aumento significativo da utilização dos dispositivos móveis (meados do ano de 2009),
o número de aplicações para tal também acompanhou essa evolução e empresas estão
investindo em aplicativos para dispositivos móveis com o intuito de estreitar a relação com o
cliente e, em contrapartida, fazer com que a empresa se aproxime cada vez mais dos clientes
(Kim et al. 2011).
De acordo com Ballard (2007), o desenvolvimento de aplicações para dispositivos
móveis deve considerar 3 (três) principais fatores relacionados com o ambiente móvel:
contexto móvel, usuário de dispositivo móvel e aplicação móvel, conforme apresentado na
Figura 2.9.
57
Figura 2.9. Fatores que definem o ambiente móvel
O contexto móvel está associado às limitações dos dispositivos móveis; o usuário de
dispositivo móvel está associado à mobilidade que os dispositivos móveis oferecem para os
usuários, e a aplicação móvel está associada às peculiaridades dos produtos de software que
operam em dispositivos móveis. Os fatores descritos que constituem o ambiente móvel são
apresentados de forma mais detalhada nas seções que seguem.
2.6.1. Contexto Móvel
Dentre as limitações que caracterizam o contexto móvel, tais como: bateria, tamanho de tela,
conexão, teclado, processamento, destaca-se uma importante característica que é a capacidade
do usuário carregar o dispositivo consigo o tempo todo. Isso faz com que o dispositivo torne-
se um dos principais fatores que contribuem para complexidade do contexto móvel, pois os
dispositivos são fáceis de carregar, possuem acesso a tecnologias de rede sem fio, além de
permitir a comunicação em qualquer lugar, justificando a mobilidade oferecida ao usuário por
meio de smartphones e tablets (Dantas et al., 2009).
Dispositivos móveis podem apresentar grande diferença no modelo, pois são
confeccionados levando em consideração questões de marketing. Os dispositivos que
apresentam como principal objetivo a comunicação de voz, possuem alto-falante, teclado
numérico e microfone, já os dispositivos focados em jogos, apresentam controles como os
periféricos de entrada.
Contexto Móvel
Usuário de Dispositivo
Móvel
Aplicação Móvel
Ambiente Móvel
58
2.6.1.1. Dispositivos Móveis
A Nielsen Company5, empresa de pesquisa de mercado no mundo, realizou no terceiro
trimestre de 2011 uma pesquisa global sobre o uso de meios de comunicação em telas
múltiplas. A pesquisa teve por objetivo identificar a posse e intenções de compra de
smartphones ao redor do mundo. Entre os entrevistados, 57% apresentaram um potencial de
posse de compra nos próximos 12 (doze) meses, o que demonstra um crescimento
considerável de dispositivos móveis.
Os dispositivos móveis vêem demonstrando transformações rigorosas ao longo dos
anos, evoluindo a partir de um simples dispositivo de comunicação para uma plataforma de
computação, possibilitando o suporte para aplicações complexas e maduras. Algumas
características importantes contribuíram para essas transformações, como a capacidade de
processamento e armazenamento, conectividade de Internet cada vez mais rápida e
acessibilidade aos dados, chegando cada vez mais próximos as características de um
computador (desktops, laptops). Além disso, smartphones e tablets já somam um grande
percentual do total de vendas de novos dispositivos móveis (Jain e Shanbhag, 2012).
Embora seja visível a constante evolução dos dispositivos móveis, algumas limitações
ainda impactam de forma negativa sobre o ambiente móvel como, as limitações de tela (em
média até 4.13 polegadas e no máximo 800x480 pixels), capacidade de armazenamento
(alguns dispositivos possuem memória para expansão de 32GB, mas normalmente apresentam
pouca capacidade), memória (pequena e limitada, em média 128MB de memória RAM),
processamento (lento), bateria (necessário recarregar a bateria após um período de tempo que
pode variar de acordo com a tecnologia de acesso de rádio usada, configuração e uso),
conectividade (lenta e instável, geralmente feita através de redes sem fio (Wi-Fi, GPRS e 3G),
mobilidade (passível de interrupção, pois pode ser utilizado facilmente com o usuário em
movimento) e dispositivos de entrada (teclado pequeno e limitado, caneta, tela sensível ao
toque, botões para navegação, microfone, câmera, cartão de memória, teclados slide) (Heiss,
2002).
5 http://br.nielsen.com
59
2.6.2. Usuário de Dispositivo Móvel
Dispositivos móveis são inseridos no mercado com uma gama enorme de aplicações e
funcionalidades, com o intuito de agilizar as tarefas cotidianas dos mais diversos tipos, desde
se comunicar com outros usuários e responder e-mails até utilizar a Internet para efetuar
algum tipo de transação bancária, sem necessitar do auxílio de um computador,
caracterizando o fator chave do ambiente móvel: a mobilidade (Lee, Schneider e Schell,
2005).
A conveniência e as poderosas funcionalidades oferecidas pelos dispositivos móveis
fizeram com que as pessoas optassem pela mobilidade, desenvolvendo uma forte interação
entre o usuário e o ambiente no qual ele está inserido enquanto opera suas aplicações.
Portanto, o ambiente afeta diretamente como o dispositivo é utilizado, pois o mesmo não é
capaz de determinar se o usuário está em uma reunião de negócios ou em uma viagem ou em
outra atividade, caracterizando-o como um fator contextual (Ballard, 2007; Lee, Schneider e
Schell, 2005).
Dessa forma, o usuário torna-se passível de interrupções, pois pode ser interrompido a
qualquer momento enquanto utiliza o dispositivo, inclusive impedido de finalizar alguma
atividade em uma aplicação específica, por exemplo, ser interrompido por um recebimento de
uma chamada enquanto está redigindo uma mensagem. Diante disso, as aplicações ou
serviços do dispositivo móvel devem permitir que o usuário finalize sua operação em outro
momento, sem perder as informações inseridas que não foram salvas.
Os usuários móveis mais característicos são os profissionais e consumidores. Os
usuários móveis profissionais referem-se a 6 (seis) principais tipos: profissionais em trânsito
remoto (viajam muito), agentes de vendas, agentes de serviços, consultores, profissionais em
trânsito local e escritórios. Os usuários móveis consumidores referem-se a 2 (dois) principais
tipos: jovem e adulto. Estes usuários esperam atividades variadas das aplicações móveis que
operam em seus dispositivos, como a comunicação (voz, áudio, texto, imagens), trabalho
(intercâmbio de informações, emissão de instruções), entretenimento (jogos de divertimento,
jogos de azar, músicas, filmes), educação (individualizada, interativa) e localização
(informações de localização do usuário, informações de destino) (Lee, Schneider e Schell,
2005).
60
Vale ressaltar que, a partir do momento que o usuário torna-se móvel (opera um
dispositivo móvel) entende-se que ele está disponível a todo o momento, pois a mobilidade do
dispositivo insere essa característica, mesmo o usuário não se sentindo a vontade em atender
uma ligação ou responder uma mensagem no meio de uma reunião de negócios, por exemplo.
2.6.3. Aplicação Móvel
Uma aplicação (software) pode ser considerada móvel quando ela é executada em um
dispositivo que pode se mover. Ou seja, pode-se considerar como uma aplicação móvel,
softwares que operam em leitores de MP3, câmeras digitais, GPS. Porém, algumas
características importantes diferenciam as aplicações móveis citadas anteriormente das
aplicações mais complexas que operam em dispositivos robustos como, smartphones e
tablets. São elas: recursos limitados, segurança e vulnerabilidade, desempenho e
confiabilidade, variabilidade e fonte de energia limitada (Muccini, Di Francesco e Esposito,
2012; Satyanarayanan, 1996).
Os usuários apresentam grande expectativa sobre a qualidade do software
disponibilizado para os seus dispositivos. Portanto, é de extrema importância que o software
seja confiável e estável, pois caso contrário, os usuários não vão se sentir confiantes em
armazenar informações em um dispositivo que pode travar ou perder as informações
armazenadas (Bo, Xiang, Xiaopeng, 2007). Além disso, os usuários de dispositivos móveis
tornaram-se acostumados a manusear aplicações simples, que se comportam de forma correta,
sem falhas, sem perda de dados ou serviços, e que não interferem em outras aplicações que
estão sendo executadas (She, Sivapalan e Warren, 2009).
As aplicações móveis são constituídas de um dispositivo, um navegador, um ambiente
de aplicação e suas capacidades, um usuário de dispositivo móvel, ambiente de aplicação,
mensagens, ambientes de mídia, interfaces de saídas (tela, caixa de som, bluetooth, Wi-Fi),
interfaces de entradas (teclados, tela sensível ao toque, microfone, câmera), interfaces entre
servidor de aplicação e outras fontes de informação (Ballard, 2007).
61
2.6.3.1. Tipos de Aplicações Móveis
A análise de uma aplicação móvel durante o planejamento dos testes é uma prática primordial,
pois a partir do planejamento é possível determinar os principais riscos envolvidos e
desenvolver os respectivos planos de mitigação, além de direcionar o objetivo do teste.
Entretanto, para analisar uma aplicação móvel é necessário entender o contexto no
qual ela está envolvida. No entanto, não é uma tarefa trivial classificar as aplicações móveis,
pois várias classificações são encontradas na literatura abordando algumas características
individuais.
Dessa forma, esta dissertação baseia-se em Weiss (2003), Pocatilu (2008) e Fling
(2009), para classificar as aplicações móveis. Os principais tipos identificados foram:
Web Sites: são sites desenvolvidos para dispositivos móveis, caracterizados por uma
simples apresentação de links de navegação que direcionam o usuário para uma página
de um nível mais profundo;
Web Widgets: são aplicações criadas para superar as limitações de páginas web para
dispositivos móveis, e apresentam funcionalidades limitadas que podem ser instaladas
e executadas em uma página web;
Aplicações Web: são aplicações móveis que não precisam ser instaladas ou compiladas
no dispositivo de destino, permitindo aos usuários interagirem com o conteúdo em
tempo real, nos quais um clique ou toque realizam uma ação dentro da visão atual;
Aplicações Nativas: são aplicativos construídos especificamente para dispositivos que
executam a plataforma em questão, por exemplo, Android e iOS;
Jogos: aplicações nativas com foco em entretenimento;
Aplicações de Negócios: são aplicações nativas e referem-se à automatização de
necessidades específicas de negócios apresentando características peculiares como,
acomodar o início e a parada de um processo sem perder dados, garantir a consistência
nas interfaces de usuário desktop web e manter a comunicação dos sistemas de modo
que os perfis disponíveis para desktop também sejam para a web sem fio;
Aplicações para Produtividade: incluem os calendários, calculadoras, agendas, bloco
de notas, planilhas e serviços de diretório
Aplicações para Comunicação: incluem e-mail, vídeo, telefone, bate-papo interativo e
sistemas de fóruns de discussão e mensagens; e
Utilitários: incluem gerenciadores de perfis, tarefas de chamada e arquivos.
62
De acordo com Ickin et al. (2012), as aplicações móveis também podem ser
diferenciadas de acordo com 12 (doze) principais categorias correspondentes à frequência de
utilização pelo usuário. As categorias estão apresentadas em ordem decrescente de utilização.
Comunicação;
Web;
Redes Sociais;
Ferramentas de produtividade;
Clima (tempo);
Notícias;
Multimídia;
Jogos;
Estilo de vida;
Finanças:
Compras; e
Viagens.
Além das características particulares apresentadas sobre o ambiente móvel (contexto
móvel, usuário de dispositivo móvel e aplicação móvel), o aspecto gerencial de projetos de
desenvolvimento de aplicações móveis também apresenta características específicas se
comparado com a gestão de projetos de softwares tradicionais.
Na Tabela 2.5 é apresentada a correlação entre a gestão de projetos de software
tradicional e aplicação móvel.
Tabela 2.5. Correlação entre a gestão de projetos de software tradicional e aplicação móvel
(adaptada de Andrade et al., 2012)
Área Software Tradicional Aplicação Móvel
Escopo do Produto
Desenvolvimento de produtos
genuínos (próprios e independentes
de outros sistemas);
Normalmente transação on-line;
Desenvolvimento de produtos de
integração com sistemas de
informação;
Transação on-line e off-line;
Duração dos Projetos Médio e longo prazo; Curto prazo;
Recursos Humanos Processo de seleção específico;
Equipes estáticas;
Processo de seleção generalizado;
Equipes dinâmicas;
Continua
63
Área Software Tradicional Aplicação Móvel
Riscos
Baixo impacto de fatores externos
não regulatórios;
Médio impacto de fatores
tecnológicos;
Disponibilidade média de
profissionais especialistas no
mercado de trabalho;
Médio impacto de fatores externos
não regulatórios;
Alto impacto de fatores
tecnológicos;
Disponibilidade baixa de
profissionais no mercado de
trabalho;
Planejamento
Estratégico de
Mercado
Médio e longo prazo;
Previsão do mercado;
Curto prazo;
Reação do mercado
Custos Teste em uma ou poucas
plataformas/equipamentos;
Teste em várias
plataformas/equipamentos;
Segundo Andrade et al. (2012), projetos de desenvolvimento de aplicações móveis são
aplicados ao negócio com o propósito de estender as funções organizacionais e alcançar novos
objetivos estratégicos que antes não eram possíveis, caracterizando esses projetos como de
curto prazo e menor escopo se comparado aos projetos de desenvolvimento de software
tradicionais. Além disso, os riscos e custos divergem principalmente na diversidade dos
dispositivos e plataformas móveis e nas habilidades e qualificações dos recursos humanos.
2.7. Testes de Aplicações Móveis
Os produtos de software que operam em dispositivos móveis demandam por características de
qualidade diferenciadas em relação aos tradicionais (desktop).
Além das características de qualidade apresentadas pela norma NBR ISO/IEC 9126-1
(funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade, portabilidade),
alguns autores (Capgemini, Sogeti e Hewlett-Packard, 2012; Franke e Weise, 2011; Muccini,
Di Francesco e Esposito, 2012; Palit et al., 2011; Lee, Schneider e Schell, 2005; Zhang e
Adipat, 2005; Dantas et al., 2009; Franke e Weise, 2011; Jain e Shanbhag, 2012; OWASP
Foundation, 2012) ressaltam características particulares relacionadas à qualidade das
aplicações móveis e, portanto, novas abordagens de testes devem considerá-las.
Na Tabela 2.6 são apresentadas as principais características de avaliação de qualidade
do dispositivo móvel e suas funcionalidades.
64
Tabela 2.6. Características de avaliação de qualidade do dispositivo móvel e suas
funcionalidades
Característica Descrição Referência
Adaptabilidade/
Compatibilidade
Capacidade da aplicação móvel se comportar de maneira
estável em diferentes configurações de hardware e
sistemas operacionais. Centenas de dispositivos móveis
estão no mercado produzido por diferentes fornecedores e
com características diferentes de software e hardware.
Durante a execução, as aplicações móveis podem se
comportar de forma diferente devido a variações nos
componentes de hardware ou sistema operacional. Por
exemplo, os sensores utilizados nos dispositivos são
calibrados de maneira diferente, de modo que dois
dispositivos distintos que executam a mesma aplicação, no
mesmo ambiente, podem obter resultados diferentes. Dessa
forma, explorar técnicas para aumentar o alcance de
cobertura do teste entre a diversidade de modelos torna-se
uma técnica de teste importante.
[Capgemini, Sogeti e
Hewlett-Packard, 2012]
[Franke e Weise, 2011]
[Muccini, Di Francesco e
Esposito, 2012]
Autonomia
De acordo com o tipo da aplicação móvel, o consumo de
energia pelo dispositivo pode apresentar grandes
variações. Como os dispositivos móveis não podem
depender de uma tomada elétrica para o funcionamento, a
autonomia da bateria é uma questão que merece destaque e
deve ser avaliada por meio de testes e/ou monitoramento
contínuo. A utilização do dispositivo em modo stand-by,
conexão Wi-Fi ou 3G ativada, são aplicações/serviços que
impactam na autonomia do dispositivo.
[Muccini, Di Francesco e
Esposito, 2012]
[Palit et al., 2011]
Conectividade
(Rede)
A conectividade de dispositivos móveis é muitas vezes
lenta e pouco confiável e, portanto, terá impacto sobre o
desempenho das aplicações móveis que utilizam esses
recursos. As aplicações móveis geralmente se conectam a
redes móveis que podem variar na velocidade, segurança e
confiabilidade. A confiabilidade do aplicativo,
desempenho, segurança e correto funcionamento depende
fortemente do tipo de conectividade disponível. Além
disso, aplicações que dependem de rede também devem
ser priorizadas, pois as funcionalidades básicas do
dispositivo dependem desse recurso, por exemplo, efetuar
chamadas.
[Capgemini, Sogeti e
Hewlett-Packard, 2012]
[Lee, Schneider e Schell,
2005]
[Muccini, Di Francesco e
Esposito, 2012]
[Zhang e Adipat, 2005]
Desempenho/
Eficiência
O desempenho e a confiabilidade das aplicações móveis
dependem fortemente dos recursos disponíveis nos
dispositivos. Novas técnicas de análise de desempenho e
confiabilidade devem considerar as características
relacionadas com os diferentes tipos de dispositivos
móveis.
[Capgemini, Sogeti e
Hewlett-Packard, 2012]
[Muccini, Di Francesco e
Esposito, 2012]
Continua
65
Característica Descrição Referência
Flexibilidade/
Sensibilidade ao
Contexto
De acordo com o ambiente e/ou ações do usuário, as
aplicações podem se comportar de maneira não esperada,
pois o dispositivo está vulnerável a várias características,
por exemplo, luminosidade, temperatura, altitude, ruído,
tipo de conectividade (bluetooth, GPS, Wi-Fi, 3G), largura
de banda e até mesmo outros dispositivos que estão
próximos. As restrições ambientais também incluem a
interação com as pessoas próximas, objetos e elementos
ambientais que podem distrair a atenção dos usuários.
[Dantas et al., 2009]
[Franke e Weise, 2011]
[Muccini, Di Francesco e
Esposito, 2012]
[Zhang e Adipat, 2005]
Funcionalidade Assegurar o funcionamento da aplicação móvel conforme
especificado.
[Capgemini, Sogeti e
Hewlett-Packard, 2012]
[Lee, Schneider e Schell,
2005]
Limitação de
Recursos
Os dispositivos móveis estão se tornando cada vez mais
robustos, porém, seus recursos ainda estão distantes dos
que estão disponíveis em laptops ou computadores de
mesa. A utilização de recursos pelas aplicações móveis
deve ser monitorada de modo a evitar a degradação do
desempenho e funcionamento correto do software, além de
ações corretivas no caso de escassez de recursos.
[Muccini, Di Francesco e
Esposito, 2012]
Persistência de
dados
Aplicações móveis em pausa podem ser encerradas devido a problemas com a memória do dispositivo, e suas informações perdidas.
[Franke e Weise, 2011]
Segurança/
Integridade das
Informações
A segurança e integridade das informações são
características importantes devido à mobilidade do
dispositivo e o acesso a redes com diferentes níveis de
segurança. A facilidade de acesso ao desenvolvimento de
aplicações para dispositivos móveis aumenta o número de
aplicativos disponíveis, que de alguma forma, armazenam
informações dos usuários. Dessa forma, abordagens
tradicionais de teste de segurança devem ser revistas para
que considerem fatores contextuais, com a intenção de
serem simuladas de modo a verificar quais são os dados
que realmente são transmitidos para o dispositivo móvel.
[Capgemini, Sogeti e
Hewlett-Packard, 2012]
[Jain e Shanbhag, 2012]
[Muccini, Di Francesco e
Esposito, 2012]
[OWASP6 Foundation,
2012]
Sistemas
Operacionais
Aplicações móveis são executadas em sistemas
operacionais que ainda são pouco confiáveis. Novas
versões de sistemas operacionais móveis são divulgadas e
na maioria das vezes não são compatíveis com versões
anteriores, o que implica em alterações nas aplicações que
já estão instaladas no dispositivo. Além disso, a
diversidade de sistemas operacionais móveis faz com que
as linguagens de programação sejam diferentes entre os
dispositivos móveis, dificultando a padronização. São
exemplos de sistemas operacionais: Apple iOS, Google
Android, Windows Mobile, Rim BlackBerry OS, Nokia
Symbian, entre outros.
[Muccini, Di Francesco e
Esposito, 2012]
Continua
6 Open Web Application Security Project – http://www.owasp.org.
66
Característica Descrição Referência
Touch Screen
O tempo de resposta da aplicação a um toque em uma tela
sensível depende muitas vezes da utilização dos recursos
do dispositivo. Telas sensíveis ao toque são os principais
meios de inserção de dados pelo usuário em uma aplicação
móvel, e, por isso, sua estabilidade é importante. Técnicas
de teste devem ser introduzidas para testar o
funcionamento da tela sensível ao toque em circunstâncias
diferentes, por exemplo, sobrecarga do processador,
sobrecarga de memória.
[Dantas et al., 2009]
[Muccini, Di Francesco e
Esposito, 2012]
Usabilidade
As aplicações móveis podem agir de forma diferente
dependendo da resolução e dimensão da tela do
dispositivo. O teste de interfaces gráficas é uma
necessidade, pois diferentes dispositivos móveis podem
reagir de forma diferente para o mesmo código da
aplicação. Dispositivos móveis apresentam telas muito
pequenas, o que significa que a quantidade de informação
que pode ser exibida é drasticamente reduzida quando
comparado a um computador. Além disso, a resolução de
telas de dispositivos móveis é de baixa qualidade,
impactando na qualidade da imagem.
[Muccini, Di Francesco e
Esposito, 2012]
[Zhang e Adipat, 2005]
As organizações que testam aplicações móveis enfatizam a obtenção de diferentes
níveis de qualidade em comparação com os testes em softwares tradicionais, pois o foco
principal é o desempenho do aplicativo, em vez de sua funcionalidade. A eficiência do
desempenho das aplicações é identificada como foco principal para a atividade de teste. Ou
seja, o usuário pode admitir falhas pontuais nas aplicações, desde que elas apresentem um
bom desempenho e boa usabilidade em relação à mobilidade do usuário (Capgemini, Sogeti e
Hewlett-Packard, 2012).
Diante disso, é visível a necessidade de uma abordagem de testes para aplicações
móveis, de modo que as particularidades do contexto móvel não afetem de forma negativa a
qualidade das aplicações finais disponibilizadas para os usuários.
67
2.8. Engenharia de Software Experimental (ESE)
A Engenharia de Software (ES) pode ser considerada como um processo social em que os
artefatos (métodos/ferramentas/paradigmas) a serem utilizados são afetados pelo
conhecimento, experiência e a capacidade do usuário. Assim, uma diferença importante entre
a ES e outras disciplinas de engenharia é a importância do elemento humano. Além disso, a
ES tem lugar em um contexto social e, como tal, é influenciado por relacionamentos entre as
pessoas (equipe do projeto, os gestores, os usuários, etc.) e do contexto social (cultura
corporativa, procedimentos organizacionais, etc.) (Juristo e Moreno, 2010).
Nesse contexto, a ESE afirma que os estudos empíricos exercem um papel
fundamental na evolução da disciplina de ES, pois permitem construir um corpo de
conhecimento apoiado pela observação e evidências empíricas, com a intenção de obter
informações sobre um objeto de pesquisa (Basili, 2007).
De acordo com Wohlin et al. (2000), a experimentação caracteriza-se por um processo
com as seguintes etapas:
Definição: os objetivos e metas são definidos, visando definir questões relacionadas
com o objeto do estudo, propósito, foco de qualidade, perspectiva e contexto;
Planejamento: define como o estudo experimental será conduzido, por meio dos
seguintes elementos: contexto, hipóteses, variáveis, participantes e projeto
experimental, contendo instrumentação e avaliação da validade;
Execução: acompanhar se o estudo está ocorrendo conforme o planejado;
Análise e Interpretação: as hipóteses elaboradas são comparadas com os dados por
meio de ferramentas estatísticas adequadas. Os resultados gerados são utilizados pelo
experimentador na tentativa de rejeitar a hipótese nula e confirmar a hipótese
alternativa; e
Apresentação e Empacotamento: os resultados obtidos com o experimento são
apresentados e empacotados.
Conforme Juristo e Vegas (2011) afirmam, a experimentação é a possibilidade de
outros pesquisadores replicarem o experimento, com a intenção de qualificar uma ideia como
prova irrefutável. Assim, o processo de replicação é composto pelas seguintes atividades:
Definição e Planejamento: entender o cenário (ambiente, contexto) original, analisar o
novo cenário, realizar as modificações necessárias no experimento e analisar os
possíveis impactos das mudanças nos resultados da replicação;
68
Execução e Análise: executar a replicação e analisar os dados;
Interpretação: comparar os resultados da replicação com resultados anteriores, gerar
conhecimento a partir das modificações necessárias e gerar conhecimento a partir das
modificações não-intencionais; e
Contribuição da Replicação: analisar o tipo de replicação obtida e contribuição à
confiança dos resultados.
2.9. Trabalhos Relacionados
Esta Seção apresenta os 2 (dois) trabalhos relacionados que foram selecionados a partir da
revisão bibliográfica e serviram como base para o desenvolvimento da abordagem TM-Aplic
apresentada nesta dissertação. Na Tabela 2.7 são apresentados os trabalhos por título, ano e
autor.
Tabela 2.7. Trabalhos relacionados
Título Ano Autor
Testing Requirements for Mobile Applications 2009 Dantas, V. L. L.; Marinho, F. G.;
Costa, A. L.; Andrade, R. M. C.
The Definition of a Testing Process to small-sized
companies: The Brazilian Scenario 2010
Rodrigues, A.; Pinheiro, P. R.;
Albuquerque, A.
2.9.1. Descrição e Análise dos Trabalhos Relacionados
O trabalho de Dantas et al. (2009) intitulado de Testing Requirements for Mobile Applications
apresenta um conjunto de 16 (dezesseis) requisitos para o teste de aplicações móveis. Os
autores classificam esses requisitos em duas categorias: i) relacionados com o processo de
teste e ii) relacionados com a usabilidade. Os requisitos do número 1 (um) ao 8 (oito) são
relacionados com o processo de teste e os requisitos do número 9 (nove) ao 16 (dezesseis) são
relacionados com a usabilidade, conforme apresentado na Tabela 2.8.
69
Tabela 2.8. Requisitos de testes para aplicações móveis (adaptada de Dantas et al., 2009)
Classificação Requisito Descrição
Pro
cess
o d
e T
este
s
1 O modelo de processo de desenvolvimento das aplicações móveis
deve focar no processo de teste.
2 As aplicações devem ser testadas tanto em emuladores quanto em
dispositivos móveis.
3
O relatório de teste deve informar o nome da aplicação, a versão da
aplicação, a versão do emulador e/ou dispositivo e o ambiente de
teste.
4
Para cada erro reportado devem ser fornecidos a sua descrição, a
sua frequência de ocorrência (sistemático, aleatório ou apenas uma
vez), a sua localização na aplicação e um passo a passo para
reproduzi-lo.
5 As aplicações móveis devem ser testadas de acordo com as
limitações do contexto móvel às quais elas se aplicam.
6 As aplicações móveis desenvolvidas não devem destruir as
funcionalidades das aplicações já inseridas no dispositivo móvel.
7 O testador deve saber quais características podem ser testadas no
laboratório e quais podem ser testadas no contexto móvel.
8 O teste de usabilidade deve ser incluído durante o ciclo de
desenvolvimento da aplicação móvel.
Usa
bil
idad
e
9
O usuário de dispositivo móvel deve sempre saber onde está na
aplicação, o que ele já fez, o que pode fazer e como desfazer os seus
erros.
10 As ações do usuário de dispositivo móvel não devem ser desfeitas
quando interrupções externas forçam a aplicação pausar.
11 A aplicação deve suportar os formatos de tela retrato e paisagem.
12 As aplicações móveis devem pedir a permissão do usuário antes de
estabelecer conexões.
13
As aplicações móveis não devem usar texto justificado, alinhado à
direita, cortado, todo em maiúsculo, e sua quantidade deve ser
mínima para que não seja necessário utilizar barra de rolagem.
Além disso, a aplicação móvel deve ter um bom contraste em
relação ao plano de fundo.
14 As aplicações móveis devem requerer a confirmação do usuário
para executar ações não reversíveis.
15 As aplicações móveis devem explorar a utilidade e a usabilidade
proporcionadas pelo som durante a sua execução.
16
As teclas do tipo softkey quando utilizadas para controlar as ações
das aplicações móveis devem mapear as ações mais importantes e
mais usadas na aplicação. Recomenda-se utilizar a tecla softkey da
esquerda para ações positivas e a da direita para ações negativas.
70
Apesar da identificação dos requisitos, os autores não definem claramente os aspectos
relacionados com a condução do teste. No entanto, os requisitos devem ser utilizados como
base para auxiliar as equipes nas atividades de teste para aplicações móveis. A pesquisa
ressalta que, a maioria das empresas que desenvolvem aplicativos para dispositivos móveis
não possui um processo de teste específico para esse tipo de software, tornando a cobertura do
teste insuficiente, no que se refere à cobertura das particularidades das aplicações.
Como trabalho futuro, os autores sugerem que os requisitos de teste propostos sejam
aplicados em diferentes cenários e, também, sejam agrupados em níveis de prioridade. Além
disso, é importante aperfeiçoar e documentar os requisitos de teste para outros tipos de
aplicações móveis, por exemplo, jogos. Pode-se concluir que, durante a análise do trabalho, os
autores também se limitam em abordar requisitos de testes, não mencionando questões
gerenciais do teste, por exemplo, riscos do produto, estratégias de testes, critérios de
aceitação, recursos humanos, ambiente de teste, artefatos gerados e entre outros.
O trabalho de Rodrigues, Pinheiro e Albuquerque (2010) intitulado The Definition of a
Testing Process to small-sized companies: The Brazilian Scenario apresenta os resultados de
uma pesquisa, realizada com o intuito de identificar os fatores que impossibilitam a
implantação de processos de testes de software em empresas Brasileiras de pequeno porte.
Alguns dos principais fatores identificados foram: dificuldade em adaptar os modelos de
processos de teste existentes para um ambiente específico, falta de orçamento, falta de tempo,
tamanho da equipe de testes, falta de profissionais especializados nas atividades de teste,
dificuldade em escolher a técnica de teste adequada, falta de conhecimento, artefatos de baixa
qualidade, falta de compromisso dos gestores do projeto e entre outras.
Diante desses fatores, os autores propuseram um processo de testes de software
direcionado para empresas brasileiras de pequeno porte, constituído de 2 (duas) principais
atividades: Planejamento e Execução, conforme apresentada na Figura 2.10.
71
Figura 2.10. Processo de testes para empresas de pequeno porte (adaptada de Rodrigues,
Pinheiro e Albuquerque, 2010)
A atividade de Planejamento é constituída das seguintes tarefas: identificar o produto
de teste, selecionar técnicas e tipos de testes, identificar critérios de aceitação, identificar os
papéis, analisar relatórios de defeitos e definir ambiente de teste. O artefato de teste principal
da atividade é o plano de testes. A atividade de Execução é constituída das seguintes tarefas:
realizar teste, enviar relatório de testes para análise e analisar o resultado de teste. O artefato
gerado é o relatório de falhas e um plano de ação.
Assim, o trabalho de Rodrigues, Pinheiro e Albuquerque (2010) está relacionado com
a abordagem TM-Aplic porque as empresas que desenvolvem aplicações móveis se encaixam
nos fatores identificados. Os estudos de Jeong, Lee e Shin (2008) e Kim, Choi e Wong (2009)
apresentam algumas características que justificam a escolha de uma abordagem de testes mais
flexível para apoiar as organizações que desenvolvem aplicações móveis. As justificativas
são:
As organizações que aplicam um ciclo curto e rápido para desenvolver as aplicações
móveis ganham vantagem competitiva;
A maioria das empresas que desenvolvem aplicações móveis é de pequeno porte, o
que torna difícil a aplicação de métodos complexos durante o desenvolvimento; e
Devido a determinadas restrições de recursos dos dispositivos móveis, as aplicações
móveis desenvolvidas são simples e pequenas.
Além disso, o trabalho de Rodrigues, Pinheiro e Albuquerque (2010) aponta as
diretrizes no que se refere às tarefas que devem ser realizadas durante os testes. No entanto,
carece de detalhes referentes aos artefatos que devem ser gerados, dificultando o
entendimento prático da proposta.
72
2.10. Considerações Finais
Os conceitos e técnicas apresentados neste capítulo oferecem o embasamento teórico
necessário para a contextualização e fundamentação desta dissertação, bem com a condução
dos estudos experimentais. Além disso, o capítulo apresentou os trabalhos relacionados que
abordam as questões referentes ao teste para aplicações móveis e a condução das atividades
de testes.
Assim, a partir da análise dos trabalhos relacionados, algumas características foram
elencadas para a definição da abordagem TM-Aplic. As características são:
Alinhamento dos requisitos para o teste de aplicações móveis proposto por Dantas et
al. (2009) no que se refere a definição das tarefas, papéis e artefatos, de modo a
considerar as particularidades das aplicações, bem como as questões inerentes do
ambiente móvel;
Definir uma metodologia sistemática de teste abordando as tarefas propostas por
Rodrigues, Pinheiro e Albuquerque (2010), de maneira que combine as boas práticas
de planejamento, projeto e execução de testes estabelecidas pelas áreas de processos
do modelo de maturidade MPT.BR; e
Controle e monitoramento dos artefatos gerados ao longo das atividades de teste.
O capítulo seguinte apresenta a abordagem de TM-Aplic proposta nesta dissertação.
73
Abordagem TM-Aplic
3.1. Considerações Iniciais
Embora vários estudos relacionados ao teste de software sejam encontrados na literatura
(Borner, Illes-Seifert e Paech, 2007; Crespo et al., 2010a; Dias Neto e Travassos, 2006; Mette
e Hass, 2008; Jacobs, Van Moll e Stokes, 2000; Jun-feng et al., 2006; Li, Ma e Chao, 2008;
Mao e Zhang, 2007; Monteiro et al., 2010; Rodrigues, Pinheiro e Albuquerque, 2010; Sanz et
al., 2009), observa-se que os componentes que fazem parte de um processo de testes (por
exemplo: entradas, mecanismos e agentes, restrições e condições), podem apresentar
variações específicas de acordo com as particularidades apresentadas pelo software.
Assim, a etapa de planejamento deve ser destacada de modo que as características
particulares de qualidade sejam consideradas durante a execução das tarefas de teste, a fim de
contribuir para a melhoria da qualidade do produto, no que se refere à identificação de falhas
antes da aplicação ser disponibilizada para os usuários finais.
Segundo Kim et al. (2011), o aumento significativo dos dispositivos móveis e,
consequentemente, o surgimento de inúmeras aplicações e serviços que operam nesses
dispositivos, acarreta em uma busca constante pela melhoria da qualidade desses produtos de
software.
3
Capítulo
74
No entanto, torna-se um desafio aprimorar a qualidade das aplicações móveis
desenvolvidas, pois este tipo de software impõe inúmeras características específicas que as
difere de software tradicionais, tais como: a quantidade de usuários de dispositivos móveis,
usuários com menos experiência, variedade de modelos de dispositivos, questões relacionadas
com a mobilidade do usuário (Dantas et al., 2009; Muccini, Di Francesco e Esposito, 2012).
A mobilidade proporcionada aos usuários é o principal fator que contribui para a
complexidade das aplicações móveis, pois está diretamente associada às características de
qualidade da aplicação (por exemplo: portabilidade, usabilidade, funcionalidade,
conectividade) (Lee, Schneider e Schell, 2005; Zeidler, Kittl e Petrovic, 2007).
Neste contexto, o capítulo apresenta a abordagem TM-Aplic, na qual são definidas as
tarefas relacionadas com o planejamento, projeto e execução dos testes, de maneira que as
questões inerentes a um ambiente móvel sejam consideradas, bem como os papéis, artefatos e
os resultados esperados de cada tarefa.
3.2. Composição da Abordagem
A abordagem TM-Aplic, proposta na presente dissertação, considera 2 (duas) características
principais:
Definição de um Processo de Testes; e
Requisitos para Testes de Aplicações Móveis.
Além delas, foram considerados alguns elementos do processo de testes para empresas
brasileiras de pequeno porte e do modelo de maturidade MPT.BR.
Assim, na Figura 3.1 é ilustrada a composição da abordagem TM-Aplic, e na Tabela
3.1 é apresentado um resumo das principais características, bem como os principais elementos
abordados ao longo do desenvolvimento da abordagem.
75
Figura 3.1. Composição da abordagem TM-Aplic
Tabela 3.1. Resumo das principais características que compõe a abordagem TM-Aplic
Características Resumo
Definição de um Processo
de Testes
Tarefas consideradas (Rodrigues, Pinheiro e Albuquerque, 2010):
Planejamento - identificar o produto de testes, selecionar técnicas
e tipos de testes, identificar critérios de aceitação, identificar os
papéis, analisar relatórios de defeitos e definir ambiente de teste;
e
Execução - realizar teste, enviar relatório de testes para análise e
analisar o resultado de teste.
Caracterização das tarefas de acordo o Nível 1 (um) de maturidade do
modelo MPT.BR (SOFTEX, 2011). As áreas de processo utilizadas
foram:
Gerência de Projetos de Teste (GPT); e
Projeto e Execução de Teste (PET).
Requisitos para Testes de
Aplicações Móveis
Situações de testes para aplicações móveis que abordam questões
relacionadas com a usabilidade e o processo de testes, bem como os
fatores inerentes do ambiente móvel (Dantas et al., 2009).
76
3.3. Estrutura da Abordagem
Após o refinamento das características abordadas, tornou-se possível definir a estrutura
principal da abordagem TM-Aplic, na qual 2 (dois) principais subprocessos são definidos:
Planejamento de Teste e;
Projeto e Execução de Teste.
O subprocesso Planejamento de Teste apresenta como principal objetivo desenvolver
um plano de testes, de modo que o subprocesso Projeto e Execução de Teste projete e execute
os casos de teste. Ambos os subprocessos estão caracterizados de forma a considerar as
particularidades das aplicações móveis, conforme apresentado na Figura 3.2.
Figura 3.2. Subprocessos da abordagem TM-Aplic (adaptado de Dias Neto e Travassos, 2006
e Rodrigues, Pinheiro e Albuquerque, 2010)
De modo geral, a primeira etapa de um processo é a entrada, responsável por fornecer
as informações sobre o software que será testado, por exemplo, informações relacionadas com
a aplicação móvel. Após definida a entrada, a etapa de procedimento consiste na execução das
tarefas estabelecidas, divididas entre os subprocessos. Cada tarefa executada resulta em um
artefato de teste, caracterizado como uma saída e, serve como entrada para a realização da
próxima tarefa.
A descrição gráfica da abordagem foi realizada por meio da notação para modelagem
de processos de negócios BPMN (Business Process Modeling Notation), mantida pelo Object
Management Group (OMG)7, por entender ser uma notação de fácil entendimento do
percurso das tarefas apresentadas. Os objetos utilizados para compor o diagrama da
abordagem TM-Aplic são apresentados na Tabela 3.2.
7 http://www.omg.org/bpmn/index.htm
77
Tabela 3.2. Objetos utilizados para compor o diagrama (adaptado de Bizagi, 2013)
Figura Objeto Descrição
Evento de Início Indica o início do processo.
Evento de Início com
Mensagem
Indica que processo inicia ao receber uma mensagem de
outro processo.
Evento de Término Indica o término do processo.
Evento de Término
com Mensagem
Indica que uma mensagem é enviada a outro processo,
quando o fim é atingido.
Decisões
São locais dentro do processo onde o fluxo de sequência
das tarefas pode tomar dois ou mais caminhos
alternativos.
Fluxo de Sequência Utilizado para mostrar a ordem em que as tarefas serão
executadas em um processo.
Fluxo de Mensagem Representa a comunicação entre dois processos ou duas
entidades representadas por processos diferentes.
Associação Utilizada para associar informações e artefatos com os
objetos do fluxo de tarefas.
Tarefa Atividade que está incluída dentro de um processo.
Objeto de Dados
Fornecem informações sobre como os documentos, dados
e outros objetos são utilizados e atualizados durante o
processo.
Anotação de Texto Mecanismo para fornecer informações adicionais para o
leitor do processo.
Pool Representa um participante no processo.
Todos os componentes (subprocessos, tarefas, papéis e artefatos) apresentados na
abordagem TM-Aplic estão fundamentados pelo modelo de maturidade MPT.BR, pois o
modelo fornece uma série de diretrizes que, quando implementadas de maneira coletiva, apoia
as atividades de teste de software independente do porte da empresa.
Na Figura 3.3 é apresentado o diagrama da abordagem TM-Aplic proposta na presente
dissertação.
78
Figura 3.3. Diagrama da abordagem TM-Aplic
Por entender que as organizações que desenvolvem aplicações móveis apresentam
características de empresas de pequeno porte, conforme citado em Jeong, Lee e Shin (2008) e
Kim, Choi e Wong (2009), e discutido no Capítulo 2 na Seção 2.9. (Trabalhos Relacionados)
desta dissertação, a abordagem TM-Aplic considerou apenas as tarefas relacionadas com o
Nível 1 (um) de maturidade do modelo MPT.BR. Este nível representa o primeiro patamar de
maturidade de uma organização, e representa o mínimo que uma organização necessita para
demonstrar que a disciplina de teste de software é aplicada nos projetos, e que ocorre de
forma planejada e controlada.
79
Entre as 28 (vinte e oito) tarefas que definem a área de processo GPT - Gerência de
Projetos de Teste do modelo MPT.BR (apresentadas na Tabela 2.3.), o subprocesso
Planejamento de Teste considera relevante 7 (sete) tarefas: i) Analisar Produto de Teste, ii)
Estabelecer Objetivos do Teste, iii) Definir Estratégia de Teste, iv) Definir Equipe de Teste,
v) Definir Ambiente de Teste, vi) Estabelecer Plano de Teste e vii) Planejar os Artefatos e
Dados. Entre as 7 (sete) tarefas que definem a área de processo PET - Projeto e Execução de
Teste (apresentadas na Tabela 2.3.), o subprocesso Projeto e Execução de Teste considera
relevante 4 (quatro) tarefas: i) Identificar Casos de Teste, ii) Executar Teste, iii) Reportar
Incidentes e iv) Acompanhar Incidentes.
3.4. Descrição das Tarefas
Essa Seção descreve as tarefas a serem realizadas durante a abordagem TM-Aplic. As tarefas
são caracterizadas de modo a considerar as características particulares das aplicações móveis,
bem como as questões inerentes do ambiente móvel, por exemplo, o contexto móvel e o
usuário de dispositivo móvel.
Embora as tarefas apresentadas pela abordagem sejam aplicadas com as mesmas
definições e terminologias do modelo MPT.BR, o resultado está diretamente relacionado ao
contexto em que o teste é aplicado, no caso desta dissertação, às aplicações móveis. O
template dos artefatos gerados pelas tarefas da abordagem está apresentado no Apêndice B
desta dissertação.
3.4.1. Planejamento de Teste
O planejamento é a primeira e mais importante etapa da abordagem TM-Aplic, pois fornece a
base para a condução das demais atividades, resolvendo questões essenciais sobre a
implantação do projeto e execução de testes e, portanto, grande parte das decisões sobre o
teste deve ocorrer durante esta fase inicial (Mao e Zhang, 2007; Qi et al., 2009; Tian, 2005).
O gerente de testes é o responsável pela etapa de planejamento, que consiste em
determinar os recursos necessários que servirão de base para o subprocesso Projeto e
Execução de Teste.
A execução das tarefas na ordem apresentada é importante para estabelecer de forma
coerente o plano de teste, pois apesar de cada tarefa resultar em um artefato de teste diferente,
essas informações devem ser concentradas no plano, que é o artefato mais importante do
80
planejamento, pois é ele que vai determinar as diretrizes necessárias para a execução das
próximas tarefas.
Para auxiliar o gerente de testes durante a etapa de planejamento, algumas ferramentas
de apoio são apresentadas, tais como: Bugzilla, Enterprise Architect, Selenium IDE e
dotProject (Monteiro et al., 2010).
3.4.1.1. Analisar Produto de Teste
A tarefa de análise do produto de teste consiste na identificação de riscos relacionados ao
produto, de forma a identificar e caracterizar as áreas críticas que carecem de testes mais
detalhados (SOFTEX, 2011).
No contexto das aplicações móveis, algumas atividades devem ser realizadas, a fim de
desvendar as áreas críticas, como: considerar as limitações dos dispositivos (Dantas et al.,
2009; Kim, Choi and Wong, 2009; Fling, 2009); garantir o funcionamento das aplicações e
serviços já existentes no dispositivo móvel (Dantas et al., 2009; Muccini, Di Francesco e
Esposito, 2012; Kivi, 2007; Verkasalo, 2010); analisar possível rejeição do usuário de
dispositivo móvel (Dantas et al., 2009; Fling, 2009); e analisar o impacto da mobilidade
(Dantas et al., 2009; Fling, 2009).
Embora uma aplicação móvel funcione adequadamente no emulador8, no qual várias
características do contexto móvel podem ser avaliadas (bateria, tamanho de tela, conexão,
teclado, processamento) no dispositivo móvel físico pode não funcionar, acarretando em
perda de tempo e aumento de custos para as devidas correções. Isso se deve ao fato de que
cada dispositivo móvel apresenta características funcionais únicas, e prever o comportamento
dos modelos é uma tarefa praticamente impossível em um ambiente de testes baseado
somente em emulador (Kim, Choi e Wong, 2009).
Outra característica que deve ser observada é que no momento da instalação de uma
nova aplicação no dispositivo móvel é primordial que essa aplicação não afete outras
aplicações já existentes, bem como os serviços que o dispositivo oferece. Torna-se um desafio
garantir a qualidade de um dispositivo móvel que está constantemente recebendo novas
aplicações.
8 Software que reproduz as funções de um determinado aplicativo móvel em um ambiente controlado.
81
Por essa razão, os serviços relacionados com a rede são de prioridade alta durante a
execução do teste. Ou seja, os aplicativos que dependem da rede para o funcionamento, por
exemplo: Internet, chamadas de voz, chamadas de vídeo, MMS, SMS, são abordados com
maior cautela, para que nenhum deles apresente falhas durante a sua execução, pois à
comunicação é uma característica primordial do dispositivo.
De acordo com o Relatório Mundial de Qualidade (Capgemini, Sogeti e Hewlett-
Packard, 2012), 62% das organizações que buscam por parceiros externos para testar as
aplicações móveis priorizam a capacidade de efetuar os testes em várias redes (por exemplo,
redes rápidas e lentas). Com isso, procura-se garantir a cobertura da maior variedade possível
de ambientes, pois a conectividade é uma das características mais críticas do dispositivo
móvel, apresentando variações nos fatores relacionados à velocidade, segurança e
confiabilidade (Muccini, Di Francesco e Esposito, 2012).
No entanto, os dispositivos móveis são utilizados em muitas situações na qual a
comunicação é uma característica essencial, fazendo com que a qualidade de voz e a
comunicação de dados possam influenciar negativamente a troca de informações entre uma
equipe de salvamento, por exemplo. Por isso, é essencial saber qual o nível de robustez,
estabilidade e segurança que os dispositivos podem fornecer (Habib, Jacob e Olovsson, 2008).
Além da preocupação com o funcionamento correto dos serviços que utilizam a rede,
existe uma preocupação com os serviços relacionados ao marketing do dispositivo. Por vezes
o dispositivo móvel é direcionado para um público alvo específico, no qual os usuários
enfatizam determinado componente do aparelho e, dessa forma, as novas aplicações instaladas
não devem alterar o funcionamento desses serviços, como é o caso dos serviços de áudio,
vídeo e multimídia.
Na Tabela 3.3 são apresentados os principais serviços presentes nos dispositivos
móveis, cujo funcionamento não deve ser prejudicado pela instalação de novas aplicações.
Por meio da literatura, identificaram-se os principais serviços relacionados às funcionalidades
de rede e marketing, bem como as principais referências.
82
Tabela 3.3. Serviços do dispositivo móvel
Funcionalidades Serviços Referências
Rede
Comunicação por chamadas de voz.
[Falsafi, 2008]
[Kivi, 2007]
[Verkasalo, 2010]
Comunicação em tempo real em ambientes
heterogêneos, como VoIP9.
[Steuer et al., 2006]
[Verkasalo, 2010]
Comunicação por e-mail, SMS, MMS e mensagens
instantâneas.
[Steuer et al., 2006]
[Verkasalo, 2010]
Serviços de televisão móvel e streaming10. [Verkasalo, 2010]
Serviços de conexão de rede (Wi-Fi, 3G, GSM11, GPRS,
bluetooth, WLAN12, protocolos, sinais, taxas e
transferências).
[Kivi, 2007]
[Steuer et al., 2006]
[Verkasalo, 2010]
Serviços de mapas e navegações (GPS). [Kivi, 2007]
[Verkasalo, 2010]
Marketing
Serviços de multimídia (câmeras, músicas, galerias,
vídeos, jogos, downloads, armazenamento de arquivos,
calendário, agenda e perfil).
[Kivi, 2007]
[Verkasalo, 2010]
Classificou-se um total de 7 (sete) serviços, sendo que 6 (seis) estão relacionados com
a área de rede e 1 (um) com a área de marketing. Dessa forma, com os principais serviços
caracterizados e classificados, torna-se possível um melhor controle durante a abordagem
TM-Aplic, pois caso a aplicação móvel afete o funcionamento correto de algum dos serviços
observados, a aplicação deve ser revista e mais testes efetuados com o intuito de identificar a
falha na aplicação que está causando problemas nos serviços do dispositivo.
Com base nas características apresentadas, foi possível agrupar na Tabela 3.4 os
principais riscos (R) referentes às aplicações móveis e um plano de mitigação a fim de evitar
sua ocorrência ou, na pior situação, reduzir os seus efeitos. Vale ressaltar que um risco é um
evento no qual a ocorrência poderá causar algum tipo de problema no produto que será
disponibilizado para o usuário.
9 Voice over Internet Protocol (VoIP). 10 Forma de distribuir conteúdo multimídia na Internet. 11 Global System for Mobile Communications. 12 Wireless Local Area Network.
83
Tabela 3.4. Principais riscos e planos de mitigação
ID Riscos Referências Plano de Mitigação
R01
A aplicação pode não
funcionar em
determinados modelos de
dispositivos móveis
(contexto móvel).
[Dantas et al., 2009]
[Fling, 2009]
[Dim, Choi and
Wong, 2009]
Realizar testes nos mais variados modelos
de dispositivos móveis e analisar o
comportamento da aplicação.
R02 A aplicação pode ser
rejeitada pelos usuários.
[Dantas et al., 2009]
[Fling, 2009]
Enfatizar técnicas relacionadas aos testes
de usabilidade. Prover treinamentos e/ou
fornecer documentos para auxiliar os
usuários no manuseio das principais
funcionalidades da aplicação.
R03
A aplicação pode falhar
em ambientes externos
devido à mobilidade
fornecida ao usuário de
dispositivo móvel.
[Dantas et al., 2009]
[Fling, 2009]
Testes devem ser efetuados em campo a
fim de avaliar o comportamento da
aplicação sob a influência de fatores
externos, por exemplo, locais onde a
conexão de rede é instável.
R04
A aplicação pode
prejudicar o
funcionamento correto
dos serviços e/ou
aplicações existente no
dispositivo móvel.
[Dantas et al., 2009]
[Muccini, Di
Francesco e
Esposito, 2012]
[Kivi, 2007]
[Verkasalo, 2010]
Após a instalação da aplicação, testar os
principais serviços disponíveis no
dispositivo (chamadas, mensagens,
vídeos). Caso algum problema seja
encontrado, realizar reuniões com o
desenvolvedor da aplicação para que ele
possa realizar uma análise mais
aprofundada sobre qual funcionalidade
está impactando no funcionamento
incorreto de aplicações e/ou serviços
existentes no dispositivo.
Com base nos riscos apresentados, alguns questionamentos devem ser considerados
durante a análise da aplicação móvel.
Em relação ao risco R01 (Fling, 2009):
É possível utilizar todas as características físicas que o modelo do dispositivo
oferece?
As teclas funcionam corretamente?
A visualização da aplicação muda quando a orientação do dispositivo é alterada?
Se o dispositivo estiver em modo offline, tornando-se incapaz de enviar ou receber
dados, a aplicação apresenta erro ou indica para o usuário como resolver o
problema?
84
Em relação ao risco R02 (Fling, 2009):
Qual é a experiência do usuário em manusear um dispositivo móvel?
A aplicação inicia corretamente?
Quanto tempo demora até que o usuário possa executar uma ação?
Existe um indicador de progresso para orientar o usuário?
Em relação ao risco R03 (Fling, 2009):
Como a aplicação se comporta no momento de troca de torre de sinal? (esse teste
pode ser efetuado quando estiver dentro do carro em uma rodovia).
O que acontece quando o dispositivo perde a conexão?
Os usuários podem recuperar suas sessões? (inicie uma ação e, em seguida, entre
em um elevador ou garagem de estacionamento ou em algum lugar onde você sabe
que vai perder o sinal).
Em relação ao risco R04 (Dantas et al., 2009; Fling, 2009):
Após a instalação e operação da aplicação móvel os serviços relacionados a rede
continuam funcionando corretamente? E os serviços relacionados ao marketing?
Após a instalação e operação da aplicação móvel as aplicações já existentes
continuam funcionando corretamente?
A aplicação móvel pausa corretamente quando é interrompida por algum serviço
(por exemplo, chamada)?
É possível, ao término do serviço, retomar ao estado anterior da aplicação?
Os documentos (artefatos) gerados pelos desenvolvedores das aplicações também
devem ser considerados durante a análise do produto de teste. Por exemplo, ao término do
desenvolvimento de uma aplicação, o desenvolvedor responsável pode criar um documento
detalhando passo a passo possíveis situações de erro, com a intenção de identificar possíveis
situações anômalas e corrigi-las antes de enviar a aplicação para o teste. Esse documento pode
servir de apoio para o analista de teste identificar as situações de riscos.
De acordo com as características apresentadas, na Figura 3.4 é apresentado o fluxo de
atividades que compõe a realização da tarefa.
85
Figura 3.4. Diagrama de atividades – Analisar produto de teste
O artefato de teste gerado nessa tarefa é o relatório de análise do produto que, além
dos riscos e dos planos de mitigação, deve apresentar o gerente de testes responsável, nome
da aplicação (nome comercial), tipo da aplicação (web, negócio, produtividade,
comunicação), versão da aplicação e uma descrição.
Ao término da tarefa, o gerente de testes será capaz de identificar os riscos que podem
ameaçar à qualidade da aplicação móvel e, portanto, deve-se efetuar um controle e
monitoramento ao longo das tarefas. Os riscos identificados servem como base para qualquer
tipo de aplicação móvel.
3.4.1.2. Estabelecer Objetivos do Teste
Ao estabelecer o objetivo do teste determina-se o propósito da realização do teste de um
software específico. A maneira que o teste é conduzido depende dos objetivos esperados, que
representa o motivo e/ou propósito para projetar e executar um determinado teste, como
também delimita o que a organização busca alcançar com o teste (Crespo et al., 2010b;
SOFTEX, 2011).
86
A abordagem TM-Aplic considera duas principais atividades, a fim de estabelecer os
objetivos do teste, são elas: determinar o propósito do teste (Crespo et al., 2010; Softex,
2011); e definir características de aceitação e qualidade (Ickin et al., 2012; Mizouni et al.,
2009; Dantas et al., 2009; Zhang e Adipat, 2005).
A aceitação da aplicação móvel pelo usuário final merece destaque, pois várias
aplicações são retiradas de venda por não apresentarem um nível suficiente de aceitação pelos
usuários. No entanto, definir os critérios de aceitação de uma aplicação móvel não é uma
tarefa trivial, pois além dos critérios que envolve os produtos de software tradicionais, os
fatores relacionados à mobilidade estão presentes e devem ser considerados (Ickin et al.,
2012).
A usabilidade, por exemplo, é um fator essencial para determinar o sucesso e a
aceitação de uma aplicação móvel pelo usuário, pois é um atributo de qualidade importante
para que o usuário se sinta à vontade no momento de manusear uma aplicação em seu
dispositivo (Mizouni et al., 2009).
Dantas et al. (2009), Ickin et al., (2012) e Zhang e Adipat (2005) definem alguns
requisitos de testes referentes a usabilidade das aplicações móveis e, portanto, devem ser
considerados durante o teste. Por exemplo, a necessidade do usuário saber onde está na
aplicação; o que ele já fez; o que pode fazer e como desfazer os seus erros; as atividades não
devem ser desfeitas quando interrupções externas forçam a aplicação pausar; a aplicação deve
suportar os formatos de tela retrato e paisagem; solicitar a permissão do usuário antes de
estabelecer conexões; o contexto móvel, conectividade, telas com tamanho pequeno,
variedade de resoluções, métodos de entrada de dados, dificuldade com a posição e
localização das teclas e funções e entre outros.
Além disso, a aceitação de uma aplicação móvel vai além das características
relacionadas com a usabilidade, pois a percepção do usuário sobre a qualidade da aplicação
móvel também deve ser considerada e, com isso, 6 (seis) fatores são observados por Ickin et
al., (2012). São eles:
Desempenho: refere-se ao baixo desempenho da aplicação, como à velocidade de
execução das funcionalidades. Deve-se analisar o desempenho quando o usuário
estiver em movimento (mobilidade), pois fatores externos podem influenciar o usuário
e impactar na aplicação. Aplicações podem apresentar o desempenho afetado quando
necessitam de uma conexão para o funcionamento e a conexão disponibilizada é de
baixa qualidade;
87
Bateria: refere-se à utilização limitada do dispositivo, devido à capacidade da bateria;
Funções do Dispositivo: refere-se à ausência de características específicas no modelo
de dispositivo utilizado. São exemplos, suporte ao Adobe Flash, despertador
personalizado, modo silencioso (vibrar), suporte a GPS, configurações de privacidade;
Custo de Dados para Conexão e Aplicações: refere-se ao custo elevado de pacotes de
dados para conexão e aquisição de aplicações;
Rotina do Usuário: refere-se aos momentos do dia do usuário, no qual a aplicação vai
ser acessada. Por exemplo: na parte da manhã, antes de dormir, no carro, no trabalho,
ou seja, o ambiente que o usuário vai operar a aplicação; e
Estilo de Vida do Usuário: refere-se à classificação da aplicação em relação ao estilo
de vida do usuário, por exemplo, esportes, lazer, moda, entretenimento.
Outro objetivo que merece destaque durante o teste de aplicações móveis, é referente
às características de qualidade que a aplicação deve contemplar. Além das características de
qualidade que a norma NBR ISO/IEC 9126-1 que avalia produtos define para todo software
(seis níveis de qualidade), outras características mais específicas foram observadas na
literatura, por exemplo: autonomia, conectividade (rede), limitação de recursos, touch screen
e entre outras, descritas na Tabela 2.6. (Características de avaliação de qualidade do
dispositivo móvel e suas funcionalidades) da Seção 2.7. (Testes de Aplicações Móveis).
O artefato de teste gerado nessa tarefa é o relatório de objetivos do teste e deve
informar a descrição dos objetivos, ressaltando as características relacionadas com a aceitação
da aplicação móvel. Na Figura 3.5 é apresentado o fluxo de atividades que compõe a
realização da tarefa.
88
Figura 3.5. Diagrama de atividades – Definir objetivos do teste
3.4.1.3. Definir Estratégia de Teste
Essa tarefa define como o teste será realizado com base nos objetivos e na análise do produto
de teste. Faz parte dessa tarefa a identificação das principais características que estão
relacionadas com o contexto no qual o produto está inserido, além de traçar uma estratégia
para que elas não interfiram de forma negativa na aplicação móvel (SOFTEX, 2011).
Alguns fatores devem ser analisados com o intuito de definir as principais
características da aplicação (produto), por exemplo: observar as principais funcionalidades da
aplicação; avaliar as consequências se determinada funcionalidade não se comportar de
maneira correta, analisar o desempenho/eficiência da aplicação de acordo com o dispositivo
utilizado.
Assim, na Tabela 3.5 são apresentadas 4 (quatro) principais características (C) que
devem ser consideradas para compor a estratégia de testes para aplicações móveis.
89
Tabela 3.5. Principais características consideradas para compor a estratégia de testes para
aplicações móveis
ID Características Referências
C01 Analisar produto e os objetivos do teste. [Broekman e Notenboom, 2003]
C02 Tipos de testes.
C03 Local do teste (emulador e/ou no dispositivo móvel).
[Dantas et al., 2009]
C04 Ambiente do teste (laboratório - ambiente controlado
e/ou contexto móvel - ambiente externo).
Dessa forma, na Tabela 3.6 é apresentada a estratégia de testes para aplicações móveis,
na qual associou-se os 4 (quatro) principais riscos (R) e as 4 (quatro) principais características
(C), a fim de evitar a ocorrência ou, pelo menos, reduzir os efeitos dos riscos identificados. A
associação apresentada serve de base para a definição de outras estratégias de teste.
Tabela 3.6. Estratégia de testes para aplicações móveis
Características
Riscos C01 C02 C03 C04
R01 Adaptabilidade /
Compatibilidade
Usabilidade/
Estresse/
Desempenho
Dispositivo Móvel Laboratório
(ambiente controlado)
R02 Funcionalidade /
Touch Screen Usabilidade
Emulador e
Dispositivo Móvel
Laboratório
(ambiente controlado)
R03
Flexibilidade /
Sensibilidade ao
Contexto
Usabilidade/
Estresse/
Desempenho
Dispositivo Móvel Contexto Móvel
(ambiente externo)
R04
Conectividade
(Rede) /
Funcionalidade
Desempenho Dispositivo Móvel Laboratório
(ambiente controlado)
90
A coluna C01 da Tabela 3.6 indica o objetivo do teste para cada risco identificado. Em
outras palavras, para o risco R01 deve-se considerar como objetivos do teste a adaptabilidade
e a compatibilidade, para o risco R02 considerar a funcionalidade e o touch screen, para o
risco R03 considerar a flexibilidade e sensibilidade ao contexto e, para o risco R04, considerar
a conectividade e funcionalidade.
A coluna C02 indica o tipo do teste para cada situação de risco. Ou seja, para o risco
R01 deve-se considerar os testes de usabilidade, estresse e desempenho, para o risco R02
testes de usabilidade, para o risco R03 testes de usabilidade, estresse e desempenho e, para o
risco R04, testes de desempenho.
A coluna C03 indica o local de testes para cada situação de risco. Ou seja, para os
riscos R01, R02 e R03 deve-se efetuar testes no próprio dispositivo móvel e para o risco R04
deve-se efetuar testes no emulador e dispositivo móvel.
A coluna C04 indica o ambiente de testes para cada situação de risco. Ou seja, para os
riscos R01, R02 e R04, deve-se utilizar um laboratório específico e para o risco R03 os testes
devem ser efetuados sob a influência do contexto móvel.
É importante ressaltar que, para algumas características de qualidade, o ambiente em
que o teste será efetuado pode influenciar significativamente no resultado. Por exemplo, o
teste de usabilidade será melhor aproveitado se realizado no próprio dispositivo móvel em
condições reais de uso. Assim, os testes não devem ser feitos somente nos laboratórios
(ambientes controlados), mas também considerando as variações proporcionadas pela
mobilidade, no qual os fatores do ambiente externo podem influenciar o funcionamento
correto da aplicação, por exemplo, interrupções, movimento, barulho e iluminação.
Ou seja, operar a aplicação móvel em um dispositivo e ambiente real é uma
característica importante para o teste, pois quão mais próximo da realidade o teste se
aproximar, mais detalhes das aplicações poderão ser consideradas e, consequentemente, mais
falhas podem ser descobertas.
O artefato de teste gerado nessa tarefa é o relatório da estratégia de testes que
apresenta informações relacionadas com aos critérios de qualidade e/ou aceitação que serão
considerados, os tipos de testes, o local de teste (emulador e/ou dispositivo móvel) e o
ambiente de teste (laboratório e/ou contexto móvel). Na Figura 3.6 é apresentado o fluxo de
atividades que compõem a realização da tarefa.
91
Figura 3.6. Diagrama de atividades – Definir estratégia de teste
3.4.1.4. Definir Equipe de Teste
A composição de uma equipe depende das habilidades e conhecimentos disponíveis para
apoiar a execução do projeto de software (Bourque et al., 1999; Rios, Cristalli e Moreira
Filho, 2011; SOFTEX, 2011).
A abordagem TM-Aplic proposta nesta dissertação, considera 3 (três) principais
papéis específicos em cada uma das partes envolvidas no teste: Gerente de Teste, Analista de
Teste e Testador. O Gerente de Teste é o responsável pelas tarefas relacionadas ao
planejamento de teste; o Analista de Teste é o responsável por projetar os casos de testes de
acordo com as necessidades abordadas durante o planejamento, reportar e acompanhar os
incidentes; o Testador é responsável por executar os casos de testes.
Devido o tamanho da equipe (geralmente a equipe de teste é reduzida), o Gerente de
Teste pode desempenhar o papel dos outros membros da equipe. Por exemplo, realizar as
atividades de projetar e executar os casos de teste. No entanto, sugere-se que essas atividades
sejam divididas de acordo com o perfil de cada membro.
Na Tabela 3.7 são apresentados os papéis, responsabilidades e as respectivas tarefas da
abordagem TM-Aplic que serão executadas.
92
Tabela 3.7. Matriz de responsabilidades e tarefas (adaptada de Cristalli e Moreira Filho,
2011)
Papéis Responsabilidades Tarefas
Gerente de Teste
Profissional responsável por gerenciar
custos, esforços e riscos, definir
cronogramas, reportar progresso dos
testes e qualidade do produto, iniciar
ações corretivas quando houver desvios
dos parâmetros do planejamento do teste
ou quando a qualidade do produto se
desviar do esperado, perfil de liderança,
planejar, monitorar e controlar a
abordagem de testes, avaliar as
necessidades e recursos, trabalhar parte
do tempo em nível estratégico, a fim de
alinhar o trabalho de gestão com as
necessidades da organização.
Analisar o Produto de Teste
Estabelecer Objetivos do Teste
Definir Estratégia de Teste
Definir Equipe de Teste
Definir Ambiente de Teste
Estabelecer Plano de Teste
Planejar os Artefatos e Dados
Analista de Teste
Profissional responsável por projetar os
casos de teste, reportar incidentes
identificados pelo testador (detectar os
defeitos) e acompanhar incidentes até a
correção.
Identificar Casos de Teste
Reportar Incidentes
Acompanhar Incidentes
Testador
Profissional de perfil técnico responsável
pela execução dos casos de teste
especificados.
Executar Teste
De acordo com as responsabilidades e tarefas direcionadas ao Gerente de Teste,
Farrell-Vinay (2008) afirma que o mesmo deve apresentar habilidades, por exemplo: a
capacidade de analisar e distinguir entre as pessoas determinadas e as que agradam apenas por
interesses próprios, as iniciantes das experientes, as intelectuais das obcecadas por
tecnologias; seguir os preceitos do metodismo; escutar o que está sendo dito (quem e o que);
se portar de maneira profissional com outras equipes do projeto e tornar a popularidade uma
característica indiferente; suportar a pressão exercida pela atividade de gestão (insistir em
uma ideia ou opinião); avaliar a qualidade do trabalho da equipe de teste e conter o
entusiasmo em determinadas situações; não se prender nas preocupações do dia-a-dia e se
esquecer de situações primordiais relacionadas ao teste (por exemplo, um software que está
apresentando muitas situações de erros e deve ser inutilizável); reconhecer e elogiar o bom
trabalho da equipe; ser implacável com os maus funcionários; ser espontâneo; se preocupar
com o processo e o suporte no que se refere às ferramentas de apoio e as saídas; objetividade;
93
motivar a equipe; admitir as derrotas; avaliar os problemas de maneira otimista; conhecer na
prática as tarefas de um testador, a fim de entender as motivações e os valores necessários.
Além do Gerente de Teste, os Analistas de Teste e Testadores também devem
apresentar qualidades específicas, por exemplo: facilidade com a escrita, leitura e cálculo; ler
e escrever código; manter uma relação agradável com os membros da equipe (inclusive com a
equipe de desenvolvimento); atenção aos detalhes; se tornar especialista em determinado
domínio; pessimistas no que se refere em acreditar que o software possui erros; ser
competente tecnicamente; ser preciso; ser multitarefa no que se refere a testar vários recursos
do software; saber gerenciar o tempo; ser criativo em relação a novas maneiras de aplicação
do teste (Farrell-Vinay, 2008).
A presença de especialistas em serviços específicos do dispositivo móvel (por
exemplo, conectividade, chamadas, mensagens, identificação pessoal do usuário (PIN),
áudio/vídeo, multimídia), pode auxiliar na identificação e elaboração dos casos de testes e,
também, na análise dos possíveis incidentes. Além disso, os especialistas podem auxiliar para
que o testador concentre esforços em características específicas, para garantir que os serviços
dos dispositivos não foram prejudicados por alguma nova aplicação.
Durante a definição da equipe de testes, a organização pode não dispor recursos
humanos necessários para o início do projeto, acarretando no início de um processo de
contratação. Isso se deve a 2 (dois) principais fatores: carência técnica ou carência pessoal. A
carência técnica ocorre quando não existe um profissional com o perfil desejado para atuar
em determinada vaga (por exemplo, necessidade de um especialista em conectividade de
dispositivos móveis), e a carência pessoal ocorre quando todos os profissionais já estão
inseridos em outros projetos (a alocação de profissionais pode auxiliar nesse problema) (Rios,
Cristalli e Moreira Filho, 2011).
No entanto, alocar um profissional para outro projeto nem sempre é uma atividade
simples, pois quando um funcionário é inserido em outro projeto, muitas vezes em
andamento, desafios como, i) saber a quem perguntar sobre dúvidas do projeto, ii) não
incomodar os integrantes do projeto mais do que o necessário, iii) conhecer o produto, iv)
acesso limitado à documentação do projeto, v) saber onde encontrar as informações
necessárias, são situações que devem ser acompanhadas pelo gerente responsável de modo a
não prejudicar o andamento do projeto (Larsson, Bertilsson e Feldt, 2008). Além disso, deve
existir um processo de negociação entre os gerentes envolvidos, pois geralmente a alocação
de algum membro da equipe pode acarretar em alterações no cronograma do projeto (Rios,
Cristalli e Moreira Filho, 2011).
94
O artefato gerado nessa tarefa é o relatório da equipe de testes que apresenta as
informações relacionadas com a avaliação das carências técnicas e pessoais, necessidade de
especialistas, treinamentos, necessidade de alocação de profissionais de outros projetos e
composição da equipe.
A Figura 3.7 apresenta o fluxo de atividades que compõem a realização da tarefa.
Figura 3.7. Diagrama de atividades – Definir equipe de teste
3.4.1.5. Definir Ambiente de Teste
A definição de um ambiente de testes visa organizar todos os elementos necessários para a
execução do teste, tais como: parte física, infraestrutura, software de apoio, rede, hardware,
banco de dados e simuladores de testes (Broekman e Notenboom, 2003; SOFTEX, 2011).
Um ambiente de testes específico para aplicações móveis apresenta características
diferenciadas em comparação com ambientes para software tradicionais. Um ambiente de
testes convencional caracteriza-se como um ambiente estático, pois não sofre alterações
externas, se limitando somente ao software e às operações do usuário. Em contrapartida, as
aplicações móveis necessitam de um ambiente dinâmico, de modo a contemplar,
95
principalmente, as características relacionadas ao contexto móvel (dispositivos móveis) e ao
usuário de dispositivo móvel (mobilidade).
Na Figura 3.8 é apresentada uma comparação entre um ambiente estático e dinâmico.
Figura 3.8. Comparação entre um ambiente estático e dinâmico
Mesmo que uma aplicação móvel funcione adequadamente no emulador executado em
um computador, no dispositivo móvel pode não funcionar, demandando muito tempo e
dinheiro para corrigir os ajustes necessários. Isso se deve ao fato de que, cada dispositivo
móvel apresenta características funcionais únicas e, prever os mesmos resultados é quase
impossível em um ambiente de teste baseado em emulador, tornando-se necessário o teste em
dispositivos reais (Kim, Choi e Wong, 2009).
O usuário de dispositivo móvel é passível de interrupção, o que faz com que o
ambiente ao seu redor possa distrair sua atenção, interferindo na sua interação com a
aplicação móvel e, por isso, não se deve limitar um ambiente dinâmico somente a um
laboratório e uma variedade de modelos de dispositivos móveis, mas sim considerar os fatores
externos (mobilidade) que podem impactar de maneira negativa em como o usuário vai operar
um dispositivo (Ballard, 2007; Dantas et al., 2009).
Dessa forma, a estrutura do ambiente dinâmico deve favorecer a liberdade no uso do
dispositivo móvel, ser confortável e próxima da realidade, pois é importante que a pessoa que
estiver operando a aplicação sinta-se à vontade para segurar o aparelho e usá-lo da maneira
que mais o agrada, permitindo avaliar os gestos e outros movimentos corporais do usuário,
resultando em dados mais reais para as análises dos testes. Além disso, deve-se considerar os
testes efetuados em campo como uma forma de simular, o mais próximo da realidade, a
utilização da aplicação móvel. O teste em campo pode ser feito em movimento, em
pé/sentado, em casa/escritório, com silêncio/barulho, em ambientes claros/escuros, e
96
apresenta como objetivo analisar recursos específicos como, conectividade, mobilidade e
interrupções (Dantas, 2009).
As características apresentadas devem ser registradas em um artefato denominado
Relatório do Ambiente de Testes, o qual deve apresentar as seguintes informações básicas:
hardware, modelos de dispositivos, software, emuladores e aquisições necessárias para testes
em campo (por exemplo, necessidade de um automóvel para deslocamento). Além disso,
deve-se elaborar um documento com as características dos dispositivos homologados, a fim
de controlar, com maior precisão, os modelos que passaram pelo ambiente dinâmico de testes.
As características podem estar relacionadas com: marca, modelo, sistema operacional, se
possui teclado físico ou não e entre outros. Esses dispositivos devem estar relacionados com a
versão da aplicação móvel. No Quadro 3.1 é apresentado um exemplo de um catálogo de
dispositivos homologados.
Quadro 3.1. Exemplo de um catálogo de dispositivos homologados
CATÁLOGO DE DISPOSITIVOS HOMOLOGADOS
Aplicação XX 1.0v
Apple iPad
Apple iPhone
Samsung GT-P1000 Galaxy Tab
Samsung GT-I9000B Galaxy S Vibrant
Sony Ericsson LT15i Xperia Arc
Aplicação YY 1.0v
Apple iPad
Samsung GT-I9000B Galaxy S Vibrant
Samsung GT-i5500 Galaxy 5
Aplicação YY 2.0v
Apple iPad
Samsung GT-I9000B Galaxy S Vibrant
Samsung GT-i5500 Galaxy 5
Importante observar que, devido a nova versão da Aplicação YY, os mesmos modelos
de dispositivos da Versão 1.0v foram homologados, pois a nova versão apresenta
funcionalidades que podem não funcionar corretamente em determinados dispositivos.
Na Figura 3.9 é apresentado o fluxo de atividades que compõem a realização da tarefa.
97
Figura 3.9. Diagrama de atividades – Definir ambiente de teste
3.4.1.6. Estabelecer Plano de Teste
O plano de testes é um artefato que deve reunir todas as informações geradas a partir da
realização das tarefas do subprocesso Planejamento de Teste (Farrell-Vinay, 2008; Softex,
2011).
O plano de testes auxilia o analista de teste no que se refere à compreensão do
contexto em que o teste se enquadra, fornecendo as informações necessárias para iniciar as
tarefas do próximo subprocesso (Projeto e Execução do Teste). Quanto mais detalhado for o
plano de teste, mais eficientes serão as definições dos casos de teste e, portanto, levarão
menos tempo para serem elaborados.
Na Figura 3.10 é apresentado o fluxo de atividades que compõem a tarefa responsável
por estabelecer o plano de teste da abordagem TM-Aplic.
98
Figura 3.10. Diagrama de atividades – Estabelecer plano de teste
Alguns critérios podem ser estabelecidos para definir o término do subprocesso
Planejamento de Teste, por exemplo: as tarefas que compõe o plano devem ter sido
concluídas, o plano de teste deve atender aos padrões e às normas adotadas pela empresa e ser
avaliado por um processo de revisão, aprovação da versão corrente do plano de teste pelos
gestores responsáveis (Crespo et al., 2010b).
Para a abordagem TM-Aplic, o subprocesso Planejamento de Teste será concluído
somente ao término de todas as tarefas, pois mudanças significativas que ocorram ao longo do
teste indicam a necessidade de revisar as tarefas do planejamento e efetuar os ajustes
necessários.
Após a definição do plano de testes, a tarefa Planejar os Artefatos e Dados é invocada
para centralizar as informações documentadas e disponibilizar os artefatos necessários.
3.4.1.7. Planejar os Artefatos e Dados
Embora os Níveis 1 (um) (nível utilizado como base para a formulação da abordagem TM-
Aplic) e 2 (dois) de maturidade do modelo MPT.BR não estabeleçam diretrizes mais
específicas sobre a gestão dos artefatos de teste, a tarefa Planejar os Artefatos e Dados
(GPT12) ressalta a importância de gerenciar todas as informações documentadas ao longo das
atividades de teste no que se refere a coleta, armazenamento e distribuição (SOFTEX, 2011).
99
Essa característica deve ser ressaltada na abordagem TM-Aplic, pois as aplicações
móveis apresentam características similares entre si e, portanto, as informações registradas
nos artefatos gerados podem ser reusadas para o teste de outras aplicações. Por exemplo,
informações referentes a uma aplicação que foi testada em um modelo de dispositivo
específico contribuem para a transferência e reuso do conhecimento gerado e reavaliado nas
etapas da abordagem.
Além disso, Rodrigues, Pinheiro e Albuquerque (2010) ressaltam em seu trabalho, a
importância de um mecanismo para o armazenamento de artefatos visando apoiar as empresas
na divulgação de informações relacionadas com os artefatos gerados durante o teste, criando
uma cultura de teste e permitindo que algumas tarefas possam ser executadas por membros da
equipe que não tem experiência na área, no caso de alguma situação de carência técnica.
A primeira atividade da tarefa é concentrar os artefatos de testes gerados durante o
subprocesso Planejamento de Teste, armazená-los e comunicar o subprocesso Projeto e
Execução de Teste com as informações necessárias.
Após a execução das tarefas do subprocesso Projeto e Execução de Teste, os artefatos
gerados devem ser direcionados para a tarefa Planejar os Artefatos e Dados para que sejam
armazenados em um servidor, pois segundo a SOFTEX (2011), é fundamental que os
conceitos e procedimentos da gerência de configuração sejam aplicados.
Ao término da execução tarefas da abordagem TM-Aplic, as configurações deixadas
nos dispositivos utilizados ou em softwares podem influenciar no teste de outras aplicações,
portanto, é importante que as aplicações sejam testadas em dispositivos que apresentem
somente as configurações iniciais de fábrica, para que nenhum software ou configuração
externa possam influenciar nos testes.
Além disso, reuniões devem ser realizadas com a intenção de discutir os resultados da
execução das tarefas de teste, bem como as situações que não ocorreram como planejadas,
visando aprimorar os testes futuros. O gerente de testes pode apresentar um relatório final
com os resultados obtidos, por exemplo: cronograma, quantidade de casos de teste
identificados, quantidade de casos de teste executados, incidentes rejeitados, incidentes
adiados, incidentes corrigidos, conclusão final e melhorias observadas.
Na Figura 3.11 é apresentado o fluxo de atividades que descrevem a tarefa.
100
Figura 3.11. Diagrama de atividades – Planejar os artefatos e dados
3.4.2. Projeto e Execução de Teste
O objetivo do subprocesso Projeto e Execução de Teste é identificar, elaborar e executar casos
de teste, registrar a execução e as divergências entre os resultados atuais e esperados na forma
de incidentes, acompanhar e monitorar as devidas correções, com base no plano de teste
definido no subprocesso Planejamento de Teste (SOFTEX, 2011).
A primeira tarefa é realizada pelo Analista de Testes e consiste na identificação dos
casos de testes com base no Plano de Teste. Após os casos de testes serem identificados e
elaborados, o Testador inicia a tarefa de execução dos casos testes. Nesse momento, caso
algum defeito seja identificado, deve-se encaminhar um relatório de execução de teste para a
101
tarefa Reportar Incidentes, na qual o Analista de Teste gera o registro de incidentes,
encaminha para os responsáveis pelo desenvolvimento e acompanha até a sua correção (tarefa
Acompanhar Incidentes). Assim que a execução dos testes não detectar mais defeitos na
aplicação móvel, uma avaliação deve ser realizada para analisar se os objetivos do teste,
definidos no plano foram cumpridos. Essa avaliação deve ser efetuada pelo Analista de Teste.
Caso os objetivos não sejam cumpridos, deve-se retornar à tarefa Identificar Casos de
Teste, para que novos casos sejam elaborados pelo Analista de Testes, incluindo o Teste de
Regressão para garantir que as funcionalidades já existentes na aplicação não foram afetadas
negativamente. Assim, os artefatos devem ser enviados para a tarefa Planejar os Artefatos e
Dados, para que sejam devidamente arquivados. Além disso, o Gerente de Testes deve
supervisionar as tarefas, a fim de ajustar, se necessário, alguma característica do plano de
teste.
3.4.2.1. Identificar Casos de Teste
Segundo Myers (2004), um caso de teste deve apresentar pelo menos dois principais
componentes: i) a descrição dos dados de entrada para o programa; e ii) a descrição precisa da
saída correta do programa para a entrada. Além disso, o sucesso do caso de teste está
diretamente relacionado com a detecção de um defeito ainda não descoberto.
Identificar Casos de Teste é a primeira tarefa do subprocesso Projeto e Execução de
Testes e indica o que será verificado, quais as entradas, os procedimentos e resultados que
devem ser produzidos e como deve ser executado (SOFTEX, 2011).
A postura do responsável pela geração dos casos de testes (muitas vezes atribuída ao
Analista de Testes) é considerada como destrutiva, uma vez que ele deve buscar situações em
que o sistema possa reagir incorretamente às entradas. Entretanto, esta postura deve ser
considerada como positiva e ser utilizada para o desenvolvimento de software de melhor
qualidade (Crespo et al., 2010a).
O objetivo do caso de teste está diretamente relacionado com o nível de detalhes
apresentados no plano, pois quanto mais detalhado for o plano de testes, mais fácil é
determinar casos de testes que realmente desvendarão falhas na aplicação. Assim, a
identificação de falhas deve estar relacionada com os riscos que foram identificados durante a
análise da aplicação móvel. Para isso, deve-se fazer uma análise dos riscos identificados, da
estratégia de testes adotada e simular situações, com o intuito de garantir que os riscos
realmente não afetem de forma negativa o funcionamento da aplicação móvel.
102
Segundo Liu, Gao e Long (2010), a identificação de casos de testes para aplicações
móveis deve levar em consideração a limitação dos recursos dos dispositivos móveis, o que
acarreta em uma avaliação mais apurada de qual técnica de teste deve ser utilizada, pois
algumas técnicas apresentam um alto consumo de recursos e impactam de forma negativa na
execução normal da aplicação móvel. Por exemplo, as técnicas de teste caixa-branca que
requerem abordagens de análise estática e análise dinâmica para obter informações do código
fonte. A análise dinâmica necessita que a aplicação execute em tempo real consumindo muito
recurso do dispositivo e a análise estática está relacionada com as linguagens de programação
utilizadas para o desenvolvimento da aplicação.
Dessa forma, devido à grande variedade de dispositivos e sistemas operacionais, as
linguagens de programação diferem muito, dificultando o reuso dos casos de testes. Além
disso, as ferramentas que utilizam as técnicas de caixa-branca apresentam grandes
dificuldades em produzir casos de testes eficientes que utilizem o mínimo de recurso dos
dispositivos e que sejam flexíveis e reusáveis para outros contextos de aplicações móveis
(Liu, Gao e Long, 2010).
Sob esse aspecto, considera-se a técnica de teste caixa-preta para a geração de casos de
testes para aplicações móveis, na qual as informações de entrada e saída devem ser
consideradas. As entradas estão divididas em duas principais categorias: as fornecidas pelo
usuário por meio de uma interface gráfica (eventos de teclado e tela) e o contexto ambiental.
O contexto ambiental divide-se em: contexto físico e contexto social. O contexto físico é
obtido a partir das características físicas do dispositivo móvel, por exemplo: os receptores de
GPS, sensores de Bluetooth, de acelerômetro, magnéticos, umidade e de rede. O contexto
social está relacionado com as atividades realizadas pelo usuário no momento de operar a
aplicação móvel, por exemplo: alterações de humor. Assim, a aplicação móvel deve
considerar as variações de entrada, de modo a produzir as respectivas saídas que estão
diretamente relacionadas com a interface gráfica da aplicação e com a interação com o
usuário, por exemplo: exibição de imagens, vídeo, áudio, vibração e sinais luminosos (Liu,
Gao e Long, 2010).
O documento de caso de teste deve informar: o analista de testes responsável, o nome
da aplicação, o plano de testes correspondente, o objetivo do caso de testes, as condições de
entrada (usuário e/ou contexto ambiental) e os resultados esperados. Na Figura 3.12 é
apresentado o fluxo de atividades que compõem a realização da tarefa.
103
Figura 3.12. Diagrama de atividades – Identificar casos de teste
3.4.2.2. Executar Testes
Para cada caso de teste, o testador responsável deverá executá-lo, documentando as entradas e
os resultados, bem como comparar com os resultados esperados descritos no caso de teste
(SOFTEX, 2011).
O registro da execução do teste resulta em um artefato de teste denominado de
Relatório de Execução, e envolve a identificação e o detalhamento das informações
observadas durante os testes. Um incidente de teste é a manifestação de qualquer defeito no
software ou uma anomalia no funcionamento do ambiente operacional. Incidentes
encontrados durante a execução dos testes devem ser relatados em relatórios e encaminhados
para a tarefa Reportar Incidentes (Crespo et al., 2010a).
104
O relatório de execução do teste deve apresentar informações relacionadas com o
testador responsável pela execução, data e hora dos testes, duração da execução, caso de teste
executado, resultado da execução e o incidente identificado caso exista. Na Figura 3.13 é
apresentado o fluxo de atividades que compõem a realização da tarefa.
Figura 3.13. Diagrama de atividades – Executar teste
A tarefa é finalizada quando todos os casos de teste projetados tenham sido
executados, suas saídas avaliadas e todos os registros tenham sido feitos. Conforme
apresentado no diagrama da abordagem TM-Aplic (Figura 3.3), após a tarefa Executar Teste,
um comando de decisão (ver na Tabela 3.2) questiona a existência de defeitos. Se defeitos
foram detectados, os mesmos devem ser registrados e reportados pela tarefa Reportar
Incidentes e, em seguida, acompanhados até a sua correção pela tarefa Acompanhar
Incidentes. Caso defeitos não sejam detectados, outro questionamento é efetuado para analisar
se os casos de testes projetados foram suficientes para cobrir todos os requisitos de teste ou as
características definidas durante o planejamento e documentadas no plano de testes.
105
3.4.2.3. Reportar Incidentes
Um dos principais resultados do teste é a identificação dos incidentes. Entretanto, se os
incidentes detectados não são gerenciados, o esforço do teste é desperdiçado, uma vez que um
incidente é qualquer evento significativo, não planejado e observado durante a execução do
teste. Portanto, esta tarefa é responsável por reportar os incidentes observados durante a
execução do teste, para que os desenvolvedores realizem as devidas correções (SOFTEX,
2011).
Para cada incidente reportado, o Analista de Testes deve fornecer as condições
iniciais, resultados esperados, resultados atuais, incidente, data e hora, passos do
procedimento, frequência de ocorrência (sistemático, aleatório ou apenas uma vez), ambiente
de testes utilizado, tentativas de repetição, observador (refere-se a pessoas que estão
acompanhando o registro do incidente, por exemplo, um estagiário) e impacto do incidente.
A atividade que descreve os passos realizados que resultaram no incidente, deve
apresentar o máximo de detalhes possível, em ordem cronológica, das ações realizadas, além
de imagens para facilitar a compreensão e a reprodução do incidente. Quanto mais detalhes a
atividade apresentar, mais fácil será a sua reprodução e posterior correção.
A análise de impacto refere-se às consequências negativas na aplicação caso o
incidente ocorra. Por exemplo, o testador pode caracterizar um incidente que impede que um
cadastro seja finalizado e as informações inseridas sejam perdidas como um incidente de alto
impacto negativo.
Assim, de acordo com as características apresentadas sobre a tarefa Reportar
Incidentes, na Figura 3.14 é apresentado o fluxo de atividades que compõem a realização da
tarefa.
106
Figura 3.14. Diagrama de atividades – Reportar incidentes
3.4.2.4. Acompanhar Incidentes
O objetivo desta tarefa é garantir que todos os incidentes reportados sejam analisados e
acompanhados até a sua correção. Depois de registrado, o incidente deve passar por uma
análise detalhada pela equipe de correção (desenvolvedores) para que o impacto seja
analisado e uma prioridade atribuída. A prioridade pode variar entre: Rejeitar, Adiar e
Corrigir (SOFTEX, 2011).
O relatório de acompanhamento de incidentes deve ser elaborado pelo Analista de
Testes e deve apresentar, pelo menos, as informações relacionadas com o testador, descrição
do incidente, nível de prioridade, parecer do desenvolvedor e ação que deve ser realizada. Na
Figura 3.15 é apresentado o fluxo de atividades que compõem a realização da tarefa.
107
Figura 3.15. Diagrama de atividades – Acompanhar incidentes
Segundo SOFTEX (2011), de acordo com a descrição do incidente, o desenvolvedor
responsável deve classificar a prioridade (severidade) do mesmo entre baixa, média e alta, e
inserir o seu parecer a respeito do incidente. Após, as ações que devem ser tomadas para o
incidente são divididas em: rejeitar, adiar ou corrigir o incidente. Se a ação a ser tomada é a
rejeição do incidente, o incidente analisado não é um defeito, portanto não será corrigido. Se a
ação a ser tomada é adiar o incidente, o incidente não será corrigido no momento por entender
que o mesmo não é uma falha que vai prejudicar o funcionamento correto da aplicação,
portanto poderá ser corrigido posteriormente. Se a ação a ser tomada é corrigir o incidente, o
incidente é aceito e será corrigido. Após a composição do relatório de acompanhamento do
incidente, deve-se encaminhar o relatório para a tarefa de executar testes, para que o testador
responsável refaça os testes e, aplique o Teste de Regressão para garantir que a correção não
influenciou negativamente em outros módulos da aplicação.
Enfim, de acordo com Crespo et al. (2010c), o principal critério para o encerramento
do subprocesso Projeto e Execução de Teste é que todos os casos de teste previstos no plano
de teste tenham sido projetados e executados. No entanto, da mesma maneira que o
Planejamento de Testes, o Projeto e Execução de Testes também é um subprocesso
incremental, portanto, durante a realização das tarefas, novos itens ou funcionalidades podem
ser identificados, tornando necessária a geração de novos casos de teste.
108
3.5. Considerações Finais
A abordagem TM-Aplic abrange um conjunto de tarefas, artefatos e papéis, baseados no
Nível 1 (um) de maturidade do modelo MPT.BR, de forma a considerar os fatores inerentes
do ambiente móvel, tais como, contexto móvel, usuário de dispositivo móvel e aplicação
móvel. Além disso, fornece uma metodologia sistemática de execução das tarefas para
auxiliar na identificação de falhas antes da aplicação móvel ser liberada para os usuários
finais, contribuindo para a melhoria da qualidade do produto de software.
O cenário de uso da abordagem está apresentado na Figura 3.3., e conta com 2 (dois)
principais subprocessos (Planejamento de Teste e Projeto e Execução de Teste), 11 (onze)
tarefas (Analisar Produto de Teste, Estabelecer Objetivos do Teste, Definir Estratégia de
Teste, Definir Equipe de Teste, Definir Ambiente de Teste, Estabelecer Plano de Teste e
Planejar os Artefatos e Dados; Identificar Casos de Teste, Executar Teste, Reportar Incidentes
e Acompanhar Incidentes) e 3 (três) papéis (Gerente de Teste, Analista de Teste e Testador),
além dos artefatos resultantes de cada tarefa.
A fim de facilitar a compreensão da abordagem TM-Aplic, o capítulo a seguir
descreve um exemplo de aplicação da mesma, por meio de uma prova de conceito.
109
Exemplo de Aplicação da Abordagem
TM-Aplic
4.1. Considerações Iniciais
A prova de conceito apresentada neste capítulo é um tipo de estudo, realizado por meio da
descrição do funcionamento da abordagem TM-Aplic em um determinado exemplo, que pode
ser real ou não. A prova de conceito caracteriza-se pela falta de formalização durante a
realização do estudo, no qual o autor não utiliza os conceitos de experimentação, o que
inviabiliza obter conclusões sobre a real viabilidade da abordagem (Kitchenham et al., 2002).
Dessa forma, este capítulo apresenta um exemplo fictício de aplicação da abordagem
TM-Aplic apresentada no Capítulo 3, mas não serve para provar a viabilidade da mesma. A
viabilidade deve ser analisada por meio de um estudo experimental, realizado e apresentado
no Capítulo 5 desta dissertação.
4.2. Cenário
Para a prova de conceito da abordagem TM-Aplic considerou-se uma aplicação móvel que
registra o horário de trabalho do funcionário, na qual ele pode ter um controle diário das suas
horas trabalhadas, atrasos e faltas na empresa, além de possibilitar o confronto entre as
informações registradas e os relatórios fornecidos pela empresa.
4
Capítulo
110
A abordagem TM-Aplic deverá considerar um modelo de dispositivo móvel específico
que possui um teclado físico QWERTY deslizante. A aplicação foi desenvolvida para a
plataforma Android e utilizou-se o ambiente MOTODEV Studio for Android 3.0.0 que
fornece um conjunto de ferramentas para o desenvolvimento de aplicações. Utilizou-se a
Versão 12.0 do Android Development Toolkit13. O banco de dados utilizado foi o SQLite14,
que utiliza a Linguagem SQL (Structured Query Language) e faz parte da API da Plataforma
Android. O emulador utilizado a versão Android 2.1, conforme apresentada na Figura 4.1.
Figura 4.1. Emulador Android 2.1
As seções que seguem descrevem as tarefas definidas na abordagem TM-Aplic para o
cenário proposto.
4.3. Planejamento de Testes
Conforme abordado no Capítulo 3, o subprocesso Planejamento de Testes apresenta 7 (sete)
tarefas. São elas: i) Analisar Produto de Teste, ii) Estabelecer Objetivos do Teste, iii) Definir
Estratégia de Teste, iv) Definir Equipe de Teste, v) Definir Ambiente de Teste, vi) Estabelecer
Plano de Teste e vii) Planejar os Artefatos e Dados.
4.3.1. Analisar Produto de Testes
Nessa tarefa foram detalhados os aspectos técnicos relacionados à análise do produto para
compor o relatório de análise do produto. Desse modo o relatório deve apresentar o
identificador, o gerente de testes responsável, o nome, tipo e versão da aplicação, além da
descrição, os riscos e planos de mitigação. No Quadro 4.1 é apresentada a estrutura do
relatório de análise do produto com as principais informações.
13 http://developer.android.com/sdk/eclipse-adt.html 14 http://www.sqlite.org/
111
Quadro 4.1. Relatório de análise do produto
RELATÓRIO DE ANÁLISE DO PRODUTO
Identificador: PROD01
Gerente de Teste: Marcelo
Nome da Aplicação: Controle de Horários - CoHo
Tipo da Aplicação: Aplicação de Negócios
Versão da Aplicação: 1.0v
Descrição da Aplicação (Requisitos): A aplicação tem por objetivo armazenar os horários
de entrada, saída, intervalos e horas extras do funcionário durante o dia de trabalho. Ou
seja, toda vez que o usuário da aplicação registrar o seu ponto na empresa, ele também vai
fazer o registro na aplicação (CoHo), para que ele tenha um controle da sua pontualidade e
possa confrontar os resultados com o relatório emitido pela empresa no fim de cada mês.
Após a inicialização do aplicativo, o usuário vai selecionar qual horário ele deseja registrar
e confirmar. Em seguida a data e hora deverão ser preenchidas automaticamente e um
campo de observação poderá ser preenchido e o usuário deve confirmar. Por fim, o usuário
receberá uma mensagem de confirmação do registro gravado. A aplicação também permite
consultas, alterações e exclusões dos registros. Abaixo segue a imagem das principais
interfaces disponibilizadas pelo aplicativo.
Risco(s) Plano(s) de Mitigação
1) A aplicação pode não funcionar
corretamente em modelos diferenciados
de dispositivos móveis;
Realizar testes em modelos de dispositivos
móveis que apresentem teclado físico
QWERTY deslizante;
2) Os serviços básicos do dispositivo
podem não funcionar corretamente após
a instalação da aplicação;
Analisar o funcionamento dos serviços de
chamadas e mensagens;
112
4.3.2. Estabelecer Objetivos do Teste
Nessa tarefa foram detalhados os aspectos técnicos relacionados aos objetivos do teste, no que
se refere a determinar o propósito da realização do teste da aplicação móvel. Para esse
contexto, dois principais objetivos foram considerados: i) definir critérios de aceitação da
aplicação móvel; e ii) definir critérios de qualidade. Para isso, foram detalhados os aspectos
técnicos de alguns critérios de aceitação e algumas características de qualidade. No Quadro
4.2 é apresentada a estrutura do relatório de objetivos do teste.
Quadro 4.2. Relatório de objetivos do teste
RELATÓRIO DE OBJETIVOS DO TESTE
Identificador: OBJE01
Gerente de Teste: Marcelo
Nome da Aplicação: Controle de Horários – CoHo
Objetivos:
Definir Critérios de Aceitação:
o Usabilidade: a aplicação deve ajustar corretamente o formato de acordo com
a ativação do teclado físico, além de apresentar uma interface intuitiva e de
fácil entendimento e localização das funcionalidades.
o Desempenho: Como a aplicação não apresenta funcionalidades complexas e
nem exige algum tipo de conexão para funcionar, não é permitido qualquer
tipo de “congelamento” durante o manuseio.
Definir Critérios de Qualidade:
o Adaptabilidade/Compatibilidade: capacidade da aplicação móvel se
comportar de maneira estável em diferentes modelos de dispositivo;
o Conectividade (Rede): capacidade dos serviços básicos que utilizam rede
(chamadas e mensagens) funcionarem após a instalação e utilização da
aplicação móvel.
113
4.3.3. Definir a Estratégia de Testes
Nessa tarefa foram detalhados os aspectos técnicos relacionados a estratégia de testes para
aplicações de Controle de Horários – CoHo. A estratégia apresenta uma relação entre os
riscos e objetivos identificados, os tipos de testes, o local que será realizado o teste (emulador
e/ou dispositivo móvel) e o ambiente de teste (laboratório e/ou contexto móvel). No Quadro
4.3 é apresentada a estrutura do relatório da estratégia de testes.
Quadro 4.3. Relatório da estratégia de testes
RELATÓRIO DA ESTRATÉGIA DE TESTES
Identificador: ESTR01
Gerente de Teste: Marcelo
Nome da Aplicação: Controle de Horários – CoHo
Riscos Critérios Tipos de Teste Local Ambiente
Risco 1 Adaptabilidade/
Compatibilidade
Teste de
Usabilidade
Dispositivo Móvel (modelo
GT-I5510 SAMSUNG com
teclado físico QWERTY
deslizante)
Laboratório
(ambiente
controlado)
Risco 2 Conectividade Teste de
Desempenho
Dispositivo Móvel (modelo
GT-I5510 SAMSUNG com
teclado físico QWERTY
deslizante)
Laboratório
(ambiente
controlado)
4.3.4. Definir Equipe de Testes
Nessa tarefa foram detalhados os aspectos técnicos relacionados a definição da equipe de
testes e registrado no relatório da equipe de testes. O Quadro 4.4 apresenta o relatório da
equipe de testes.
Quadro 4.4. Relatório da equipe de testes
RELATÓRIO DA EQUIPE DE TESTES
Identificador: EQUI01
Gerente de Teste: Marcelo
Nome da Aplicação: Controle de Horários – CoHo
Analista de Testes: Ivo – Função: analisar plano de testes, projetar casos de testes, acompanhar o testador.
Testador: Geovane – executar casos de testes, reportar incidentes, acompanhar incidentes.
Especialista Específico: ( X ) Não ( ) Sim Qual (is):
Treinamento: ( X ) Não ( ) Sim Qual (is):
114
4.3.5. Definir Ambiente de Testes
Nessa tarefa foram detalhados os aspectos técnicos relacionados a definição do ambiente de
testes necessário para o processo, envolvendo características relacionadas a hardware,
software, rede, simuladores de testes. No Quadro 4.5 é apresentado o relatório do ambiente de
testes para aplicações móveis
Quadro 4.5. Relatório do ambiente de testes
RELATÓRIO DO AMBIENTE DE TESTES
Identificador: AMBI01
Gerente de Teste: Marcelo
Nome da Aplicação: Controle de Horários – CoHo
Hardware: computador pessoal dos participantes.
Dispositivo Móvel: dispositivo GT-I5510 SAMSUNG com teclado QWERTY deslizante.
Software: MOTODEV Studio for Android 3.0 e skype.
Emulador: Android 2.1 – update 1
Requisitos para Testes em Campo: Não aplicável
4.3.6. Estabelecer Plano de Testes
Nessa tarefa foram detalhados os aspectos técnicos relacionados ao plano de teste para
aplicações móveis com informações obtidas a partir da execução das tarefas que compõem o
subprocesso Planejamento do Teste. No Quadro 4.6 é apresentado o plano de testes gerado.
Quadro 4.6. Plano de testes
PLANO DE TESTES
Identificador: PLAN01
Gerente de Teste: Marcelo
Nome da Aplicação: Controle de Horários – CoHo
Tipo da Aplicação: Aplicação de Negócios
Versão da Aplicação: 1.0v
Continua
115
PLANO DE TESTES
Descrição da Aplicação (Requisitos): A aplicação tem por objetivo armazenar os horários
de entrada, saída, intervalos e horas extras do funcionário durante o dia de trabalho. Ou
seja, toda vez que o usuário da aplicação registrar o seu ponto na empresa, ele também vai
fazer o registro na aplicação (CoHo), para que ele tenha um controle da sua pontualidade e
possa confrontar os resultados com o relatório emitido pela empresa no fim de cada mês.
Após a inicialização do aplicativo, o usuário vai selecionar qual horário ele deseja registrar
e confirmar. Em seguida a data e hora deverão ser preenchidas automaticamente e um
campo de observação poderá ser preenchido e o usuário deve confirmar. Por fim, o usuário
receberá uma mensagem de confirmação do registro gravado. A aplicação também permite
consultas, alterações e exclusões dos registros. Abaixo segue a imagem das principais
interfaces disponibilizadas pelo aplicativo.
Risco(s) Plano(s) de Mitigação
1) A aplicação pode não funcionar
corretamente em modelos diferenciados
de dispositivos móveis;
Realizar testes em modelos de dispositivos
móveis que apresentem teclado físico
QWERTY deslizante;
2) Os serviços básicos do dispositivo
podem não funcionar corretamente após
a instalação da aplicação;
Analisar o funcionamento dos serviços de
chamadas e mensagens;
Continua
116
PLANO DE TESTES
Objetivos:
Definir Critérios de Aceitação:
o Usabilidade: a aplicação deve ajustar corretamente o formato de acordo com
a ativação do teclado físico, além de apresentar uma interface intuitiva e de
fácil entendimento e localização das funcionalidades.
o Desempenho: Como a aplicação não apresenta funcionalidades complexas e
nem exige algum tipo de conexão para funcionar, não é permitido qualquer
tipo de “congelamento” durante o manuseio.
Definir Critérios de Qualidade:
o Adaptabilidade/Compatibilidade: capacidade da aplicação móvel se
comportar de maneira estável em diferentes modelos de dispositivo;
o Conectividade (Rede): capacidade dos serviços básicos que utilizam rede
(chamadas e mensagens) funcionarem após a instalação e utilização da
aplicação móvel.
Riscos Critérios Tipos de Teste Local Ambiente
Risco 1 Adaptabilidade/
Compatibilidade
Teste de
Usabilidade
Dispositivo Móvel (modelo
GT-I5510 SAMSUNG com
teclado físico QWERTY
deslizante)
Laboratório
(ambiente
controlado)
Risco 2 Conectividade Teste de
Desempenho
Dispositivo Móvel (modelo
GT-I5510 SAMSUNG com
teclado físico QWERTY
deslizante)
Laboratório
(ambiente
controlado)
Analista de Testes: Ivo – Função: analisar plano de testes, identificar casos de testes, acompanhar o testador, consolidar dados de testes.
Testador: Geovane – Função: executar casos de testes, reportar incidentes, acompanhar incidentes. Especialista Específico: ( X ) Não ( ) Sim Qual (is):
Treinamento: ( X ) Não ( ) Sim Qual (is):
Hardware: computador pessoal dos participantes.
Dispositivo Móvel: dispositivo GT-I5510 SAMSUNG com teclado QWERTY deslizante.
Software: MOTODEV Studio for Android 3.0 e Skype.
Emulador: Android 2.1 – update 1
Requisitos para Testes em Campo: Não aplicável
Cronograma: 25/02/2013 a 25/03/2013
117
4.3.7. Planejar os Artefatos e Dados
Nessa tarefa foram detalhados os aspectos técnicos relacionados ao resumo do teste que deve
ser realizado ao término da execução das tarefas de teste, a fim de analisar e discutir o
cumprimento do cronograma, quantidade de casos de testes identificados e executados,
quantidade de incidentes rejeitados, adiados, corrigidos e conclusão, com os membros da
equipe. O Quadro 4.7 apresenta as observações.
Quadro 4.7. Observações gerais do teste
OBSERVAÇÕES GERAIS DO TESTE
Identificador: ENCE01
Plano de Testes: PLAN01
Gerente de Teste: Marcelo
Data Início: 25/02/2013 Data Fim: 25/03/2013
Casos de Teste Identificados: 3 (três)
Casos de Teste Executados: 3 (três)
Incidentes Rejeitados: 1 (um)
Incidentes Adiados: 0 (zero)
Incidentes Corrigidos: 1 (um)
Conclusão: Com base em 2 (duas) principais áreas de risco: Risco 1 (a aplicação pode não
funcionar corretamente em modelos diferenciados de dispositivos móveis) e Risco 2 (os
serviços básicos do dispositivo podem não funcionar corretamente após a instalação da
aplicação), e nos objetivos principais do teste, como: garantir a aceitação da aplicação
móvel pelo cliente e obter a confiança sobre o nível de qualidade da aplicação, a abordagem
aplicada para a aplicação de Controle de Horários – CoHo definiu uma estratégia de testes,
a qual resultou na identificação de 3 (três) casos de teste. Após a execução dos casos de
testes, identificou-se 2 (dois) incidentes, no qual um foi rejeitado e o outro corrigido.
Melhorias Observadas: Observou-se a necessidade da geração de outros casos de testes
com a intenção de explorar novas funcionalidades da aplicação móvel.
118
4.4. Projeto e Execução de Testes
Conforme abordado no Capítulo 3 da presente dissertação, o subprocesso Projeto e Execução
de Testes apresenta 4 (quatro) tarefas. São elas: i) Identificar Casos de Teste, ii) Executar
Teste, iii) Reportar Incidentes e iv) Acompanhar Incidentes.
4.4.1. Identificar Casos de Teste
Nessa tarefa foram detalhados os aspectos técnicos relacionados a geração de casos de testes,
baseando-se no plano de testes apresentado. Vários casos de teste poderiam ser identificados,
porém, para via de explicação, 3 (três) casos de testes foram considerados. Os Quadros 4.8,
4.9 e 4.10 apresentam os casos de testes que serão executados pela tarefa Executar Teste.
Quadro 4.8. Caso de teste – CASO01
CASO DE TESTE
Identificador: CASO01
Analista de Teste: Ivo
Nome da Aplicação: Controle de Horários – CoHo
Plano de Testes: PLAN01
Objetivo: Registrar o horário na aplicação utilizando o teclado físico deslizante QWERTY
do modelo GT-I5510 SAMSUNG.
Condições Iniciais: A aplicação deve estar iniciada.
Entradas:
Usuário (interface gráfica): enviar informações por meio do teclado físico.
Contexto Ambiental: ativação do acelerômetro (contexto físico).
Resultado Esperado: A aplicação deve registrar o horário corretamente. Deve se adequar
ao sentido da tela quando o teclado físico for habilitado, para que o usuário consiga efetuar
o registro de horário. Uma mensagem deve informar o usuário se a transação foi efetuada
com sucesso.
119
Quadro 4.9. Caso de teste – CASO02
CASO DE TESTE
Identificador: CASO02
Analista de Teste: Ivo
Nome da Aplicação: Controle de Horários – CoHo
Plano de Testes: PLAN01
Objetivo: Efetuar e receber chamadas com a aplicação CoHo ativada.
Condições Iniciais: A aplicação CoHo deve estar iniciada.
Entradas
Usuário (interface gráfica): enviar informações para o dispositivo móvel para efetuar e
receber chamadas.
Resultado Esperado: A aplicação deve permitir a realização e o recebimento de chamadas
de voz.
Quadro 4.10. Caso de teste – CASO03
CASO DE TESTE
Identificador: CASO03
Analista de Teste: Ivo
Nome da Aplicação: Controle de Horários – CoHo
Plano de Testes: PLAN01
Objetivo: Enviar e receber mensagens de texto com a aplicação CoHo ativada.
Condições Iniciais: A aplicação CoHo deve estar iniciada.
Entradas
Usuário (interface gráfica): enviar informações para o dispositivo móvel para enviar e
receber mensagens.
Resultado Esperado: A aplicação deve permitir o envio e o recebimento de mensagens de
texto.
4.4.2. Executar Testes
Nessa tarefa foram detalhados os aspectos técnicos relacionados a execução dos casos de
testes. O objetivo da tarefa é registrar a execução e os incidentes identificados. No Quadro
4.11 é apresentado o relatório de execução do teste, o qual resultou em 1 (um) incidente
identificado e registrado no documento.
120
Quadro 4.11. Relatório de execução
RELATÓRIO DE EXECUÇÃO
Identificador: EXEC01
Testador: Geovane
Data/Hora e Duração da Execução: 26/02/2013 11h13min – 1h30min
Casos de Testes Executados: CASO01, CASO02, CASO03
Resultado da Execução: Todas as execuções ocorreram conforme instruções estabelecidas
no caso de teste. Os casos de teste CASO02 e CASO03 não apresentaram incidentes.
Incidente Identificado: Para o caso de teste CASO01, no momento da ativação do teclado
físico, percebeu-se certa demora (4 segundos) para a tela se ajustar ao sentido correto. Além
disso, após o ajuste, a aplicação se comportou de maneira confusa, dificultando o
entendimento da localização das funcionalidades da aplicação, por exemplo, a localização
dos botões Ok e Cancelar. Dessa forma, 2 (dois) incidentes foram identificados.
4.4.3. Reportar Incidentes
Nessa tarefa foram detalhados os aspectos técnicos relacionados ao registro de incidentes. O
registro de incidente deve conter todas as informações observadas pelo testador para auxiliar o
desenvolvedor durante as correções. Os Quadros 4.12 e 4.13 apresentam os registros dos
incidentes que devem ser reportados para a tarefa próxima tarefa.
Quadro 4.12. Registro de incidente – INCI01
REGISTRO DE INCIDENTE
Identificador: INCI01
Analista de Teste: Ivo
Relatório de Execução: EXEC01
Condições Iniciais: A aplicação deve estar iniciada.
Resultados Esperados: Espera-se que seja possível utilizar a aplicação de forma correta e
efetuar o registro de horários utilizando o modelo de dispositivo que possua um teclado
físico QWERTY deslizante.
Resultados Atuais: Após a ativação do teclado físico, a aplicação demora em ajustar ao
sentido correto da tela.
Incidente: A aplicação móvel demora em ajustar o layout da tela quando o teclado físico é
solicitado.
Data/Hora: 26/02/2013 13h30min
Continua
121
REGISTRO DE INCIDENTE
Passos do Procedimento: Iniciou-se a aplicação com o teclado físico desativado. Logo
após, solicitou-se a ativação do teclado físico QWERTY deslizante, para auxiliar na
digitação. No momento da ativação do teclado, houve certa demora para a aplicação se
justar ao novo sentido da tela (aproximadamente 4 segundos), conforme apresenta a
imagem abaixo.
Frequência de Ocorrência: ( ) Sistemático (X) Aleatório ( ) Apenas uma vez
Ambiente: O teste foi efetuado em laboratório (ambiente controlado), no qual o testador
estava em pé com o dispositivo móvel GT-I5510 SAMSUNG em mãos.
Tentativas de Repetição: O procedimento foi repetido aproximadamente 5 (cinco) vezes.
Observadores: 1 (um) estagiário acompanhou o registro do incidente.
Impacto: O incidente identificado impacta diretamente na aceitação da aplicação pelo
usuário final, pois vai contra os critérios de aceitação relacionados com a Usabilidade e
Interface.
Quadro 4.13. Registro de incidente – INCI02
REGISTRO DE INCIDENTE
Identificador: INCI02
Analista de Teste: Ivo
Relatório de Execução: EXEC01
Condições Iniciais: A aplicação deve estar iniciada.
Resultados Esperados: Espera-se que seja possível utilizar a aplicação de forma correta e
efetuar o registro de horários utilizando o modelo de dispositivo que possua um teclado
físico QWERTY deslizante.
Continua
122
REGISTRO DE INCIDENTE
Resultados Atuais: Após a ativação do teclado físico, a aplicação se comporta de maneira
confusa, dificultando o entendimento da localização das funcionalidades da aplicação, por
exemplo, a localização dos botões Ok e Cancelar.
Incidente: A aplicação móvel não obedece ao layout de tela apresentado pelo modelo do
dispositivo utilizado
Data/Hora: 26/02/2013 14h00min
Passos do Procedimento: Quando o teclado físico é solicitado, a aplicação não se ajusta ao
layout da tela, dificultando a navegação, pois o ajuste da tela “esconde” a localização dos
botões Ok e Cancelar, conforme apresenta a imagem abaixo.
Frequência de Ocorrência: (X) Sistemático ( ) Aleatório ( ) Apenas uma vez
Ambiente: O teste foi efetuado em laboratório (ambiente controlado), no qual o testador
estava em pé com o dispositivo móvel GT-I5510 SAMSUNG em mãos.
Tentativas de Repetição: O procedimento foi repetido aproximadamente 5 (cinco) vezes.
Observadores: 1 (um) estagiário acompanhou o registro do incidente.
Impacto: O incidente identificado impacta diretamente na aceitação da aplicação pelo
usuário final, pois vai contra os critérios de aceitação relacionados com a Usabilidade e
Interface.
123
4.4.4. Acompanhar Incidentes
Nessa tarefa foram detalhados os aspectos técnicos relacionados ao acompanhamento dos
incidentes reportados, a fim de registrar todas as informações sobre as decisões a respeito de
um determinado incidente. Dessa forma, nos Quadros 4.14 e 4.15 são apresentados os
relatórios de acompanhamento de incidentes.
Quadro 4.14. Relatório de acompanhamento de incidentes – ACOM01
RELATÓRIO DE ACOMPANHAMENTO DE INCIDENTES
Identificador: ACOM01
Analista de Teste: Ivo
Incidente: INCI01
Descrição: A aplicação móvel demora em ajustar o layout da tela quando o teclado físico é
solicitado.
Prioridade: ( ) Baixa ( X ) Média ( ) Alta
Parecer do Desenvolvedor: O incidente reportado não se trata de um problema
relacionado diretamente com a aplicação móvel, e sim, com o hardware do modelo do
dispositivo. No entanto, o incidente impacta diretamente nos critérios de aceitação
relacionados com a Interface e Usabilidade da aplicação.
Ação: ( X ) Rejeitar ( ) Adiar ( ) Corrigir
Quadro 4.15. Relatório de acompanhamento de incidentes – ACOM02
RELATÓRIO DE ACOMPANHAMENTO DE INCIDENTES
Identificador: ACOM02
Analista de Teste: Ivo
Incidente: INCI01
Descrição: Após a ativação do teclado físico, a aplicação se comporta de maneira confusa,
dificultando a localização das funcionalidades da aplicação, por exemplo, a localização dos
botões Ok e Cancelar.
Prioridade: ( ) Baixa ( X ) Média ( ) Alta
Parecer do Desenvolvedor: O incidente reportado deve ser corrigido, revendo os métodos
responsáveis pela disposição dos componentes na tela quando o teclado físico é ativado. O
incidente impacta diretamente nos critérios de aceitação relacionados com a Interface e
Usabilidade da aplicação.
Ação: ( ) Rejeitar ( ) Adiar ( X ) Corrigir
124
4.5. Considerações Finais
A prova de conceito apresentada demonstra como a abordagem TM-Aplic apresentada no
Capítulo 3, da presente dissertação, pode ser instanciada, não tendo como objetivo extrair
conclusões sobre a real viabilidade e funcionalidade da mesma. As limitações e dificuldades
encontradas durante a realização da prova de conceito foram:
Limitação do produto, pois foi utilizada uma aplicação móvel de complexidade
mínima para a exemplificação da abordagem TM-Aplic;
Limitação da quantidade de casos de testes, pois seria necessário um prazo maior para
análise de mais casos; e
Dificuldade em encontrar profissionais especialistas em testes de aplicações móveis
para acompanhar a prova de conceito.
No entanto, esta prova de conceito não tem o intuito de validar a abordagem proposta,
mas sim elucidar o seu funcionamento. O próximo capítulo apresenta o estudo experimental
de viabilidade da abordagem TM-Aplic.
125
Estudo Experimental de Viabilidade da
Abordagem TM-Aplic
5.1. Considerações Iniciais
Conforme apresentado na metodologia de desenvolvimento caracterizada no Capítulo 1, os
princípios da Engenharia de Software Experimental (Basili, 2007) foram utilizados para
conduzir o estudo experimental de viabilidade da abordagem TM-Aplic proposta no Capítulo
3 da presente dissertação.
Diante da lacuna entre a comunidade científica e a indústria, novas tecnologias são
adotadas sem qualquer prova convincente de que realmente são eficazes para o contexto. A
comunidade científica, por sua vez, possui maneiras específicas de avaliar a qualidade dos
processos e produtos quando submetidos a novas abordagens, fortalecendo ainda mais a
distância entre academia e indústria (Zelkowitz et al., 2003).
Dessa forma, o principal objetivo do estudo experimental é investigar a abordagem
TM-Aplic com relação à sua viabilidade para ser utilizada em empresas que desenvolvem
aplicações móveis, além de construir um corpo de conhecimento que aborda a plausibilidade
da continuidade do estudo.
5
Capítulo
126
Assim, o estudo experimental foi caracterizado como um estudo quasi experimental in
virtuo, pois é composto por modelos numéricos, manipulados por um conjunto de
participantes disponíveis selecionados de forma não aleatória (Travassos e Barros, 2003).
O capítulo está composto pelas seguintes seções: definição, planejamento, execução,
análise e interpretação dos resultados, avaliação de validade do estudo, além das lições
aprendidas com o estudo experimental na Seção de considerações finais.
5.2. Definição do Estudo Experimental
A definição do estudo experimental utiliza uma notação baseada em Goal/Question/Metric
(GQM), pois a mesma fornece uma abordagem sistemática para definir as metas do estudo
experimental (Basili e Rombach, 1988). A notação consiste na elaboração dos objetivos (G),
formulação das questões (Q) e definição das métricas (M). Dessa forma, o objetivo do estudo
experimental é apresentado a seguir:
Analisar a abordagem TM-Aplic
Com o propósito de avaliar sua viabilidade
Referente à capacidade de ser utilizada como uma abordagem sistemática de testes
para aplicações móveis
Do ponto de vista de empresas que desenvolvem software para dispositivos móveis
No contexto de profissionais da área de Tecnologia da Informação de empresas de
pequeno porte que atuam com aplicações móveis e teste de software.
O objetivo apresentado é alcançado quando respostas podem ser dadas às questões (Q)
a seguir. Para isso, métricas (M) foram associadas às questões.
Q1: A tarefa Analisar Produto de Teste presente na abordagem atende as necessidades
das aplicações móveis (fatores do ambiente móvel)?
M1: Número de indicações dos participantes quanto à concordância com a tarefa.
Q2: A tarefa Estabelecer Objetivos do Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
M2: Número de indicações dos participantes quanto à concordância com a tarefa.
127
Q3: A tarefa Definir Estratégia de Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
M3: Número de indicações dos participantes quanto à concordância com a tarefa.
Q4: A tarefa Definir Equipe de Teste presente na abordagem atende as necessidades
das aplicações móveis (fatores do ambiente móvel)?
M4: Número de indicações dos participantes quanto à concordância com a tarefa.
Q5: A tarefa Definir Ambiente de Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
M5: Número de indicações dos participantes quanto à concordância com a tarefa.
Q6: A tarefa Estabelecer Plano de Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
M6: Número de indicações dos participantes quanto à concordância com a tarefa.
Q7: A tarefa Planejar os Artefatos e Dados presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
M7: Número de indicações dos participantes quanto à concordância com a tarefa.
Q8: A tarefa Identificar Casos de Teste presente na abordagem atende as necessidades
das aplicações móveis (fatores do ambiente móvel)?
M8: Número de indicações dos participantes quanto à concordância com a tarefa.
Q9: A tarefa Executar Teste presente na abordagem atende as necessidades das
aplicações móveis (fatores do ambiente móvel)?
M9: Número de indicações dos participantes quanto à concordância com a tarefa.
Q10: A tarefa Reportar Incidentes presente na abordagem atende as necessidades das
aplicações móveis (fatores do ambiente móvel)?
M10: Número de indicações dos participantes quanto à concordância com a tarefa.
128
Q11: A tarefa Acompanhar Incidentes presente na abordagem atende as necessidades
das aplicações móveis (fatores do ambiente móvel)?
M11: Número de indicações dos participantes quanto à concordância com a tarefa.
Q12: Os artefatos gerados nas tarefas presentes na abordagem são suficientes para
atender as necessidades das aplicações móveis (fatores do ambiente móvel)?
M12: Número de indicações dos participantes quanto à concordância com os artefatos.
Q13: A padronização das tarefas e artefatos, definidos na abordagem TM-Aplic, pode
contribuir para um significativo ganho na qualidade do produto final?
M13: Número de indicações dos participantes quanto à concordância.
5.3. Planejamento do Estudo Experimental
Esta Seção descreve o plano do estudo experimental, composta pelos seguintes elementos:
contexto global, contexto local, treinamento, projeto piloto, participantes, instrumentação,
variáveis dependentes, variáveis independentes, análise qualitativa, capacidade aleatória,
classificação em bloco, mecanismos de análise, validade interna, validade externa e validade
de conclusão.
5.3.1. Contexto Global
As indústrias de desenvolvimento de aplicações móveis enfrentam grandes desafios
relacionados ao fornecimento de aplicações que sejam de real valor para as pessoas e
empresas, no que se refere ao comportamento correto, sem falhas, sem perda de dados ou
serviços, que não interfiram em outras aplicações e serviços já existentes no dispositivo, além
dos fatores inerentes do ambiente móvel (Mizouni et al., 2009; Muccini, Di Francesco e
Esposito, 2012; She, Sivapalan e Warren, 2009).
No entanto, as ferramentas e técnicas que têm sido estudadas para auxiliar os
ambientes de desenvolvimento de software tradicionais (desktop), não traduzem as
necessidades das aplicações móveis, ocasionando inúmeros problemas, principalmente
relacionados com a usabilidade, uma das principais razões da insatisfação do usuário
(Mizouni et al., 2009).
129
Sob tal aspecto, a abordagem TM-Aplic foi proposta (Capítulo 3), com a intenção de
estabelecer uma metodologia sistemática de testes que combine boas práticas de
planejamento, projeto e execução de testes com as necessidades e particularidades das
aplicações móveis, em termos de tarefas, artefatos e papéis, de maneira que contribua para a
qualidade do produto final.
5.3.2. Contexto Local
Este estudo tem como objetivo analisar a viabilidade da abordagem TM-Aplic proposta no
Capítulo 3 desta dissertação. Para tanto, a abordagem foi avaliada por profissionais da área,
com o objetivo de verificar se a metodologia sistemática de testes é passível de apoiar na
melhoria da qualidade do produto final, considerando os fatores inerentes do ambiente móvel.
5.3.3. Treinamento
Nenhum treinamento foi realizado para este estudo, apenas uma breve apresentação sobre o
contexto do experimento.
5.3.4. Projeto Piloto
Antes da real execução do estudo experimental, um estudo piloto foi realizado com o intuito
de avaliar a instrumentação que será utilizada no estudo. Para isso, um participante foi
utilizado, sendo atribuídos a ele os mesmos instrumentos do estudo experimental. Os dados
obtidos pelo estudo piloto não foram utilizados para compor o estudo.
5.3.5. Participantes
Os participantes do estudo devem estar atuando na área da Tecnologia da Informação, e
possuir conhecimentos mínimos sobre:
Aplicação Móvel – especificamente sobre as características que influenciam na
qualidade das aplicações, além dos fatores relacionados com o contexto móvel e o
usuário de dispositivo móvel; e
Teste de Software – especificamente sobre as áreas de processo que envolve o teste
de software, como planejamento, projeto e execução.
O estudo leva em consideração o ambiente no qual o participante está inserido que, no
caso, é o ambiente industrial.
130
5.3.6. Instrumentação
Todos os participantes receberão o seguinte conjunto de documentos:
Uma cópia do termo de adesão do estudo experimental;
Uma cópia do questionário de caracterização, no qual o participante indicará sua
formação acadêmica e seu nível de experiência com aplicações móveis e o teste de
software;
Uma cópia do memorial descritivo; e
Uma cópia do questionário sobre a viabilidade da abordagem TM-Aplic.
5.3.7. Variáveis Dependentes
As variáveis dependentes do estudo experimental são:
A tarefa Analisar Produto de Teste presente na abordagem atende as necessidades das
aplicações móveis (fatores do ambiente móvel);
A tarefa Estabelecer Objetivos do Teste presente na abordagem atende as necessidades
das aplicações móveis (fatores do ambiente móvel);
A tarefa Definir Estratégia de Teste presente na abordagem atende as necessidades das
aplicações móveis (fatores do ambiente móvel);
A tarefa Definir Equipe de Teste presente na abordagem atende as necessidades das
aplicações móveis (fatores do ambiente móvel);
A tarefa Definir Ambiente de Teste presente na abordagem atende as necessidades das
aplicações móveis (fatores do ambiente móvel);
A tarefa Estabelecer Plano de Teste presente na abordagem atende as necessidades das
aplicações móveis (fatores do ambiente móvel);
A tarefa Planejar os Artefatos e Dados presente na abordagem atende as necessidades
das aplicações móveis (fatores do ambiente móvel);
A tarefa Identificar Casos de Teste presente na abordagem atende as necessidades das
aplicações móveis (fatores do ambiente móvel);
A tarefa Executar Teste presente na abordagem atende as necessidades das aplicações
móveis (fatores do ambiente móvel);
A tarefa Reportar Incidentes presente na abordagem atende as necessidades das
aplicações móveis (fatores do ambiente móvel);
A tarefa Acompanhar Incidentes presente na abordagem atende as necessidades das
aplicações móveis (fatores do ambiente móvel);
131
Os artefatos sugeridos nas tarefas presentes na abordagem são suficientes para atender
as necessidades das aplicações móveis (fatores do ambiente móvel); e
A padronização das tarefas e artefatos, definidos na abordagem TM-Aplic, pode
contribuir para um significativo ganho na qualidade do produto final.
Uma escala no intervalo de 0 (zero) a 3 (três) estabelece os níveis de concordância do
participante. A fim de evitar respostas não conformes geradas por incertezas,
desconhecimento ou interpretação ambígua, foi acrescentada a escala SR (sem resposta) que
descarta o item a título de análise descritiva para obter o valor mais representativo, conforme
apresentado na Tabela 5.1.
Tabela 5.1. Níveis de concordância das variáveis dependentes
Variável/Valor [0] [1] [2] [3] [SR]
Concordância Discordo
Totalmente Discordo
Parcialmente Concordo
Parcialmente Concordo
Totalmente Sem
Resposta
5.3.8. Variáveis Independentes
As variáveis independentes do estudo experimental são:
A experiência com aplicações móveis; e
A experiência com teste de software.
Uma escala no intervalo de 0 (zero) a 3 (três) estabelece os níveis de experiência do
participante. A fim de evitar respostas não conformes geradas por incertezas,
desconhecimento ou interpretação ambígua, foi acrescentada a escala SR (sem resposta) que
descarta o item a título de análise descritiva para obter o valor mais representativo, conforme
apresentado na Tabela 5.2.
Tabela 5.2. Níveis de concordância das variáveis independentes
Variável/Valor [0] [1] [2] [3] [SR]
Perfil Nenhuma
Experiência Experiência
Básica Experiência Moderada
Experiência Avançada
Sem Resposta
132
5.3.9. Análise Qualitativa
A análise qualitativa tem o objetivo de avaliar os resultados obtidos neste estudo, de acordo
com os dados a partir do manifesto de profissionais envolvidos com aplicações móveis e teste
de software.
5.3.10. Capacidade Aleatória
Devido à limitação da quantidade que compõe o universo de participantes, a seleção não será
de forma aleatória.
5.3.11. Classificação em Bloco
Não há necessidade de dividir os participantes em blocos, pois o estudo avaliará apenas os
dados colhidos a partir da opinião de profissionais que tenham experiência com aplicações
móveis e teste de software. Contudo, durante a análise dos dados os resultados poderão ser
classificados e organizados em blocos.
5.3.12. Mecanismos de Análise
O estudo experimental proposto analisa, com base na opinião de profissionais da área da
Tecnologia da Informação e que possuem conhecimento em aplicações móveis e teste de
software, a abordagem TM-Aplic proposta (Capítulo 3), com o intuito de ampliar o
conhecimento referente a melhoria da qualidade das aplicações móveis. Dessa forma, os
possíveis mecanismos de análise são:
Identificação do perfil dos participantes; e
Apuração de forma descritiva a representatividade das medidas obtidas pela escala de
Likert15 com o intuito de obter o entendimento dos participantes sobre o tema e com
isso, avaliar a viabilidade da abordagem.
5.3.13. Validade Interna
Com o intuito de garantir a validade interna deste estudo, foi incluído no termo de adesão, o
total sigilo das informações relevantes e a troca de ideias entre os participantes, além disso, os
participantes deverão realizar o estudo de forma isolada.
15 É um tipo de escala de resposta utilizada em questionários de pesquisas de opinião.
133
5.3.14. Validade Externa
A validade externa do estudo experimental tem como objetivo medir a capacidade de refletir o
mesmo comportamento em outros grupos de participantes profissionais da indústria, além
daqueles em que o estudo foi aplicado. Diante disso, a validade externa deste estudo é
considerada suficiente, pois os participantes atuam diretamente com o desenvolvimento e/ou
testes de aplicações móveis.
5.3.15. Validade de Conclusão
Por se tratar de um estudo experimental que utilizará como base a opinião de profissionais
envolvidos diretamente com o desenvolvimento e/ou testes de aplicações móveis, acredita-se
que a validade do estudo esteja garantida, uma vez que a análise dos dados poderá ser
realizada por meio de métodos estatísticos generalizando os resultados obtidos.
5.4. Execução do Estudo Experimental
Esta Seção descreve a execução do estudo experimental, composta pelos seguintes elementos:
seleção dos participantes, instrumentação, procedimentos de participação e execução.
5.4.1. Seleção dos Participantes
Para este estudo, foram selecionados 27 (vinte e sete) profissionais de Tecnologia da
Informação, envolvidos diretamente com teste de software e/ou aplicações móveis. Os
participantes selecionados estão de acordo com as restrições apresentadas no planejamento
deste estudo.
5.4.2. Instrumentação
Para a execução deste estudo experimental, foram entregues a cada participante todos os
documentos que formam a instrumentação desta validação, todos eles relacionados no
Apêndice A. As principais tarefas de cada participante foram:
Responder a 3 (três) questões relacionadas com a caracterização do participante;
Analisar e entender o memorial descritivo; e
Responder a 14 (quatorze) questões relacionadas com a viabilidade da abordagem
TM-Aplic.
134
5.4.3. Procedimentos do Participante
Um único procedimento de participação foi adotado para cada participante do estudo. Os itens
a seguir apresentam, em ordem cronológica, cada procedimento:
1. O participante comparece ao local em que o estudo será realizado;
2. O experimentador ministra a apresentação e esclarece possíveis dúvidas sobre o
experimento;
3. O experimentador entrega ao participante o Termo de Adesão ao estudo experimental,
o Questionário de Caracterização e o Questionário sobre a Viabilidade da Abordagem
TM-Aplic;
4. O participante lê, esclarece possíveis dúvidas e assina o Termo de Adesão ao estudo
experimental;
5. O participante lê, esclarece possíveis dúvidas e responde o Questionário de
Caracterização do Participante;
6. O participante lê e esclarece possíveis dúvidas sobre o Memorial Descritivo;
7. O participante lê, esclarece possíveis dúvidas e responde o Questionário sobre a
Viabilidade da Abordagem TM-Aplic; e
8. O experimentador recolhe os questionários e associa um identificador (ID) ao
participante.
5.4.4. Execução
Para cada participante, 3 (três) critérios foram utilizados para a classificação:
Formação Acadêmica:
Superior Incompleto (SI), Superior Completo (SC), Pós-Graduação Lato Sensu
Incompleta (PLI), Pós-Graduação Lato Sensu Completa (PLC), Pós-Graduação Stricto
Sensu Incompleta (PSI), Pós-Graduação Stricto Sensu Completa (PSC)
Experiência com Aplicação Móvel:
Nenhuma (N), Básica (B), Moderada (M), Avançada (A), Sem Resposta (SR)
Experiência com Teste de Software:
Nenhuma (N), Básica (B), Moderada (M), Avançada (A), Sem Resposta (SR)
135
Ao todo 27 (vinte e sete) pessoas participaram do estudo experimental, sendo a
maioria com Pós-Graduação Lato Sensu Completa (PLC). Ou seja, 1 (uma) com ensino
Superior Incompleto (SI), 5 (cinco) com ensino Superior Completo (SC), 3 (três) com Pós-
Graduação Lato Sensu Incompleta (PLI), 11 (onze) com Pós-Graduação Lato Sensu Completa
(PLC), 4 (quatro) com Pós-Graduação Stricto Sensu Incompleta (PSI) e 3 (três) com Pós-
Graduação Stricto Sensu Completa (PSC).
Em relação a experiência com aplicações móveis, 11 (onze) pessoas apresentam
experiência básica (B), 10 (dez) experiência moderada (M) e 6 (seis) experiência avançada
(A). Em relação a experiência com teste de software, 2 (duas) pessoas apresentam nenhuma
experiência (N), 7 (sete) experiência básica, 11 (onze) experiência moderada (M) e 7 (sete)
experiência avançada (A). Assim, na Tabela 5.3 são apresentadas as repostas coletadas e
tabuladas sobre o perfil dos participantes.
Tabela 5.3. Respostas coletadas sobre o perfil dos participantes
Perfil
Questões Nenhuma
(N)
Básica
(B)
Moderada
(M)
Avançada
(A)
1 (Experiência com Aplicação
Móvel)
0 11 10 6
2 (Experiência com Teste de
Software)
2 7 11 7
Total 2 18 21 13
De forma geral, os participantes apresentam experiência básica com aplicação móvel e
experiência moderada com teste de software. Os participantes que apresentam nenhuma
experiência em teste de software tiveram as respostas desconsideradas, conforme abordado na
Seção 5.5.1 (Validação dos Dados).
Além da formação acadêmica e das 2 (duas) questões relacionadas com o perfil, cada
participante respondeu 13 (treze) questões relacionadas com as tarefas da abordagem proposta
e uma questão dissertativa que o usuário poderia expressar a opinião sobre a abordagem TM-
Aplic. A última questão serviu para fins de conclusão do estudo experimental. Na Tabela 5.4
são apresentadas as repostas coletadas e tabuladas sobre a viabilidade da abordagem.
136
Tabela 5.4. Respostas coletadas sobre a viabilidade da abordagem TM-Aplic
Viabilidade
Questões Discordo
Totalmente
Discordo
Parcialmente
Concordo
Parcialmente
Concordo
Totalmente
3
(Analisar Produto de Teste) 0 0 5 20
4
(Estabelecer Objetivos do
Teste)
0 1 6 18
5
(Definir Estratégia de Teste) 0 1 5 19
6
(Definir Equipe de Teste) 0 2 5 18
7
(Definir Ambiente de Teste) 0 1 6 18
8
(Estabelecer Plano de Teste) 0 0 6 19
9
(Planejar os Artefatos e Dados) 0 0 6 19
10
(Identificar Casos de Teste) 0 0 6 19
11
(Executar Teste) 0 1 2 22
12
(Reportar Incidentes) 0 1 5 19
13
(Acompanhar Incidentes) 0 0 9 16
14
(Artefatos) 0 1 7 17
15
(Qualidade) 0 0 2 23
Total 0 8 70 247
Ao final, 15 (quinze) respostas foram coletadas e tabuladas. De acordo com a Tabela
5.4, é possível perceber que a maioria dos participantes concorda totalmente com as questões
relacionadas com a viabilidade da abordagem TM-Aplic.
137
5.5. Análise e Interpretação dos Resultados do Estudo
Experimental
A análise e interpretação dos resultados divide-se em 2 (duas) principais etapas: a validação
dos dados coletados e a estatística descritiva e análise. A seguir essas etapas são descritas.
5.5.1. Validação dos Dados
Com a intenção de eliminar as respostas não conformes geradas por dúvidas ou
desconhecimento, foi incluído o item SR (Sem Resposta) nas escalas, que descarta o item a
título de estatística descritiva para obter o valor mais representativo, ou seja, a moda. Além
disso, caso o participante não apresente o mínimo de conhecimento nas áreas desejadas
(aplicação móvel e teste de software), as respostas também devem ser descartadas, pois trata-
se de um outlier16.
Dessa forma, 2 (dois) participantes (ver Tabela 5.3) foram considerados outliers, pois
não apresentam conhecimentos mínimos sobre teste de software e, portanto, foram excluídos
da estatística descritiva.
5.5.2. Estatística Descritiva e Análise
A apresentação e tabulação dos dados coletados durante a realização do experimento visam
representar as informações relevantes sobre o contexto do trabalho. Dessa forma, para
destacar os valores coletados, utilizam-se as medidas de tendência central, representadas pelos
cálculos da mediana e moda. Se o número de observações for par, a mediana estará na média
dos dois valores centrais. Se o número for ímpar, a mediana será o valor central. A moda é o
valor da observação que ocorre com mais frequência na amostragem (Montgomery e Runger,
2009). Assim, na Tabela 5.5 é apresentado o cálculo da mediana e moda dos dados coletados.
Tabela 5.5. Cálculo da mediana e moda das respostas coletadas
Questões Perfil Viabilidade 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Mediana 2 2 3 3 3 3 3 3 2 3 3 3 3 3 3
Moda 1 2 3 3 3 3 3 3 3 3 3 3 3 3 3
16 Resultado atípico que apresenta um grande afastamento dos demais valores. São ameaças em pesquisas e estudos experimentais.
138
Na Figura 5.1 é apresentado o gráfico com todas as perguntas que os participantes
responderam de acordo com a mediana e a moda. Quanto mais interno no gráfico, menor o
conhecimento (questões 1 e 2) e menor a concordância (questões 3 a 15).
Figura 5.1. Análise das respostas em relação a mediana e a moda
Dessa forma, é possível observar uma variação entre a mediana e moda em relação ao
conhecimento em aplicações móveis e na tarefa planejar os artefatos e dados.
Após a tabulação dos dados, alguns gráficos foram gerados para facilitar a
visualização das informações. O primeiro gráfico é apresentado pela Figura 5.2 e tem por
objetivo demonstrar as respostas dos participantes em relação ao nível de conhecimento sobre
aplicações móveis e teste de software. Nas Figuras 5.3 e 5.4 são apresentados os gráficos com
a análise das respostas.
Figura 5.2. Respostas dos participantes
Figura 5.3. Análise das respostas dos
participantes em relação ao nível de
conhecimento em aplicação
Pode-se observar que 40% dos participantes apresentam experiência avançada com
aplicações móveis, 40% experiência mo
participantes apresentam experiência avançada com teste de software, 53% experiência
moderada e 33% experiência básica.
0
0,5
1
1,5
2
2,5
3
3,5
Par
tici
pan
te 2Aplicações Móveis
Teste de Software
0 - Nenhuma Experiência1 - Experiência Básica2 - Experiência Moderada3 - Experiência Avançada
0%
40%
40%
20%
Aplicação Móvel
participantes em relação ao nível de conhecimento em
móvel e teste de software
Análise das respostas dos
participantes em relação ao nível de
conhecimento em aplicação móvel
Figura 5.4. Análise das respostas dos
participantes em relação ao nível de
conhecimento em teste de software
se observar que 40% dos participantes apresentam experiência avançada com
xperiência moderada e 20% experiência básica e,
participantes apresentam experiência avançada com teste de software, 53% experiência
moderada e 33% experiência básica.
Par
tici
pan
te 2
Par
tici
pan
te 3
Par
tici
pan
te 4
Par
tici
pan
te 5
Par
tici
pan
te 6
Par
tici
pan
te 7
Par
tici
pan
te 8
Par
tici
pan
te 9
Par
tici
pan
te 1
0
Par
tici
pan
te 1
1P
arti
cip
ante
12
Par
tici
pan
te 1
4
Par
tici
pan
te 1
5P
arti
cip
ante
16
Par
tici
pan
te 1
7P
arti
cip
ante
18
Par
tici
pan
te 1
9P
arti
cip
ante
20
Par
tici
pan
te 2
1
Par
tici
pan
te 2
2
Aplicação Móvel
Nenhuma Experiência
Experiência Básica
Experiência Moderada
Experiência Avançada
0%
33%
53%
14%
Teste de Software
139
de conhecimento em aplicação
Análise das respostas dos
participantes em relação ao nível de
conhecimento em teste de software
se observar que 40% dos participantes apresentam experiência avançada com
derada e 20% experiência básica e, 14% dos
participantes apresentam experiência avançada com teste de software, 53% experiência
Par
tici
pan
te 2
2
Par
tici
pan
te 2
3P
arti
cip
ante
24
Par
tici
pan
te 2
5P
arti
cip
ante
26
Par
tici
pan
te 2
7
Teste de Software
Nenhuma Experiência
Experiência Básica
Experiência Moderada
Experiência Avançada
Na Figura 5.5 é apresenta
relação à tarefa Analisar Produto de Teste
análise das respostas. Os participantes apresentam pouc
(vinte) participantes concordam totalmente e 5 (cinco) concord
Figura 5.5. Respostas dos participantes
Figura 5.6. Análise das respostas em relação a tarefa analisar produto de teste
Pode-se observar que 80% dos participantes concordam totalmente com a tarefa e 20%
concordam parcialmente.
80%
Analisar Produto de Teste
apresentado o gráfico que representa as repostas dos partici
relação à tarefa Analisar Produto de Teste, e na Figura 5.6 é apresentado
s participantes apresentam pouca variação nas respostas, sendo que 20
(vinte) participantes concordam totalmente e 5 (cinco) concordam parcialmente.
dos participantes em relação a tarefa analisar produto de teste
lise das respostas em relação a tarefa analisar produto de teste
se observar que 80% dos participantes concordam totalmente com a tarefa e 20%
0% 0%
20%
80%
Analisar Produto de Teste
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
140
gráfico que representa as repostas dos participantes em
o gráfico com a
a variação nas respostas, sendo que 20
am parcialmente.
a tarefa analisar produto de teste
lise das respostas em relação a tarefa analisar produto de teste
se observar que 80% dos participantes concordam totalmente com a tarefa e 20%
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.7 é apresenta
relação a tarefa Estabelecer O
análise das respostas.
Figura 5.7. Respostas dos participantes
Figura 5.8. Análise das respostas em relação a ta
Pode-se observar que 72% dos participantes concordam totalmente com a tarefa, 24%
concordam parcialmente e 4% discordam parcialmente.
72%
Estabelecer Objetivos do Teste
apresentado o gráfico que representa as repostas dos participantes em
tarefa Estabelecer Objetivos do Teste, e na Figura 5.8 apresentado
dos participantes em relação a tarefa estabelecer objetivos do teste
Análise das respostas em relação a tarefa estabelecer objetivos do teste
se observar que 72% dos participantes concordam totalmente com a tarefa, 24%
concordam parcialmente e 4% discordam parcialmente.
0% 4%
24%
Estabelecer Objetivos do Teste
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
141
gráfico que representa as repostas dos participantes em
do o gráfico com a
a tarefa estabelecer objetivos do teste
refa estabelecer objetivos do teste
se observar que 72% dos participantes concordam totalmente com a tarefa, 24%
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.9 é apresenta
relação a tarefa Definir Estratégia de T
análise das respostas.
Figura 5.9. Respostas dos participantes
Figura 5.10. Análise das respostas em relação a tarefa definir estratégia de teste
Pode-se perceber que 76% dos participantes concordam totalmente com a tarefa, 20%
concordam parcialmente e 4% discordam parcialmente.
76%
Definir Estratégia de Teste
apresentado o gráfico que representa as repostas dos participantes
Definir Estratégia de Teste, e na Figura 5.10 é apresentado
dos participantes em relação a tarefa definir estratégia de teste
Análise das respostas em relação a tarefa definir estratégia de teste
se perceber que 76% dos participantes concordam totalmente com a tarefa, 20%
concordam parcialmente e 4% discordam parcialmente.
0% 4%
20%
Definir Estratégia de Teste
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
142
gráfico que representa as repostas dos participantes em
o gráfico com a
a tarefa definir estratégia de teste
Análise das respostas em relação a tarefa definir estratégia de teste
se perceber que 76% dos participantes concordam totalmente com a tarefa, 20%
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.11 é apresenta
relação a tarefa Definir Equipe de T
análise das respostas.
Figura 5.11. Respostas dos participantes
Figura 5.12. Análise das respostas em relação a tarefa definir equipe de teste
Pode-se perceber que 72% dos participantes concordam totalmente com a tarefa, 20%
concordam parcialmente e 8% discordam parcialmente.
72%
Definir Equipe de Teste
resentado o gráfico que representa as repostas dos participantes em
Equipe de Teste, e na Figura 5.12 é apresentado
dos participantes em relação a tarefa definir equipe de teste
Análise das respostas em relação a tarefa definir equipe de teste
se perceber que 72% dos participantes concordam totalmente com a tarefa, 20%
mente e 8% discordam parcialmente.
0% 8%
20%
Definir Equipe de Teste
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
143
gráfico que representa as repostas dos participantes em
o gráfico com a
a tarefa definir equipe de teste
Análise das respostas em relação a tarefa definir equipe de teste
se perceber que 72% dos participantes concordam totalmente com a tarefa, 20%
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.13 é apresenta
relação a tarefa Definir Ambiente de T
análise das respostas.
Figura 5.13. Respostas dos participantes
Figura 5.14. Análise das respostas em relação a tarefa definir ambiente de teste
Pode-se perceber que 72% dos participa
parcialmente e 4% discordam parcialmente.
72%
Definir Ambiente de Teste
apresentado o gráfico que representa as repostas dos participantes em
Ambiente de Teste, e na Figura 5.14 é apresentado
dos participantes em relação a tarefa definir ambiente de teste
Análise das respostas em relação a tarefa definir ambiente de teste
se perceber que 72% dos participantes concordam totalmente, 24% concordam
parcialmente e 4% discordam parcialmente.
0% 4%
24%
Definir Ambiente de Teste
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
144
gráfico que representa as repostas dos participantes em
o gráfico com a
ambiente de teste
Análise das respostas em relação a tarefa definir ambiente de teste
ntes concordam totalmente, 24% concordam
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.15 é apresenta
relação a tarefa Estabelecer Plano de T
análise das respostas.
Figura 5.15. Respostas dos participantes
Figura 5.16. Análise das respostas em relação a tarefa estabelecer pla
Pode-se perceber que 76% dos participantes concordam totalmente com a tarefa e 24%
concordam parcialmente.
76%
Estabelecer Plano de Teste
apresentado o gráfico que representa as repostas dos participantes em
Plano de Teste, e na Figura 5.16 é apresentado
dos participantes em relação a tarefa estabelecer plano de teste
Análise das respostas em relação a tarefa estabelecer plano de teste
se perceber que 76% dos participantes concordam totalmente com a tarefa e 24%
0% 0%
24%
Estabelecer Plano de Teste
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
145
gráfico que representa as repostas dos participantes em
o gráfico com a
a tarefa estabelecer plano de teste
no de teste
se perceber que 76% dos participantes concordam totalmente com a tarefa e 24%
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.17 é apresenta
relação tarefa Planejar os Artefatos e Dados
análise das respostas.
Figura 5.17. Respostas dos participantes
Figura 5.18. Análise das resp
Pode-se perceber que 76% dos participantes concordam totalmente com a tarefa e 24%
concordam parcialmente.
76%
Planejar os Artefatos e Dados
apresentado o gráfico que representa as repostas dos participantes em
Planejar os Artefatos e Dados, e na Figura 5.18 é apresentado
dos participantes em relação a tarefa planejar os artefatos e dados
Análise das respostas em relação a tarefa planejar os artefatos e dados
se perceber que 76% dos participantes concordam totalmente com a tarefa e 24%
0% 0%
24%
Planejar os Artefatos e Dados
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
146
gráfico que representa as repostas dos participantes em
do o gráfico com a
a tarefa planejar os artefatos e dados
ostas em relação a tarefa planejar os artefatos e dados
se perceber que 76% dos participantes concordam totalmente com a tarefa e 24%
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.19 é apresenta
em relação a tarefa Identificar
análise das respostas.
Figura 5.19. Respostas dos participantes
Figura 5.20. Análise das respostas em relação a tarefa identificar casos de teste
Pode-se perceber que 76% dos participantes concordam totalmente com a tarefa e 24%
concordam parcialmente.
76%
Identificar Casos de Teste
apresentado um gráfico que representa as repostas dos participantes
entificar Casos de Teste, e na Figura 5.20 é apresentado
dos participantes em relação a tarefa identificar casos de teste
Análise das respostas em relação a tarefa identificar casos de teste
se perceber que 76% dos participantes concordam totalmente com a tarefa e 24%
0% 0%
24%
Identificar Casos de Teste
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
147
um gráfico que representa as repostas dos participantes
do o gráfico com a
a tarefa identificar casos de teste
Análise das respostas em relação a tarefa identificar casos de teste
se perceber que 76% dos participantes concordam totalmente com a tarefa e 24%
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.21 é apresenta
relação a tarefa Executar Testes, e
respostas.
Figura 5.21. Respostas dos participantes
Figura 5.22. Análise das respostas em relação a tarefa executar testes
Pode-se perceber que 88% dos participantes concordam totalmente com a tarefa, 8%
concordam parcialmente e 4% discordam parcialmente.
88%
apresentado o gráfico que representa as repostas dos participantes em
estes, e na Figura 5.22 é apresentado o gráfico com a análise das
Respostas dos participantes em relação a tarefa executar testes
Análise das respostas em relação a tarefa executar testes
se perceber que 88% dos participantes concordam totalmente com a tarefa, 8%
concordam parcialmente e 4% discordam parcialmente.
0% 4%8%
88%
Executar Testes
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
148
dos participantes em
o gráfico com a análise das
a tarefa executar testes
Análise das respostas em relação a tarefa executar testes
se perceber que 88% dos participantes concordam totalmente com a tarefa, 8%
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.23 é aprese
em relação a tarefa Reportar
análise das respostas.
Figura 5.23. Respostas
Figura 5.24. Análise das respostas em relação a tarefa reportar incidentes
Pode-se perceber que 76% dos participantes concordam totalmente com a tarefa, 20%
concordam parcialmente e 4% dis
76%
apresentado um gráfico que representa as repostas dos participantes
eportar Incidentes, e na Figura 5.24 é apresentado o gráfico com a
espostas dos participantes em relação a tarefa reportar incidentes
Análise das respostas em relação a tarefa reportar incidentes
se perceber que 76% dos participantes concordam totalmente com a tarefa, 20%
concordam parcialmente e 4% discordam parcialmente.
0% 4%
20%
Reportar Incidentes
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
149
um gráfico que representa as repostas dos participantes
o gráfico com a
a tarefa reportar incidentes
Análise das respostas em relação a tarefa reportar incidentes
se perceber que 76% dos participantes concordam totalmente com a tarefa, 20%
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.25 é apresenta
em relação a tarefa Acompanhar
análise das respostas.
Figura 5.25. Respostas dos participantes
Figura 5.26. Análise das respostas em relação a tarefa acompanhar incidentes
Pode-se perceber que 64% dos participantes concordam totalmente
concordam parcialmente.
64%
Acompanhar Incidentes
apresentado um gráfico que representa as repostas dos participantes
companhar Incidentes, e na Figura 5.26 é apresentado
dos participantes em relação a tarefa acompanhar incidentes
Análise das respostas em relação a tarefa acompanhar incidentes
se perceber que 64% dos participantes concordam totalmente com a tarefa e 36%
0% 0%
36%
Acompanhar Incidentes
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
150
um gráfico que representa as repostas dos participantes
o gráfico com a
a tarefa acompanhar incidentes
Análise das respostas em relação a tarefa acompanhar incidentes
com a tarefa e 36%
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.27 é apresenta
em relação aos artefatos gerados pela abordagem
gráfico com a análise das respostas
Figura 5.27. Respostas dos participantes
Figura 5.28. Análise das respostas em relação aos artefatos presentes na abordagem
Pode-se perceber que 68% dos participantes concordam totalmente que os artefatos
gerados pelas tarefas presentes na abordagem
necessidades das aplicações móveis, 28% concordam parcialmente e 4% discordam
parcialmente.
68%
apresentado um gráfico que representa as repostas dos participantes
em relação aos artefatos gerados pela abordagem TM-Aplic, e na Figura 5.28
gráfico com a análise das respostas.
dos participantes em relação aos artefatos presentes na abordagem
Análise das respostas em relação aos artefatos presentes na abordagem
r que 68% dos participantes concordam totalmente que os artefatos
tarefas presentes na abordagem TM-Aplic são suficientes para atender as
necessidades das aplicações móveis, 28% concordam parcialmente e 4% discordam
0% 4%
28%
Artefatos Gerados
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
151
um gráfico que representa as repostas dos participantes
Figura 5.28 é apresentado o
os artefatos presentes na abordagem
Análise das respostas em relação aos artefatos presentes na abordagem
r que 68% dos participantes concordam totalmente que os artefatos
são suficientes para atender as
necessidades das aplicações móveis, 28% concordam parcialmente e 4% discordam
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
Na Figura 5.29 é apresenta
em relação a contribuição da abordagem
exceção de 2 (dois) participantes (participante 5 e 27), os outros concordam totalmente que a
abordagem pode contribuir para melhorar a qualidade das aplicações móveis
é apresentado o gráfico com a análise das respostas.
Figura 5.29. Respostas dos participantes
Figura 5.30. Análise das respostas em relação a qualidade do produto
Pode-se perceber que 92% dos participantes concordam totalmente que as tarefas e os
artefatos podem contribuir para a qualidade do produto final e 8% concordam pa
92%
apresentado um gráfico que representa as repostas dos participantes
em relação a contribuição da abordagem TM-Aplic em apoiar a qualidade do produto
exceção de 2 (dois) participantes (participante 5 e 27), os outros concordam totalmente que a
contribuir para melhorar a qualidade das aplicações móveis
o gráfico com a análise das respostas.
Respostas dos participantes em relação a qualidade do produt
Análise das respostas em relação a qualidade do produto
se perceber que 92% dos participantes concordam totalmente que as tarefas e os
artefatos podem contribuir para a qualidade do produto final e 8% concordam pa
0% 0%
8%
92%
Qualidade do Produto
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
152
um gráfico que representa as repostas dos participantes
iar a qualidade do produto. Com
exceção de 2 (dois) participantes (participante 5 e 27), os outros concordam totalmente que a
contribuir para melhorar a qualidade das aplicações móveis. Na Figura 5.30
em relação a qualidade do produto
Análise das respostas em relação a qualidade do produto
se perceber que 92% dos participantes concordam totalmente que as tarefas e os
artefatos podem contribuir para a qualidade do produto final e 8% concordam parcialmente.
Discordo Totalmente
Discordo Parcialmente
Concordo Parcialmente
Concordo Totalmente
153
Por meio da medida de tendência central denominada de moda estatística, conclui-se
que a abordagem TM-Aplic é viável, no que se refere a apoiar a qualidade das aplicações
móveis, auxiliando na identificação de falhas antes da liberação do software para o usuário
final. Contudo, torna-se necessário a aplicação de novos experimentos para mensurar, por
meio de empresas desenvolvedoras de aplicações móveis, a viabilidade da abordagem em
termos de esforço, tempo e custo, por exemplo.
5.6. Avaliação de Validade do Estudo Experimental
A avaliação de validade deste estudo experimental é apresentada por meio das seguintes
ameaças: à validade de conclusão, à validade de construção, à validade interna e à validade
externa, conforme discutidas abaixo:
Ameaça à validade de conclusão: refere-se à capacidade do estudo experimental em
gerar alguma conclusão (Wohlin et al., 2000). Dessa forma, não houve dificuldades em
relação à conclusão do estudo, pois os dados foram coletados de profissionais que atuam em
áreas relacionadas com as aplicações móveis e teste de software. Além disso, houve a
validação dos dados com a intenção de identificar possíveis outliers, e a aplicação da
estatística descritiva e análise para apurar a conclusão do estudo.
As métricas utilizadas para a análise de cada questão estipulada na definição do estudo
experimental são de fácil entendimento, reduzindo a influência de possíveis enganos no
entendimento e conclusão dos resultados.
Ameaça à validade de construção: refere-se à capacidade do estudo experimental em
relacionar a instrumentação com os participantes do estudo e a teoria que esta sendo provada,
que é a viabilidade da abordagem TM-Aplic (Wohlin et al., 2000).
Dessa forma, entende-se que a validade de construção do estudo foi alcançada, pois
todos os participantes do estudo estão envolvidos diretamente com atividades relacionadas
com aplicações móveis e teste de software. Ou seja, possui conhecimento na área, refletindo
em uma avaliação mais apurada a respeito da viabilidade da abordagem. A validade de
construção poderia ser ameaçada se os participantes não tivessem conhecimento específico
em aplicações móveis ou teste de software.
154
Ameaça à validade interna: refere-se à capacidade do estudo experimental em
fornecer subsídios para que um novo estudo repita o comportamento do estudo atual,
considerando a seleção dos participantes, a divisão das classes, a aplicação dos tratamentos e
os aspectos sociais (Wohlin et al., 2000).
O estudo experimental contou com 27 (vinte e sete) participantes que apresentavam
pouca variação com relação às habilidades. Além disso, todos os participantes realizaram as
tarefas definidas na mesma ordem e sem consultas externas, com a intenção de não haver
troca de informação entre os participantes e, consequentemente, serem influenciados por
opiniões alheias.
Em relação à fadiga dos participantes, em média, o experimento durou 30 minutos
para cada participante. Assim, a fadiga não foi considerada relevante. Além disso, o memorial
descritivo, com tabelas e figuras, contribui para reduzir tal efeito.
Uma vez entendido o memorial descritivo (Apêndice A), somado à experiência dos
participantes com aplicações móveis e teste de software, considera-se que suas respostas são
válidas.
Ameaça à validade externa: refere-se às limitações em generalizar os resultados do
experimento (Wohlin et al., 2000).
Obter participantes qualificados foi uma das grandes dificuldades do estudo, pois
como se utilizou somente profissionais que estivessem envolvidos com aplicações móveis e
teste de software, a dificuldade em manter contato com as empresas para que os funcionários
fossem liberados para participar do estudo foi alta.
Além disso, a validade externa pode ser comprometida, pois o experimento foi
realizado abordando somente a análise qualitativa dos dados e, isso pode ameaçar a
generalização dos resultados relacionados à viabilidade da abordagem.
155
5.7. Considerações Finais
A literatura existente ressalta a necessidade de novas abordagens de Engenharia de Software a
fim de apoiar a qualidade das aplicações móveis disponibilizadas aos usuários finais e, sob
esse aspecto, métodos experimentais são necessários para provar as novas abordagens.
O estudo foi realizado por profissionais da área da Tecnologia da Informação que
atuam diretamente com aplicações móveis e teste de software, com a intenção de aproximar,
por meio de uma transferência de conhecimentos, a indústria e a academia.
Nesse sentido, a realização deste estudo experimental forneceu indícios da viabilidade
da abordagem TM-Aplic proposta nesta dissertação. No entanto, devido à ausência de
trabalhos relacionados com aplicações móveis e teste de software, pode-se entender que todo
trabalho é relevante, e pode ser aproveitado e aprimorado pela indústria, como é possível
observar pelos resultados do experimento.
Novos experimentos podem ser efetuados com a intenção de buscar profissionais mais
qualificados para a participação, além da necessidade de realização de experimentos
relacionados a uma análise quantitativa, principalmente no que se refere a termos de esforço,
tempo e custo.
A condução do estudo de viabilidade possibilitou levantar, junto aos participantes, os
seguintes pontos:
Esclarecer a integração com ferramentas de gestão de projetos;
Incluir TDD (Test Driven Development), testes unitários automáticos e uso de
ferramentas como o Sonar17 para avaliar a qualidade do software;
Geração de casos/cenários de teste pela equipe de desenvolvimento, e o
reaproveitamento e aprimoramento dos mesmos pela equipe de teste; e
Incluir o papel do arquiteto de testes para auxiliar na automatização dos testes, no que
se refere a entender um problema específico e criar uma solução adequada (geralmente
com a ajuda de uma ferramenta), além de apoiar a equipe a evoluir tecnicamente e
auxiliar na melhoria do processo de teste.
17 http://www.sonarqube.org/
156
Conclusões
6.1. Propósito da Pesquisa
Desenvolver aplicações móveis que apresentem um comportamento correto, sem falhas, sem
perda de dados, sem interferir negativamente em outras aplicações e serviços, além de
funcionar corretamente nos mais variados modelos de dispositivos e atender os quesitos
relacionados à mobilidade do usuário, são alguns dos desafios que diferenciam as aplicações
móveis de softwares tradicionais no que se refere a qualidade do produto. Essas
particularidades estão distribuídas de forma a constituir o ambiente móvel, composto por 3
(três) principais fatores: contexto móvel, usuário de dispositivo móvel e aplicação móvel
(Ballard, 2007; Mizouni et al., 2009; She, Sivapalan e Warren, 2009).
Diante desses desafios, considera-se necessário o desenvolvimento de novas
abordagens de engenharia de software, a fim de considerar as particularidades presentes nas
aplicações móveis, desvendando e corrigindo falhas antes da liberação do produto final para o
usuário (Kim, Choi e Wong, 2009; Muccini, Di Francesco e Esposito, 2012).
Assim, com base na lacuna identificada a partir da análise dos trabalhos relacionados
apresentada no Capítulo 2, da presente dissertação, foi desenvolvida a abordagem TM-Aplic
em termos de tarefas, papéis e artefatos, por meio das áreas de processo de planejamento,
projeto e execução de testes.
6
Capítulo
157
6.2. Contribuições
Esta pesquisa contribui com uma área que, apesar da sua ascensão exponencial, ainda é
carente de trabalhos científicos. Isso objetivou a proposta da abordagem TM-Aplic,
disponibilizando material acessível para subsidiar os envolvidos com a qualidade das
aplicações móveis. Dessa forma, como contribuições desta dissertação, destacam-se:
Auxiliar na condução do teste de software, pois oferece a todos os envolvidos uma
nomenclatura comum, além de permitir que a mesma seja analisada e, como resultado
dessa análise, possa sofrer evoluções sendo passível de melhoria contínua;
Oferecer suporte ao teste de aplicações móveis, por meio das áreas de processo de
planejamento, projeto e execução, de acordo com as diretrizes estabelecidas pelo
modelo de maturidade MPT.BR;
Abordar os fatores inerentes do ambiente móvel, com o intuito de atingir as
particularidades das aplicações móveis;
Oferecer uma ampla análise dos passos construtivos para a elaboração de um controle
de qualidade em aplicações móveis, bem como resguardando as avaliações dos
dispositivos móveis e seus componentes;
Apresentar um roteiro de organização da elaboração de testes ao longo do processo
adotado;
Apresentar uma avaliação de viabilidade da abordagem TM-Aplic por meio de um
estudo experimental controlado com base na Engenharia de Software Experimental.
Os resultados obtidos no estudo experimental são utilizados para aprimorar a
abordagem melhorando a viabilidade da mesma; e
Apresentar várias bibliografias correlatas à área de qualidade e testes.
6.3. Dificuldades e Limitações
Dentre as dificuldades e limitações encontradas durante o estudo experimental e o
desenvolvimento da abordagem proposta, estão:
Escassez de trabalhos científicos sobre a área abordada;
Acesso às empresas do âmbito regional para a realização do experimento;
Colaboração dos líderes das empresas para avaliar o resultado da pesquisa; e
Escassez de profissionais especialistas em aplicações móveis e teste de software para
participar do estudo experimental.
158
6.4. Trabalhos Futuros
Visando a melhoria e expansão da abordagem TM-Aplic, algumas perspectivas de trabalhos
futuros foram identificadas, as quais estão além do escopo desta dissertação:
Definir o nível de treinamento necessário para que os responsáveis sejam capazes de
cumprir com êxito as tarefas apresentadas na abordagem proposta;
Considerar as metodologias ágeis como parte da abordagem proposta, por exemplo, a
utilização de TDD (Test Driven Development);
Definir ferramentas automatizadas, pois devido à quantidade de combinações que
influenciam o teste de aplicações móveis (por exemplo: diferentes dispositivos,
navegadores, sistemas operacionais, memória, processadores), a realização de forma
manual torna o teste demorado e caro. A automação de teste pode ser usada para
reduzir o tempo e os custos associados com os testes, além de ser utilizada para
aumentar a produtividade da equipe, no que se refere a diminuir esforço e tempo de
mercado para o produto;
Apresentar diretrizes para possibilitar a integração da abordagem com ferramentas de
gestão;
Mensurar a viabilidade da abordagem TM-Aplic, por meio da utilização por empresas
que desenvolvem e testam aplicações móveis, em termos de esforço, tempo e custo;
Aplicar a abordagem considerando os demais níveis de maturidade do modelo
MPT.BR; e
Definir planos de testes relacionados às características de dispositivos móveis
abordando o Teste Estrutural e Funcional.
159
Referências
ABNT. NBR ISO/IEC 9126-1 Engenharia de Software – Qualidade de Produto Parte 1:
Modelo de Qualidade, Rio de Janeiro, ABNT, 2003.
ANDRADE, S. C.; TAIT, T. F. C.; HUZITA, E. H. M.; BRUZAROSCO, D. C.;
CARMIZINI, M. An Approach to Support the Software Project Management for Mobile
Devices. In: XXXIX Latin American Computing Conference (CLEI 2013), Venezuela, 2013.
BALLARD, B. Designing the Mobile User Experience. Little Springs Design, Inc., USA:
Wiley, 2007.
BASILI, V. R. The Role of Controlled Experiments in Software Engineering Research. In:
Empirical Software Engineering Issues: Critical Assessment and Future Directions, LNCS
4336, V. Basili et al., (Eds.), Springer-Verlag, p. 33-37, 2007.
BASILI, V. R.; ROMBACH, H. D. The TAME Project: Towards Improvement-Oriented
Software Environments. Transactions on Software Engineering (TSE). IEEE, v. 14, n. 6, p.
758-773, 1988.
BIZAGI. Disponível em: < http://www.bizagi.com>. Acesso em: 2 set. 2013.
BO, J.; XIANG, L.; XIAOPENG, G. MobileTest: A Tool Supporting Automatic Black Box
Test for Software on Smart Mobile Devices. In: 2nd International Workshop on Automation
of Software Test (AST'07). IEEE, p. 8-8, 2007.
BOURQUE, P.; DUPUIS, R.; ABRAN, A.; MOORE, J. W.; TRIPP, L. The Guide to the
Software Engineering Body of Knowledge. Software. IEEE, v. 16, n. 6, p. 35-44, 1999.
160
BORNER, L.; ILLES-SEIFERT, T.; PAECH, B. The Testing Process - A Decision Based
Approach. In: 1st International Conference on Software Engineering Advances (ICSEA).
IEEE, p. 41, 2007.
BROEKMAN, B.; NOTENBOOM, E. Testing Embedded Software. Addison-Wesley, 2003.
CAPGEMINI; SOGETI; HEWLETT-PACKARD. World Quality Report. Fourth Edition,
2012. Disponível em: <http://www.tmap.net/en/news/world-quality-report-2012-13>. Acesso
em: 23 out. 2012.
CHEN, G.; KOTZ, D. A Survey of Context-Aware Mobile Computing Research. Technical
Report TR2000-381, Dept. of Computer Science, Dartmouth College, 2000.
CRESPO, A. N.; JINO, M.; ARGOLLO, M.; BUENO, P.; BARROS, C. P. Teste de Software:
Motivação e Conceitos Básicos. Estrutura Tecnológica de Teste de Software do SPB
(Software Público Brasileiro). Centro de Tecnologia da Informação Renato Archer –
CTI/MCT, 2009.
CRESPO, A. N.; JINO, M.; ARGOLLO, M.; BUENO, P.; BARROS, C. P. Modelo de
Processo Genérico de Teste de Software. Estrutura Tecnológica de Teste de Software do SPB
(Software Público Brasileiro). Centro de Tecnologia da Informação Renato Archer –
CTI/MCT, 2010a.
CRESPO, A. N.; JINO, M.; ARGOLLO, M.; BUENO, P.; BARROS, C. P. Guia para Planejar
o Teste de Software. Estrutura Tecnológica de Teste de Software do SPB (Software Público
Brasileiro). Centro de Tecnologia da Informação Renato Archer – CTI/MCT, 2010b.
CRESPO, A. N.; JINO, M.; ARGOLLO, M.; BUENO, P.; BARROS, C. P. Guia para Projetar
o Teste de Software. Estrutura Tecnológica de Teste de Software do SPB (Software Público
Brasileiro). Centro de Tecnologia da Informação Renato Archer – CTI/MCT, 2010c.
CMMI Product Team. CMMI for Development, Version 1.2. Technical Report, Software
Engineering Institute, 2006.
161
DANTAS, V. L. L. Requisitos para Testes de Aplicações Móveis. Dissertação (Mestrado em
Ciência da Computação) – Departamento de Computação. Universidade Federal do Ceará,
Fortaleza. 2009.
DANTAS, V. L. L.; MARINHO, F. G.; COSTA, A. L.; ANDRADE, R. M. C. Testing
Requirements for Mobile Applications. In: 24th International Symposium on Computer and
Information Sciences (ISCIS). IEEE, p. 555-560, 2009.
DIAS NETO, A. C. Uma Infra-estrutura Computacional para Apoiar o Planejamento e
Controle de Testes de Software. Departamento de Engenharia de Sistemas e Ciência da
Computação. Universidade Federal do Rio de Janeiro, COPPE, 2006.
DIAS NETO, A. C., TRAVASSOS, G. H. Maraká: Infra-Estrutura Computacional para
Apoiar o Planejamento e Controle dos Testes de Software, In: 5º Simpósio Brasileiro de
Qualidade de Software (SBQS), Vila Velha, ES, 2006.
ERICSON, T.; SUBOTIC, A.; URSING, S. TIM: A Test Improvement Model. Software
Testing Verification and Reliability, v. 7, n. 4, p. 229-246, 1997.
FALSAFI, A. Improving Voice Quality in International Mobile-to-Mobile Calls. In: 19th
International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC).
IEEE, p. 1-5, 2008.
FARRELL-VINAY, P. Manage Software Testing. Auerbach Publications, 2008.
FURTADO, A. P. C. C.; GOMES, M. A. W.; ANDRADE, E. C.; JUNIOR, I. H. F. MPT.BR:
A Brazilian Maturity Model for Testing. In: 12th International Conference on Quality
Software (QSIC). IEEE, p. 220-229, 2012.
FLING, B. Mobile Design and Development: Practical Concepts and Techniques for Creating
Mobile Sites and Web Apps. O'Reilly Media, Incorporated, 2009.
FRANKE, D.; WEISE, C. Providing a Software Quality Framework for Testing of Mobile
Applications. In: 4th International Conference on Software Testing, Verification and
Validation (ICST). IEEE, p. 431- 434, 2011.
162
GUERRA, A. C.; COLOMBO, R. M. T. Tecnologia da Informação: Qualidade de Produto de
Software. Brasília: PBQP Software - Programa Brasileiro de Qualidade e Produtividade,
2009.
GRAHAM, D.; VAN VEENENDAAL, E. Foundations of Software Testing: ISTQB
Certification. Cengage Learning Emea, 2008.
HABIB, S. M.; JACOB, C.; OLOVSSON, T. A Practical Analysis of the Robustness and
Stability of the Network Stack in Smartphones. In: 11th International Conference on
Computer and Information Technology (ICCIT). IEEE, p. 393-398, 2008.
HUMPHREY, W. S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989.
ICKIN, S.; WAC, K.; FIEDLER, M.; JANOWSKI, L.; HONG, J. H.; DEY, A. K. Factors
Influencing Quality of Experience of Commonly Used Mobile Applications. Communications
Magazine, IEEE, v. 50, n. 4, p. 48-56, 2012.
JACOBS, J.; VAN MOLL, J.; STOKES, T. The Process of Test Process Improvement,
XOOTIC Magazine, v. 8, n. 2, p. 23-29, 2000.
JAIN, A. K.; SHANBHAG, D. Addressing Security and Privacy Risks in Mobile
Applications. IT Professional Magazine, IEEE, p. 28-33, 2012.
JEONG, Y.; LEE, J.; SHIN, G. Development Process of Mobile Application SW Based on
Agile Methodology. In: 10th International Conference on Advanced Communication
Technology (ICACT). IEEE, p. 362-366, 2008.
JUN-FENG, Y.; SHI, Y.; JU-BO, L.; DAN, X.; XIANG-YANG, J. Reflective Architecture
Based Software Testing Management Model. In: 1st International Conference on
Management of Innovation and Technology. IEEE, p. 821-825, 2006.
JUNG, E. A Test Process Improvement Model for Embedded Software Developments. In: 9th
International Conference on Quality Software (QSIC'09). IEEE, p. 432-437, 2009.
JURISTO, N.; MORENO, A. Basics of Software Engineering Experimentation. Springer
Publishing Company, Incorporated, 2010.
163
JURISTO, N.; MORENO, A. M.; VEGAS, S. Reviewing 25 Years of Testing Technique
Experiments. Empirical Software Engineering, v. 9, n. 1, p. 7-44, 2004.
JURISTO, N.; VEGAS, S. The Role of Non-Exact Replications in Software Engineering
Experiments. Empirical Software Engineering, v. 16, n. 3, p. 295-324, 2011.
KASURINEN, J. Elaborating Software Test Processes and Strategies. In: 3rd International
Conference on Software Testing, Verification and Validation (ICST). IEEE, p. 355-358, 2010.
KASURINEN, J.; TAIPALE, O.; SMOLANDER, K. Analysis of Problems in Testing
Practices. In: Asia-Pacific Software Engineering Conference, (APSEC'09). IEEE, p. 309-315,
2009.
KIM, C. K.; MOON, Y.; FIFE, E.; LEE, S. Content Analysis of Mobile Applications from the
Top 100 Global Brands. In: 10th International Conference on Mobile Business (ICMB).
IEEE, p. 340-344, 2011.
KIM, H.; CHOI, B.; WONG, W. Performance Testing of Mobile Applications at the Unit Test
Level. In: 3rd International Conference on Secure Software Integration and Reliability
Improvement (SSIRI). IEEE, p. 171-180, 2009.
KITCHENHAM, B. A.; PFLEEGER, S. L.; PICKARD, L. M.; JONES, P. W.; HOAGLIN, D.
C.; EMAM, K. E.; ROSENBERG, J. Preliminary Guidelines for Empirical Research in
Software Engineering. IEEE Trans. Softw. Eng., v. 28, n. 8, p. 721-734, 2002.
KIVI, A. Measuring Mobile User Behavior and Service Usage: Methods, Measurement
Points, and Future Outlook. In: 6th Proceedings of the Global Mobility Roundtable (GMR), p.
1-2, Los Angeles, USA, 2007.
KOOMEN, T.; POL M. Test Process Improvement: A Practical Step-by-Step Guide to
Structured Testing. Addison-Wesley Professional, 1999.
LARSSON, D.; BERTILSSON, H.; FELDT, R. Challenges and Solutions in Test Staff
Relocations Within a Software Consultancy Company. In: 1st International Conference on
Software Testing, Verification, and Validation. IEEE, p. 423-431, 2008.
164
LEE, V.; SCHNEIDER, H.; SCHELL, R. Aplicações Móveis: Arquitetura, Projeto e
Desenvolvimento. Tradução: Amaury Bentes e Deborah Rudiger. São Paulo. Pearson
Education do Brasil, 2005.
LI, F.; MA, W.; CHAO, A. Architecture Centric Approach to Enhance Software Testing
Management. In: 8th International Conference on Intelligent Systems Design and
Applications (ISDA'08). IEEE, p. 654-659, 2008.
LIU, Z.; GAO, X.; LONG, X. Adaptive Random Testing of Mobile Application. In: 2nd
International Conference on Computer Engineering and Technology (ICCET). IEEE, v. 2, p.
297-301, 2010.
MACHADO, C. B.; FREITAS, H. Planejamento de Iniciativas de Adoção de Tecnologias
Móveis. Revista GEPROS, ano 4, n. 1, p. 101-115, jan/mar., 2009. Disponível em
<http://www.ea.ufrgs.br/professores/hfreitas/files/artigos/2009/2009_gepros_cbm_hf_planeja
m_tecn_moveis.pdf>. Acesso em: 01 mar. 2012.
MAHMOUD, Q. H.; POPOWICZ, P. Toward a Framework for the Discovery and
Acquisition of Mobile Applications. In: 9th International Conference on Mobile Business and
9th Global Mobility Roundtable (ICMB-GMR). IEEE, p. 58-65, 2010.
MAO, C.; ZHANG, J. Workflow-based Testing Process Management of Software Project.
In: International Conference on Wireless Communications, Networking and Mobile
Computing (WiCom). IEEE, p. 4950-4953, 2007.
METTE, A.; HASS, J. Testing Processes. In: International Conference on Software Testing,
Verification and Validation (ICST). IEEE, p. 321-327, 2008.
MONTEIRO, R. W.; SIZO, A.; VINICIUS, T.; GUIMARÀES, L. F.; MARTINS, C. R. L.;
SALES, E.; REIS, C. A. L. Uma Experiência de Implantação de Processo de Testes - Caso
PRODEPA. In: IX Simpósio Brasileiro de Qualidade de Software (SBQS), 2010.
MONTGOMERY, D. C.; RUNGER, G. C. Estatística Aplicada e Probabilidade para
Engenheiros. 4 ed. Norwell, MA, USA: LTC, 2009.
165
MIZOUNI, R.; SERHANI, A.; DSSOULI, R.; BENHARREF, A. Challenges in “Mobilizing”
Desktop applications: a New Methodology for Requirements Engineering. In: International
Conference on Innovations in Information Technology, (IIT'09). IEEE, p. 225-229, 2009.
MUCCINI, H.; DI FRANCESCO, A.; ESPOSITO, P. Software Testing of Mobile
Applications: Challenges and Future Research Directions. In: 7th International Workshop on
Automation of Software Test (AST). IEEE, p. 29-35, 2012.
MYERS, G. J. The Art of Software Testing. Ed. John Wiley & Sons, Inc., Hoboken, New
Jersey, 2004.
NAYEBI, F.; DESHARNAIS, J. M.; ABRAN, A. The State of the Art of Mobile Application
Usability Evaluation. In: 25th Canadian Conference on Electrical & Computer Engineering
(CCECE). IEEE, p. 1-4, 2012.
OWASP. Open Web Application Security Project - Mobile Security Project. Disponível em:
<https://www.owasp.org/index.php/OWASP_Mobile_Security_Project>. Acesso em: 08 ago.
2012.
PALIT, R.; ARYA, R.; NAIK, K.; SINGH, A. Selection and Execution of User Level Test
Cases for Energy Cost Evaluation of Smartphones. In: 6th International Workshop on
Automation of Software Test (ACM), p. 84-90, 2011.
POCATILU, P. Testing Java ME Applications. Revista Informática Econômica, vol. 12, n. 3,
p. 147-150, 2008.
PRESSMAN, R. S. Engenharia de Software – Uma Abordagem Profissional, 7 ed., McGraw-
Hill, 2011.
QIAN, Q.; YINHUI, C.; FENG, Q.; XUESONG, Q. Workflow-Based Process Management
of Network Management Testing. In: 3rd International Symposium on Intelligent Information
Technology Application Workshops, (IITAW'09). IEEE, p. 265-268, 2009.
RADATZ, J.; GERACI, A.; KATKI, F. IEEE Standard Glossary of Software Engineering
Terminology. IEEE Std, v. 610121990, p. 121, 1990.
166
RIOS, E. Modelos de Melhoria de Processos de Teste de Software. Disponível em:
<http://www.iteste.com.br/LinkClick.aspx?fileticket=HqZPUqoWOjM%3d&tabid=1&mid=1
007>. Acesso em: 09 mar. 2013.
RIOS, E.; CRISTALLI, R.; MOREIRA FILHO, T. R. Gerenciando Projetos de Teste de
Software, Imagem Art Studio, Rio de Janeiro, 2011.
RODRIGUES, A.; PINHEIRO, P. R.; ALBUQUERQUE, A. The Definition of a Testing
Process to Small-Sized Companies: The Brazilian Scenario. In: 7th International Conference
on the Quality of Information and Communications Technology (QUATIC). IEEE, 2010.
RUIZ, I. J. M.; NAGAPPAN, M.; ADAMS, B.; HASSAN, A. E. Understanding Reuse in the
Android Market. In: 20th International Conference on Program Comprehension (ICPC).
IEEE, p. 113-122, 2012.
SANZ, A.; GARCIA, J.; SALDANA, J.; AMESCUA, A. A Proposal of a Process Model to
Create a Test Factory. In: Workshop on Software Quality (WOSQ). IEEE, p. 65-70, 2009.
SATYANARAYANAN, M. Fundamental Challenges in Mobile Computing. In: 15th Annual
ACM Symposium on Principles of Distributed Computing. ACM, p. 1-7, 1996.
SHE, S.; SIVAPALAN, S.; WARREN, I. Hermes: A Tool for Testing Mobile Device
Applications. In: Australasian Software Engineering Conference (ASWEC). IEEE, p. 121-
130, 2009.
STEUER, F.; ELKOTOB, M.; ALBAYRAK, S.; STEINBACH, A. Testbed for Mobile
Network Operator Scenarios. In: 2nd International Conference on Testbeds and Research
Infrastructures for the Development of Networks and Communities (TRIDENTCOM). IEEE,
p. 256-265, 2006.
SOFTEX, “MPT.BR – Melhoria do Processo de Teste Brasileiro”, Guia Geral, V2.0., Recife,
Softex, 2011.
SOFTEX, “MPS.BR – Melhoria de Processo de Software Brasileiro”, Guia Geral, V1.2., Rio
de Janeiro, Softex, 2007.
167
THOMPSON, H. S. XML Schema Part 1: Structures Second Edition. W3C Recommendation
28 October 2004. Disponível em: <http://www.w3.org/TR/xmlschema-1/>
TIAN J. Software Quality Engineering: Testing, Quality Assurance and Quantifiable
Improvement. Wiley, 2005.
TRAVASSOS, G. H.; BARROS, M. Contributions of in Virtuo and in Silico Experiments for
the Future of Empirical Studies in Software Engineering. In: 2nd International Workshop The
Future of Empirical Studies in Software Engineering, v. 2, p. 117–130, Roman Castles, Italy.
ISBN 3-8167-6418-5, 2003.
VÄLIMÄKI, T. Test Automation in Symbian Smartphone Development. Presentation.
SysOpen Digia Plc, 2006. Disponível em:
<http://www.tol.oulu.fi/projects/wg4/minutes/Test_Automation_Symbian1.ppt>. Acesso em:
08 mai. 2013.
VAN VEENENDAAL, E. Test Maturity Model integration (TMMi), version 1.0. TMMi
Foundation (www.tmmi.org), 2008.
VERKASALO, H. Analysis of Smartphone User Behavior. In: 9th International Conference
on Mobile Business and 9th Global Mobility Roundtable (ICMB-GMR). IEEE, p. 258-263,
2010.
WEBER, K. C.; ROCHA, A. R.; ALVES, A.; AYALA, A. M.; GONÇALVES, A.; PARET,
B.; SALVIANO, C.; MACHADO, C. F.; SCALET, D.; PETIT, D.; ARAÚJO, E.;
BARROSO, M. G.; OLIVEIRA, K.; OLIVEIRA, L. C. A.; AMARAL, M. P.; CAMPELO, R.
E. C.; MACIEL, T. Modelo de Referência para Melhoria de Processo de Software: uma
abordagem brasileira. In: XXX Conferência Latino-Americana de Informática (CLEI2004), v.
30, 2004.
WEISS, S. Handheld Usability. John Wiley & Sons, 2003.
WOHLIN, C.; RUNESON, P.; HUST, M.; OHLSSON, M. C.; REGNELL, B.; WESSLUN,
A. Experimentation in Software Engineering: An Introduction. Norwell, MA, USA: Kluwer
Academic Publishers, 2000.
168
ZHANG, D.; ADIPAT, B. Challenges, Methodologies, and Issues in the Usability Testing of
Mobile Applications. International Journal of Human-Computer Interaction, v. 18, n. 3, p.
293-308, 2005.
ZEIDLER, C.; KITTL, C.; PETROVIC, O. An Integrated Product Development Process for
Mobile Software. In: International Journal of Mobile Communications, v. 6, n. 3, p. 345-356,
2008.
ZELKOWITZ, M. V.; WALLACE, D. R.; BINKLEY, D. W. Experimental Validation of
New Software Technology. Lecture Notes on Empirical Software Engineering, v. 12, n. 1, p.
229-263, 2003.
169
Estudo Experimental de Viabilidade da
Abordagem TM-Aplic: Instrumentação
A.1. Considerações Iniciais
Este apêndice apresenta os principais documentos utilizados no estudo experimental de
viabilidade da abordagem TM-Aplic (Capítulo 3). Tais documentos são apresentados
obedecendo à seguinte ordem:
1. Termo de Adesão ao Estudo Experimental;
2. Questionário de Caracterização do Participante;
3. Memorial Descritivo;
4. Questionário sobre a Viabilidade da Abordagem TM-Aplic;
A
Apêndice
170
Termo de Adesão ao Estudo Experimental
“Estudo Experimental de Viabilidade da Abordagem TM-Aplic”
Declaro estar ciente de participar de um estudo experimental, denominado Estudo
Experimental de Viabilidade da Abordagem TM-Aplic, a ser coordenado pelo aluno de
mestrado Marcelo Anderson Carmizini (UEM) e pelas professoras Dra. Elisa Hatsue
Moriya Huzita (UEM) e Dra. Tania Fatima Calvi Tait (UEM). Neste estudo responderei
questionários declarando minha formação, minha experiência com aplicações móveis e teste
de software e sobre a viabilidade da abordagem. Declaro estar ciente de que os resultados
coletados a meu respeito (perfil) serão divulgados como parte do estudo de forma anônima.
Declaro, também, estar ciente de que as informações obtidas/produzidas neste estudo podem
ser divulgadas/publicadas única e exclusivamente pelo coordenador deste estudo. Finalmente,
estou ciente de que não receberei nenhum benefício/pagamento pela participação neste
estudo, além do conhecimento adquirido contribuindo com a minha formação profissional.
* O campo ID do Participante não precisa ser preenchido, pois é exclusivo do coordenador
do experimento.
Nome do Participante ID do
Participante Assinatura Local e Data
_________________
_____________________
Cidade, Estado – País
____/____/______ Data
Hora de Início
__ __:__ __
171
Questionário de Caracterização do Participante
“Estudo Experimental de Viabilidade da Abordagem TM-Aplic”
ID do Participante
Nas perguntas a seguir, quando duas ou mais alternativas forem válidas, marque a alternativa
que mais se aplica ao seu caso.
1. Qual o seu nível de formação?
[ ] Superior Incompleto
[ ] Superior Completo
[ ] Pós-Graduação Incompleto – lato sensu (Especialização)
[ ] Pós-Graduação Completo – lato sensu (Especialização)
[ ] Pós-Graduação Incompleto – stricto sensu (Mestrado, Doutorado)
[ ] Pós-Graduação Completo – stricto sensu (Mestrado, Doutorado)
2. Qual a sua experiência com aplicações móveis em relação aos fatores que
caracterizam o ambiente móvel: i) contexto móvel (limitações dos modelos de
dispositivos), ii) usuário de dispositivo móvel (mobilidade) e iii) peculiaridades das
aplicações (características particulares de qualidade, por exemplo, compatibilidade
entre diferentes hardwares e sistemas operacionais, conectividade, segurança e entre
outros)?
[ ] Nenhuma experiência.
Desconheço os fatores que envolvem as aplicações móveis.
[ ] Minha experiência é básica.
Já li, de forma superficial, algo a respeito sobre aplicações móveis, mas não conheço os
fatores envolvidos.
[ ] Minha experiência é moderada.
Eu conheço alguns fatores apenas no que se refere ao fator peculiaridades das aplicações,
pois desenvolvo aplicações móveis para uso pessoal.
172
[ ] Minha experiência é avançada.
Eu conheço todos os fatores do ambiente móvel e sei como eles podem impactar na
qualidade das aplicações móveis, pois participo ativamente de projetos de desenvolvimento
de aplicações comerciais.
[ ] Sem Resposta.
3. Qual a sua experiência com o teste de software em relação às áreas de processo
relacionadas ao planejamento, projeto e execução dos testes?
[ ] Nenhuma experiência.
Desconheço o teste de software e suas áreas de processo.
[ ] Minha experiência é básica.
Já li, de forma superficial, algo a respeito sobre o teste de software (técnicas, tipos, fases),
mas não conheço as áreas de processo.
[ ] Minha experiência é moderada.
Eu conheço a área de processo relacionada à execução dos testes, pois aplico testes de
unidade nas aplicações (softwares) que desenvolvo, mas não conheço as outras áreas de
processo.
[ ] Minha experiência é avançada.
Eu conheço as áreas de processo de teste de software, pois já atuei em projetos que
abordavam o teste de software como um processo.
[ ] Sem Resposta.
Assinatura do Participante Local e Data
___________________________
_____________________
Cidade, Estado – País
____/____/______ Data
173
Memorial Descritivo
“Estudo Experimental de Viabilidade da Abordagem TM-Aplic”
Em comparação com softwares tradicionais, as aplicações móveis apresentam características
de qualidade relacionadas principalmente aos fatores que constituem o ambiente móvel e,
portanto, impactam diretamente na maneira de desenvolver e testar as aplicações.
Os 3 (três) principais fatores de impacto são: i) contexto móvel (limitações dos
modelos de dispositivos), ii) usuário de dispositivo móvel (mobilidade) e iii) aplicação
móvel (características particulares de qualidade, por exemplo: compatibilidade entre
diferentes hardwares e sistemas operacionais, conectividade, segurança e entre outros). Assim
sendo, diante da preocupação com a qualidade das aplicações móveis, torna-se um desafio
fornecer aplicações que satisfaçam as reais necessidades dos usuários, além de serem corretas,
seguras e confiáveis. Além disso, embora as aplicações móveis sejam desenvolvidas em
plataformas e linguagens já existentes, os desenvolvedores não apresentam grande
familiaridade com as particularidades das aplicações, tornando os softwares propensos as
falhas.
Dessa forma, a abordagem de testes para aplicações móveis é proposta, chamada de
TM-Aplic, visa estabelecer uma metodologia sistemática de testes que combine boas práticas
de planejamento, projeto e execução de testes com as necessidades e particularidades das
aplicações móveis, em termos de tarefas, artefatos e papéis, de maneira que contribua para a
qualidade do produto final.
A descrição gráfica do diagrama da abordagem foi realizada por meio da notação para
a modelagem de processos de negócios BPMN (Business Process Modeling Notation),
mantida pelo Object Management Group (OMG), por entender ser uma notação de fácil
entendimento do percurso das tarefas apresentadas.
Os componentes (subprocessos, tarefas, papéis e artefatos) apresentados na abordagem
estão fundamentados pelo Nível 1 (um) de maturidade do modelo MPT.BR (Melhoria do
Processo de Teste Brasileiro), pois o modelo fornece uma série de diretrizes que, quando
implementadas de maneira coletiva, apoia as atividades de teste de software independente do
porte da empresa.
Na Figura A.1 é apresentado o diagrama da abordagem TM-Aplic, e na Tabela A.1 são
apresentados os objetos utilizados para compor o diagrama.
174
Figura A.1. Diagrama da abordagem TM-Aplic
Tabela A.1. Objetos utilizados para compor o diagrama
Figura Objeto Figura Objeto
Evento de Início Associação
Evento de Início com Mensagem
Tarefa
Evento de Término
Objeto de Dados (artefatos)
Evento de Término com Mensagem
Anotação de Texto
Decisões Pool
Fluxo de Sequência Fluxo de Mensagem
175
As Tabelas a seguir apresentam as principais características de cada tarefa da
abordagem TM-Aplic.
Tabela A.2. Tarefa: analisar produto de teste
Analisar Produto de Teste
Subprocesso Planejamento de Teste
Responsável Gerente de Teste
Artefato Relatório de Análise do Produto
Descrição
Identificar as principais áreas de risco da aplicação móvel. Alguns riscos
identificados e que serve de base para qualquer aplicação móvel: i) a aplicação pode
não funcionar em determinados modelos de dispositivos móveis; ii) a aplicação
pode ser rejeitada pelos usuários; iii) a aplicação pode falhar em ambientes externos
devido à mobilidade; e iv) a aplicação pode prejudicar o funcionamento correto dos
serviços e/ou aplicações existente no dispositivo móvel. Para cada risco, planos de
mitigação devem ser identificados.
Tabela A.3. Tarefa: estabelecer objetivos do teste
Estabelecer Objetivos do Teste
Subprocesso Planejamento de Teste
Responsável Gerente de Teste
Artefato Relatório de Objetivos do Teste
Descrição
Determinar o propósito da realização do teste da aplicação móvel. Entre os
vários objetivos identificados, 2 (dois) merecem destaque: i) definir critérios
de aceitação da aplicação móvel pelo usuário final, por exemplo, usabilidade,
desempenho, bateria, funções do dispositivo, custo de dados para conexões e
aplicações, rotina do usuário, estilo de vida do usuário; e ii) definir
características de qualidade que a aplicação deve contemplar, por exemplo,
autonomia, conectividade (rede), limitação de recursos, touch screen e entre
outras.
176
Tabela A.4. Tarefa: definir estratégia de teste
Definir Estratégia de Teste
Subprocesso Planejamento de Teste
Responsável Gerente de Teste
Artefato Relatório da Estratégia de Teste
Descrição
Identificar como o teste será conduzido com base na análise do produto e nos
objetivos do teste. Algumas características devem ser analisadas para
compor a estratégia de testes para aplicações móveis, por exemplo: definir os
critérios de qualidade, definir os tipos de testes, definir o local do teste
(emulador e/ou no dispositivo móvel), definir o ambiente do teste
(laboratório - ambiente controlado e/ou contexto móvel - ambiente externo).
Após analisada as características, deve-se associá-las com os riscos, para que
seja possível definir a melhor estratégia, a fim de evitar a ocorrência ou
reduzir os efeitos do risco.
Tabela A.5. Tarefa: definir equipe de teste
Definir Equipe de Teste
Subprocesso Planejamento de Teste
Responsável Gerente de Teste
Artefato Relatório da Equipe de Teste
Descrição
Compor a equipe de teste e atribuir papéis. Para a abordagem TM-Aplic,
além do gerente de testes responsável pelas atividades do planejamento,
outros 2 (dois) papéis foram selecionados: analista de testes (responsável por
identificar os casos de teste, reportar e acompanhar incidentes) e testador
(responsável por executar testes). É comum a necessidade de especialistas
em funções específicas das aplicações móveis, por exemplo, conectividade,
chamadas, mensagens, identificação pessoal do usuário (PIN), aplicações,
áudio/vídeo, multimídia e entre outros; o que pode acarretar em uma
carência técnica, devido a falta de profissionais especializados nas áreas
citadas.
177
Tabela A.6. Tarefa: definir ambiente de teste
Definir Ambiente de Teste
Subprocesso Planejamento de Teste
Responsável Gerente de Teste
Artefato Relatório do Ambiente de Teste
Descrição
Identificar o ambiente necessário para os testes da aplicação móvel, o qual
deve ser caracterizado como um ambiente dinâmico. Além dos modelos de
dispositivos móveis necessários para o teste (por exemplo, um modelo
específico de dispositivo), a estrutura do ambiente dinâmico deve favorecer a
liberdade no uso do dispositivo móvel, pois é essencial que a pessoa que
estiver operando a aplicação sinta-se à vontade para segurar o aparelho e
usá-lo da maneira que mais o agrada, resultando em dados mais reais para as
análises do teste. Além disso, pode-se desenvolver um documento que
apresente as características dos dispositivos homologados, a fim de controlar,
com maior precisão, os modelos que passaram pelo teste. As características
podem estar relacionadas com a marca, modelo, sistema operacional, se
possui teclado físico ou não e entre outros. Esses dispositivos devem estar
relacionados com a versão da aplicação móvel.
Tabela A.7. Tarefa: estabelecer plano de teste
Estabelecer Plano de Teste
Subprocesso Planejamento de Teste
Responsável Gerente de Teste
Artefato Plano de Teste
Descrição Identificar uma estrutura formal para organizar e consolidar todas as
informações produzidas pelas tarefas (anteriores) do planejamento de testes.
178
Tabela A.8. Tarefa: planejar os artefatos e dados
Planejar os Artefatos e Dados
Subprocesso Planejamento de Teste
Responsável Gerente de Teste
Artefato Relatório de Informações Gerais
Descrição
Gerenciar todas as informações documentadas ao longo das tarefas de teste,
no que se refere à coleta, armazenamento e distribuição de artefatos. As
aplicações móveis apresentam características similares entre si e, portanto, as
informações registradas nos artefatos podem ser reaproveitadas para o teste
de outras aplicações. Essa prática pode apoiar as empresas na divulgação de
informações relacionadas com os artefatos gerados durante o teste, criando
uma cultura de teste para permitir que algumas tarefas possam ser executadas
por membros da equipe que não tem experiência na área, no caso de alguma
situação de carência técnica. Com o auxílio do analista de testes, o gerente
deve restaurar as configurações utilizadas nos dispositivos, além de
apresentar as informações gerais na reunião final, por exemplo, casos de
teste identificados, executados, incidentes, cronogramas e entre outros.
Tabela A.9. Tarefa: identificar casos de teste
Identificar Casos de Teste
Subprocesso Projeto e Execução de Teste
Responsável Analista de Testes
Artefato Caso de Teste
Descrição
Com base no Relatório de Análise do produto, identificar situações em que a
aplicação móvel possa reagir incorretamente às possíveis entradas. Por
entender que as técnicas de caixa-branca consomem muito recursos dos
dispositivos, impactando na execução normal da aplicação, considera-se a
técnica de teste caixa-preta para a geração de casos de teste, na qual as
informações de entrada e saída devem ser consideradas. As entradas estão
divididas em duas principais categorias: as fornecidas pelo usuário por meio
de uma interface gráfica (eventos de teclado e toque) e o contexto ambiental.
O contexto ambiental divide-se em: contexto físico e contexto social. O
contexto físico é obtido a partir das características físicas do dispositivo
móvel, por exemplo: os receptores de GPS, sensores de Bluetooth, sensores
de acelerômetro, sensores magnéticos, sensores de umidade e sensores de
rede. O contexto social está relacionado com as atividades realizadas pelo
usuário no momento de operar a aplicação móvel, por exemplo: estar em
uma reunião, comportamento do usuário (humor). Dessa forma, a aplicação
móvel deve considerar as variações de entrada, de modo a produzir as saídas
adequadas. As saídas podem ser apresentadas de várias formas, como:
exibição de imagens, vídeo, áudio, vibração, sinais de LED.
179
Tabela A.10. Tarefa: executar testes
Executar Testes
Subprocesso Projeto e Execução de Teste
Responsável Testador
Artefato Relatório de Execução
Descrição
Executar os casos de teste elaborados, além de envolver a identificação e o
detalhamento dos incidentes observados durante os testes. Um incidente de
teste é a manifestação de qualquer defeito no software ou uma anomalia no
funcionamento do ambiente operacional. Após a execução do teste, deve-se
fazer uma avaliação para determinar se a execução foi suficiente, pois caso
contrário, novos casos de testes deverão ser projetados. Caso incidentes
sejam identificados, deve-se encaminhar o relatório de execução para a tarefa
de reportar incidentes, caso contrário, as tarefas de teste são finalizadas.
Tabela A.11. Tarefa: reportar incidentes
Reportar Incidentes
Subprocesso Projeto e Execução de Teste
Responsável Analista de Teste
Artefato Registro de Incidentes
Descrição
Registrar os incidentes encontrados durante a execução do teste, o qual deve
apresentar as informações observadas pelo testador, a fim de auxiliar o
desenvolvedor durante as correções.
Tabela A.12. Tarefa: acompanhar incidentes
Acompanhar Incidentes
Subprocesso Projeto e Execução de Teste
Responsável Analista de Teste
Artefato Relatório de Acompanhamento
Descrição Acompanhar o incidente até a sua correção pelo desenvolvedor responsável.
Após a correção, os casos de testes deverão ser executados novamente.
180
Questionário sobre a Viabilidade da Abordagem TM-Aplic
“Estudo Experimental de Viabilidade da Abordagem TM-Aplic”
ID do Participante
Para as questões 1 a 13, responda de acordo com a legenda apresentada na tabela
abaixo:
Variável/Valor [0] [1] [2] [3] [SR]
Concordância Discordo
Totalmente Discordo
Parcialmente Concordo
Parcialmente Concordo
Totalmente Sem
Resposta
1. Em sua opinião, a tarefa Analisar Produto de Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
2. Em sua opinião, a tarefa Estabelecer Objetivos do Teste presente na abordagem
atende as necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
3. Em sua opinião, a tarefa Definir Estratégia de Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
4. Em sua opinião, a tarefa Definir Equipe de Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
181
5. Em sua opinião, a tarefa Definir Ambiente de Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
6. Em sua opinião, a tarefa Estabelecer Plano de Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
7. Em sua opinião, a tarefa Planejar os Artefatos e Dados presente na abordagem
atende as necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
8. Em sua opinião, a tarefa Identificar Casos de Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
9. Em sua opinião, a tarefa Executar Teste presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
10. Em sua opinião, a tarefa Reportar Incidentes presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
182
11. Em sua opinião, a tarefa Acompanhar Incidentes presente na abordagem atende as
necessidades das aplicações móveis (fatores do ambiente móvel)?
Concordância
[0] [1] [2] [3] SR
12. Em sua opinião, os artefatos gerados nas tarefas presentes na abordagem são
suficientes para atender as necessidades das aplicações móveis (fatores do ambiente
móvel)?
Concordância
[0] [1] [2] [3] SR
13. Em sua opinião, a padronização das tarefas e artefatos, definidos na abordagem
TM-Aplic, pode contribuir para um significativo ganho na qualidade do produto
final?
Concordância
[0] [1] [2] [3] SR
14. Você visualiza tarefas e/ou artefatos adicionais que devem ser contemplados pela
abordagem? Se sim, quais?
( ) Sim ( ) Não
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Hora de Término
__ __:__ __
Obrigado pela sua colaboração!
183
Templates para os Artefatos
B.1. Considerações Iniciais
Este apêndice apresenta os templates para os artefatos gerados pelas tarefas da abordagem
TM-Aplic proposta no Capítulo 3, além dos respectivos arquivos no formato XSD (XML
Schema Definition).
O arquivo XSD tem por objetivo descrever a estrutura e restringir o conteúdo de um
documento XML (eXtensible Markup Language). Os componentes utilizados são definidos
em termos das suas propriedades, e cada propriedade define os valores que são possíveis. Para
um melhor entendimento, pode-se fazer uma analogia com a definição de esquema de um
grafo direcionado rotulado, no qual a raiz é um esquema, todos os vértices são componentes
do esquema e cada aresta rotulada é uma propriedade (Thompson, 2004).
O objetivo dos arquivos XSD para a abordagem TM-Aplic é a possível integração com
alguma ferramenta de apoio, pois os artefatos gerados devem ser validados para que
apresentem as informações abordadas nesse trabalho.
B
Apêndice
184
B.2. Relatório de Análise do Produto
O template para o Relatório de Análise do Produto é apresentado no Quadro B.1 e o arquivo
de validação na Figura B.1.
Quadro B.1. Template para o relatório de análise do produto
RELATÓRIO DE ANÁLISE DO PRODUTO
Identificador:
Gerente de Teste:
Nome da Aplicação:
Tipo da Aplicação:
Versão da Aplicação:
Descrição da Aplicação:
Risco(s) Plano(s) de Mitigação
Figura B.1. Arquivo de validação para o relatório de análise do produto
185
B.3. Relatório de Objetivos do Teste
O template para o Relatório de Objetivos do Teste é apresentado no Quadro B.2 e o arquivo
de validação na Figura B.2.
Quadro B.2. Template para o relatório de objetivos do teste
RELATÓRIO DE OBJETIVOS DO TESTE
Identificador:
Gerente de Teste:
Nome da Aplicação:
Objetivo(s):
Figura B.2. Arquivo de validação para o relatório de objetivos do teste
186
B.4. Relatório da Estratégia de Teste
O template para o Relatório da Estratégia de Teste é apresentado no Quadro B.3 e o arquivo
de validação na Figura B.3.
Quadro B.3. Template para o relatório da estratégia de testes
RELATÓRIO DA ESTRATÉGIA DE TESTES
Identificador:
Gerente de Teste:
Nome da Aplicação:
Riscos Critérios Tipos de Teste Local Ambiente
Figura B.3. Arquivo de validação para o relatório da estratégia de testes
187
B.5. Relatório da Equipe de Teste
O template para o Relatório da Equipe de Teste é apresentado no Quadro B.4 e o arquivo de
validação na Figura B.4.
Quadro B.4. Template para o relatório da equipe de testes
RELATÓRIO DA EQUIPE DE TESTES
Identificador:
Gerente de Teste:
Nome da Aplicação:
Analista de Testes:
Testador:
Especialista: ( ) Não ( ) Sim - Qual (is):
Treinamento: ( ) Não ( ) Sim - Qual (is):
Figura B.4. Arquivo de validação para o relatório da equipe de teste
188
B.6. Relatório do Ambiente de Teste
O template para o Relatório do Ambiente de Teste é apresentado no Quadro B.5 e o arquivo
de validação na Figura B.5.
Quadro B.5. Template para o relatório do ambiente de testes
RELATÓRIO DO AMBIENTE DE TESTES
Identificador:
Gerente de Teste:
Nome da Aplicação:
Hardware:
Modelo Dispositivo Móvel:
Software:
Emulador:
Requisitos para Testes em Campo:
Figura B.5. Arquivo de validação para o relatório do ambiente de testes
189
B.7. Estabelecer Plano de Teste
O template para o Plano de Teste é apresentado no Quadro B.6. Como o Plano de Teste é a
união das tarefas anteriores realizadas pelo planejamento, o arquivo de validação será
omitido, por entender que os componentes utilizados no arquivo ficarão idênticos aos
arquivos de validação anteriores. Para a construção do arquivo de validação para o artefato
plano de testes, basta unir os arquivos das tarefas anteriores.
Quadro B.6. Template para o plano de teste
PLANO DE TESTES
Identificador:
Gerente de Teste:
Nome da Aplicação:
Tipo da Aplicação:
Versão da Aplicação:
Descrição da Aplicação:
Risco(s) Plano(s) de Mitigação
Objetivos:
Riscos Critérios Tipos de Teste Local Ambiente
Analista de Testes:
Testador:
Especialista: ( ) Não ( ) Sim - Qual (is):
Treinamento: ( ) Não ( ) Sim - Qual (is):
Hardware:
Dispositivo Móvel:
Software:
Emulador:
Requisitos para Testes em Campo:
Cronograma:
190
B.8. Planejar os Artefatos e Dados
O template do relatório de Observações Gerais do Teste resultante da tarefa Planejar os
Artefatos e Dados é apresentado no Quadro B.7 e o arquivo de validação na Figura B.6.
Quadro B.7. Template para as observações gerais do teste
OBSERVAÇÕES GERAIS DO TESTE
Identificador:
Plano de Testes:
Gerente de Teste:
Data Início: Data Fim:
Casos de Teste Identificados:
Casos de Teste Executados:
Incidentes Rejeitados:
Incidentes Adiados:
Incidentes Corrigidos:
Conclusão:
Melhorias Observadas:
191
Figura B.6. Arquivo de validação para o relatório de observações gerais do teste
192
B.9. Identificar Caso de Teste
O template para os Casos de Teste é apresentado no Quadro B.8 e o arquivo de validação na
Figura B.7.
Quadro B.8. Template para os casos de teste
CASO DE TESTE
Identificador:
Analista de Teste:
Nome da Aplicação:
Plano de Testes:
Objetivo:
Condições Iniciais:
Entradas:
Usuário (interface gráfica):
Contexto Ambiental:
Resultado Esperado:
Figura B.7. Arquivo de validação para o caso de teste
193
B.10. Executar Teste
O template para o Relatório de Execução é apresentado no Quadro B.9 e o arquivo de
validação na Figura B.8.
Quadro B.9. Template para o relatório de execução do teste
RELATÓRIO DE EXECUÇÃO
Identificador:
Testador:
Data/Hora:
Duração da Execução:
Casos de Testes Executados:
Resultado da Execução:
Incidente Identificado:
Figura B.8. Arquivo de validação para o relatório de execução do teste
194
B.11. Reportar Incidentes
O template para o Registro de Incidentes é apresentado no Quadro B.10 e o arquivo de
validação na Figura B.9.
Quadro B.10. Template para o registro de incidente
REGISTRO DE INCIDENTE
Identificador:
Analista de Teste:
Relatório de Execução:
Condições Iniciais:
Resultados Esperados:
Resultados Atuais:
Incidente:
Data/Hora:
Passos do Procedimento:
Frequência de Ocorrência: ( ) Sistemático ( ) Aleatório ( ) Apenas uma vez
Ambiente:
Tentativas de Repetição:
Observadores:
Impacto:
195
Figura B.9. Arquivo de validação para o registro de incidente
196
B.12. Acompanhar Incidentes
O template para o Relatório de Acompanhamento de Incidentes é apresentado no Quadro
B.11 e o arquivo de validação na Figura B.10.
Quadro B.11. Template para o relatório de acompanhamento de incidentes
RELATÓRIO DE ACOMPANHAMENTO DE INCIDENTES
Identificador:
Analista de Teste:
Incidente:
Descrição:
Prioridade: ( ) Baixa ( ) Média ( ) Alta
Parecer do Desenvolvedor:
Ação: ( ) Rejeitar ( ) Adiar ( ) Corrigir
Figura B.10. Arquivo de validação para o relatorio de acompanhamento de incidente