0
FACULDADE BOA VIAGEM
Bruno Eduardo de Souza Silva
Processo de Testes de Aplicações Mobile: Uma Abordagem Prática com Base
na Norma ISO/IEC/IEEE 29119
Recife
2014
1
Bruno Eduardo de Souza Silva
Processo de Testes de Aplicações Mobile: Uma Abordagem Prática com Base
na Norma ISO/IEC/IEEE 29119
Monografia apresentada como requisito para
conclusão do Curso de Ciência da Computação da
Faculdade Boa Viagem (FBV).
Orientador: Victor Hazin da Rocha
Recife
2014
2
Catalogação na fonte Biblioteca da Faculdade Boa Viagem, Recife/PE
S586pSilva,
Bruno Eduardo de Souza.
Processo de Testes de Aplicações Mobile: uma abordagem prática
com base na norma ISSO/IEC/IEEE 29119 / Bruno Eduardo de
Souza Silva. - Recife : FBV | DeVry, 2014.
64 f. : il.
Orientador(a) : Victor Hazin da Rocha.
Trabalho de Conclusão de Curso (Computação) - Faculdade
Boa Viagem | DeVry.
1.
Engenharia de software. 2. Testes de software.
Processo de testes. I. Título.
CDU 004[14.1]
Ficha catalográfica elaborada pelo bibliotecário: Jadinilson Afonso CRB-4/1367
3.
3
Bruno Eduardo de Souza Silva
Processo de Testes de Aplicações Mobile: Uma Abordagem Prática com Base
na Norma ISO/IEC/IEEE 29119
Monografia apresentada como pré-requisito para conclusão do Curso de Ciência da
Computação da Faculdade Boa Viagem (FBV).
Aprovada em:
Recife, 16 de Junho de 2014
Banca Examinadora
_________________________________________________________
Orientador
________________________________________________________
1o Examinador
_______________________________________________________
2o Examinador
4
Dedico este trabalho à minha família.
5
AGRADECIMENTOS
Em primeiro lugar, agradeço a Deus.
Agradeço aos meus pais, Paulo e Janaci, por toda dedicação e amor, por sempre
me apoiarem em cada passo da minha vida, por acreditarem em mim, por todo
esforço feito para que eu chegasse aonde cheguei e por sempre mostrar que o
estudo é o melhor caminho, sendo humilde e respeitando ao próximo.
Agradeço aos meus irmãos Flávia e Neto, obrigado por confiarem em mim e por me
incentivarem sempre, e que eu possa servir de inspiração para vocês. E a minha
sobrinha Bruna, que chegou para iluminar a nossa família com sua pureza e fofura.
Agradeço também aos meus avós José e Nair, meus grandes exemplos de força,
amor, respeito e união, que mesmo nas dificuldades sempre se mantem unidos e me
ensinaram que a família é o bem mais precioso que se pode ter na vida.
Agradeço a minha segunda família, a família Ferraz, que são para mim uma
inspiração de dedicação, educação e respeito e que me ensinaram e ensinam até
hoje como ser uma pessoa melhor, obrigado por tudo, sou extremamente grato a
vocês, em especial ao meu padrinho Carlos e minha tia Ana.
Agradeço à toda minha família, que direta ou indiretamente contribuíram para minha
educação e formação, obrigado por fazerem parte da minha vida e que continuemos
essa família unida que sempre se mostra firme em qualquer momento de
dificuldade.
Agradeço também a minha Rebecca, que teve tanta paciência comigo e que mais
me incentivou na realização deste trabalho, logo peço desculpas pela ausência e
pelos meus dias nervosos. Também faço um agradecimento ao meu sogro, sogra e a
minha cunhada.
Ao meu orientador, Victor Hazin, muito obrigado por me incentivar sempre a concluir
o trabalho e pela pressão imposta para que eu concluísse as atividades e prazos, e
pela paciência, sempre estando disponível para que eu tirasse minhas duvidas e
para explicações.
Agradeço aos meus amigos do C.E.S.A.R, que me incentivaram nessa caminhada, e
meus amigos da faculdade, em especial Emídio Oliveira, que me ajudou bastante
com o aplicativo Android.
Finalmente, agradeço aos meus professores da FBV, não só aos atuais, mas
também aqueles que já passaram pela faculdade e que colaboraram muito na minha
formação.
6
”Não é na ciência que está a felicidade, mas na aquisição da ciência”.
Edgar Allan Poe
7
RESUMO
Testes de software já é um conceito consagrado como necessário para a obtenção
da qualidade e um programa, assim como processos de software, que tem por
objetivo padronizar o desenvolvimento de um programa. A norma internacional
ISO/EIC/IEEE 29119 determina um padrão um processo de testes. Com o
crescimento do mercado de aplicativos para dispositivos moveis, é clara a
necessidade de garantir a qualidade desses aplicativos. Este trabalho tem como
objetivo apresentar um processo de testes para aplicativos de pequeno porte de
dispositivos móveis baseado na norma ISO/EIC/IEEE 29119, para atingir o objetivo,
foi realizado um experimento para validar o processo proposto e os resultados serão
apresentados neste trabalho.
Palavras-chave: Engenharia de Software. Testes de Software. Processos de Testes.
8
ABSTRACT
Software testing is already an established concept as necessary for the achievement
of quality and program, as well as software processes, which aims to standardize the
development of software. The international standard ISO/IEC/IEEE 29119 determines
a pattern for process of testing. With the growth of market of applications for mobile
devices is a clear need to ensure the quality of these applications. This work aims at
presenting a process of testing for small-sized mobile applications based on
ISO/IEC/IEEE 29119 international standard , to achieve the goal, an experiment was
conducted to validate the proposed process and results will be presented in this
paper.
Keywords: Software Engineering. Software Testing. Test Processes.
9
LISTA DE ILUSTRAÇÕES
Figura 1 – Ciclo de visa dos testes.............................................................................18
Figura 2 – Modelo em cascata...................................................................................23
Figura 3 – Processos de teste segundo a ISO/IEC/IEEE 29119................................25
Figura 4 – Atividades do processo organizacional.....................................................26
Figura 5 – Atividades do processo de gerenciamento...............................................27
Figura 6 – Atividades do processo de planejamento de testes..................................28
Figura 7 – Atividades do processo de monitoração e controle de testes...................29
Figura 8 – Atividades do processo de conclusão de testes.......................................30
Figura 9 – Atividades do processo dinâmico..............................................................31
Figura 10 – Atividades do processo de projeto e implementação de testes..............32
Figura 11 – Atividades do processo de configuração e manutenção do ambiente de
testes..........................................................................................................................33
Figura 12 – Atividades do processo de execução de testes......................................33
Figura 13 – Atividades do processo de relatório de incidentes de testes..................34
Figura 14 – Técnicas de teste cobertas pela norma ISO/IEC/IEEE 29119-4.............36
Figura 15 – Modelo multicamadas contendo os processos.......................................38
Figura 16 – Processos de Gerenciamento de Testes................................................40
Figura 17 – Processos Dinâmicos de Teste...............................................................47
Figura 18 – Árvore de eventos de um aplicativo de bloco de notas...........................50
Figura 19 – Cronograma do projeto de testes............................................................56
Figura 20 – Árvore de eventos derivada da aplicação em uso..................................57
Figura 21 – Fluxo da função inserir valor...................................................................58
10
LISTA DE TABELAS
Tabela 1 – Definições de Teste de Software..............................................................15
Tabela 2 – Princípios de teste de software.................................................................17
Tabela 3 – Atividades genéricas para processo de software.....................................22
11
LISTA DE QUADROS
Quadro 1 – Especificação dos campos dos casos de teste.......................................51
Quadro 2 – Caso de teste da função inserir valor......................................................58
12
LISTA DE ABREVIATURAS E SIGLAS
CASE
Computer-Aided Software Engineering
ABNT
Associação Brasileira de Normas Técnicas
IEEE
Institute of Electrical and Electronics Engineers
ISO
International Organization for Standardization
IEC
International Electrotechnical Commission
NBR
Norma Brasileira Regulamentadora
ISTQB
International Software Testing Qualifications Board
BSTQB
Brazilian Software Testing Qualifications Board
App
Aplicativo
Abinee
Associação brasileira de indústria elétrica e eletrônica
13
SUMÁRIO
1.
INTRODUÇÃO ................................................................................................... 14
2.
REFERENCIAL TEÓRICO ................................................................................ 16
2.1.
TESTE DE SOFTWARE ................................................................................. 16
2.2.
ESTRATÉGIA DE TESTES ............................................................................ 19
2.3.
PROCESSO DE TESTES DE SOFTWARE ................................................... 22
2.4.
NORMA INTERNACIONAL ISO/IEC/IEEE 29119 .......................................... 24
2.4.1.
ISO/IEC/IEEE 29119-1: 2013 ...................................................................... 25
2.4.2.
ISO/IEC/IEEE 29119-2: 2013 ...................................................................... 25
2.4.3.
ISO/IEC/IEEE 29119-3: 2013 ...................................................................... 35
2.4.4.
ISO/IEC/IEEE 29119-4: 2013 ...................................................................... 36
2.4.5.
ISO/IEC/IEEE 29119-5: 2013 ...................................................................... 36
3.
PROCESSO DE TESTES .................................................................................. 38
3.1.
PROCESSO ORGANIZACIONAL ................................................................. 39
3.2.
PROCESSOS DE GERENCIAMENTO DE TESTES ..................................... 40
3.2.1.
PLANEJAMENTO DE TESTES .................................................................. 41
3.2.2.
MONITORAÇÃO E CONTROLE ................................................................. 45
3.2.3.
CONCLUSÃO ............................................................................................. 47
3.3.
PROCESSOS DINÂMICOS DE TESTE ......................................................... 48
3.3.1.
PROJETO E ELABORAÇÃO DE TESTES ................................................. 48
3.3.2.
EXECUÇÃO E RELATÓRIO DE INCIDENTES........................................... 53
4.
VALIDAÇÃO DO PROCESSO DE TESTES ..................................................... 55
4.1.
CONTEXTUALIZAÇÃO ................................................................................. 55
4.2.
EXECUÇÃO DO PROCESSO ........................................................................ 56
4.3.
RESULTADOS OBTIDOS .............................................................................. 61
5.
5.1.
CONSIDERAÇÕES FINAIS ............................................................................... 62
TRABALHOS FUTUROS................................................................................ 62
14
1. INTRODUÇÃO
Testes de software vêm se tornando cada vez mais uma necessidade junto ao
desenvolvimento de um programa, visto que o custo médio com testes ultrapassa
50% do custo total do software [1] e a regra 10 de Myers [1] afirma que quanto mais
cedo os defeitos forem encontrados, menor o custo para resolvê-los, e caso um
defeito seja encontrado quando o software já está em produção, o custo desse
defeito pode ser catastrófico.
Como o mercado de smartphones disparou nos últimos anos, pesquisas da Abinee,
citam o crescimento médio de 100% em 2013 [2] e em 2014 smartphones já ocupam
65% do mercado de telefonia no Brasil [3], um nicho de mercado também vem
crescendo rapidamente, que é o de desenvolvimento de aplicativos para dispositivos
móveis, como por exemplo, smartphones e tablets [4]. O que implica diretamente na
falta de qualidade de alguns aplicativos é que com a alta demanda e prazos cada
vez mais curtos devido à pressa para publicar um aplicativo, algumas empresas
desenvolvedoras acabam por negligenciar os testes destes aplicativos[5].
A importância desse trabalho se reflete em auxiliar na obtenção da conformidade e
alcançar a qualidade esperada para organizações que desenvolvem pequenos
aplicativos e não dedicam o esforço necessário para planejamento de testes, seja
por falta de tempo, experiência ou mesmo de recursos.
O principal objetivo deste trabalho é desenvolver um processo de testes de
aplicativos de pequeno porte desenvolvidos para dispositivos móveis, onde é usada
como base a especificação genérica para processos de testes apresentada na
norma ISO/IEC/IEEE 29119-2. O processo proposto nesse trabalho traz uma
abordagem prática alinhada com alguns dos princípios da metodologia ágil, de forma
que uma pequena organização consiga governar, gerenciar, implementar e executar
testes de software para qualquer ciclo de vida de desenvolvimento de um software
[6].
Os objetivos específicos do processo proposto neste trabalho são os seguintes:

Padronizar a execução dos testes, facilitando o entendimento e reduzindo o
esforço para projetar os casos de teste;
15

Melhoria da qualidade do software, pois o processo garante uma melhor
cobertura do software a ser testado;

Redução dos custos associados ao risco de se encontrar um defeito no
software em produção;
Os capítulos subsequentes deste trabalho serão apresentados da seguinte forma: no
capitulo 2 serão discutidos os conceitos e fundamentos necessários para a
elaboração deste trabalho; o capitulo 3 é composto pelo processo de testes de
software proposto neste trabalho, onde tem como objetivo o teste de aplicações de
pequeno porte para dispositivos móveis; já o capitulo 4 realiza um experimento para
validar a proposta sugerida neste trabalho; finalmente o capitulo 5 são apresentadas
as conclusões referentes à este trabalho.
16
2. REFERENCIAL TEÓRICO
Esse capítulo apresenta os conceitos de testes de software, processos de teste de
software e estratégia de teste, fundamentais para o entendimento do trabalho
proposto. A seção 2.1 apresenta os conceitos fundamentais de testes de software.
Já a seção 2.2 apresenta uma visão geral do processo de teste de software e dos
processos genéricos que compõem o teste de software, do nível organizacional ao
nível de projeto. Finalmente na seção 2.3 são apresentados conceitos fundamentais
sobre estratégias de testes, como as principais técnicas, tipos de teste entre outros
conceitos que serão abordados neste trabalho.
2.1. Teste de software
Para desenvolver qualquer software, é necessário aplicar algum tipo de teste,
mesmo que seja feito apenas pelos próprios desenvolvedores para avaliar se o que
foi desenvolvido está funcionando, [1], empiricamente, as organizações que
desenvolviam software perceberam a necessidade de definir padrões e técnicas que
garantem a conformidade do software com o que se espera que ele faça, reduzindo
o risco de erros no software em produção [7]. A Tabela 1 apresenta algumas
definições de teste de software.
Tabela 1 – Definições de Teste de Software
Teste de software é um processo de execução de um
Myers [1]
programa com a intenção de encontrar erros, com o
intuito e agregar valor ao programa de elevando sua
qualidade e confiabilidade.
Teste tem como objetivos: Encontrar defeitos, ganho de
ISTQB [8]
confiança na qualidade, fornece informações para a
tomada de decisão e prevenção de defeitos.
Verificar se o software é executado de forma controlada
Rios & Moreira [9]
e está fazendo o que deveria fazer, de acordo com os
seus requisitos, e não está fazendo o que não deveria
fazer.
17
Esses e diversos outros conceitos e definições de teste de software podem ser
encontrados na literatura como em [10], [11] e [7], chegando a uma definição comum
de que teste de software tem como objetivo principal de encontrar erros, garantir a
qualidade do sistema que está sendo testado e se ele esta em conformidade com o
que foi planejado.
Teste de software consiste em uma atividade de um tema mais vasto, conhecido
como validação e verificação. Segundo [10], verificação consiste no conjunto de
tarefas que garantem que determinada função implementada no software está
correta e validação consiste em um conjunto de tarefas que asseguram que o
software foi implementado de acordo com os requisitos do cliente.
O objetivo de um teste é encontrar um defeito, falha ou um erro no sistema que está
sendo testado. De acordo com [12], as diferenças entre defeito, erro, falha e
incidente são:

Defeito: Uma falha em um componente ou sistema que pode fazer com que o
componente ou sistema para de executar a sua função, por exemplo, uma
declaração incorreta ou definição de dados. Um defeito, se encontrado
durante a execução, pode provocar uma falha do sistema ou no componente.

Erro: Uma ação humana que produz um resultado incorreto.

Falha: Desvio do componente ou sistema a partir de sua entrega, serviço ou
resultado esperado. Uma falha é um erro que foi para produção.

Incidente: Qualquer evento que ocorra que requer investigação.
Myers [1] diz que o teste de software leva em considerações conceitos econômicos
e psicológicos, apesar de ser uma tarefa técnica. E também definiu os princípios
para o teste de software apresentados na Tabela 2.
Do ponto de vista psicológico, a atividade de encontrar erros em um programa é
mais adequada do que a atividade de demostrar que o programa não contém erros;
e que um teste que foi dado como “mal sucedido” é por que não encontrou erros e o
programa produziu os resultados esperados corretamente [1].
18
Tabela 2 – Princípios de teste de software
Número
1.
2.
Principio
A parte mais necessária de um caso de teste é a definição do
resultado ou saída esperada.
Um programador deve evitar a tentativa de testar o seu próprio
programa.
3.
Os casos de teste não devem ser grandes e exaustivos.
4.
Analisar abundantemente os resultados de cada teste.
5.
Casos de teste devem ser escritos com entradas que são inválidas
e não esperadas, como também com entradas válidas e esperadas.
Examinar um programa para ver se ele não faz que é proposto, é
6.
apenas metade da batalha; a outra metade é verificar se o
programa faz o que não é proposto.
7.
8.
Evite casos de teste descartáveis, a menos que o programa seja
também descartável.
Nunca faça um teste assumindo que nenhum erro vai ser
encontrado.
A probabilidade de encontrar mais erros numa seção de um
9.
programa é proporcional ao número de erros já encontrados
naquela seção.
10.
Testar é uma tarefa extremamente criativa e intelectualmente
desafiante.
Fonte: [1]
Do ponto de vista econômico, é impossível testar um software a ponto de encontrar
todos os erros que ele possa produzir, mesmo em um programa pequeno, então
deve se levar em conta critérios e estratégias para que o teste de software encontre
o máximo de erros no menor tempo possível dentro do planejado [1].
Cada teste é um processo, e para [7] um processo consiste em um conjunto de
atividades inter-relacionadas que transformam determinadas entradas em saídas. O
ciclo de vida de um teste de software definido por [9] é apresentado na Figura 1.
19
Figura 1 – Ciclo de visa dos testes
Fonte: [9]
Testes ad hoc são testes em que não há um roteiro para executar, ou seja, são
executados à medida que o testador vai usando o programa e encontrando
aleatoriamente bugs e reportando aos desenvolvedores, de acordo com [12]:
“[...] Teste realizado informalmente; nenhuma preparação formal de teste
ocorre, não é usada nenhuma técnica de projeto de teste reconhecida, não
há expectativas para os resultados e arbitrariedade orienta a atividade de
execução de teste”. (ISTQB, 2014, p. 8, tradução nossa).
Porém, ao utilizar estratégias e técnicas de teste, para que os testes de software
proporcionem uma cobertura adequada e para que métricas possam ser obtidas, é
necessário que estes testes sejam reportados aos stakeholders [13] de alguma
forma, seja como um relatório ou através de ferramentas CASE [14], que auxiliam no
processo de desenvolvimento de um software.
2.2. Estratégia de testes
Para que ao testar um software se tenha um máximo proveito dos testes, é
importante que estes testes estejam sendo conduzidos por uma estratégia de testes,
de acordo com [15] a estratégia guia o projeto de testes e pode ser um método para
direcionar o projeto de testes para o time, ajudando a determinar quando e onde
aplicar os diferentes tipos de teste e quais testes são mais importantes para
determinado software.
20
Uma estratégia de testes deve conter tipos de testes, níveis, abordagens e métodos
para guiar o time na execução dos testes; também deve incluir uma avaliação dos
riscos de teste, assim como planos para treinamento ou educação do time de teste
[15].
A estratégia de teste deve conter as características ou funcionalidades que serão
testadas, o objetivo geral, e os objetivos específicos para determinado conjunto de
características [15].
Quanto aos níveis de teste, a estratégia de testes deve especificar o nível de teste
que ira adotar para execução. Os principais níveis de teste segundo [8]:

Teste de componente: São testes com acesso ao código, que devem procurar
defeitos e verifica o funcionamento dos módulos que são testáveis
separadamente, testes de componente podem incluir tanto testes funcionais
quanto testes de características específicas não funcionais (robustez,
memoria);

Teste de Integração: Para testar as interfaces entre os componentes ou
sistemas diferentes, ou seja, testa se houve impacto, algum conflito ou
surgimento de erros ao integrar componentes ou sistemas, e estes testes
podem ocorrer antes ou depois da fase de testes de sistema, porem há riscos
que devem ser levantados, quanto à garantia de apenas um lado da
integração;

Teste de sistema: Teste de sistema deve levar em consideração o sistema
como um todo como definido pelo escopo do projeto, há varias maneiras de
derivar testes de sistema, como por exemplo, por requisitos, casos de uso,
por riscos, entre varias formas que surgem na literatura, O teste de sistema
deve tratar requisitos funcionais e não funcionais, e o testador deve estar
pronto para lidar com requisitos incompletos, incoerentes ou ate mesmo com
a falta deles;

Teste de aceite: Teste de aceite geralmente é de responsabilidade do cliente
ou do usuário do sistema, é quando o sistema é avaliado pelo cliente ao
termino do projeto, os stakeholders podem também ter envolvimentos no
teste de aceite;
21
Quanto aos tipos de teste, cada tipo de teste tem como foco um objetivo em
particular que pode ser teste de uma funcionalidade, ou de uma característica do
software ou para verificar se mudanças não causaram impacto no produto, aponta
[8], que indica os principais tipos de teste que são: testes funcionais, testes não
funcionais, testes estruturais e testes de regressão.

Testes funcionais, como já diz o nome, deve verificar as funções do produto
se estão se comportando como planejado, ou seja, deve verificar “o que” o
sistema faz. Testes de função devem ser realizados em todos os níveis de
teste, seguindo a especificação do artefato a ser testado;

Testes não funcionais se referem a atributos que geralmente não podem ser
avaliados como aprovado ou reprovado, e sim medir as características
colhidas se estão de acordo com o que foi acordado no planejamento do
sistema. Testes não funcionais podem ser feitos em todos os níveis de teste e
incluem testes de carga, estresse, usabilidade entre outros tipos, testando
“como” o sistema funciona;

Testes estruturais se referem à cobertura do software, que consiste na
extensão em que os testes desenvolvidos alcançam toda a estrutura do
software, a fim de validar a arquitetura do sistema, e podem ser aplicados em
todos os níveis de teste;

Teste de regressão consiste em reexecutar um teste em um sistema para
verificar se alguma modificação feita após os testes não causou nenhum
impacto ou inseriu algum bug no sistema, ou de um defeito que não foi
coberto anteriormente. Teste de regressão não incide em refazer um teste que
na execução anterior encontrou um defeito e foi corrigido.
Na estratégia de testes, também devem ser descritas as técnicas de modelagem de
teste, que consistem em identificar as condições e os casos de teste através de
analise da documentação ou do software em questão, onde [8] considera técnicas
baseadas em especificação ou experiência como técnicas caixa-preta e técnicas
baseadas em estrutura como técnicas caixa-branca.
22
Os critérios de conclusão, suspensão e retomada também são definidos na
estratégia de testes e devem ser acordados com os stakeholders na fase de
planejamento. Critérios de saída, segundo [12]:
“[...] conjunto de condições genéricas e específicas, acordadas com as
partes interessadas para permitir um processo a ser oficialmente concluído.
O objetivo do critério de saída é evitar uma tarefa de ser considerada
concluída quando ainda restam partes da tarefa que não foram concluídas.
Critérios de saída são usados para relatar contra e planejar quando parar de
testar.” (T. Gilb, D. Graham apud ISTQB, 1993, p. 22).
Já os critérios de retomada são aqueles que são definidos quando as atividades de
teste que foram interrompidos devem ser retomadas e critérios de suspenção
consistem em critérios usados para parar temporariamente uma ou mais atividades
de teste [12].
Os riscos do projeto e do produto devem ser levantados e declarados, assim como a
estratégia de mitigação dos mesmos deve ser documentada no plano de teste. Um
cronograma com as atividades referentes à estratégia de testes e as atividades de
treinamento e educação também compõem a estratégia de testes [12].
Como testes de software é tido como um projeto que anda paralelamente ao
desenvolvimento do software [9], é necessário que um processo de testes seja
adotado, padronizando e organizando o ciclo de vida dos testes, permitindo que se
tenha um controle do que está sendo testado e para que seja possível obter as
medidas de qualidade e conformidade esperadas na execução dos testes.
2.3. Processo de testes de software
Segundo [10], processo consiste em um conjunto de atividades, ações e tarefas para
desenvolvimento de produtos, onde uma tarefa consiste em um pequeno e bem
definido objetivo, uma ação equivale a um conjunto de tarefas que resultam em um
artefato e uma atividade é um esforço no sentido amplo, independente do campo de
atuação, tamanho ou complexidade do projeto.
Na Tabela 3 são apresentadas as cinco atividades que são consideradas essenciais
por [10], para uma metodologia genérica de processo de software.
23
Tabela 3 – Atividades genéricas para processo de software
Comunicação
É fundamental uma boa comunicação com os stakeholders para
compreensão dos objetivos e levantamento das necessidades
que ajudarão a definir as funções e características do projeto.
Planejamento
Definição das atividades, dos riscos recursos necessários, os
produtos resultantes e o cronograma de trabalho.
Modelagem
Criar um modelo do software para que erros de arquitetura sejam
previstos e corrigidos antes da implementação. Criar um “esboço”
do software antes de começar a desenvolvê-lo de fato.
Construção
Combina a geração de código e dos testes de software.
Emprego
O software é entregue ao cliente que deve avaliar o produto e
retornar o resultado da avaliação para a organização que o
desenvolveu.
Fonte: [10]
Um modelo de processo de software é uma abstração de um processo de software,
fornecendo informações parciais sobre o desenvolvimento. Existem diversos
modelos de processo de software, porem os modelos mais conhecidos são o modelo
em cascata, desenvolvimento evolucionário e a engenharia de software baseada em
componentes [11].
O modelo adotado para o desenvolvimento deste trabalho é o modelo cascata, onde
as atividades de teste estão bem definidas e para a organização que irá testar o
software em questão, as fases de desenvolvimento são abstraídas, porém outros
modelos de processo de software também podem ser considerados.
O modelo cascata é composto por fases bem definidas fluindo por todas as
atividades genéricas, onde as fases estão encadeadas e uma fase não pode ser
começada sem que a anterior seja concluída, a Figura 2 exemplifica o modelo em
cascata.
24
Figura 2 – Modelo em cascata
Fonte: [11]
Assim como o desenvolvimento de software tem um processo definido, o projeto de
testes também deve ter um processo definido, acompanhando, monitorando e
gerando artefatos e reportando os incidentes que ocorrem durante a execução dos
testes do sistema em questão.
2.4. Norma Internacional ISO/IEC/IEEE 29119
A norma internacional ISO/IEC/IEEE 29119 foi desenvolvida para definir um modelo
padrão de processos e para guiar o desenvolvimento do processo de testes de
software, apresentando conceitos, fundamentos e modelos genéricos que orientam o
responsável pelos testes de uma organização a definir um processo de teste para a
organização quanto para cada projeto ou produto, de acordo com sua
particularidade. A seguir serão apresentados os processos de teste de software que
foram definidos na norma internacional ISO/IEC/IEEE 29119, com o objetivo de
padronizar os testes de software. A ISO/IEC/IEEE 29119 foi dividida em quatro
partes:

Parte 1 – Conceitos e definições, publicada em setembro de 2013;
25

Parte 2 – Processos de teste, publicada em setembro de 2013;

Parte 3 – Documentação de teste, publicada em setembro de 2013;

Parte 4 – Técnicas de teste, ainda não publicada;

Parte 5 – Testes dirigidos por palavras-chave, em fase de desenvolvimento;
2.4.1. ISO/IEC/IEEE 29119-1: 2013
A primeira parte da norma ISO/IEC/IEEE 29119 tem como objetivo apresentar os
conceitos, definições e fundamentos de teste de software, contextualizando os
termos utilizados com o intuito de facilitar o uso das partes conseguintes da norma
ISO/IEC/IEEE 29119 [7].
2.4.2. ISO/IEC/IEEE 29119-2: 2013
A segunda parte da norma ISO/IEC/IEEE 29119 define um modelo de processos de
teste de software genérico que pode ser usado por qualquer organização ao
executar qualquer forma de teste [6]. Os processos de testes especificados na
norma ISO/IEC/IEEE 29119-2 podem ser usados para governar, gerenciar e
implementar testes de software para qualquer ciclo de vida de desenvolvimento de
software e independe do tamanho da atividade de testes.
Sobre a conformidade dos processos apresentados, a conformidade completa (full
conformance) implica que todos os requisitos e todos os conjuntos de processos
definidos em [6] foram satisfeitos. Já para alcançar a conformidade ajustada (tailored
conformance), é necessário que se justifique o porquê de certos processos não
adotarem a plena conformidade.
O modelo de processo adotado por [6] é o modelo multicamadas, onde um grupo de
três processos pode ser executado durante o ciclo de vida, como mostrado na
Figura 3.
26
Figura 3 – Processos de teste segundo a ISO/IEC/IEEE 29119
Fonte: [6]
Processo organizacional de testes
O primeiro processo a ser demonstrado é o processo organizacional de testes, que
tem como objetivo desenvolver e gerenciar as especificações organizacionais de
teste [6], a politica de testes e a estratégia organizacional de testes são exemplos de
especificações organizacionais, pois o processo organizacional não depende de
projeto, e contem os propósitos, práticas, objetivos e o escopo geral de testes da
organização.
A política de testes consiste nas diretrizes de teste e nas especificações de teste que
uma empresa deve adotar para garantir a qualidade do software que ela está a
desenvolver, enquanto a estratégia organizacional de testes deve informar, em
linhas gerais, detalhes técnicos de como a organização trata os testes e não deve
ser especifico a um único projeto [6].
A Figura 4 demonstra as atividades contidas no processo organizacional de teste e
são aplicados tanto para política quanto para a estratégia de testes organizacional.
27
Figura 4 – Atividades do processo organizacional
Fonte: [6].
Processos de gerenciamento de testes
A norma ISO/IEC/IEEE-2 apresenta três processo de gerenciamento de testes, que
são mostrados na Figura 5, e o processo de gerenciamento de testes pode ser
aplicado em nível de projeto, como para gerenciamento de testes em determinadas
fases de teste e também para diferentes tipos de teste. Quando aplicado em nível de
projeto, o gerenciamento de testes é responsável por todos os testes do projeto,
tendo como base o plano de testes.
28
Figura 5 – Atividades do processo de gerenciamento
Fonte: [6].
O primeiro processo gerencial, o processo de planejamento de testes, é usado para
desenvolver o plano de testes, de acordo com as atividades executadas na Figura 6,
no processo de planejamento de teste as atividades podem ser sequenciais ou não,
permitindo mudanças e atualizações no plano de teste [6].
29
Figura 6 – Atividades do processo de planejamento de testes
Fonte: [6].
O segundo processo, monitoração e controle apresentado em [6], tem como objetivo
acompanhar o desenvolvimento dos testes e guiar para a direção correta caso os
testes estejam decorrendo de forma não esperada. Também é responsável pela
monitoração e controle de riscos e cronograma de testes. A Figura 7 ilustra as
atividades deste processo.
30
Figura 7 – Atividades do processo de monitoração e controle de testes
Fonte: [6].
O ultimo processo gerencial, o processo de conclusão, tem suas atividades
apresentadas na Figura 8, e tem como objetivo realizar os procedimentos de
conclusão de teste, como arquivar os dados e artefatos de teste, limpar o ambiente
de testes, identificar as lições aprendidas e realizar o relatório de completude de
testes. O processo de conclusão também pode ser usado em nível de projeto, como
para uma fase ou tipo de teste especifico [6].
31
Figura 8 – Atividades do processo de conclusão de testes
Fonte: [6].
Processos dinâmicos de teste
Os testes dinâmicos são associados a fases do processo de testes, como por
exemplo, testes unitários ou de integração, ou a um tipo de teste especifico, como
testes de desempenho ou usabilidade. Os processos de teste dinâmicos, mostrados
na Figura 9, são os responsáveis pelo planejamento, criação execução e relatório
dos ciclos de teste e servem como entrada para os processos de gerenciamento,
onde estes testes dinâmicos são monitorados e respondem às entradas atualizando
o plano de testes ou tomando alguma ação de controle [6].
32
Figura 9 – Atividades do processo dinâmico segundo a ISO/IEC/IEEE 29119
Fonte: [6].
O processo de projeto e implementação de testes tem como atividades principais a
criação dos casos de teste e suas atividades estão representadas na Figura 10 em
sequencia logica, mas na prática algumas atividades ocorrem em paralelo. Sempre
que se julgar necessário, é possível voltar ao processo de projeto e implementação
de testes, no caso de novos cenários serem descobertos e necessitam ser
documentados [6].
33
Figura 10 – Atividades do processo de projeto e implementação de testes
Fonte: [6].
O processo de configuração e manutenção do ambiente de testes é responsável
pelas atividades de preparar e manter o ambiente em que os testes serão
executados. A Figura 11 apresenta as atividades desse processo.
34
Figura 11 – Atividades do processo de configuração e manutenção do ambiente de testes
Fonte: [6].
O processo de execução dos testes consiste em realizar os procedimentos de
execução de teste de acordo com o planejado no processo de projeto e
implementação de testes e suas atividades são mostradas na Figura 12. De acordo
com [6] o processo de execução pode ser executado mais de uma vez e pode ser
necessário que todos os testes disponíveis não sejam executados em uma única
iteração devido a incidentes que podem ser encontrados durante a execução,
interrompendo o processo até que o critério de retomada seja satisfeito.
Figura 12 – Atividades do processo de execução de testes
Fonte: [6].
35
O ultimo processo dinâmico de testes é o processo de relatório de incidentes, que
tem como objetivos reportar os incidentes encontrados no relatório de incidentes e
caso seja um reteste, deve ser atualizado o resultado para que os stakeholders
possam definir a ação a ser tomada para correção do incidente [6]. A figura 13
apresenta as atividades desse processo.
Figura 13 – Atividades do processo de relatório de incidentes de testes
Fonte: [6].
Esse processo genérico apresentado pela norma ISO/IEC/IEEE 29119-2 define
apenas as etapas necessárias para que um projeto de testes execute com sucesso,
porém é imprescindível o apoio das demais partes da norma ISO/IEC/IEEE 29119, a
primeira, que trata de conceitos e definições gerais de teste, e a terceira que
abrange a documentação de acordo com cada processo apresentado na segunda
parte.
2.4.3. ISO/IEC/IEEE 29119-3: 2013
A terceira parte da norma ISO/IEC/IEEE 29119 substituindo a norma IEEE 829:2008
[16], tratando especificamente da documentação dos processos de testes
apresentados na segunda parte desta norma, ou seja, para cada processo que
necessita de uma entrada ou gera um artefato que possa ser documentável, a
terceira parte da norma mostra modelos genéricos de documentos a serem seguidos
36
e exemplos de documentos gerados para organizações ágeis assim como para
organizações que adotam os processos clássicos de desenvolvimento [17].
Sobre a conformidade dos documentos apresentados, a conformidade completa (full
conformance) implica que todos os campos e todos os conjuntos de requisitos
definidos em [17] foram satisfeitos. Já para alcançar a conformidade ajustada
(tailored conformance), é necessário que se justifique o porquê de certos requisitos
não adotarem a conformidade plena.
2.4.4. ISO/IEC/IEEE 29119-4: 2013
A quarta parte da norma ISO/IEC/IEEE 29119 aborda um tema relevante na área de
testes, técnicas de projeto de testes, também conhecido como métodos de teste ou
técnicas de projeto de casos de teste, apresentando padrões internacionais para
projeto de casos de teste que podem ser usados no processo de projeto e
implementação de testes, apresentados em [6], independente da organização ou
modelo de processo de software adotado [18]. Esta norma está em processo de
aprovação e até o presente momento não foi publicada, porém está disponível um
diagrama informando as técnicas de teste cobertas pela ISO/IEC/IEEE 29119-4,
como apresentada na Figura 14.
2.4.5. ISO/IEC/IEEE 29119-5: 2013
Há também uma quinta parte da ISO/IEC/IEEE 29119, que trata de uma técnica de
testes conhecida como Keyword-Driven Testing, ou testes dirigidos por palavraschave, aonde as palavras-chave são nomes associados a um conjunto de ações que
são necessários para executar um passo especifico em um caso de teste [19]. Esta
norma está em processo de desenvolvimento e não há informações suficientes para
detalhá-la.
37
Figura 14 – Técnicas de teste cobertas pela norma ISO/IEC/IEEE 29119-4
Fonte: [6].
38
3. PROCESSO DE TESTES
De acordo com [8], o processo fundamental de teste compreende nas seguintes
atividades: planejamento e controle, análise e modelagem, implementação e
execução do teste, a avaliação de critérios de saída e relatórios e atividades de
encerramento do teste. O processo proposto nesse trabalho contempla as atividades
necessárias para execução de testes de aplicativos para dispositivos moveis
baseados em gestos.
Visto que é uma tendência no mercado de tecnologia o surgimento de pequenas
organizações especializadas em desenvolvimento de aplicativos devido à demanda
vinda de grandes empresas para terceirizarem a concepção de ‘apps’ [20], é
necessário um processo que garanta a qualidade do software, e que a execução
deste processo seja ágil, onde o mercado está exigindo que os softwares sejam
desenvolvidos com os prazos cada vez mais curtos, o que abre uma brecha para
que defeitos e comportamentos indesejados apareçam quando o software está em
produção [5].
O processo proposto neste trabalho será apresentado da seguinte forma: primeiro
serão definidos todos os passos de cada processo, em seguida serão detalhadas as
atividades correspondentes a cada uma das etapas, visando manter o máximo de
simplicidade e coerência com um processo ágil para testes de aplicativos de
dispositivos móveis.
Nas seções a seguir, serão determinados os processos que irão compor cada fase
do processo de teste, indicando de uma forma prática, como cada atividade de cada
processo deve ser implementada para que o projeto de testes cumpra com eficácia o
principal objetivo que o teste de software tem, que é encontrar defeitos e garantir a
que o que foi implementado é de fato o que o software deve fazer [1].
Para garantir a agilidade do processo de testes na execução do projeto de testes, foi
composto um modelo multicamadas de processos, apresentado na Figura 15. O
modelo de processo de testes foi desenvolvido com base no modelo descrito em [6]
alinhado com os princípios definidos em [21], onde um dos fundamentos do
manifesto é que a redução de processos tende a agilizar o desenvolvimento do
software.
39
Figura 15 – Modelo multicamadas contendo os processos
Processos
Organizacionais
de Teste
Processos de Gerenciamento de Teste
Processo de
Monitoração e
Controle
Processo de
Planejamento
Processo de
Conclusão
Processos Dinâmicos de Teste
Processo de
Planejamento e
Elaboração
Processo de Execução
e Relatório de
Incidentes
Fonte: Autoria Própria, 2014.
3.1. Processo Organizacional
O processo organizacional de testes tem como principal função desenvolver e
manter o processo de testes de uma organização, para que se torne reutilizável e
proporcione o desenvolvimento da organização em relação à qualidade do processo
de testes [22].
O processo organizacional de testes tem como processos o desenvolvimento da
política de testes, que consiste nas diretrizes de teste e nas especificações de teste
que uma empresa deve adotar para garantir a qualidade do software que ela está a
desenvolver, e a definição das estratégias de testes organizacional, que são as
estratégias aplicadas às diversas abordagens de teste na organização [6].
Nesses processos serão definidas as atividades que compreendem a criação da
política e das especificações de testes organizacionais adequadas ao contexto de
aplicações móveis em dispositivos com interação por toques. É no processo
organizacional que ocorre a coleta dos requisitos para a especificação de testes, a
partir das práticas adotadas pela organização usada nos testes de software, de
40
informações obtidas dos stakeholders [13], e informações colhidas de outros
processos e/ou projetos. Assim como a política de testes da organização também vai
sendo definida a partir dessas atividades de coleta de informações, aprimorando o
processo de testes da organização [5].
As especificações organizacionais de teste não serão detalhadas neste trabalho,
pois o mesmo tem como foco principal a definição de um processo de testes para
produto, onde o contexto organizacional já deve estar fomentado, de acordo com a
especificação adotada na norma ISO/IEC/IEEE 29119-3, onde é exemplificada a
definição dos documentos gerados nos processos de política de testes e de
especificação organizacional de teste para organizações ágeis; e tendo como base o
documento de norma ISO/IEC/IEEE 29119-2, que define a formação e interação
entre esses processos (Processo Organizacional de Politica de Testes e Processo
Organizacional de Estratégia de Testes) para determinar o processo organizacional.
3.2. Processos de Gerenciamento de Testes
Os processos de gerenciamento de testes são processos que atuam em nível de
projeto, podendo ser adaptados de acordo com a particularidade de cada projeto de
testes [22] e tem como funções o planejamento, monitoração e controle dos testes
de um projeto, também são responsáveis pela atualização do plano de testes do
projeto em questão.
Para este trabalho, cada processo de gerenciamento foi ajustado para satisfazer a
necessidade de haver menos atividades separadas, o que comprometeria a
agilidade do processo, e como a contribuição deste trabalho é gerar um processo de
testes para pequenas aplicações seguindo a norma ISO/IEC/IEEE 29119, o
enxugamento de cada processo é fundamental, pois há atividades que não serão de
fato necessárias para a execução do processo.
Nas subseções a seguir serão apresentados e detalhados os processos de
gerenciamento de testes. Na Figura 16, é apresentado o modelo de fluxo dos
processos de gerenciamento relacionado com os outros processos e são mostradas
as macro atividades de cada processo definidas para este trabalho.
41
Figura 16 – Processos de Gerenciamento de Testes
Processos
Organizacionais
de Teste
Processos de Gerenciamento de Teste
Processo de Planejamento
Processo de Conclusão
- Organizar o Planejamento
- Identificar e analisar riscos
Processo de Monitoração e Controle
- Relatório Final de Testes
- Projetar a estratégia de testes
- Desenvolver o plano de testes
- Monitorar o processo de testes
- Controlar o processo de testes
Processos de
Gerenciamento
de Teste
Fonte: Autoria Própria, 2014.
3.2.1. Planejamento de testes
O processo de planejamento de testes tem como objetivo o desenvolvimento do
plano de testes, que pode ser para o projeto como um todo ou apenas para uma
fase específica do projeto [6].
Neste trabalho, algumas atividades do processo de planejamento de testes serão
desconsideradas e outras serão fundidas para que o processo tenha um
desenvolvimento ágil, diminuindo a carga de um processo extenso que por conter
diversas atividades aninhadas, pode vir a engessar o processo e causar impacto no
planejamento.
42
A atividade de identificar contexto será absorvida pela atividade de organização do
plano de testes, pois o contexto dos testes já é definido como aplicação para
dispositivos móveis, já as atividades de riscos e mitigação de riscos são fundidas em
uma só, pois ao identificar os riscos de um projeto de aplicação móvel as ações e
ações de mitigação já serão definidas em uma mesma atividade.
As atividades correspondentes à estratégia de teste e a atividade de definição de
pessoal e cronograma são unidas à atividade de projeto da estratégia de testes,
enquanto estratégias que definem a formação do plano de testes como as atividades
de registro do plano de testes, ganho de consenso do plano de testes e
comunicação da disponibilidade do plano de testes serão substituídas pela atividade
de desenvolvimento do plano de testes, pois as atividades citadas dispensam muito
tempo e comunicação com os stakeholders quando normalmente não existe esse
tempo de espera para um projeto de pequeno porte.
Organizar o desenvolvimento do plano de testes
Essa atividade consiste em identificar os possíveis stakeholders [6] e obter com o
auxílio deles a definição das atividades, cronograma e o envolvimento dos mesmos
com o projeto.
Exemplos:

Validar com o cliente o cronograma de testes, e mantê-lo informado sobre
cada entrega do projeto;

A partir de uma pesquisa de mercado, identificar um grupo de usuários do
produto e colher uma amostragem para realização de testes de usabilidade;
Identificar e analisar riscos
Identificar todos os riscos que podem vir a impactar no desenvolvimento do projeto
de testes, e a partir desse mapeamento identificar os riscos que estão relacionados
com o teste do software. De acordo com [10] os riscos devem ser definidos de
acordo com:
43

O tamanho do produto, onde o risco do projeto é diretamente proporcional ao
tamanho do produto a ser desenvolvido ou modificado;

O
impacto
no
negócio
-
Esses
riscos
são
associados
mais
ao
desenvolvimento do produto, geralmente são levantados na fase de
planejamento do produto e já devem ter sua estratégia de contingência e
mitigação alinhada com o projeto de testes;

As características do cliente - Deve ser considerado que cada cliente tem
suas necessidades, porém este risco também deve ser levantado desde o
início do processo e o planejamento de testes não deve levar em
consideração, pois é um risco do projeto de desenvolvimento como um todo e
não apenas do projeto de testes.

A definição do processo - Se os processos definidos estão sendo ou não
utilizados, e se os processos estão causando impacto no projeto de testes e
quais impactos seriam esses.

A tecnologia a ser utilizada, - Os riscos de usar determinada tecnologia, ou
novas abordagens e técnicas se tratando de testes, podem surgir e causar
impacto no projeto;

O tamanho da experiência da equipe – O tamanho da experiência da equipe é
inversamente proporcional à severidade dos riscos apontados no projeto de
testes.
Feito o levantamento dos riscos potenciais para os testes é necessário realizar uma
análise de cada risco e classificá-los de acordo com tipo do risco e o impacto que ele
deve causar. As atividades de mapear cada risco com a ação que deve ser tomada
e caso necessário, montar uma estratégia de mitigação dos riscos é de
responsabilidade da gerencia do projeto [10] enquanto a função do projeto de testes
é de levantar e analisar os potenciais riscos.
Projetar a estratégia de testes
Esta atividade consiste em, inicialmente, estimar os recursos necessários para
implementar os requisitos definidos no processo organizacional, com o auxílio da
estratégia de testes e da política de testes.
44
A estratégia de testes apresentada neste trabalho terá o foco no produto, e como
este trabalho foi desenvolvido com a finalidade de testar um software para
dispositivos moveis de pequeno porte, a estratégia de testes será baseada no fato
de que estes aplicativos requerem um curto tempo de desenvolvimento e testes, e
que as especificações tratadas pela estratégia de testes organizacional e politicas de
teste organizacionais não serão levados em conta para a implementação desta
estratégia de testes.
A fase de testes unitários [10] não será abordada neste trabalho, o mesmo se aplica
às fases de teste de componente e teste de integração [1], a menos que a aplicação
em si defina que estas fases de testes devam ser implementadas, elas deverão
fazer parte do escopo negativo do projeto. Os testes de aceitação também não
serão abordados neste trabalho, pois esta é uma atividade do cliente ao receber o
software [1].
Quanto aos níveis de testes adotados, serão os testes de sistema, pois essa fase é
de imprescindível importância para os testes, onde nesse nível de testes que o
sistema é testado como um todo, tratando os requisitos funcionais e não funcionais
do sistema [1].
A técnica a ser adotada na estratégia de testes proposta será a técnica de testes
caixa-preta, onde a aplicação será testada sem o conhecimento do código-fonte da
aplicação, ou seja, não importa como a aplicação foi projetada e desenvolvida, a
técnica caixa-preta é usada para testar o aplicativo simulando o uso do programa
[15].
Quanto aos tipos de testes que serão adotados pela estratégia, para que o software
seja validado e verificado com eficácia, serão adotados os seguintes tipos de testes:

Funcionais, pois as funcionalidades do software devem ser garantidas e
validadas de acordo com o que foi planejado.

Configuração, para validar se o software funciona corretamente em diferentes
ambientes de hardware e software.

Instalação, pois é necessário verificar se o processo de instalação e
desinstalação é efetivo e não impacta no funcionamento de outros softwares.
45

Testes não funcionais são testes que variam também de acordo com a
necessidade do cliente e englobam testes de confiabilidade, usabilidade,
eficiência, manutenibilidade e portabilidade [23].
Quanto ao ambiente de testes, a estratégia adotada não requer muitas
especificações de ambiente, apenas de aparelhos disponíveis com rede de dados ou
sem fio configurada.
Para definir os critérios de aceitação, suspensão e continuidade de testes, é
necessário determinar esses critérios junto aos stakeholders, ao inicio do projeto,
pois dependendo do cliente, os critérios de aceitação podem ser mais flexíveis,
permitindo entregas mais rápidas, ou clientes mais rígidos, onde a verificação deve
seguir à risca os critérios determinados no contrato [10].
Desenvolver plano de testes
A atividade de desenvolvimento do plano de testes do projeto consiste em reunir as
informações obtidas anteriormente e montar o plano de testes para que seja
aprovado pelos stakeholders [6].
É importante levar em consideração que o plano de testes tem foco no produto,
porém, usualmente empresas desenvolvem seu próprio modelo de plano de testes
padrão para determinados softwares, enquanto o propósito deste trabalho é
desenvolver um processo de testes com foco no produto, formando um modelo de
plano de testes para aplicações de dispositivos moveis de pequeno porte, com o
objetivo de proporcionar a redução dos processos e agilidade entre desenvolvimento
e teste [21].
O documento do plano de testes proposto para este projeto terá como modelo o
documento de plano de testes para organizações ágeis, definido em [17], porém as
informações contidas no plano de testes serão dirigidas ao projeto de testes do
produto.
3.2.2. Monitoração e Controle
Para que este trabalho, os processos de monitoração e controle tiveram suas
atividades ajustadas de acordo com que seja satisfeita a necessidade tornar o
46
processo de testes mais ágil [21], garantindo a redução de processos, e como a
contribuição deste trabalho é gerar um processo de testes para pequenas aplicações
seguindo as definições propostas na norma ISO/IEC/IEEE 29119, o enxugamento de
cada processo é fundamental, pois a norma contempla um processo de testes
completo e haverá atividades que não serão de fato necessárias para a execução do
processo.
O processo de monitoração e controle tem como principais objetivos determinar as
medidas adequadas para verificar se o progresso dos testes está indo de acordo
com o que foi definido no planejamento e monitorar as atividades de teste, checando
se os riscos mudam ou se surgem novos riscos, essas medidas devem refletir na
atualização do plano de estratégia de testes [6].
Monitorar
Essa atividade consiste em monitorar o progresso do planejamento e implementação
dos testes do processo dinâmico, se ele está alinhado ao plano de testes, na
monitoração dos riscos que foram definidos no processo de planejamento e também
no caso de novos riscos relacionados ao projeto serem detectados, identificando
aqueles que devem ser mitigados ou levantados para os stakeholders [5].
Controlar
Na fase de controle será onde as ações correspondentes às medidas tomadas nas
atividades anteriores, ou seja, se caso o progresso de testes não está indo de
acordo com o plano de testes, deverão ser tomadas ações para que a maneira que
esteja testando o software torne a se alinhar com o planejado [6].
Nessa atividade é que deve ser estabelecido se as atividades de teste estão prontas
para serem iniciadas, checando se todos os artefatos e atividades necessários para
iniciar ou dar continuidade à atividade de teste, esses artefatos são concebidos tanto
na fase de planejamento quanto no processo dinâmico, que será mostrado no item
3.3.
E no caso de mudanças ocorridas no plano de teste, elas deverão entrar como
atualização, e deverão ser expostas aos stakeholders. Na fase de controle que se
47
verifica se os critérios de conclusão são satisfeitos, para que a decisão de conclusão
de testes seja tomada.
Ao final das atividades do processo de monitoramento e controle, as saídas obtidas
serão os seguintes artefatos:
a) O relatório de status dos testes, que consiste no resultado da execução de
um ciclo de testes ou de vários ciclos, indicando se o projeto de testes pode
passar para o processo de conclusão.
b) O documento com as diretivas de controle, que consiste no mapeamento
das mudanças no plano de testes, nos testes, riscos e outros fatores (dados
utilizados, ambiente e pessoal).
3.2.3. Conclusão
O processo de conclusão dos testes consiste em compilar os resultados obtidos nas
execuções e desenvolver o relatório final de testes, quando todas as features do
software foram cobertas e verificadas, ou seja, quando o critério de conclusão é
alcançado [6].
Nessa fase também onde é possível obter as lições aprendidas, que consistem em
identificar os pontos positivos e pontos negativos do projeto e levantar as ações que
devem ser tomadas para melhora do processo organizacional.
Relatório final de testes
Com a execução dos testes concluída, ou de um ciclo de execução concluído, o
próximo passo é relatar o processo de testes em um documento, assim que os
critérios de completude forem alcançados, e que a aplicação esteja pronta para ser
publicada para entrar em produção. Este documento é necessário para que o
cliente, ao desejar refazer uma regressão no sistema para que ele possa ser
homologado para produção, checar o que de fato foi testado e se está de acordo
com o que foi planejado inicialmente e se está cobrindo os requisitos do software
devidamente.
48
3.3. Processos dinâmicos de teste
Os processos apresentado neste trabalho tem como objetivo principal auxiliar o
projeto de testes de aplicativos desenvolvidos para dispositivos móveis com
interação através de gestos, tais como: toque simples, duplo toque, pinça, entre
outros diversos gestos de interação.
Seguindo um modelo de processo ágil de desenvolvimento, visando ter mais
agilidade no processo de teste por se tratar de pequenas aplicações, o processo de
testes foi definido com o seguinte ciclo de vida: projeto e implementação e execução
e relatório de testes. Após a exposição de cada fase do processo, será feito um
mapeamento com as atividades para cada fase do processo baseado no modelo
apresentado na norma ISO/IEC/IEEE 29119-2. A Figura 17 ilustra os processos
dinâmicos de teste.
Figura 17 – Processos Dinâmicos de Teste
Processos de
Gerenciamento de
Testes
Processos
Organizacionais de
Teste
Processos Dinâmicos de Teste
Processo de Planejamento e
Elaboração
Processo de Execução e Relatório
de Incidentes
- Estudo de Viabilidade
- Configuração do Ambiente
- Gerar Árvore de Eventos
- Criar casos de teste
- Execução e Analise dos Testes
- Relatório de Incidentes
Fonte: Autoria Própria, 2014.
3.3.1. Projeto e elaboração de testes
Esta é uma fase de extrema importância na execução de um projeto de testes e
ocorre sempre em paralelo com as outras atividades e é definida pelas seguintes
49
atividades: realizar o estudo da viabilidade, definição e configuração do ambiente de
testes, geração da arvore de eventos e a criação dos casos de teste.
Estas etapas foram definidas para que o processo de testes seja otimizado, evitando
a perda de tempo com planejamentos excessivos, já que a finalidade deste processo
é verificar e validar aplicações de dispositivos com interação por gestos que são de
pequeno porte. Caso necessário, essas atividades podem ser alteradas e
complementadas como explicado em [16].
Essa fase terá como saída os seguintes artefatos: a árvore de eventos, os casos de
teste definidos e implementados e o plano de testes atualizado, definido de acordo
com o projeto.
Estudo de viabilidade
O estudo da viabilidade consiste em avaliar o esforço para o software ser testado, ao
receber um documento de requisitos, ou na falta dele a própria aplicação pode servir
como uma entrada válida, ou com modelos de protótipos, que de acordo com [24] é
uma poderosa ferramenta para construção de GUI, que consiste em uma versão
provisória do software para que o usuário possa ter uma experiência de uso e que
também seja capaz de fornecer outros requisitos que possam ser implementados na
próxima fase ou em um protótipo posterior.
Feito o estudo de viabilidade do projeto de testes, pode surgir a necessidade de
atualizar o planejamento das atividades de teste, reavaliar os riscos e redefinir o
escopo, o esforço e recursos necessários para o projeto de testes, atualizando o
plano de testes.
Definição e configuração do ambiente de testes
A fase de definição e configuração do ambiente de testes também pode ser
executada no processo de projeto e implementação, e na abordagem definida neste
trabalho, tem como objetivo definir o ambiente necessário para a execução dos
testes, que será basicamente delimitado pela própria aplicação a ser testada, e caso
aplicável, a montagem de ambiente de testes automatizados, banco de dados,
servidores, entre outras configurações.
50
Gerar árvore de eventos
A árvore de interação consiste em um mapeamento de todas as iterações entre os
componentes da GUI que são orientados a eventos [25], ou seja, dada uma
aplicação em uso, a finalidade da árvore de eventos é realizar o mapeamento de
todas as iterações possíveis entre os componentes da interface GUI do sistema para
que os casos de teste sejam criados afim de garantir a cobertura de todos os
componentes da interface e que passe por todas as combinações dos eventos, pelo
menos uma vez.
Para gerar a árvore de interação é necessário realizar, a partir de cada tela do
aplicativo em execução, o mapeamento de cada componente que compõe a tela e
obter as relações entre os componentes da interface gráfica, que são definidas pelos
eventos que são disparados por estes componentes normalmente são disparados
por botões, check boxes, combo boxes, áreas sensíveis a gestos da aplicação,
gestos estes que podem ser os mais diversos, como toque simples, toque múltiplo
(dois ou mais pontos), pinça, toque longo, rolagem horizontal e vertical, entre outras
iterações [26], que devem ser levadas em conta na fase de criação dos casos de
teste.
Quando as telas são mapeadas e as iterações são definidas, a árvore de eventos
está pronta para que os casos de teste sejam criados. Essa etapa é muito
importante para o processo de teste, pois é nela que é definida a cobertura e se o
critério de cobertura planejado inicialmente deve ser alcançado, implicando a
realização de um novo planejamento a partir do feedback obtido nessa fase do
processo.
Caso não haja aplicação implementada e esta tenha um documento de prototipação
disponível, dependendo do grau de fidelidade do documento e se essa prototipação
já foi previamente validada com os stakeholders, é possível adiantar ou pular a
etapa de verificação das telas e interações e partir para a geração do gráfico de
fluxo de eventos e da árvore de eventos.
Para ilustrar o processo de criação de uma árvore de eventos, a Figura 18 apresenta
o resultado da derivação de uma árvore de eventos a partir de um aplicativo de
bloco de notas simples, onde só contém as seguintes funcionalidades: criar texto,
editar, salvar e apagar um registro.
51
Figura 18 – Árvore de eventos de um aplicativo de bloco de notas
Fonte: Autoria Própria, 2014.
Para que o desenvolvimento da árvore de eventos seja ágil e não cause impacto no
processo, é recomendado usar meios manuais, como um quadro branco ou papel e
caneta, para formar o esboço da árvore, e se necessário documentar através de
uma ferramenta CASE [14].
Criação de casos de teste
Tomando como entrada para essa fase os artefatos de saída gerados na fase
anterior, que são árvore de eventos e o plano de testes, junto da própria aplicação
em execução ou dos protótipos/requisitos, os casos de teste devem ser gerados,
usando o modelo descrito a seguir.
52
Cada campo da especificação de um caso de teste proposto na norma
ISO/IEC/IEEE 29119-3, será detalhado e justificado o porquê de ser desconsiderado
ou fundido a outro campo, ao ser desenvolvido para este trabalho, como mostrado
no Quadro 1.
Quadro 1 – Especificação dos campos dos casos de teste
ID
Adotando o padrão numérico crescente seguido de nome do caso de
teste , pois ele facilitará na identificação do rastreamento e relatório de
defeitos.
Objetivo
Esse campo será o mais importante da especificação dos casos de
teste, pois é nele que estarão as informações necessárias para
execução do teste, como pré-condições, dependências e deverá ser
especificado o objetivo e o cenário do teste.
Prioridade
As especificações propostas de cobertura e estratégias de testes
dispensam priorização de casos de teste devido ao porte da aplicação.
Rastreabilidade
A rastreabilidade não é um campo de extrema importância devido às
aplicações testadas ser de pequeno porte e os seus defeitos poderão
ser facilmente rastreados.
Pré-condições
Este campo poderá ser utilizado, porem será unido ao campo ‘Objetivo’,
porque em certas condições ele pode não ser de fato necessário.
Entradas
Este campo poderá ser utilizado, porem será unido ao campo ‘Objetivo’,
porque em certas condições ele pode não ser de fato necessário.
Resultados Esperados
Campo que define qual será a saída ou comportamento esperado do
teste, que será comparado ao resultado obtido na execução do mesmo.
Resultado Real e
Este campo não é deveras útil para a proposta do trabalho, pois se ele
Resultado de Teste
for removido não irá impactar na execução ou resultado dos casos de
teste.
Fonte: Autoria Própria, 2014.
O modelo de caso de teste definido pela norma ISO/IEC/IEEE 29119-3 é tomado
como base para o desenvolvimento do modelo de caso de teste apresentado nesta
abordagem, porém, para garantir a agilidade e fluidez do processo de especificação,
53
alguns campos que compõem o modelo de caso de teste foram desconsiderados,
porém a testabilidade ainda é garantida, pois a remoção destes campos não irá
impactar na execução dos testes. Como saída desse processo se obtém a
especificação dos casos de testes, que neste trabalho poderá ser um anexo, ou
compor o plano de testes.
3.3.2. Execução e relatório de incidentes
Esta fase do processo de testes é de grande importância para este trabalho, pois é
nessa fase que é sugerida a abordagem proposta no mesmo, que consiste em uma
serie de atividades que irão validar a proposta os casos de teste e cenários de teste
para que o software seja validado.
Para que o processo dinâmico de testes atenda aos requisitos desejáveis para um
processo ágil, como foi definido em [21] que uma característica de um processo ágil
é a diminuição de processos, foi identificado que, como a aplicação a ser testada
necessita de um feedback rápido e coerente, os processos de execução e relatório
de testes definidos em [6] foram unificados e suas atividades reorganizadas,
atendendo a essa premissa do manifesto ágil. As atividades do processo de
execução e relatório sessão discutidas a seguir.
Execução e análise de testes
A fase de execução consiste basicamente na execução das atividades de teste
planejadas anteriormente, em que o software em questão é devidamente testado,
executando os testes, os resultados dos testes são comparados e é gerado o
relatórios de incidentes de teste, que encontra-se no apêndice deste trabalho.
O processo de execução é iniciado quando uma versão de teste é liberada pelos
responsáveis pelo desenvolvimento do software. Os testes que foram gerados no
processo de planejamento e implementação de testes são executados e os
resultados destes testes são comparados aos resultados esperados definidos nos
casos de teste.
Os testes devem ser executados em forma de ciclo, ou seja, de acordo com [6] os
testes podem ser interrompidos a qualquer momento por fatores, como defeitos
54
críticos que impeçam a continuidade dos testes ou uma nova versão intermediaria
ser lançada, por exemplo; e podem vir a executar varias vezes até que o resultado
dos testes satisfaça os critérios de aceitação, que são definidos no momento que o
cliente fecha o contrato com a equipe de testes.
A partir dos resultados obtidos na execução dos testes, é feita uma analise desses
resultados dos testes [6], para descobrir se um incidente encontrado na execução do
ciclo atual é um bug e se já está documentado por outros ciclos ou pelos
desenvolvedores, e se caso não for um bug conhecido, identificar o cenário em que
ele ocorre e rastrear o incidente, categorizando ele no relatório de incidentes como
incidente ou defeito.
Criar/atualizar o documento de relatório de incidentes
Concluídas as etapas anteriores de execução dos testes, onde os testes já foram
executados, analisados e tiveram seus incidentes categorizados, a última fase do
processo tem como finalidade relatar e documentar todos os incidentes encontrados
na execução do ciclo de testes. Os incidentes relatados devem ser compilados em
um documento para que os desenvolvedores e outros envolvidos tenham um retorno
sobre o problema encontrado e que possam decidir qual ação será tomada referente
a este bug [8], criando, ou caso já exista uma versão do documento criada,
atualizando o relatório de incidentes.
O documento de relatório de incidentes para organizações ágeis, apresentado em
[17], será seguido como modelo para a formação do relatório de incidentes proposto
neste trabalho, pois esse modelo entra em conformidade com o objetivo deste
trabalho, que é documentar os incidentes encontrados de uma forma rápida e de
fácil entendimento.
Com o relatório criado, é sinalizado que a execução de um ciclo de testes foi
concluída com sucesso. O relatório de testes é então analisado pelo responsável
pelo processo de monitoração e controle que tomará as providencias para que os
incidentes encontrados sejam resolvidos e novos ciclos de teste venham a ser
executados.
55
4. VALIDAÇÃO DO PROCESSO DE TESTES
Este capítulo tem como objetivo validar a proposta deste trabalho, que consiste em
apresentar um processo de testes de software para aplicações de dispositivos
móveis de pequeno porte com base nos princípios da agilidade [21], visando a
melhoria da qualidade do software.
4.1. Contextualização
Para validar a proposta deste trabalho, foi criado um cenário, onde é realizado um
projeto de testes para uma aplicação destinada a dispositivos móveis. As respectivas
informações a respeito deste cenário serão especificadas a seguir.
A organização responsável pelo projeto de testes em questão é uma startup [27]
formada por um time de estudantes universitários, uma empresa que está com o
modelo de negócios em fase de afirmação, no entanto não possui um processo de
testes definido de acordo com padrões internacionais, porém isso não quer dizer que
ela não possa implementar um processo para melhorar a qualidade dos seus testes.
A estratégia de testes organizacional e politica de testes organizacional adotadas
pela organização seguirão o modelo proposto para organizações ágeis em [17].
A empresa solicitante, em reunião com a equipe define o como será o aplicativo: um
gerenciador de gastos, rodando na plataforma móvel Android [28], onde o usuário
pode definir um limite para seus gastos e armazená-los de acordo com o tipo, se foi
em dinheiro, credito ou debito; detalhando a data e o local; o usuário poderá
acompanhar seus gastos a qualquer momento. O fluxo de telas, capturadas do
próprio aplicativo encontra-se no apêndice.
Como explicado na seção 2.1, é necessário definir critérios de aceitação com os
stakeholders para que sejam obtidas métricas para o processo de testes. Na reunião
de fechamento de contrato, é definido que o projeto terá uma duração de 5 dias por
ciclo de execução e os critérios de aceitação também são definidos, onde o cliente
solicita que o critério de aceitação será 98% de todos os testes funcionais tendo
status como ‘aprovado’ e que os 2% dos testes que não foram aprovados não
causem impactos na execução do software, que o aplicativo execute em pelo menos
56
três resoluções diferentes [29] e que execute nas plataformas mais recentes do
sistema [30].
Os riscos definidos no contrato são: O prazo de entrega, que por ser curto, deve ser
otimizado; O cliente solicitar mudança de requisitos, o que pode implicar em um
replanejamento do projeto e o aplicativo não funcionar em determinados aparelhos,
visto que a plataforma em que será desenvolvido tem uma grande gama de
aparelhos com diferenças de hardware [31].
Outros aspectos do projeto como custos e recursos, pessoal, riscos externos e a
nível organizacionais, cronogramas e estimativas de desenvolvimento, entre outros
aspectos gerenciais, não entrarão em mérito na execução deste estudo de caso, que
se restringe a testes de software, porem eles devem ser levados em conta, pois
indiretamente influenciarão na execução do projeto.
4.2. Execução do processo
Para a execução de um ciclo de testes, que deve durar 5 dias, foi montado um
cronograma, como mostrado no Figura 19, onde está especificado o planejamento
de um ciclo de testes, e para cada instancia de testes dinâmicos, o cronograma deve
ser atualizado, adicionando a quantidade de dias e as atividades referente à este
novo ciclo.
Como o projeto de testes é um projeto distinto do projeto de desenvolvimento e deve
ocorrer em paralelo durante o ciclo de desenvolvimento do software [6], desde o
inicio do projeto o engenheiro de testes, encarregado de montar o plano de testes,
deve começar a desenvolvê-lo, com base nas especificações da politica
organizacional, estratégia organizacional e com as especificações definidas pelo
cliente, usando o modelo definido neste trabalho, os campos são preenchidos de
acordo com a necessidade e requerimentos do projeto.
Quanto à estratégia de testes deste ciclo, será adotada a especificação da estratégia
de testes proposta na subseção 3.2.1, aplicando testes funcionais utilizando a
técnica caixa-preta. De acordo com o que foi definido em [17], a estratégia de testes
pode ser documentada como parte do plano de testes, e os casos de testes
gerados, serão documentados também como parte do plano de testes, garantindo a
57
redução de documentos [21], para que esses proporcionem a possibilidade de testes
de regressão.
Figura 19 – Cronograma do projeto de testes
Ciclo
Ciclo 1
ID dos dias
1
2
3
4
5
Atividade por processo
Organizarr o desenvolvimento do plano de testes
Identificar e analisar riscos
Projetar a estrategia de testes
Desenvolver plano de testes
Monitoração e controle
Processo de conclusão
Estudo de Viabilidade
Configuração do Ambiente
Gerar Árvore de Eventos
Criar casos de teste
Execução e analise dos testes
Relatorio de incidentes
Fonte: Autoria Própria, 2014.
A partir das informações obtidas nos processos anteriores, o próximo passo é
realizar o planejamento e implementação dos testes. O primeiro passo é dispor da
aplicação e realizar o mapeamento das interações entre os componentes GUI e
gerar a arvore de eventos, que é demonstrada na Figura 20. O próximo passo é
começar a criação dos casos de teste, realizando a cobertura de todas as iterações
entre os componentes, garantindo que o critério de cobertura de todos os eventos
disparados por estes componentes sejam invocados ao menos uma vez.
58
Figura 20 – Árvore de eventos derivada da aplicação em uso
Fonte: Autoria Própria, 2014.
59
Quanto aos tipos de teste adotados na estratégia, a prioridade do ciclo é testar as
funcionalidades principais do sistema, a partir da árvore de eventos são gerados os
casos de teste relativos às funções fundamentais, como registrar gastos nas
modalidades disponíveis; visualizar a lista de gastos; ativar, desativar e alterar o
limite de gastos e remover um registro de gastos.
Como exemplo de formação de um grupo de casos de teste, usaremos a
funcionalidade registrar um gasto na modalidade crédito. A figura 21 mostra o
mapeamento da função isolada da árvore de eventos.
Figura 21 – Fluxo da função inserir valor
Fonte: Autoria Própria, 2014.
A partir da função extraída da árvore, deve ser derivado em primeiro lugar o caso de
teste do ‘caminho feliz’, onde o testador realiza os passos para gerar o registro de
um gasto com sucesso. Este será o caso de teste base para a geração dos próximos
casos de teste e esta estratégia será tomada a partir de todas as funcionalidades
principais do software.
O quadro a seguir mostra o caso de teste para a função inserir valor, onde o usuário
deve selecionar o campo, inserir um valor válido, confirmar e verificar se o valor
persiste no campo após a confirmação.
Quadro 2 – Caso de teste da função inserir valor
ID: CT-001 – Inserir valor válido
Objetivo: realizar a função de inserir um dado valido no campo
valor.
Pré-condições: N/A
Entradas: N/A
Resultado esperado: O valor deve persistir no campo após a
confirmação da tarefa.
Fonte: Autoria Própria, 2014.
60
Os próximos casos de teste podem ser derivados para a validação de dados
inválidos inseridos em um campo, testando valores positivos, negativos, valores
limite e com formatação diferente do esperado. Para cada campo que possa receber
um valor ou dado deve haver um caso de teste com as diretivas necessárias para
sua execução, não se deve generalizar nestes testes validando vários campos de
uma vez, pois isso poderá dificultar no rastreamento de incidentes e na priorização
quando houver um ciclo de regressão.
Quando a fase de planejamento e implementação obter testes suficientes para que
critérios de cobertura sejam satisfeitos e já tenha sido gerada uma quantidade
considerável de casos de teste, a execução já pode ser preparada, onde o ciclo de
execução é gerado e os testes que foram preparados são dispostos para execução,
aonde a cada execução o documento de relatório vai sendo alimentado, com
informações colhidas e os resultados obtidos no decorrer da execução dos testes.
Novos casos de testes podem surgir durante a fase de execução e devem ser
documentados no plano de testes e adicionados ao ciclo, verificando também se
esses casos de testes irão impactar no cronograma e execução dos testes. Ao final
da execução de cada ciclo de testes, o relatório de incidentes e sumario de testes
são alimentados com as informações e resultados dos testes executados, estes
documentos gerados encontram-se no apêndice deste trabalho.
Feita a execução e preparado o relatório de incidentes e sumario de testes, o
próximo passo é a validação das correções apontadas no documento de incidentes,
de forma que, se houver tempo disponível para uma nova execução, validar que as
alterações feitas não causaram impacto em outras partes do sistema, um ciclo de
regressão com os mesmos testes deve ser preparado e executado completamente e
se, caso não haja tempo hábil, é necessário realizar uma priorização dos casos de
teste a serem reexecutados, dando preferencia aos que falharam e aos que podem
ter sofrido algum tipo de impacto pelas alterações.
Quando o processo de execução é concluído, não necessariamente foi porque
nenhum bug foi encontrado, pois segundo [7] é impossível testar exaustivamente
qualquer software, e sim porque os critérios de aceitação foram alcançados com
sucesso e o software já está disponível para ser publicado para os usuários finais.
61
É altamente recomendado ao cliente que realize testes de aceitação [8] para validar
se o software está de acordo com o planejado e se o projeto de testes foi bem
sucedido ou não. Também são reunidos todos os entregáveis e repassados como
versão final para o cliente e este também deve validar os documentos entregues,
apontando para a equipe de testes se o processo foi satisfatório e se não, as causas
apontadas pelo cliente.
Também pode ser feita uma analise do processo, levantando os pontos positivos e
as possibilidades de melhoria, apontando o que foi proveitoso, o que poderia ser
desenvolvido e sugestões de melhorias para o próximo projeto.
4.3. Resultados obtidos
O resultado do experimento de validação do processo de teste proposto neste
trabalho testes foi satisfatório e mostra que o emprego do processo de testes no
projeto de testes para um aplicativo de pequeno porte desenvolvido para dispositivos
móveis é mais efetivo que testes ad hoc, pois além de garantir uma cobertura maior,
possibilita o rastreio dos defeitos e possibilitam que testes de regressão sejam
executados mais facilmente, pois os testes gerados já estão documentados e
também tem o apoio do relatório de incidentes para priorizar o ciclo de regressão.
62
5. CONSIDERAÇÕES FINAIS
Este trabalho apresentou uma solução para aplicação de processo de testes de
software para aplicativos de pequeno porte de dispositivos móveis. A proposta
apresentada foi satisfatória e pode se concluir que a adoção de um processo de
testes é eficaz quando gerada de acordo com a necessidade do projeto, no caso
deste trabalho, visando a agilidade nos processos e na execução dos testes.
A principal contribuição deste trabalho foi divulgar o novo padrão internacional de
testes de software, onde foi desenvolvido um processo genérico, para que
organizações adotem um processo de testes para a melhoria da qualidade tanto do
processo organizacional, quanto dos produtos desenvolvidos pela organização.
O objetivo geral deste trabalho foi alcançado e mostra que o emprego do processo
de testes no projeto de testes para um aplicativo de pequeno porte desenvolvido
para dispositivos móveis é mais efetivo que testes ad hoc, pois além de garantir uma
cobertura maior, possibilita o rastreio dos defeitos e possibilitam que testes de
regressão sejam executados mais facilmente, pois os testes gerados já estão
documentados e também tem o apoio do relatório de incidentes para priorizar o ciclo
de regressão.
Os objetivos específicos propostos neste trabalho foram alcançados, pois foi
possível padronizar a execução de testes através do processo e da estratégia de
testes propostos, garantir a melhoria do processo devido à maior cobertura de testes
do aplicativo e a reduzir os custos, pois o processo é reutilizável.
5.1 Trabalhos Futuros
Como o tema de validação e verificação é bastante amplo e proporciona diversas
frentes de pesquisa, há uma série de aspectos que podem ser abordados a fim de
complementar a pesquisa proposta nesse trabalho.
Em virtude do escopo definido para o desenvolvimento deste trabalho, alguns pontos
importantes tiveram que ficar para trabalhos futuros como: Documentação para o
processo de testes, pois há uma parte da norma ISO/IEC/IEEE 29119 que trata
63
exclusivamente de documentação de testes; testes não funcionais e outras técnicas
de teste, que podem ser explorados com a publicação da quarta parte da
ISO/IEC/IEEE 29119; automação de testes, que é um campo de pesquisa que vem
ganhando espaço na área de testes de software e também abordando novas
estratégias de teste.
Como este trabalho foi proposto para um alvo especifico de software, que são
dispositivos móveis, outra sugestão para trabalhos futuros seria validar o processo
em outros ecossistemas e também em plataformas diferentes, assim como
desenvolver novos processos com base na ISO/IEC/IEEE 29119 para cada tipo de
software.
64
REFERENCIAS
[1] MYERS, G. J.;; SANDLER, C. e BADGETT, T. The Art of Software Testing. 3.
ed. [S.l.]: John Wiley & Sons, 2012. p. 256
[2] ABINEE. Smartphones puxam desempenho do segmento de
Telecomunicações. Disponível em: <http://www.abinee.org.br/noticias/com88.htm>.
Acesso em: 27 maio. 2014.
[3] ABINEE. Smartphones já representam 65% do mercado de celulares no país.
Disponível em: <http://www.abinee.org.br/noticias/com246.htm>. Acesso em: 27
maio. 2014.
[4] TWENEY, D. MOBILE APP GROWTH EXPLODING, AND THIS SHOWS NO
SIGNS OF LETTING UP. Disponível em: <http://venturebeat.com/2013/07/10/stateof-the-apposphere/#tkvSv0DbkuURQJUt.99>. Acesso em: 27 maio. 2014.
[5] LISKAUKAS, S. “Pressa” é vilã na qualidade dos aplicativos móveis
brasileiros. Disponível em:
<http://convergenciadigital.uol.com.br/cgi/cgilua.exe/sys/start.htm?infoid=33949&sid=
17#.U13qv_ldWSo>. Acesso em: 27 abr. 2014.
[6] INTERNATIONAL STANDARD ISO / IEC / IEEE Software and systems
engineering — Part 2: Test processes. . Geneva: [s.n.], 2013.
[7] INTERNATIONAL STANDARD ISO / IEC / IEEE Software and systems
engineering — Part 1: Concepts and definitions. . Geneva: [s.n.], 2013.
[8] INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD (ISTQB).
Certified Tester Foundation Level Syllabus. Disponível em:
<http://www.istqb.org/downloads/viewdownload/16/15.html>. Acesso em: 27 abr.
2014.
[9] RIOS, E. e MOREIRA, T. Teste de software. [S.l.]: Alta Books, 2006. p. 222
[10] PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional.
Tradução Mario Moro Fecchio Ariovaldo Gressi. 7. ed. Porto Alegre: AMGH Editora,
2012. p. 780
[11] SOMMERVILLE, I. Engenharia de software. Tradução Selma Shin Shimizu
Melnikoff; Reginaldo Arakaki; Edilson de Andrade Barbosa. 8. ed. [S.l.]: ADDISON
WESLEY BRA, 2007. p. 568
[12] ISTQB. Standard glossary of terms used in Software Testing. . [S.l: s.n.],
2014.
[13] FREEMAN, R. E. Strategic Management: A Stakeholder Approach. Illustrada
ed. [S.l.]: Cambridge University Press, 2010. p. 292
[14] KUHN, D. L. Selecting and effectively using a computer aided software
engineering tool. [S.l: s.n.], 1989. .
[15] PAGE, A.;; JOHNSTON, K. e ROLLISON, B. How We Test Software at
Microsoft. Redmond: Microsoft Press, 2009. p. 448
[16] IEEE. IEEE Standard for Software and System Test Documentation. . New
York: IEEE-SA Standards Board, 2008.
65
[17] INTERNATIONAL STANDARD ISO / IEC / IEEE Software and systems
engineering — Part 3: Test documentation. . Geneva: [s.n.], 2013.
[18] ISO/IEC/IEEE 29119-4: Test Techniques. Disponível em:
<http://www.softwaretestingstandard.org/part4.php>. Acesso em: 27 maio. 2014.
[19] ISO/IEC/IEEE 29119-5: Keyword-Driven Testing. Disponível em:
<http://www.softwaretestingstandard.org/part5.php>. Acesso em: 24 maio. 2014.
[20] DRINKWATER, D. Businesses too slow to deploy mobile apps, but there’s
hope for the future: study. Disponível em: <http://tabtimes.com/news/ittech-statsresearch/2013/01/25/businesses-too-slow-deploy-mobile-apps-there-hope-futurestudy>. Acesso em: 27 abr. 2014.
[21] BECK, K. et al. Manifesto for Agile Software development. Disponível em:
<http://agilemanifesto.org/>. Acesso em: 28 abr. 2014.
[22] KASURINEN, J. Advances in Computers. In: MEMON, A. (Ed.). Advances in
Computers: Volume 85. 1. ed. Lappeenranta, Finland: Academic Press, 2012. v. 4p.
1–63.
[23] ABNT. NBR ISO/IEC 9126 Engenharia de software - Qualidade de produto
Parte 1 : Modelo de qualidade. . Rio de janeiro: [s.n.], 2003.
[24] REHMAN, T. U.;; KHAN, M. N. A. e RIAZ, N. Analysis of Requirement
Engineering Processes, Tools/Techniques and Methodologies. International Journal
of Information Technology and Computer Science, v. 5, n. 3, p. 40–48,
doi:10.5815/ijitcs.2013.03.05, 2013.
[25] MEMON, A. M.;; SOFFA, M. Lou e POLLACK, M. E. Coverage criteria for GUI
testing. In: ESEC/FSE-9: PROCEEDINGS OF THE 8TH EUROPEAN SOFTWARE
ENGINEERING CONFERENCE HELD JOINTLY WITH 9TH ACM SIGSOFT
INTERNATIONAL SYMPOSIUM ON FOUNDATIONS OF SOFTWARE
ENGINEERING. Anais... New York, NY, USA: ACM Press, 2001.
[26] GOOGLE. Gestures. Disponível em:
<http://developer.android.com/design/patterns/gestures.html>. Acesso em: 10 maio.
2014.
[27] BLANK, S. Search versus Execute. Disponível em:
<http://steveblank.com/2012/03/05/search-versus-execute/>. Acesso em: 28 abr.
2014.
[28] GOOGLE. Android, the world’s most popular mobile platform. Disponível
em: <http://www.android.com/>. Acesso em: 6 maio. 2014.
[29] GOOGLE. Supporting Multiple Screens. Disponível em:
<http://developer.android.com/guide/practices/screens_support.html>. Acesso em: 28
abr. 2014.
[30] GOOGLE. Supporting Different Platform Versions. Disponível em:
<http://developer.android.com/training/basics/supporting-devices/platforms.html>.
Acesso em: 28 abr. 2014.
[31] GOOGLE. Device Compatibility. Disponível em:
<http://developer.android.com/guide/practices/compatibility.html>. Acesso em: 28 abr.
2014.