UNIVERSIDADE DE SAO PAULO
ESCOLA DE ARTES, CIENCIAS E HUMANIDADES
PROGRAMA DE POS-GRADUACAO EM SISTEMAS DE INFORMACAO
SERGIO LUIS BARBIERI
Teste de software na industria: Um estudo qualitativo
Sao Paulo
2018
SERGIO LUIS BARBIERI
Teste de software na industria: Um estudo qualitativo
Versao original
Dissertacao apresentada a Escola deArtes, Ciencias e Humanidades da Uni-versidade de Sao Paulo para obtencao dotıtulo de Mestre em Ciencias pelo Programade Pos-graduacao em Sistemas de Informacao.
Area de concentracao: Metodologia eTecnicas da Computacao
Orientador: Prof. Dr. Marcos Lordello Chaim
Sao Paulo
2018
Autorizo a reprodução e divulgação total ou parcial deste trabalho, por qualquer meio
convencional ou eletrônico, para fins de estudo e pesquisa, desde que citada a fonte.
CATALOGAÇÃO-NA-PUBLICAÇÃO
(Universidade de São Paulo. Escola de Artes, Ciências e Humanidades. Biblioteca) CRB 8 - 4936
Barbieri, Sérgio Luis Teste de software na indústria : um estudo qualitativo / Sérgio
Luis Barbieri ; orientador, Marcos Lordello Chaim. – 2018. 76 f. : il
Dissertação (Mestrado em Ciências) - Programa de
Pós-Graduação em Sistemas de Informação, Escola de Artes, Ciências e Humanidades, Universidade de São Paulo.
Versão original
1. Desenvolvimento de software. 2. Teste e avaliação de software. I. Chaim, Marcos Lordello, orient. II. Título
CDD 22.ed.– 005.12
Dissertacao de autoria de Sergio Luis Barbieri, sob o tıtulo “Teste de software naindustria: Um estudo qualitativo”, apresentada a Escola de Artes, Ciencias e Huma-nidades da Universidade de Sao Paulo, para obtencao do tıtulo de Mestre em Cienciaspelo Programa de Pos-graduacao em Sistemas de Informacao, na area de concentracaoMetodologia e Tecnicas da Computacao, aprovada em de de
pela comissao julgadora constituıda pelos doutores:
Prof. Dr.
Instituicao:
Presidente
Prof. Dr.
Instituicao:
Prof. Dr.
Instituicao:
Prof. Dr.
Instituicao:
Dedico o meu trabalho de conclusao para a minha famılia que me apoiou nessa nova
jornada.
Agradecimentos
Gostaria de agradecer primeiramente ao meu orientador, Prof. Dr. Marcos Lordello
Chaim, por ter abracado o meu projeto desde o inıcio e me auxiliado no desenvolvimento
do mesmo. Quero tambem agradecer aos meus colegas de sala de aula, de profissao e demais
professores que muito contribuıram na minha formacao. E, por fim, um agradecimento
especial a minha filha Marcella Barbieri que me ajudou quando precisei.
Resumo
BARBIERI, Sergio Luis. Teste de software na industria: Um estudo qualitativo.2018. 76 f. Dissertacao (Mestrado em Ciencias) – Escola de Artes, Ciencias eHumanidades, Universidade de Sao Paulo, Sao Paulo, 2018.
Em projetos de desenvolvimento a qualidade do produto de software e fundamental para oseu sucesso. Uma das etapas que busca garantir a qualidade do produto final e a validacao,verificacao e teste (VV&T). O teste e uma das atividades chave de VV&T realizada paragarantir a qualidade. Tecnicas de teste foram desenvolvidas para verificar e validar tantorequisitos funcionais como nao funcionais. Alem disso, essas tecnicas sao aplicadas nasorganizacoes por meio de estrategias que definem os tipos de teste que serao realizados,a ordem de realizacao, a sua automatizacao e a frequencia de ocorrencia. Uma questaoimportante e verificar como essa atividade e realizada na industria de software, comoessas tecnicas sao utilizadas e a sua adocao em organizacoes desenvolvedoras de software.Este trabalho apresenta uma pesquisa qualitativa da atividade de teste. Ela utilizou atecnica teoria fundamentada aplicada em cinco empresas desenvolvedoras de software paraestabelecer uma teoria da atividade de teste. Foram realizadas entrevistas com gestoresde teste das empresas e, a partir dessas entrevistas, foi desenvolvido uma teoria sobre aorganizacao da atividade de teste. Nesta teoria, observou-se que a estrutura organizacionaldireciona a escolha das tecnicas e ferramentas, bem como o tipo do sistema; o prazo eorcamento condicionam a utilizacao de tecnicas de automatizacao.
Palavras-chaves: Teste de software. Atividade de teste. Teoria fundamentada. Estudoqualitativo. Estudo de caso na industria.
Abstract
BARBIERI, Sergio Luis. Software testing at industrial settings: A qualitative study.2018. 76 p. Dissertation (Master of Science) – School of Arts, Sciences and Humanities,University of Sao Paulo, Sao Paulo, 2018.
In development projects the quality of the software product is critical to its success. One ofthe steps that enforces the quality of the final product is validation, verification and testing(VV&T). Testing is one of the key VV&T activities to ensure quality. Testing techniqueswere developed to verify and validate both functional and non-functional requirements.In addition, these techniques are applied in organizations using strategies that define thetesting techniques that will be performed, the order of application, their automation andthe frequency of occurrence. An important issue is to verify how testing is carried outin the software industry, how these techniques are used and their adoption in industrialsettings. This work presents a qualitative research of the testing activity. It used thegrounded theory technique applied in five software development organizations to establisha model of the testing activity. Interviews were conducted with testing managers and, fromthese interviews, an organizational theory of the testing activity was developed. In thistheory, it was observed that the organizational structure directs the choice of techniquesand tools, as well as the type of the system; project schedule and budget limit the use ofautomation techniques.
Keywords: Software testing. Testing activity. Grounded theory. Qualitative study. Industrialcase study.
Lista de figuras
Figura 1 – Programa exemplo calcularMDC . . . . . . . . . . . . . . . . . . . . . 19
Figura 2 – Mapeamento de linhas para nos do programa exemplo calcularMDC . . 27
Figura 3 – Grafo de fluxo de controle do metodo cacularMDC() . . . . . . . . . . 28
Figura 4 – Processo de pesquisa teoria fundamentada . . . . . . . . . . . . . . . . 49
Figura 5 – Teoria resultante da analise dos dados . . . . . . . . . . . . . . . . . . 55
Figura 6 – Modelo organizacional . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 7 – Modelo e estrutura do projeto . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 8 – Abordagem de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 9 – Classe de teste do metodo calcularMDC . . . . . . . . . . . . . . . . . 68
Figura 10 – Cobertura de complexidade utilizando a EclEmma/JaCoCo . . . . . . 69
Figura 11 – Cobertura de instrucoes utilizando a EclEmma/JaCoCo . . . . . . . . 70
Figura 12 – Cobertura de ramos utilizando EclEmma/JaCoCo . . . . . . . . . . . . 70
Figura 13 – Resumo da analise de cobertura realizada pela EclEmma/JaCoCo . . . 71
Figura 14 – Analise de cobertura realizada pela EclEmma/JaCoCo no codigo fonte 72
Figura 15 – Trecho de codigo para cobertura de 100% do metodo calcularMDC . . 72
Lista de quadros
Quadro 1 – Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Quadro 2 – Guia Entrevista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Quadro 3 – Empresas participantes x segmento . . . . . . . . . . . . . . . . . . . 53
Quadro 4 – Profissional x Experiencia . . . . . . . . . . . . . . . . . . . . . . . . . 53
Quadro 5 – Conceitos e categorias . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Lista de tabelas
Tabela 1 – Conjunto de casos de teste . . . . . . . . . . . . . . . . . . . . . . . . . 21
Tabela 2 – Possıvel conjunto de requisitos de teste estabelecidos pelo criterio base-
ado em complexidade para o programa exemplo. . . . . . . . . . . . . . 29
Tabela 3 – Requisitos de teste estabelecidos pelos criterios todos os nos e todos os
ramos para o programa exemplo. . . . . . . . . . . . . . . . . . . . . . 29
Lista de abreviaturas e siglas
IDE Integrated Development Environment
PLUGIN Componente externo incorporado a um programa
IEEE Institute of Electrical and Electronics Engineers
API Application Programming Interface
TDD Test-driven development
Sumario
1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 Estrutura desse projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1 Engano, defeito, erro, falha e caso de teste . . . . . . . . . . . . . . . 18
2.1.1 Engano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.2 Defeito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3 Erro ou infeccao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.4 Falha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.5 Caso de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Teste de software no desenvolvimento de software . . . . . . . . . . . 21
2.3 Estrategias de testes de software . . . . . . . . . . . . . . . . . . . . . 23
2.3.1 Testes de unidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 Testes de integracao . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.3 Testes de regressao . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.4 Testes de aceitacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Tecnicas de requisitos funcionais de software . . . . . . . . . . . . . . 24
2.4.1 Tecnicas caixa preta . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.2 Tecnicas caixa branca . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.3 Analise de fluxo de controle . . . . . . . . . . . . . . . . . . . . . . 26
2.4.4 Conceitos de fluxo de controle . . . . . . . . . . . . . . . . . . . . . 26
2.4.5 Criterios Baseados em Fluxo de Controle . . . . . . . . . . . . . . . 26
2.5 Teste de requisitos nao funcionais . . . . . . . . . . . . . . . . . . . . 29
2.5.1 Teste de desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.2 Teste de usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.3 Teste de seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6 Automatizacao do teste de software . . . . . . . . . . . . . . . . . . . 31
2.7 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Teste de software e teoria fundamentada . . . . . . . . . . . . . . . . 33
3.2 Selecao dos trabalhos . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Descricao dos trabalhos selecionados . . . . . . . . . . . . . . . . . . . 34
3.3.1 Teste durante e ao final do desenvolvimento . . . . . . . . . . . . . 34
3.3.2 Atividades de teste em empresas . . . . . . . . . . . . . . . . . . . 35
3.3.3 Atividades de teste e metodos ageis . . . . . . . . . . . . . . . . . . 37
3.3.4 Teste de aplicativos plugin . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.5 Melhoria da qualidade de software . . . . . . . . . . . . . . . . . . 38
3.3.6 Uso de teoria fundamentada em teste de software . . . . . . . . . . 39
3.3.7 Complexidade do teste . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.8 Testes de seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Procedimentos metodologicos . . . . . . . . . . . . . . . . . . . 42
4.1 Coleta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Codificacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.1 Codificacao aberta . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2 Codificacao axial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.3 Codificacao seletiva . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1 Projeto para coleta de dados . . . . . . . . . . . . . . . . . . . . . . 49
4.3.2 Analise de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5 Resultados do estudo qualitativo . . . . . . . . . . . . . . . . . . 52
5.1 Descricao do processo de selecao das empresas e dos indivıduos entre-
vistados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Descricao do processo de coleta de dados . . . . . . . . . . . . . . . . 53
5.3 Descricao do processo de analise de conteudo . . . . . . . . . . . . . . 53
5.4 Resultados da analise de conteudo . . . . . . . . . . . . . . . . . . . . 54
5.4.1 Modelo organizacional . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4.2 Modelo e estrutura do projeto . . . . . . . . . . . . . . . . . . . . . 56
5.4.3 Abordagem de teste . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.5 Teoria resultado da aplicacao da analise fundamentada . . . . . . . . 61
5.6 Ameacas a validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.7 Consideracoes finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1 Sıntese do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Referencias1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Apendice A – Utilizacao da ferramenta JaCoCo . . . . . . . . 68
A.1 Relatorios Gerados e Analise dos Dados Produzidos . . . . . . . . . . 69
Apendice B – Termo de consentimento livre e esclarecido . . 73
1 De acordo com a Associacao Brasileira de Normas Tecnicas. NBR 6023.
15
1 Introducao
A qualidade no desenvolvimento de software e fundamental para o sucesso de um
projeto, tanto na concepcao do produto como nas atividades de manutencao e desenvolvi-
mento de novas funcionalidades. A qualidade esta fortemente relacionada ao atendimento
dos requisitos do projeto por meio de artefatos gerados com exatidao e com confiabilidade
(MATHUR, 2009).
Dentro do ciclo de desenvolvimento, a atividade de teste e realizada para garantir o
comportamento do software conforme o esperado (MATHUR, 2009). A atividade de teste
pode ser dividida a grosso modo em teste de requisitos funcionais e nao funcionais. Ha
diferentes tipos de teste desses requisitos, bem como estrategias para sua realizacao.
Exemplos de tecnicas de teste de requisitos funcionais sao as tecnicas caixa preta e
caixa branca (DELAMARO M. E.; MALDONADO, 2007). O teste caixa preta baseia-se
na observacao do resultado da saıda conforme a entrada de dados; ela e tambem conhecida
como “tecnica funcional” porque deriva seus requisitos de teste a partir dos requisitos
e funcoes do sistema. Essa tecnica muitas vezes e inviabilizada em funcao das infinitas
possibilidades combinatorias dos dados de entrada (MYERS G. J.;SANDLER, 2004).
A tecnica caixa branca, tambem chamada de “tecnica estrutural”, por sua vez,
utiliza a implementacao para determinar o que deve ser testado. Essa tecnica e utilizada de
duas maneiras: para criar novos casos de teste e para avaliar um conjunto de casos de teste
existente. Para tanto, utiliza criterios baseados em cobertura de codigo para determinar os
requisitos de teste, isto e, o que deve ser testado, e tambem se esses requisitos de teste sao
verificados por um conjunto de casos de teste ja existente.
Exemplos de requisitos de teste de tecnicas estruturais sao: executar todas as linhas
de um programa ou todas as saıdas dos comandos de transferencia de fluxo de controle (e.g.,
if, while, for) ao menos uma vez. Os criterios de teste estruturais tem por objetivo definir
quais estruturas devem ser exercitadas pelos casos de teste. Eles sao tambem metricas
para avaliar se o teste esta adequado (MATHUR, 2009).
As tecnicas descritas acimas foram criadas para validar os requisitos funcionais de
um sistema. Porem, a validacao dos requisitos nao funcionais e igualmente importante.
Eles sao tambem avaliados por meio de teste. Tecnicas de teste que avaliam o desempenho,
a seguranca, a usabilidade e sua adequacao do software a carga estabelecida sao essenciais
16
para atender as expectativas dos interessados (cliente e usuarios) no sistema. Essas tecnicas
derivams seus requisitos das restricoes do software.
As tecnicas de teste de requisitos funcionais e nao funcionais sao aplicadas no nıvel
de unidade, de modulos ou do sistema como um todo. Elas ainda devem ser organizadas
por meio de estrategias de teste que definem a ordem de realizacao dos testes, a frequencia
de ocorrencia e sua automatizacao.
1.1 Motivacao
Uma questao importante e verificar como a atividade de teste ocorre em ambientes
reais de desenvolvimento. Isto porque como elas sao aplicadas na industria podem variar
intensamente dependendo de fatores como orcamento de teste, metodo de desenvolvimento
utilizado, perfil do cliente, tipo de software, entre outros.
Questoes como quais tecnicas, tipos e estrategias de teste sao realizadas pela
industria de software, como os testes sao organizados e o que determina essa organizacao
sao relevantes para determinar como eles ocorrem na pratica. A partir desse conhecimento,
pode-se tracar estrategias para torna-los mais eficazes e eficientes. Por isso, e importante
avaliar como a atividade de teste ocorre, em especial, no contexto de empresas brasileiras
desenvolvedoras de software.
1.2 Justificativa
Varias tecnicas e estrategias de teste foram propostas na literatura. No entanto,
poucos sao os estudos que avaliam como elas sao realizadas na pratica. O entendimento de
como a atividade de teste da-se em ambientes industriais de desenvolvimento e fundamental
para avaliar sua efetividade e para o desenvolvimento de novas tecnicas e estrategias mais
efetivas.
1.3 Objetivos
O objetivo desta pesquisa e verificar como a atividade de teste e realizada em
ambientes industriais de desenvolvimento. Ao final, pretende-se construir um modelo de
como os testes ocorrem na industria.
17
Para elaborar esse modelo, foi utilizada metodologia de pesquisa qualitativa
(STRAUSS A.;CORBIN, 2008). Os objetivos especıficos deste trabalho sao os seguin-
tes:
• identificar organizacoes desenvolvedoras de software com atividades de teste organizadas;
• identificar os responsaveis pela atividade de teste;
• coletar os dados por meio de entrevistas;
• elaborar o modelo da atividade de teste utilizando metodologia qualitativa de pes-
quisa, em particular, a tecnica conhecida como teoria fundamentada (STRAUSS
A.;CORBIN, 2008).
1.4 Contribuicoes
Este trabalho entrevistou gestores de cinco empresas e, a partir dessas entrevistas,
foi desenvolvido uma teoria da atividade de teste em empresas brasileiras. Neste modelo,
observou-se que a estrutura organizacional direciona a escolha das tecnicas e ferramentas,
bem como o tipo do sistema e a estrutura do projeto; o prazo e orcamento condicionam a
utilizacao de tecnicas de automatizacao.
1.5 Estrutura desse projeto
Este projeto e organizado da seguinte forma. Nessa secao, foram apresentados
a motivacao, a justificativa, os objetivos da pesquisa e as contribuicoes esperadas. No
proximo capıtulo, serao apresentados os conceitos basicos; o Capıtulo 3 contem uma revisao
de literatura sobre os trabalhos relacionais. O Capıtulo 4 apresenta os procedimentos
metodologicos e, no Capıtulo 5, sao apresentados os resultado experimentais. O Capıtulo
6 apresenta as conclusoes e trabalhos futuros.
18
2 Conceitos
O objetivo do teste e provocar falhas que revelam a presenca de defeitos. Neste
capıtulo, sao descritos sucintamente os conceitos e tecnicas de teste de software utilizados
pelos desenvolvedores. Primeiramente, definem-se os conceitos de engano, defeito, erro,
falha e caso de teste. Em seguida, sao apresentados aqueles associados aos diferentes tipos,
estrategias e tecnicas de teste.
2.1 Engano, defeito, erro, falha e caso de teste
Os termos engano, defeito, erro ou infeccao, falha e caso de teste sao importantes
para a compreensao dos problemas em teste de software. A distincao entre eles e apresentada
abaixo com base no Glossario de Termos de Engenharia de Software do IEEE (Institute of
Electrical and Electronic Engineers) (IEEE, 1990) e nos trabalhos de Ammann e Offutt
(2017) e Zeller (2005).
2.1.1 Engano
Engano e uma acao humana que gera um defeito. Essa acao humana pode ocorrer
devido a distracoes, a erros de digitacao e ao cansaco do programador, mas tambem por
falta de conhecimento ou compreensao incorreta dos requisitos, dos possıveis estados do
programa e das interfaces dos modulos.
2.1.2 Defeito
O defeito e a manifestacao fısica do engano, ou seja, o trecho incorreto do codigo
do programa. Para ilustrar os conceitos, foi elaborado o programa calcularMDC, descrito
na Figura 1, que recebe como parametro dois numeros inteiros e calcula o maior divisor
comum entre eles. O programa deve retornar o valor encontrado, caso haja um divisor
comum, ou retornar -1, caso uma das entradas seja zero.
Um defeito foi inserido no codigo da linha 14 de forma que, caso o valor inserido no
parametro valor1 seja maior que o inserido no parametro valor2, tanto a variavel auxiliar
19
maiorValor como a variavel menorValor recebem o conteudo de valor2. Esse defeito e
ilustrativo, mas pode ocorrer por falta de atencao do programador, isto e, um engano, ao
copiar e colar trechos de codigo.
O defeito somente sera executado quando o valor valor1 for maior que valor2, caso
contrario, este defeito nao ocasiona uma saıda incorreta.
Figura 1 – Programa exemplo calcularMDC
1 package Programa . Exemplo ;23 pub l i c c l a s s MDC {45 pub l i c s t a t i c i n t calcularMDC ( i n t valor1 , i n t va lo r2 ) {6 i n t r e t = −1;7 i n t maiorValor ;8 i n t menorValor ;9 i n t r e s t o ;
1011 i f ( va lo r1 != 0 && va lo r2 != 0) {12 i f ( va lo r1 != va lo r2 ) {13 i f ( va lo r1 > va lo r2 ) {14 maiorValor = va lo r2 ; // <− d e f e i t o15 menorValor = va lo r2 ;16 } e l s e {17 maiorValor = va lo r2 ;18 menorValor = va lo r1 ;19 }20 r e s t o = maiorValor mod menorValor ;21 whi l e ( r e s t o != 0) {22 maiorValor = menorValor ;23 menorValor = r e s t o ;24 r e s t o = maiorValor mod menorValor ;25 }26 r e t = menorValor ;27 } e l s e28 r e t = va lo r1 ;29 }30 }31 re turn r e t ;32 }33 }
Fonte: Sergio Luis Barbieri, 2018
20
2.1.3 Erro ou infeccao
Um erro ou infeccao ocorre quando um estado de programa nao previsto e atingido
quando o defeito e executado sob certas condicoes. Um erro ou infeccao pode causar mais
erros ou infeccoes em partes de codigo sem defeitos.
No programa calculaMDC da Figura 1, o erro e disparado quando a linha 14 e
executada, ou seja, quando a condicao valor1 > valor2 for verdadeira e a variavel auxiliar
maiorValor receber valor2 ao inves valor1. Dessa forma, o programa apresenta um estado
que nao e o correto.
Uma vez que existe um erro, uma falha pode ocorrer. Porem, assim como o defeito,
um erro pode existir, mas nao ha garantias de ser observada a falha.
2.1.4 Falha
A falha e um erro ou infeccao observavel externamente. Um erro propaga-se e gera
um comportamento anormal do sistema. Uma falha e visıvel aos usuarios finais como uma
mensagem de erro ou saıdas incorretas.
No programa calculaMDC, a falha ocorre quando o valor do primeiro parametro
for maior que o segundo parametro. Como na linha 14 e na linha 15, o mesmo valor e
atribuıdo as variaveis auxiliares maiorValor e menorValor, o maximo divisor comum sera
o valor2, ocasionando uma saıda incorreta do programa.
De acordo com Dijkstra, os testes podem apenas mostrar a presenca de defeitos,
mas nunca sua ausencia (apud Zeller (2005)). Se defeitos nao causam erro (infeccao) que
geram falhas, todos os casos de teste irao passar.
2.1.5 Caso de teste
As falhas somente ocorrem quando o software em teste e executado. Quando o
programa falha, sabe-se que o defeito foi atingido, provocou um erro que se manifestou
por meio da falha observada. O programa e executado por casos de teste.
Caso de teste, ou simplesmente teste, e um artefato composto de varios componentes.
21
Ammann e Offutt (2017) definiram formalmente a composicao de um caso de
teste. Um caso de teste e composto por valores entrada, valores pre-execucao (prefix
values), valores pos-execucao (posfix values) e resultados esperados. Esses componentes
sao necessarios para execucao e avaliacao do software em teste. Os valores pre-excecucao
sao necessarios para colocar o software em condicoes de receber os valores de entrada.
Os valores pos-execucao sao necessarios para verificar os resultados e para terminar o
programa ou coloca-lo em um estado estavel.
Tabela 1 descreve casos de teste para o programa da Figura 1. Nota-se que o
programa calculaMDC e simples e, por isso, seus casos de teste requerem apenas os valores
de entrada e as saıdas esperadas. A tabela apresenta tambem o resultado dos testes: sucesso
ou falha.
Um conjunto de teste, ou uma suıte de teste, e definido por um conjunto de casos
de teste. Um script de teste e um programa para executar automaticamente um caso de
teste e produzir um relatorio.
Tabela 1 – Conjunto de casos de teste
Tn Caso de teste Resultado esperado Resultado obtido Sucesso/Falhat1 calculaMDC(8,16) 8 8 3
t2 calculaMDC(7,4) 1 4 7
t3 calculaMDC(10,10) 10 10 3
t4 calculaMDC(0,2) -1 -1 3
t5 calculaMDC(2,0) -1 -1 3
Fonte: Vincenzi et al. (2018)
2.2 Teste de software no desenvolvimento de software
Os processos de desenvolvimento de software incluem atividades comuns como:
especificacao de requisitos, desenvolvimento do sistema, validacao e verificacao (V&V)
e evolucao do software (SOMMERVILE, 2011). Geralmente, estas atividades sao imple-
mentadas seguindo a logica de um modelo de desenvolvimento de software. De acordo
com Sommervile (2011), varios modelos de processos de desenvolvimento sao utilizados no
desenvolvimento de sistemas de software. A seguir, apresentam-se alguns deles.
• Modelo em cascata: as atividades sao divididas em etapas e implementadas sequenci-
almente.
22
• Modelo iterativo e incremental: o desenvolvimento e dividido em passos similares; a
cada etapa do processo sao acrescentadas novas funcionalidades.
• Modelo formal: as atividades sao modeladas e implementadas seguindo um modelo
matematico formal.
• Modelo baseado em componentes: baseada em reuso de aplicacoes e artefatos de
software ja desenvolvidos.
O teste de software esta inserido dentro das atividades de verificacao e validacao
(AMMANN; OFFUTT, 2017). Verificacao e o processo de determinar se o produto de uma
fase de desenvolvimento preenche os requisitos estabelecidos na fase anterior. Validacao,
por sua vez, avalia se o produto gerado no final do processo de desenvolvimento esta de
acordo com o uso pretendido. As atividades de teste tem por objetivo verificar e validar os
artefatos gerados durante o desenvolvimento de software.
A importancia do teste de software aumentou consideramente com o surgimento
dos metodos ageis (BECK; ANDRES, 2004). O problema fundamental dos modelos de
desenvolvimento tradicionais, baseados em planificacao e documentacao extensa, e que eles
nao conseguem lidar adequadamente com as mudancas no contexto no desenvolvimento
de software. E comum durante o desenvolvimento as condicoes de mercado mudarem,
as necessidades dos usuarios nao serem mais as mesmas, a equipe sofrer alteracoes e
novas ameacas competitivas surgirem (PRESSMAN, 2006). Os metodos ageis tem se
tornado prevalentes na industria de software porque utilizam praticas baseadas em pouca
documentacao, interacao com o cliente, respostas rapidas a mudancas, muita comunicacao
verbal e foco na geracao de codigo executavel da aplicacao.
No contexto agil, os testes1 ocorrem cedo e frequentemente no processo de desen-
volvimento (MCGREGOR, 2007). Beck (2002) preconizam que todo requisito do software
deve ser acompanhado de um caso de teste automatizado. Mais ainda que os testes devem
ser automatizados para que produzam feedback constante do estado do software em desen-
volvimento. Por isso, praticas de desenvolvimento dirigido a testes (TDD – Test-driven
development) e de automatizacao da execucao dos casos de teste sao fundamentais para o
sucesso dos metodos ageis (BECK, 2002).
1 O termo testes, no plural, e usado de uma maneira ampla neste documento. O objetivo foi deixar otexto mais fluente, pois acredita-se que o leitor e capaz de fazer a distincao a partir do contexto.
23
2.3 Estrategias de testes de software
A aplicacao de testes corresponde a principal tecnica de Verificacao e Validacao
(V&V) de software (SOMMERVILE, 2011). Verificacao corresponde, entre outras ativi-
dades, ao processo de teste das funcionalidades implementadas, enquanto o processo de
validacao analisa se o software desenvolvido atende aos requisitos do cliente.
As subsecoes seguintes descrevem algumas estrategias de testes aplicadas durante o
processo de V&V (SOMMERVILE, 2011):
2.3.1 Testes de unidade
Testes de unidade, tambem conhecidos como testes unitarios, sao verificacoes
aplicadas a componentes ou modulos desenvolvidos. O termo unitario e utilizado, pois
componentes e modulos (conhecidos como unidades) sao testados individualmente. Sendo
aplicados a componentes internos do sistema, estes testes sao geralmente realizados por
desenvolvedores, podendo ser utilizadas tecnicas caixa preta ou caixa branca.
2.3.2 Testes de integracao
Apos a aplicacao de testes de unidade, ha a necessidade de testar o funcionamento
do sistema quando diferentes modulos do sistema sao integrados. Mesmo funcionando
corretamente em separado, os modulos podem apresentar problemas quando integrados
devido a dependencias existentes no fluxo de dados, nas chamadas e retornos de funcoes e
nas interfaces existentes. Neste tipo de teste, podem ser aplicadas tecnicas caixa preta,
branca ou cinza.
O teste de integracao tem como foco a “interface” entre os componentes, garantindo
o comportamento correto quando executados em conjunto. Diferente do teste de unidade,
na integracao o resultado gerado por um ou mais componente pode estar em um estado
nao aceitavel. O objetivo desta etapa e garantir que o conjunto de componentes funcionem
conforme desejado em conjunto (MATHUR, 2009).
24
2.3.3 Testes de regressao
Outra abordagem muito utilizada sao os chamados testes de regressao, a cada
integracao realizada, testes em funcionalidades ja implementadas e testadas sao reexe-
cutados. A intencao deste tipo de teste e verificar se os novos modulos implementados
nao danificaram o funcionamento correto de componentes que ja haviam sido validados.
Devido a caracterıstica repetitiva dos testes de regressao, e essencial que estes sejam
automatizados.
2.3.4 Testes de aceitacao
Estes testes tem a finalidade de mostrar que o software corresponde ao que o cliente
deseja, ou seja, que o software atende a seus requisitos. Eles podem ser realizados pela
equipe do cliente ou por uma organizacao contratada para realizar os testes de aceitacao.
2.4 Tecnicas de requisitos funcionais de software
A principal meta de qualquer tecnica de teste de software e executar o programa
na intencao de provocar falhas (PRESSMAN, 2006). Esta subsecao apresenta as principais
tecnicas voltadas para o teste dos requisitos funcionais do software.
2.4.1 Tecnicas caixa preta
A tecnica caixa preta ou funcional projeta casos de testes de forma que o programa
e considerado uma caixa preta e a geracao dos casos de testes da-se a partir dos requisitos
do sistema. Nesta tecnica, nao se consideram os detalhes da construcao do software
(DELAMARO M. E.; MALDONADO, 2007).
O teste funcional utiliza os requisitos do sistema para a criacao dos casos de teste.
A saıda obtida apos a entrada de dados e comparada com a saıda esperada de acordo
com os requisitos. Nessa tecnica, a implementacao do codigo nao e avaliada. A tecnica
funcional muitas vezes e inviabilizada em funcao das infinitas possibilidades combinatorias
dos dados de entrada (MYERS G. J.;SANDLER, 2004).
25
Considerando a impossibilidade de submeter um programa a todas as possıveis
entradas, existem criterios para estabelecer entradas adequadas para teste. Os criterios
mais conhecidos sao: particionamento de equivalencia e analise do valor limite.
A seguir, descrevem essas duas tecnicas.
Particionamento de equivalencia
A partir das definicoes do sistema e requisitos, o objetivo e reduzir as entradas
para teste por meio da busca de classes de equivalencia: dados que sao tratadas da mesma
maneira resultando em um comportamento similar, reduzindo assim o numero de entradas.
A intuicao e que um dado de entrada em uma classe equivalente tera o mesmo tratamento
(sucesso ou falha) em relacao a outros que pertencem a mesma classe.
Analise do valor limite
A experiencia mostra que casos de teste que exploram condicoes limites tem maior
probabilidade de encontrar defeitos (MYERS G. J.;SANDLER, 2004). Esse criterio pode
ser combinado com o particionamento de equivalencia, utilizando valores que dividem
classes de equivalencia ou valores imediatamente acima ou abaixo.
2.4.2 Tecnicas caixa branca
A tecnica caixa branca ou estrutural estabelece os requisitos de teste com base em
uma determinada implementacao (MYERS G. J.;SANDLER, 2004). O teste estrutural
tem como objetivo orientar na construcao de casos de testes, baseados em caminhos logicos
(decisoes e lacos) e pares de definicoes e uso de variaveis, sempre com o foco em revelar
novos defeitos.
Sao apresentadas a seguir tecnicas de teste caixa branca baseados em analise de
fluxo de controle, pois sao as mais utilizadas na industria.
26
2.4.3 Analise de fluxo de controle
A tecnica de teste estrutural requer que os casos de teste selecionados executem
(exercitem) determinados caminhos do programa considerados relevantes para que o
testador aumente a sua confianca em relacao a correcao do programa.
Os caminhos requeridos definem requisitos de teste que constituem um criterio de
adequacao do conjunto de casos de teste. Em outras palavras, o conjunto de casos de
teste T e considerado adequado, do ponto de vista de teste estrutural, de acordo com
um criterio de teste C, se o conjunto de requisitos de teste (TRC) estabelecido por C e
exercitado pelos casos de teste de T .
Os conceitos de fluxo de controle utilizados para definir os requisitos de teste, bem
como principais criterios de teste de fluxo de controle sao descritos a seguir.
2.4.4 Conceitos de fluxo de controle
Um programa P escrito em uma linguagem procedimental pode ser mapeado em
um grafo de fluxo de controle G(N,B, s, e) onde N e o conjunto de blocos de comandos
(nos) que sao executados sequencialmente, e e o no de entrada, s e o no de saıda e R e o
conjunto de ramos que representam a possıvel transferencia de fluxo de controle entre dois
nos.
A Figura 3 apresenta o grafo de fluxo de controle obtido a partir do programa
calcularMDC (Figura 1). O mapeamento das linhas do programa e os respectivos nos e
apresentando na forma de comentarios /* No */ no Programa 2. Assim, as linhas 5 a
9 do programa sao mapeadas para o no 1 como mostra o trecho de codigo. A possıvel
transferencia de fluxo de controle do no 2 (condicao do primeiro if) para o no 3 (condicao
do segundo if) e representada pelo ramo (2,3) na Figura 3.
2.4.5 Criterios Baseados em Fluxo de Controle
Os requisitos de teste desses criterios estao associados aos nos, ramos e caminhos
do grafo de fluxo de controle do programa.
27
Figura 2 – Mapeamento de linhas para nos do programa exemplo calcularMDC
1 package Livro . Exemplo ; /∗ No ∗/23 pub l i c c l a s s MDC {45 pub l i c s t a t i c i n t calcularMDC ( i n t valor1 , i n t va lo r2 ){/∗ 1 ∗/6 i n t r e t = −1; /∗ 1 ∗/7 i n t maiorValor ; /∗ 1 ∗/8 i n t menorValor ; /∗ 1 ∗/9 i n t r e s t o ; /∗ 1 ∗/
1011 i f ( va lo r1 != 0 && va lo r2 != 0) { /∗ 2 ∗/12 i f ( va lo r1 != va lo r2 ) { /∗ 3 ∗/1314 i f ( va lo r1 > va lo r2 ) { /∗ 4 ∗/15 maiorValor = va lo r1 ; /∗ 5 ∗/16 menorValor = va lo r2 ; /∗ 5 ∗/17 } e l s e {18 maiorValor = va lo r2 ; /∗ 6 ∗/19 menorValor = va lo r1 ; /∗ 6 ∗/20 }2122 r e s t o = maiorValor mod menorValor ; /∗ 7 ∗/23 whi l e ( r e s t o != 0) { /∗ 8 ∗/24 maiorValor = menorValor ; /∗ 9 ∗/25 menorValor = r e s t o ; /∗ 9 ∗/26 r e s t o = maiorValor mod menorValor ; /∗ 9 ∗/27 }28 r e t = menorValor ; /∗ 10 ∗/29 } e l s e30 r e t = va lo r1 ; /∗ 11 ∗/31 }32 }3334 re turn r e t ; /∗ 12 ∗/35 }36 }
Fonte: Sergio Luis Barbieri, 2018
• Criterio Todos Caminhos Linearmente Independentes ou Baseado em Complexidade:
exige que todos os caminhos linearmente independentes sejam executados, deter-
minando um limite maximo de casos de testes. Esse criterio e baseado na metrica
complexidade ciclomatica (MCCABE, 1976).
28
Figura 3 – Grafo de fluxo de controle do metodo cacularMDC()
Fonte: Sergio Luis Barbieri, 2018
• Criterio Todos os Nos: exige um conjunto de casos de teste que exercitem ao menos
um vez cada no do grafo de fluxo de controle do programa;
• Criterio Todos os Ramos: exige um conjunto de casos de teste que exercitem ao
menos um vez cada ramo do grafo de fluxo de controle do programa.
Um possıvel conjunto de requisitos do criterio baseado em complexidade e apre-
sentados na Tabela 2. Isso ocorre porque pode existir mais de um conjunto de caminhos
linearmente independentes. A Tabela 3 descreve os requisitos de teste para os criterios
todos nos e ramos para o programa exemplo.
Assim, o conjunto de casos de teste T e adequado ao criterio baseado em complexi-
dade se os caminhos descritos na Tabela 2 forem percorridos ao menos uma vez por um
caso de teste t ∈ T ; e adequado ao criterios todos nos se os nos sao visitados ao menos
29
Tabela 2 – Possıvel conjunto de requisitos de teste estabelecidos pelo criterio baseado emcomplexidade para o programa exemplo.
Caminhos linearmente independentes1 (1,2,12)2 (1,2,3,11,12)3 (1,2,4,5,7,8,10,12)4 (1,2,4,6,7,8,10,12)5 (1,2,4,5,7,8,9,8,10,12) ou (1,2,4,6,7,8,9,8,10,12)
Fonte: Sergio Luis Barbieri, 2018
Tabela 3 – Requisitos de teste estabelecidos pelos criterios todos os nos e todos os ramospara o programa exemplo.
Todos nos Todos ramos1 (2,3)2 (3,4)3 (4,5)4 (4,6)5 (8,9)6 (8,10)7 (2,12)8 (3,11)9
Fonte: Sergio Luis Barbieri, 2018
uma vez por pelo menos um caso de teste t ∈ T ; e adequado ao criterio todos ramos se os
ramos sao exercitados pelo menos uma vez da mesma maneira.
No apendice A, e apresentado um exemplo de utilizacao da ferramenta JaCoCo para
teste baseado em fluxo de controle. Esta ferramenta e utilizada para apoiar a aplicacao
dos criterios todos os nos e todos os ramos na industria (MOIR, 2011).
2.5 Teste de requisitos nao funcionais
Um produto de software e composto tambem de requisitos nao funcionais, isto e,
requisitos associados a restricoes do software tais como requisitos de seguranca, de interface
e de ambiente, de desempenho entre outros. A seguir, descrevem-se alguns exemplos de
testes de requisitos nao funcionais.
30
2.5.1 Teste de desempenho
O teste de desempenho tem como objetivo submeter o sistema a determinados
nıveis de carga (e.g., transacoes, requisicoes, etc) com a finalidade de monitorar o consumo
dos recursos computacionais (e.g., CPU, disco, trafego de rede, etc.), permitindo desta
forma validar o desempenho da aplicacao (DELAMARO M. E.;CHAIM, 2010).
Teste de carga
Trata-se de uma variacao do teste de desempenho, permtindo entender o comporta-
mento da aplicacao com grande volume de dados.
Teste de estresse
Esta modalidade permite entender o comportamento da aplicacao em volumes
acima do planejado com o objetivo de garantir que os procedimentos de recuperacao
de informacao, recuperacao de disponibilidade dos servicos e integridade de dados sao
tratados adequadamente.
2.5.2 Teste de usabilidade
O teste de usabilidade busca avaliar a facilidade com que os usuarios interagem
com o sistema. Trata-se de atividade normalmente executada com os usuarios finais do
sistema, a qual mede-se o tempo e a facilidade em realizar suas tarefas, comportamento de
excecoes etc. Os resultados deste tipo de teste podem gerar comentarios para a melhoria
da interacao-humano computador da aplicacao (DELAMARO M. E.;CHAIM, 2010).
2.5.3 Teste de seguranca
Testes de seguranca tem como objetivo verificar se os mecanismos de protecao
introduzidos em um sistema, de fato, o protegerao de uma penetracao indevida do sis-
tema (PRESSMAN, 2006).
31
Este teste simula o papel do indivıduo que deseja penetrar no sistema, ou seja,
quebrar as defesas que foram construıdas (PRESSMAN, 2006). As atividades mais comuns
sao: provocar erros propositalmente esperando intrusao durante a recuperacao, paralizacao
do servico (negacao de acesso a outros) e encontrar caminhos alternativos para a entrada
no sistema.
2.6 Automatizacao do teste de software
A automatizacao dos testes esta relacionada a execucao dos casos de teste (DELA-
MARO M. E.;CHAIM, 2010). Os conjuntos de teste normalmente sao executados todas as
vezes que uma manutencao e realizada no sistema. A automatizacao e um procedimento
que tem como objetivo facilitar a reexecucao dos casos de teste com custos reduzidos, sem
a necessidade de realiza-los manualmente. Em seguida serao apresentadas sucintamente
duas ferramentas destinadas a este proposito.
JUnit
A ferramenta JUnit (2018) e uma biblioteca que permite escrever classes de teste. O
uso consiste em codificar classes de teste nas quais os metodos sao os testes que verificam
as funcionalidades do sistema.
A automatizacao e caracterizada por possibilitar a execucao encadeada de todos
os testes de forma automatica e ao final do processo verificar e visualizar o resultado do
processo.
Selenium
O fundamento da ferramenta Selenium IDE (SELENIUM, 2018) e permitir capturar
os comandos dos testadores com o objetivo de reexecuta-los de forma automatica (DELA-
MARO M. E.;CHAIM, 2010). Disponıvel para os navegadores por meio de um programa
plugin, possibilita a automatizacao de teste funcional para aplicacoes web. Os scripts de
testes gerados pela Selenium executam automaticamente os comandos que foram captura-
dos durante a execucao dos teste. Ao final, os resultados sao comparados e um relatorio e
produzido.
32
2.7 Consideracoes finais
Neste capıtulo, foram apresentados os diversos conceitos associados a atividade de
teste como engano, defeito, erro e falha, bem como aqueles associados a estrategias e a
tecnicas de teste de requisitos funcionais e nao funcionais.
No proximo capıtulo, sao discutidos os trabalhos que analisam a atividade de teste
por meio de metodos qualitativos.
33
3 Trabalhos relacionados
Este capıtulo apresenta uma revisao da literatura com o objetivo de identificar
estudos realizados sobre a atividade de teste de software, utilizando pesquisas qualitativas
especificamente para entender quais tecnicas, metricas e ferramentas sao utilizadas pela
industria de software.
3.1 Teste de software e teoria fundamentada
Esta pesquisa visa identificar um modelo de como os desenvolvedores exercem as
atividades de teste no contexto de ambientes profissionais. Ela esta baseada na tecnica
conhecida como teoria fundamentada nos dados (TF). Por isso, os trabalhos identificados
nesta revisao da literatura procuram relacionar as atividades de teste com o uso de tecnicas
qualitativas para a sua analise.
3.2 Selecao dos trabalhos
A busca de trabalhos relacionados foi realizada nos principais repositorios de
computacao: SCOPUS 1, IEEE XPLORE 2 e ACM DIGITAL LIBRARY 3, e tambem no
GOOGLE SCHOLAR4. A cadeia de caracteres de busca utilizada foi “qualitative AND
research AND software AND testing”. Foram encontrados 65 documentos no repositorio
SCOPUS, 159 no repositorio IEEE XPLORE e 93 no ACM DIGITAL LIBRARY.
Considerando que essa pesquisa e baseada em tecnica qualitativa, em especial
TF, adicionalmente buscaram-se artigos relacionados a engenharia de software que fazem
uso dessa tecnica. A pesquisa tambem utilizou a cadeia de caracteres de busca “Ground
Theory”.
Apos a analise dos documentos foram identificados nove artigos relacionados a
pesquisa. O Quadro 1 lista os trabalhos identificados.
1 〈https://www.scopus.com〉2 〈http://ieeexplore.ieee.org〉3 〈https://dl.acm.org〉4 〈https://scholar.google.com.br〉
34
Quadro 1 – Trabalhos relacionados
Autor TF Industria Foco da pesquisaThomson, Holcombe e Simons (2009) Nao Sim First test design / TDDDeak e Stalhane (2013) Nao Sim Atividades de testeMockus, Nagappan e Dinh-Trong(2009)
Nao Sim Cobertura estrutural
Berlowski et al. (2016) Nao Sim Atividades de testeGreiler, Deursen e Storey (2012) Sim Nao Atividades de testeColeman e O’Connor (2008) Sim Sim Processo de softwareHendrick (2013) Sim Sim Modelo para melhores praticas
de teste(TAIPALE; SMOLANDER, 2006) Sim Sim Reducao de custos atividades
de testeCruzes et al. (2017) Nao Sim Teste de seguranca
Fonte: Sergio Luis Barbieri, 2018
3.3 Descricao dos trabalhos selecionados
A seguir, e apresentado a descricao dos estudos conforme o contexto de teste e
pratica utilizada.
3.3.1 Teste durante e ao final do desenvolvimento
Thomson, Holcombe e Simons (2009) analisaram o efeito sobre a qualidade do
produto para equipes que adotam a pratica TDD (Test Driven Development) (BECK, 2002)
em relacao ao teste apos o desenvolvimento. Os autores utilizaram estudantes divididos em
nove equipes para desenvolver tres trabalhos reais da industria, sendo que cada projeto foi
desenvolvido por tres equipes diferentes. As equipes selecionaram seus proprios membros,
cada uma composta por tres a cinco alunos de graduacao de segundo ou terceiro ano.
Os dados foram coletados semanalmente, sendo que as equipes foram instruıdas
para enviar seus registros de teste, script ou documento de teste, tempo gasto em testes e
codigos de programa. As equipes utilizaram as ferramentas JUnit5, PHPUnit6 e Selenium7.
O estudo concluiu que para atingir um alto nıvel de qualidade deve existir uma
cultura de teste na equipe e foco no atendimento aos requisitos do cliente.
5 https://junit.org6 https://phpunit.de7 http://www.seleniumhq.org
35
O estudo descrito neste trabalho avalia casos reais da industria, porem, com o foco
em conhecer quais tecnicas sao adotadas e quais metricas sao avaliadas, diferentemente
deste estudo que avalia duas tecnicas especıficas.
3.3.2 Atividades de teste em empresas
Deak e Stalhane (2013) exploram como as atividades de teste sao organizadas em
empresas norueguesas e os fatores que influenciam a criacao de um departamento de testes
ou incentivam o investimento em pessoal dedicado a teste. A pesquisa mescla metodos
qualitativos e quantitativos, utilizando como coleta de dados perguntas com multiplas
escolhas, bem como questoes abertas. Em uma etapa subsequente incluiu entrevistas
e uma rodada adicional de perguntas abertas. O estudo encontrou quatro categorias
organizacionais nas quais as atividades de teste podem ocorrer.
Questoes de pesquisa foram elaboradas para investigar a estrutura organizacional,
o perfil dos testadores e o grau de automatizacao dos testes. Elas sao descritas a seguir:
• QP1: Por que as empresas optaram por organizar testes de uma maneira particular?
– QP1.1: Quais sao as diferentes formas de organizar os profissionais de testes
que podem ser encontradas em empresas de software norueguesas?
– QP1.2: Quem e o responsavel por realizar atividades de teste?
• QP2: Qual e a relacao entre a organizacao das atividades de teste e o processo de
automacao de testes?
– QP2.2: Qual e o grau de envolvimento e experiencia na automatizacao do teste?
O estudo mostrou para as empresas que realizam atividades de teste tendem a se
organizarem em quatro categorias com as seguintes distribuicoes:
• com departamento de teste dedicado (21,05%);
• com departamento de teste dedicado e com testadores divididos em grupos de
aplicativos (10,53%);
• com testadores divididos entre os grupos de aplicativos (42,11%);
• com desenvolvedores responsaveis pelos testes, mas sem equipe de teste (26,32%).
36
O estudo tambem concluiu que em 10 das 19 empresas o responsavel pelas atividades
de teste e o gerente de produto ou gerente de desenvolvimento. Tambem a contratacao de
terceiros nao e uma pratica comum.
O resultado indica que a automatizacao dos testes, mesmo sendo benefica, nao e
utilizada em larga escala. A pratica estava presente em 14 das 19 organizacoes, porem,
com baixa taxa de automatizacao:
• 25% em sete organizacoes;
• 50% em duas organizacoes;
• 75% em quatro organizacoes; e
• 100% em uma organizacao.
O estudo busca entender a estrutura organizacional das empresas em relacao a
equipe e ao processo de teste. O foco deste estudo e em entender como as tecnicas de teste
sao usadas e o que determina seu uso.
Mockus, Nagappan e Dinh-Trong (2009) realizaram um estudo de caso multiplo em
dois diferentes projetos de software da industria. Seus objetivos sao investigar a relacao
entre cobertura de teste estrutural e eficacia dos testes e a relacao entre esforco de teste e
o nıvel de cobertura estrutural. As hipoteses do estudo sao:
• Hipotese 1: O aumento do nıvel de cobertura diminui a taxa de defeitos.
• Hipotese 2: Quanto maior o nıvel de cobertura, cada vez e maior o esforco necessario
para aumenta-la em uma dada quantidade.
Apesar das diferencas significativas entre os dois projetos do estudo, identificou-se
que a cobertura de codigo foi associada a diminuicao de problemas em campo e a uma menor
probabilidade de defeitos quando esta era ajustada pelo numero de mudancas antes da
liberacao do software. Isto sugere que a cobertura do codigo e uma medida sensata e pratica
da eficacia do teste. O estudo tambem descobriu que programadores mais experientes tem
como tendencia escrever codigos mais confiaveis e com maior qualidade, incluindo trechos
para o tratamento de excecoes. Essa pratica diminui a cobertura, considerando que os
testes normalmente nao sao escritos para gerar excecoes.
A similaridade com este estudo esta apenas no objeto da pesquisa: teste e industria,
porem, com foco exclusivo em buscar uma relacao entre metrica de cobertura e falhas em
campo.
37
3.3.3 Atividades de teste e metodos ageis
Berlowski et al. (2016) realizaram uma pesquisa qualitativa exploratoria com o
objetivo de ampliar o conhecimento sobre teste em metodos de desenvolvimento ageis,
documentando um processo de teste de software. Para isso, utilizou um projeto real na
industria desenvolvido para uma empresa do segmento de telecomunicacao. O artigo
descreve como os desafios sao superados, de que maneira eles afetam o processo de teste e
quais os resultados obtidos.
O estudo e focado no processo de teste com requisitos para versoes nao programadas
e infraestrutura complexa, avaliando o nıvel de adocao de praticas de testes, tais como
desenvolvimento orientado por testes (TDD), automacao de testes, programacao em pares,
entre outras. As questoes de pesquisa foram:
• QP1: Ate que ponto o requisito para “versoes” (releases) nao programadas e atendido?
• QP2: Como e realizada a automacao de teste?
• QP3: Quanto esforco de automatizacao de teste e necessario (em relacao a diferentes
tipos de atividades e ferramentas)?
Como contribuicao, os autores fornecem um estudo de caso detalhado para os
profissionais interessados em implementar um processo de teste agil em um ambiente similar.
Tambem avalia o uso de ferramentas de automatizacao de teste e as dificuldades encontradas
na implementacao. O estudo fornece uma breve descricao de todas as ferramentas que
foram usadas para implementar testes automatizados, prontas para uso, possibilitando
auxiliar outros profissionais que enfrentam desafios semelhantes.
O estudo tem como alvo a industria, porem, em uma empresa especifica e metodo de
desenvolvimento agil com o objetivo de avaliar o atendimento de versoes nao programadas
e automatizacao de teste.
3.3.4 Teste de aplicativos plugin
Greiler, Deursen e Storey (2012) conduziram um estudo qualitativo utilizando a
tecnica teoria fundamentada, entrevistando 25 profissionais seniores sobre como eles testam
38
aplicativos plug-in com base na arquitetura de plug-in do ambiente de desenvolvimento
Eclipse8.
Uma das questoes de pesquisa (QP4) foi descobrir se existiam estrategias especiais
para o teste de plug-ins. Por meio da TF, foram identificadas tres importantes estrategias:
• Auto-hospedagem de projetos. Os desenvolvedores sao usuarios do proprio pro-
jeto, utilizando-o internamente como ferramenta, facilitando, por isso, o relato de
problemas.
• Envolvimento do usuario. Os usuarios tambem sao desenvolvedores e quanto maior o
numero de instalacoes do projeto, maior sera a quantidade de formas diferentes que
o produto e utilizado (e.g., versoes, sistema operacional). Dessa forma a quantidade
de testes realizadas pelos responsaveis em relacao a como o produto e utilizado na
pratica e maior.
• Envolvimento do desenvolvedor. A arquitetura de plug-in do Eclipse permite aos
desenvolvedores criar plug-ins a partir de outros plug-ins. Por isso, os usuarios
do software sao muitas vezes desenvolvedores qualificados cujos projetos tambem
dependem da qualidade dos outros projetos. Como consequencia, em projetos proprios
dedicam parte do seu tempo para melhorar projetos dependentes.
A similaridade deste estudo com esta pesquisa esta no uso da tecnica TF como
ferramenta de coleta. Apesar de o estudo estar relacionado com teste, ele e especifico para
um artefato do ambiente de desenvolvimento Eclipse: plug-ins.
3.3.5 Melhoria da qualidade de software
Coleman e O’Connor (2008) realizaram estudo qualitativo para entender o processo
de melhoria da qualidade de software na industria. A metodologia escolhida para o
estudo foi a TF. Como ferramenta de coleta de dados, o estudo elaborou entrevistas
semi-estruturadas com as equipes de projetos evolvidas no estudo. Possui similaridade
com o estudo realizado na coleta de dados por meio de entrevistas, transcricao e analise
com a tecnica de TF.
Segue abaixo o resumo das questoes de pesquisa com a respectiva conclusao:
8 〈https://www.eclipse.org/〉
39
• Quais processos de software estao sendo utilizados por empresas desenvolvedoras de
software?
A pesquisa revelou que nenhuma empresa esta utilizando um modelo de processo
inovador, porem, todas estao utilizando algum tipo de processo proprietario baseado
em maior ou menor grau em modelos padrao.
• Como o processo e formado ou criado?
Os resultados mostram que isso depende de varios fatores. O principal fator refere-
se ao conhecimento do gestor de desenvolvimento. A experiencia acumulada pelo
profissional encarregado de gerenciar determina como sera o inicio do processo de
desenvolvimento.
• Como e por que os processos de desenvolvimento mudam?
Segundo os dados analisados, nao ha indıcios de iniciativa dos profissionais no que
diz respeito a mudancas em seus processos de desenvolvimento. A maioria dos
entrevistados apresentaram-se satisfeitos com os seus processos atuais e, enquanto
funcionam, nao fariam ajustes por medo de “quebrar algo”. Isto significa que a
melhora do processo e, em essencia, reativa.
• Por que as empresas de software nao estao utilizando as “melhores praticas” dos
frameworks de desenvolvimento?
O estudo concluiu que a implementacao e a manutencao de qualquer iniciativa de
melhoria de processo incorrem em custos significativos. Os recursos necessarios para
executar aperfeicoamento de fluxo sao proporcionalmente muito maiores em empresas
de menor porte. Essas empresas tem como prioridade a propria sobrevivencia no
mercado e, em seguida, estabilidade em relacao a melhoria de processo.
3.3.6 Uso de teoria fundamentada em teste de software
Hendrick (2013) realizou estudos qualitativos baseados em TF para avaliar as
atividade de teste no ciclo de desenvolvimento. O problema de pesquisa investigado foi
explorar se a TF pode ser usada para desenvolver uma estrutura para melhores praticas
em teste de software. A pesquisa foi aplicada em uma empresa especifica do segmento de
telecomunicacoes localizada em Dublin, Irlanda. Como metodo de coleta, etapa da TF,
o estudo elaborou sete questoes para ser utilizada em entrevistas estruturadas aplicadas
40
em cinco profissionais de teste com experiencia media de sete anos. Apos a transcricoes,
as mesmas foram utilizadas como entrada para o programa Atlas.TI. Como resultado
da analise, o projeto elaborou um “framework” de melhores praticas. Esta pesquisa e
semelhante na metodologia, porem, difere nos objetivos e resultados esperados. A busca
das melhores praticas de teste esta baseada em cenario muito particular: empresa de
telecomunicacao, estrutura organizacional e produtos, o que difere dos objetivos desse
estudo.
3.3.7 Complexidade do teste
Taipale e Smolander (2006) elaboraram pesquisa qualitativa para compreender a
complexidade pratica de teste, com o objetivo de gerar propostas para reduzir custos de
desenvolvimento e teste, bem como melhorar a qualidade de software. Eles utilizaram a
TF como metodo de pesquisa. O estudo foi realizado em 26 unidades organizacionais do
segmento de telecomunicacoes localizadas na Finlandia. Os dados foram coletados por
meio de entrevistas estruturadas e semiestruturadas. O objetivo das entrevistas, em uma
primeira rodada, foi entender as melhores praticas de teste, identificar os problemas e as
propostas de melhoria. Outras entrevistas foram realizadas para um maior aprofundamento
das praticas de teste da complexidade em testar software e componentes e da automatizacao
de teste.
Como resultado final, o estudo apresentou propostas de melhoria de processo. Em
comparacao com este estudo, o foco principal da pesquisa de Taipale e Smolander (2006)
e o processo de desenvolvimento e atividades correlatas, por exemplo, a comunicacao de
equipes e os papeis e responsabilidades dos profissionais do projeto.
3.3.8 Testes de seguranca
Cruzes et al. (2017) conduziram uma pesquisa qualitativa sobre como testes de
seguranca sao realizados em projetos de software utilizando metodologia ageis. O trabalho
definiu tres questoes de pesquisas e utilizou a tecnica de coleta de dados por meio de
entrevistas semiestruturada. O escopo de coleta foram quatro equipes de desenvolvimento.
O objetivo foi gerar diretrizes de melhores praticas. As questoes de pesquisas foram:
41
• QP1: Como o processo de engenharia de seguranca tradicional e gerenciado e
organizado nas equipes ageis?
• QP2: Como as equipes ageis realizam testes de seguranca em cada fase de teste?
• QP3: Como as tecnicas de teste de seguranca tradicionais geralmente sao usadas no
ciclo de vida de desenvolvimento de software agil?
Os principais resultados obtidos foram os seguintes. Com relacao a questao QP1,
observou-se que as grandes empresas possuem chief security officer (CSO) proprio, mas
ele nao faz parte da equipe de desenvolvimento para nao interferir nas atividades diarias.
Notou-se tambem que para empresas pequenas nao existe a hierarquia ou a definicao de
um CSO. Observou-se que testes de penetracao normalmente sao realizados por terceiros.
Alem disso, o resultado de QP2 mostrou como resultado que e comum o uso de
teste de unidade, porem, nao sendo a seguranca o foco dos testes ou a consideracao de
aspectos especıficos de seguranca, os quais sao tratados no teste de sistema.
A partir de modelos e abordagens classicas de teste de seguranca, os entrevistados
foram questionados para comentar como executam as atividades na metodologia agil com
o objetivo de responder a QP3. A conclusao foi que nao ha um modelo especifico para
seguranca, apenas abstracoes para as questoes de seguranca. Outro ponto citado foi a
utilizacao de terceiros para teste de penetracao.
3.4 Consideracoes finais
Os trabalhos apresentados mostram que tecnicas qualitativas de pesquisa tem sido
utilizadas para investigar a atividade de teste em diferentes contextos. Elas foram usadas,
por exemplo, para caracterizar o teste nos metodos ageis, o teste de seguranca e o papel
da cobertura de codigo na deteccao de defeitos, entre outras questoes.
Este trabalho utiliza metodos semelhantes, em particular teoria fundamentada,
para identificar um modelo de execucao da atividade de teste em organizacoes brasileiras
de desenvolvimento de software. Diferentemente dos trabalhos apresentados, a pesquisa
realizada tem como objetivo determinar o fatores que determinam a adocao de tecnicas e
estrategias de teste, isto e, verificar como a atividade de teste da-se na pratica.
No capıtulo a seguir, sao apresentados os procedimentos metodologicos para
conducao da pesquisa qualitativa.
42
4 Procedimentos metodologicos
O objetivo da pesquisa e entender como os profissionais da industria realizam as
atividades de teste. A pesquisa foi realizada com uma abordagem qualitativa, na qual os
resultados nao podem ser obtidos por meio de procedimentos estatısticos. Entre os diversos
metodos existentes, o estudo e baseado na metodologia teoria fundamentada (STRAUSS
A.;CORBIN, 2008). A teoria fundamentada significa que a teoria foi construıda a partir
de dados, sistematicamente reunidos e analisados por meio do processo de pesquisa. Essa
metodologia foi desenvolvida por dois sociologos, Barney Glasser e Anselm Strauss, entre
os anos de 1967 e 1992.
Essa abordagem qualitativa e definida por tres componentes fundamentais: dados,
procedimentos e codificacao. Os dados podem serem obtidos por meio de questionarios,
entrevistas ou observacoes. Os procedimentos sao tecnicas utilizadas pelos pesquisadores
para interpretar e organizar os dados. A codificacao consiste em conceitualizar, reduzir,
elaborar e relacionar os dados, sendo o passo inicial para a construcao da teoria por
meio de conceitos identificados. Em sıntese, por meio de metodos para a coleta de dados,
consegue-se identificar conceitos e explicacoes sobre fenomenos.
A execucao da pesquisa baseada na teoria fundamentada pode ser separada em
tres etapas: coleta de dados, codificacao (ou categorizacao) e redacao da teoria. A coleta
de dados e feita por meio de observacao dos participantes, entrevistas e questionarios.
Nessa metodologia, as atividades de analise sao executadas simultaneamente ate ocorrer
a saturacao teorica, indicando que novos dados nao serao descobertos. O objetivo dessa
etapa e coletar o maior volume de informacoes. O procedimento de rotular e analisar
os dados coletados e denominado de codificacao. A codificacao consiste na aplicacao de
tecnicas de analise minuciosa dos dados para o desenvolvimento e formacao de uma teoria.
A teoria consiste em um conjunto de conceitos bem desenvolvidos relacionados por meio
de declaracoes de relacoes que, juntas, constituem uma estrutura integrada que pode ser
usada para explicar ou prever fenomenos (STRAUSS A.;CORBIN, 2008).
A seguir, serao detalhados os conceitos e os processos associados a metodologia
teoria fundamentada utilizada do desenvolvimento desta pesquisa.
43
4.1 Coleta de dados
Conforme Robson (2011), ha varios metodos disponıveis para coleta de dados, sendo
que os mais usuais sao entrevistas, questionarios e observacao direta. A escolha do metodo
tambem pode depender de diversos fatores e condicoes especıficas de cada projeto, por
exemplo, custo e tempo.
Robson (2011) sugere uma regra simples para a selecao dos metodos:
• para descobrir o que as pessoas fazem em publico, utilize observacao direta;
• para descobrir o que eles fazem em particular, utilize entrevistas ou questionarios;
• para descobrir o que eles pensam, sentem ou acreditam, utilize entrevistas, ques-
tionarios ou escala de atitude; e
• para determinar suas habilidades ou mensurar suas inteligencias ou personalidade,
utilize testes padronizados.
Para esta pesquisa, foram utilizados entrevistas. Questionarios e entrevistas sao
popularmente utilizados para pesquisas (surveys), mas tambem como metodo primario
e secundario de coleta de dados. Existem diversas abordagens para a aplicacao de um
questionario: autopreenchimento, via entrevista, por telefone e via Internet. Cada uma
delas exige atencao especial na sua elaboracao em relacao a complexidade, distribuicao
(publico-alvo), ao uso de questoes abertas e ao tamanho.
Ainda sobre a aplicacao, a qualidade dos resultados obtidos pode variar sensivel-
mente, dependendo da ordem em que as questoes serao respondidas, do uso de recursos
visuais, etc. As perguntas devem ser projetadas para ajudar a alcancar os objetivos da
pesquisa. Os entrevistados devem entender as questoes da maneira que o pesquisador pla-
nejou, devem ter acesso a informacao necessaria para responde-las e devem estar dispostos
a responde-las na forma solicitada.
Abaixo segue uma lista de verificacao para ajudar a evitar problemas na redacao
de perguntas extraıda e adaptada de Robson (2011):
• manter a linguagem simples;
• manter questoes curtas; questoes longas ou complexas sao difıceis de entender;
• evitar duas questoes em uma;
• evitar questao principal;
44
• evitar questao em sentido negativo; e
• perguntar apenas o que os entrevistados tenham conhecimento necessario para
responder.
A entrevista, quando usada como metodo de pesquisa, conta com o pesquisador
realizando perguntas e recebendo as respostas da pessoa que esta sendo entrevistada.
Segundo Robson (2011), este e um metodo largamente utilizados em pesquisas sociais.
Ha diferentes tipos de entrevistas, variando na sua forma de conduzir a conversa e
de obter informacoes, classificadas em tres modelos, sendo eles: pesquisa estruturada, semi-
estruturada e nao-estruturada. A pesquisa estruturada parte de questoes pre-determinadas,
sendo um tipo de entrevista mais rıgido. Apesar de as perguntas serem ja estipuladas e
definidas, as respostas sao abertas e, assim, nao limitam a fala do entrevistado.
Ja o tipo semiestruturado possui um guia de entrevista, com uma lista de topicos
para cobrir por completo todos os assuntos pertinentes. Mesmo com a pauta estipulada,
a ordem pode ser modificada de acordo com o ritmo da entrevista e com as respostas
que aparecem ao decorrer. Pode-se tambem adicionar topicos extras quando surgir a
necessidade. Por fim, a pesquisa nao-estruturada e completamente informal, podendo
ser considerada uma conversa entre entrevistador e entrevistado. Aquele que conduz a
entrevista tem uma ideia ampla do que vai ser falado, mas nao segue uma ordem ou guia
de perguntas.
Independente de qual tipo de entrevista e feita, Robson (2011) lista algumas praticas
para serem evitadas na formulacao das perguntas. Nao fazer questoes longas e uma delas,
uma vez que o entrevistado nao costuma lembrar da pergunta por completo e assim nao
responde integralmente. Outra recomendacao e adequar a linguagem ao publico alvo,
evitando jargoes e termos tecnicos que dificultem o entendimento da pergunta. Nao induzir
o seu entrevistado e tambem um ponto essencial para obter um resultado imparcial, assim
como evitar perguntas direcionadas para um unico vies, que possam deixar a sua pesquisa
unilateral.
Partindo do princıpio de que as acoes e comportamento das pessoas e um aspecto
central que guia a maioria das pesquisas no mundo real, podemos utilizar a observacao
como tecnica simples e natural para registrar o que acontece e, entao, descrever, analisar e
interpretar tudo que foi percebido (ROBSON, 2011).
45
A observacao direta e um metodo para obter dados e que, assim, completa as demais
tecnicas ja apresentadas, tais como questionario e entrevista. Dessa forma consegue-se
assegurar um resultado mais preciso e eliminar as discrepancias deixadas pelos outros
metodos.
Robson (2011) categoriza quatro formas de participacao, sendo elas: participante
completo, participante como observador, participante marginal e observador como parti-
cipante. O participante completo trabalha agindo naturalmente, fazendo parte daquele
grupo. E como um espiao infiltrado que toma nota do que acontece ao seu redor. Ja o
participante como observador deixa claro qual o seu papel no grupo, podendo perguntar e
questionar determinados acontecimentos que se passam durante a analise e, neste caso, e
importante ter a confianca dos membros do grupo.
Ja se tratando de participacao marginal, acontece um envolvimento menor do
participante durante a sua analise. Ele esta inserido no contexto, porem, se comporta de
forma passiva. Neste tipo de observacao e necessaria muita atencao e, se possıvel, tomar
nota ao longo da experiencia. Tambem e interessante atentar-se as roupas utilizadas e
comportamento, para que nao se destoe do grupo. Alguns participantes marginais sao
muito proximos dos observadores completos, aqueles que nao participam da atividade e
nao assumem o seu papel como pesquisador.
E, por fim, o observador como participante nao interfere nas atividades que estao
sendo executadas. Apesar de ter essa atribuicao discreta, todos aqueles que estao envolvidos
na atividade sabem do seu cargo como pesquisador.
4.2 Codificacao
A coleta de dados e realizada utilizando tecnicas especıficas tais como questionarios,
entrevistas e observacoes. A etapa subsequente e a analise dos dados, processo denominado
de codificacao.
A codificacao consiste em aplicar tecnicas e procedimentos para identificacao de
categorias e propriedades. Ferramentas analıticas sao mecanismos e tecnicas utilizadas
por analistas para auxiliar o processo de codificacao (STRAUSS A.;CORBIN, 2008). O
objetivo e evitar pre-concepcoes, estimular o pensamento indutivo, ouvir as pessoas, focar
nos dados e descobrir as propriedades e dimensoes das categorias.
46
Como exemplo de ferramentas analıticas, pode-se citar o questionamento, a analise
de palavra, frase ou paragrafo e a analise por meio de comparacoes. O uso do questionamento
consiste em elaborar boas perguntas para a melhoria do desenvolvimento da teoria,
ajudando o analista a desbloquear as analises. A analise de uma palavra, uma frase ou um
paragrafo busca estabelecer possıveis significados, melhorando a interpretacao da analise,
devido a interpretacao derivada do uso cultural comum ou da experiencia.
A analise por meio de comparacoes, segundo STRAUSS A.;CORBIN (2008), e
essencial para identificar categorias e para desenvolve-las. As comparacoes podem ser
classificadas em dois grupos:
Comparacao de incidente por incidente: busca similaridade e diferencas entre suas
propriedades para classificacao;
Comparacoes teoricas: compara categorias em busca de conceitos similares ou diferen-
tes para revelar possıveis propriedades e dimensoes quando elas nao sao evidentes
para o analista.
Os processos de codificacao sao classificados em codificacao aberta, codificacao
axial e codificacao seletiva. Nao ha uma ordem previamente definida em termos de inıcio e
fim, ou seja, os processos podem ser executados em paralelo a medida que novos dados
sao coletados. Nas subsecoes abaixo sao descritos cada um dos processos.
4.2.1 Codificacao aberta
Para entende de forma aprofundada o que e de fato a codificacao aberta e necessario
compreender os termos que a cercam.
Os fenomenos sao as ideias centrais nos dados e sao representadas como conceitos.
Ja os conceitos sao os pilares que formam a teoria. As categorias sao os proprios conceitos
que representam os fenomenos e que sao caracterizadas pelas propriedades. Dentro das
propriedades, tem-se as dimensoes, que especificam as categorias e as subcategorias, que
ainda sao conceitos que pertencem a categoria e acrescentam especificacoes.
STRAUSS A.;CORBIN (2008) apresentam um exemplo simples desse processo: se
uma pessoa observa 10 objetos no ceu e os rotula como “passaros”, depois observa cinco
objetos diferentes e os rotula como “avioes”, e depois observa mais sete objetos e os chama
47
de “pipas”, mais cedo ou mais tarde ela pode se perguntar o que esses objetos tem em
comum e chegar ao conceito de “voo”. Esse termo nao apenas permite aos objetos serem
classificados, mas tambem explica o que eles estao fazendo (em termos de acao).
Tendo o conhecimento necessario sobre os termos que formam a codificacao aberta,
pode-se seguir para a criacao da teoria propriamente dita. Sao estabelecidos os conceitos,
definidas as categorias e desenvolvidas as propriedades e suas dimensoes e, se necessario,
criadas tambem subcategorias.
A conceituacao e um processo claro e linear que permite distinguir itens diferentes
e agrupar aqueles que sao semelhantes entre si, seguindo suas propriedades e dimensoes.
Tambem faz parte o ato de nomear essas categorias de maneira que represente a semelhanca
que as unem. E, quando se tem ja algumas categorias, especificam-se as suas propriedades.
Os conceitos sofrem alteracoes de acordo com as propriedades. Observam-se tambem
padroes de comportamento, que sao analisados a partir de especificacoes como as dimensoes.
Com dados, e criada uma base forte para a construcao da teoria.
4.2.2 Codificacao axial
A codificacao axial e a etapa seguinte no fluxo de codificacao. Ela se baseia no
processo de conectar categorias as suas devidas subcategorias. O seu nome e justificado
pelo elo entre uma categoria e os nıveis de propriedades e dimensoes. Ou seja, tudo gira em
torno de uma categoria. Os demais elementos que se deve tomar nota do seu significado
quando colocados neste contexto sao: paradigma, estrutura e processo. O paradigma e uma
ferramenta de analise. Para que se possa agregar estrutura com processo, o paradigma
se faz absolutamente necessario. A estrutura situa a categoria (fenomeno), isto e, fica
responsavel por fornecer um contexto que e capaz de especificar ainda mais a categoria em
que e referida. O processo nada mais e que uma serie de acoes relacionadas ao fenomeno e
a passagem de tempo. O ato de codificar em torno de uma categoria, partindo de um unico
eixo, fornece maior profundidade a analise. Desenvolve-se as categorias e entao procura-se
um meio de conecta-las, a partir daı parte-se para a construcao da teoria. Deve-se levar
em consideracao que o paradigma nada mais e do que uma ferramenta de analise, e um
instrumento para alcancar novos resultados e dados e nao uma verdade absoluta que
fornece uma unica resposta sobre o que e observado. Para os analistas nao ha um unico
48
momento em que os conceitos se relacionam. As pequenas conexoes vao fazendo sentido
em horas inesperadas, ate que o quebra-cabeca encaixa-se por inteiro. Nao ha um tempo
determinado para que se chegue a todos os conceitos relacionados, mas sim perıodos de
tempo em que se percebe o elo entre os conceitos e as conclusoes acontecem de pouco em
pouco.
4.2.3 Codificacao seletiva
Por fim, chegamos a codificacao seletiva. Depois das fases de codificacao aberta
e axial, inicia-se o processo de integracao e refinamento da teoria. Ha duas expressoes
que serao de extrema importancia para evoluir esta codificacao. A primeira delas e a
saturacao teorica. A fase da saturacao teorica faz parte do processo e cabe aos analistas
identificarem o momento em que nao aparecem mais propriedades, dimensoes ou relacoes
na analise. Ja a segunda expressao, e a de limite de variabilidade. Diz respeito ao nıvel de
variacao das dimensoes em relacao as suas propriedades, estabelece-se a variacao por meio
de amostragem. A codificacao seletiva configura-se como etapa final devido aos seus dois
elementos chaves apresentados acima: saturacao teorica e limite de variabilidade. Neste
ponto, os dados necessarios para o refinamento da teoria estao disponıveis; ocorre entao a
integracao dos dados iniciais da pesquisa ate as conclusoes finais. Com a teoria ja bem
integrada, e hora de refina-la. Para que possa ser validada, e preciso ser associada aos
dados brutos e reconhecida pelos participantes. Os conceitos devem ser reconhecidos por
eles, pelo menos de forma geral, para que possam ser confirmados.
4.3 Projeto
O projeto consiste em pesquisa qualitativa baseada em teoria fundamentada reali-
zada em empresas do segmento de desenvolvimento de sistemas. A execucao do projeto foi
realizada em entrevistas semiestruturadas baseado no processo da teoria fundamentada.
49
4.3.1 Projeto para coleta de dados
A Figura 4 ilustra os procedimentos para a execucao da pesquisa. O trabalho sera
realizado em tres grandes etapas, sendo que a primeira e a segunda etapa destinam-se a
coleta e a analise sistematica de dados, aplicando-se as tecnicas da teoria fundamentada
para determinar as categorias e a saturacao teorica.
Figura 4 – Processo de pesquisa teoria fundamentada
Fonte: Sergio Luis Barbieri, 2018
50
Para atender a etapa de coleta de dados, foram desenvolvidos questionario e guia de
entrevista. Foram aplicados duas formas de coleta de dados para as equipes participantes
do projeto. O Quadro 2 apresenta o guia de entrevista, que busca coletar o maximo de
informacoes de forma livre sobre as praticas e tecnicas utilizadas pela empresa. Ele foi
utilizado para os profissionais responsaveis pela coordenacao e lideranca de equipes de
desenvolvimento.
Quadro 2 – Guia Entrevista
Item Questao1 Qual e a melhor definicao para a sua empresa? (empresa com equipe propria
para desenvolvimento de sistema; empresa com equipe para desenvolvimentode sistema terceirizada; empresa prestadora de servico em desenvolvimentode sistema; empresa prestadora de servico em desenvolvimento de sistemaespecializada em teste de software; outra)
2 Quais tecnicas de teste sao utilizadas pela empresa? (funcional; estrutural;baseada em defeitos; desempenho; sistema; outras)
3 Como e definido o escopo de teste?4 Qual e o criterio de parada dos testes?5 Quais ferramentas de teste sao utilizadas pela equipe?6 Ferramentas de cobertura de codigo sao utilizadas pela empresa?7 Os testes sao automatizados?8 Como os resultados dos testes sao validados? Ha criterios de aceitacao?9 Quem e o responsavel pela validacao ou aceitacao?
Fonte: Sergio Luis Barbieri, 2018
4.3.2 Analise de dados
Para a analise dos dados foi utilizada a ferramenta ATLAS.ti Scientific Software
Development GmbH (2017), versao de avaliacao. A ferramenta e especifica para analise
qualitativa; ela permite a insercao das transcricoes, codificacao, geracao de categorias,
agrupamento das categorias, insercao de lembretes, relacionamentos, contagens de palavras
e ocorrencias etc. Possui uma diversidade de relatorios e exportacao de dados, auxiliando
no processo de execucao da metodologia.
4.4 Consideracoes finais
Este capıtulo apresentou suscintamente a tecnica de pesquisa qualitativa teoria
fundamentada, descrevendo como os dados sao coletados, os protocolos que foram utilizados
51
nas entrevistas e como os dados foram analisados. No proximo capitulo sera apresentado
os resultados da pesquisa.
52
5 Resultados do estudo qualitativo
Neste capıtulo, sera apresentado o resultado da pesquisa qualitativa com a tecnica
TF aplicada em cinco empresas. A tecnica foi conduzida por meio de entrevistas com cinco
profissionais.
A seguir, sera apresentada a descricao das empresas e os resultados obtidos.
5.1 Descricao do processo de selecao das empresas e dos indivıduos entrevistados
Foram selecionadas empresas de diversos segmentos e estrutura organizacional.
Todas as empresas, no momento das entrevistas, possuıam projetos em andamento. O
Quadro 3 ilustra as empresas participantes. A Empresa A desenvolvia um software para
propostas de seguro com multiplas funcionalidades (e.g., orcamento, endosso, renovacao
etc.). A Empresa B possui software destinado a integracao bancaria, chamado de frente de
caixa. O sistema combina tecnologias de interface graficas web e componentes de integracao
com o sistema de retaguarda (backoffice) de terceiros. A solucao e customizada para cada
cliente em razao das particularidades de cada instituicao bancaria. A Empresa C, por ser
especializada na prestacao de servicos de teste, possui um amplo historico de projetos,
destacando-se em sistemas especializados em transacoes bancarias e cartao de credito.
Ja a empresa Empresa D desenvolve sistema destinado a avaliacao e concessao de
credito, sendo seus principais clientes instituicoes bancarias e financeiras. O sistema passa
por constantes customizacoes para adequacao aos requisitos de cada cliente. Finalmente,
a empresa Empresa E desenvolve e mantem um produto destinado ao ramo imobiliario
comercial (real estate). O sistema possui funcionalidades de contratos, controle de obras,
administracao de condomınios, entre outras. As entrevistas foram aplicadas aos profissionais
responsaveis pela atividade de teste, sendo dois gerentes de projeto, dois coordenadores
e um analista de teste. As entrevistas foram realizadas seguindo o protocolo descrito no
capıtulo anterior. Os entrevistados estao demonstrados no Quadro 4. Todos os profissionais
tem expressiva vivencia na area de teste.
53
Quadro 3 – Empresas participantes x segmento
Identificador Segmento DescritivoEmpresa A Seguro Posicionada entre a maiores empresas do Brasil na cate-
goria seguros gerais.Empresa B Automacao Bancaria Solucoes bancarias de automacao e integracaoEmpresa C Prestador de servico Empresa especializada em testes; atende grandes clientes
em diversos segmentos com destaque para a area bancaria,cartao de credito e telefonia
Empresa D Financeiro Comercializa sistemas com produtos exclusivos para ava-liacao e concessao de credito. Grandes instituicoes finan-ceiras sao clientes.
Empresa E Setor imobiliario Empresa de medio porte; presta servico de desenvolvi-mento para a area imobiliaria comercial (real estate),provedor de comunicacao e servicos de datacenter.
Fonte: Sergio Luis Barbieri, 2018
Quadro 4 – Profissional x Experiencia
Empresa Profissional Experiencia em testeC Gerente de projeto 10 anosE Gerente de projeto 15 anosB Coordenador 5 anosD Coordenador 3 anosA Analista de teste 4 anos
Fonte: Sergio Luis Barbieri, 2018
5.2 Descricao do processo de coleta de dados
As entrevistas semiestruturadas foram utilizadas como instrumento de coleta de
dados. Elas foram gravadas e posteriormente transcritas em documento eletronico. Como
etapa final deste processo, os documentos foram inseridos na ferramenta ATLAS.ti Scientific
Software Development GmbH (2017). Ela permite unificar todos os documentos em um
unico ambiente e por meio de suas funcionalidades registrar a analise dos dados. As
proximas secoes descrevem os passos da analise.
5.3 Descricao do processo de analise de conteudo
As transcricoes foram analisados com o apoio da ferramenta Atlas.ti. A partir
das transcricoes inseridas na ferramenta, inicia-se a atividade de codificacao aberta, cujo
objetivo e identificar as categorias. A identificacao das categorias e a primeira etapa
da TF. Neste processo de codificacao a ferramenta permite a inclusao de “comentarios”
e “lembretes”. A medida em que novos documentos sao codificados, inicia-se tambem a
54
codificacao axial, processo que consiste no refinamento das categorias: juncao de categorias,
reclassificacao, entre outros.
Na etapa seguinte, da-se a codificacao seletiva. Nesta etapa, as categorias sao
agrupadas e relacionadas em um nıvel mais abstrato, surgindo os conceitos e a categoria
principal, cujo objetivo e formar a teoria. O resultado final do processo e apresentado no
Quadro 5.
Quadro 5 – Conceitos e categorias
Conceito CategoriaModelo organizacional Organizacao do trabalho
Desenvolvimento de sistemas com equipepropriaPorte da organizacaoPrestador de servico em teste de sistemas
Modelo e estrutura do projeto OrcamentoImagem da empresaPrazoProcesso de desenvolvimento de SoftwareRequisitos funcionaisTipo de sistema
Categoria principal CategoriaAbordagem de teste Conducao do teste
Metodo de desenvolvimentoTeste funcionalTeste nao funcionalVolume de teste
Fonte: Sergio Luis Barbieri, 2018
5.4 Resultados da analise de conteudo
Conforme conceituado no Capıtulo 4, a teoria e construıda a partir de dados,
sistematicamente reunidos e analisados, construindo um quadro teorico a partir dos
relacionamentos. Os conceitos, categorias e relacionamentos identificados pela pesquisa
sao apresentados na Figura 5.
Observe-se que na Figura 5 ha elementos de diferentes cores. Os retangulos brancos
representam o agrupamento de categorias que definem uma determinada teoria. As cores
para os demais retangulos foram utilizadas para destacar os grupos de categorias e
subcategorias associadas a teoria.
55
Figura 5 – Teoria resultante da analise dos dados
Fonte: Sergio Luis Barbieri, 2018
56
As linhas tracejadas na cor vermelha significam a conexao entre categoria e teoria,
ja as linhas solidas na cor preta significam a associacao da subcategoria com a categoria.
As associacoes podem ser das seguintes formas:“esta associada a”, “e parte de” ou “e
causa de”.
Nas proximas secoes, serao apresentados em detalhe os resultados obtidos.
5.4.1 Modelo organizacional
O conceito Modelo organizacional destacado na Figura 6 das empresas em sıntese
define como sera a organizacao do trabalho: prestadores de servicos, papeis e respon-
sabilidades. O porte da organizacao normalmente direciona a formacao da equipe de
desenvolvimento: propria, mista ou terceiros. Em equipes proprias, a possibilidade de
integracao das etapas de desenvolvimento e principalmente das atividades de teste e
um facilitador, apesar de nao haver evidencias consistentes sobre esse pratica nos dados
coletados.
A integracao observada foram apenas no compartilhamento dos requisitos funcionais,
base para elaboracao dos casos de teste. Em empresas com o processo verticalizado (equipe
propria em todas as etapas do desenvolvimento), ha uma definicao previa do plano de teste
que guia a elaboracao dos casos de teste e as tecnicas a serem aplicadas. O entrevistado
da Empresa D afirmou:“Hoje a gente recebe o software e juntamente com ele uma
documentacao com um plano de teste que tem passos a seguir...”.
Independente do modelo organizacional, constatou-se que os testes sao reexecutados
pelo contratante, porem, com um escopo menor. O entrevistado da Empresa B comentou:
“O cliente tambem testa...passa pelo teste deles que e a homologacao...”.
5.4.2 Modelo e estrutura do projeto
O conceito modelo e estrutura do projeto esta fundamentado em tres importantes
categorias: orcamento, prazo e tipo de sistema. O “orcamento” e decisivo para a escolha
das tecnicas e ferramentas de teste. O tempo e o grau de cobertura das atividades de teste
sao planejados conforme o orcamento disponıvel. O que o estudo observou foi a priorizacao
em testar funcionalidades “chaves” do sistema, seja por atendimento ao negocio, seja
57
Figura 6 – Modelo organizacional
Fonte: Sergio Luis Barbieri, 2018
para manter a imagem da empresa. A imagem da empresa esta relacionada a repercussao
negativa na ocorrencia de falhas em campo, devido a defeitos que permaneceram no
software, problemas de desempenho ou problemas de seguranca. O conceito esta destacado
na Figura 7,
O “tipo de sistema” e outro fator que determina uma tecnica ou tipo de teste.
Por exemplo, sistemas concebidos no modelo web tendem a utilizar testes funcionais; ja
sistemas baseados em Application Programming Interface (API), o estudo observou que a
preocupacao maior e o desempenho, sendo assim, uma boa parte do orcamento e tempo
dedicado a este requisito nao funcional.
A categoria “prazo” tem relacao direta a automatizacao de teste. A preocupacao
em automatizacao nao esta associada a facilitacao do teste em futuras manutencoes ou
implementacoes de novas funcionalidades, mas ao atendimento a prazos estabelecidos. Se
58
Figura 7 – Modelo e estrutura do projeto
Fonte: Sergio Luis Barbieri, 2018
uma determinada funcionalidade possui uma grande combinacao de entrada e a mesma
for consumir muito recursos para a execucao de forma manual, ela e uma candidata a
automatizacao.
5.4.3 Abordagem de teste
O conceito “abordagem de teste” e bem amplo e diversificado por conter varias
categorias e subcategorias relacionadas a esse conceito conforme destacado na Figura 7.
Uma das categorias de maior relevancia e a “conducao do teste”, associada a gestao do
teste. Ela e a atividade de maior relevancia para o gestor. Ha uma grande preocupacao em
documentar a conducao das atividades de teste, principalmente em criar evidencias dos
59
trabalhos realizados nesta etapa. O produto final desta atividade e um relatorio com o
detalhamento de todas as atividades de teste.
Esta atividade e sempre apoiada por ferramentas apropriadas, seja de uso comercial
(licenciada ou gratuita), seja propria (desenvolvimento interno). Outras ferramentas asso-
ciadas a gestao sao aquelas que nao testam propriamente o sistema, apenas apresentam
indicadores da qualidade do desenvolvimento. Entre os indicadores observados, podem ser
citados padronizacao do codigo (e.g., adocao de nomes de variaveis e rotinas, organizacao
dos blocos) e metricas de cobertura estrutural. A cobertura estrutural, neste contexto,
representa um direcionamento do que pode ser esperado na execucao de outras tecnicas de
teste (e.g., estrutural).
Figura 8 – Abordagem de teste
Fonte: Sergio Luis Barbieri, 2018
O entrevistado da Empresa C com mais de 10 anos de atuacao na area comentou:
“Ja vi projetos com cobertura de 90% ou mais com muito mais erros do que projetos sem
teste casos de teste ou cobertura..”.
Nota-se que o objetivo do teste e cumprir a etapa, sem a preocupacao em inovacao,
de melhoria de processo ou em utilizar a melhor tecnica.
60
Teste funcional x teste estrutural
Conforme descrito na secao anterior, a escolha de tecnicas de teste nao esta
diretamente relacionada em utilizar a melhor tecnica ou ferramenta, mas no cumprimento
da etapa de teste com os respectivos registros: relatorios e evidencias. Sendo assim, a
definicao do plano de teste nao leva em consideracao uma discussao mais profunda sobre o
tema.
Tambem foi identificado que a tarefa de teste e executada por terceiros que fazem
parte da equipe de projeto, porem, seguindo os padroes do contratante e muitas vezes
utilizando as ferramentas e controles definidos pelo contratante.
Automatizacao
Conforme citado acima, a automatizacao esta relacionada apenas a reducao do
esforco manual em etapas especificas do teste, a qual e claramente percebida uma repeticao
e impossibilidade de execucao por pessoas. O estudo tambem evidenciou outras situacoes
relacionadas a esse tema:
• falta de conhecimento das equipes em ferramentas de automatizacao;
• falta de pratica no uso das ferramentas, gerando aumento da carga de trabalho na
concepcao do software;
• preocupacao em cumprir o escopo e prazo apenas do projeto atual, sem a visao em
utilizar os casos de teste automatizados em ciclos futuros (e.g., manutencao).
Teste nao funcional x ferramentas
No estudo, as ferramentas de teste citadas (e.g., JMeter1) estao relacionadas a
testes de desempenho e carga cujo objetivo e atender requisitos nao funcionais. Requisitos
nao funcionais normalmente sao executados com a apoio de ferramentas que ja possuem
funcionalidades intrınsecas de automatizacao. O entrevistado da Empresa C citou exem-
plos de segmentos e funcionalidades nas quais o tempo de resposta e a maior preocupacao
(e.g., transacoes bancarias, cartao de credito, e-commerce) para a homologacao do software.
1 〈http://jmeter.apache.org/〉
61
As ferramentas de teste de requisitos nao funcionais sao uteis para testes de sistemas que
utilizam computacao em nuvem e fazem uso de APIs. Uma relacao mais profunda entre
arquitetura de sistemas e tecnicas de teste nao foi abordada por essa pesquisa.
5.5 Teoria resultado da aplicacao da analise fundamentada
O ponto principal da teoria fundamentada e a geracao da teoria a partir do
desenvolvimento e relacionamentos das categorias com o objetivo de formar um quadro
teorico. Baseado na analise dos resultados discutidos nas secoes anteriores, o estudo chegou
a seguinte teoria em relacao a como as empresas conduzem as atividades de teste e quais
os fatores que influenciam ou determinam o teste nas empresas participantes.
A abordagem de teste e dependente do modelo organizacional que e responsavel por
definir a estrutura do projeto na formacao da equipe. A formacao da equipe e determinante
na organizacao e conducao dos trabalhos. A organizacao dos trabalhos, normalmente
constituıda por prestadores de servicos, direciona a adocao de modelos e tecnicas basicas
de teste, com baixa inovacao ou foco apenas no ciclo atual do software.
Adicionalmente, ha fatores combinados que contribuem para a abordagem de teste:
“prazo e orcamento”, “conhecimento tecnico da equipe e metodo de desenvolvimento”
e “tipo de sistema”. Prazo e orcamento sao temas relacionados exclusivamente a uma
etapa especıfica do ciclo de vida do projeto, reduzindo a possibilidades de implementar
automatizacoes e uso de novas tecnicas para serem utilizadas no futuro. Tais implementacoes
sao potenciais redutores de custos e tempo em manutencoes ou implementacoes de novas
funcionalidades. O conhecimento tecnico e experiencia dos gestores tendem a executar
as atividades de forma padrao. Mesmo em equipes verticalizadas com metodos “ageis”,
notou-se ausencia de integracao e inovacao. O tipo de sistema e a categoria que mais forca
o uso de ferramentas de teste, principalmente para validar os requisitos nao funcionais.
5.6 Ameacas a validade
Levando em conta que se trata de um projeto de pesquisa, vale lembrar que ele e
influenciado por alguns fatores que impoem ameacas a validade interna, a validade externa
e a validade de conclusao.
62
A validade interna verifica fatores que podem ter afetado a pesquisa. Neste trabalho,
por tratar de entrevistas, os entrevistados podem ter respondidos de uma maneira subjetiva
e nao da forma que realmente executam as atividades de teste. Mesmo com o aspecto
confidencialidade garantido, poderiam existir deficiencias ou ausencias de controles na
conducao dos trabalhos que os entrevistados deixaram de citar para nao prejudicar a
imagem da empresa ou sua falta de capacitacao para a gestao das atividades.
A validade externa define as condicoes que limitam a habilidade de generalizar
os resultados. Os resultados obtidos sobre como e realizada a atividade de teste em
ambientes industriais de desenvolvimento foi limitada ao grupo de empresas que nao
representa a totalidade dos modelos empresariais existentes, nem todos os segmentos de
negocios e tambem as possıveis metodologias de desenvolvimento utilizadas na industria
de software. Porem, a base para a teoria apresentada representa uma parte significativa da
industria, tanto em modelo organizacional, porte e segmento. Deste universo, o processo
de desenvolvimento utilizando os servicos de fabrica de software nao foi avaliado e, por
consequencia, poderia surgir informacoes adicionais ao trabalho.
A validade de conclusao avalia a legitimidade do correlacionamento das variaveis
que podem induzir a um resultado equivocado. A pesquisa qualitativa com a tecnica TF
atingiu a saturacao teorica nas investigacoes considerando a amostragem das empresas e
profissionais entrevistados, representando de forma adequada as conclusoes apresentadas.
5.7 Consideracoes finais
Neste capıtulo foi apresentada as caracterısticas da empresas que participaram do
experimento, os profissionais entrevistados e como foi conduzida as atividades de analise
dos resultados.
Como resultado da aplicacao da tecnica TF, conclui-se que a estrutura organizacional
direciona a adocao de modelos e tecnicas de teste, com pouca inovacao ou foco apenas no
ciclo atual do software. Fatores adicionais, como prazo e orcamento, reduzem a possibilidade
de automatizacao. A experiencia dos gestores pode contribuir para inovacao. O tipo de
sistema e a categoria que mais direciona na escolha da tecnica de teste.
No proximo capıtulo, serao apresentados as conclusoes e trabalhos futuros.
63
6 Conclusoes
Este capıtulo sintetiza os pontos importantes da conducao do experimento realizado
com gestores em cinco empresas que desenvolvem software. O foco da investigacao foi em
entender como sao realizadas as atividades de teste na industria de software e desenvolver
uma teoria sobre a organizacao da atividade de teste.
6.1 Sıntese do trabalho
As atividades de teste podem variar intensamente dependendo de fatores como
orcamento de teste, metodo de desenvolvimento utilizado, perfil do cliente, tipo de software,
entre outros. O estudo avaliou as atividades de teste em cinco empresas brasileiras
desenvolvedoras de software.
Por meio de uma pesquisa qualitativa utilizando a teoria fundamentada (TF) foram
realizadas coleta de dados com cinco profissionais da area de teste. Foi elaborado um guia
de entrevista semiestruturada para ser o instrumento de coleta em campo. Ele foi utilizado
durante a coleta de dados com cinco gestores de teste participantes. Em seguida, na etapa
de analise, as entrevistas foram transcritas e inseridas no software ATLAS.ti Scientific
Software Development GmbH (2017). O Atlas.ti e uma ferramenta que apoia a analise
qualitativa, em especial a aplicacao da TF; ele possui funcionalidades para organizar e gerir
o material de forma sistematica, adequada para aplicar a TF. O objetivo da TF e formar
uma teoria a partir do desenvolvimento e relacionamentos das categorias interpretadas
nos dados analisados.
Como resultado final da analise, o estudo observou quatro pontos relevantes sobre
como as atividades de teste sao organizadas nas empresas que participaram desta pesquisa:
1. Dependencia do modelo organizacional. A formacao da equipe em modelo terceirizado,
na qual prestadores de servico participam do desenvolvimento, direciona a adocao
de modelos e tecnicas basicas de teste, com baixa inovacao ou foco apenas no ciclo
atual do software.
2. Prazo e orcamento. Foco apenas na fase atual do projeto reduz a possibilidades de
implementar automatizacoes e uso de novas tecnicas para serem utilizadas no futuro
(e.g., manutencoes, novas funcionalidades).
64
3. Conhecimento tecnico e experiencia. A escolha de tecnicas e inovacao e dependente
do gestor e da integracao da equipe.
4. Tipo de sistema. Categoria que mais induz ao uso de ferramentas de teste, principal-
mente para validar os requisitos nao funcionais.
6.2 Contribuicoes
As principais contribuicoes apresentadas por esse trabalho sao descritas a seguir.
1. Uso de teoria fundamentada em atividades de teste no Brasil. Que seja de nosso
conhecimento, essa e a primeira pesquisa qualitativa utilizando teoria fundamentada
para caracterizar a atividade de teste em empresas brasileiras de desenvolvimento de
software.
2. Teoria da atividade de teste em empresas brasileiras. Foi desenvolvido um modelo da
atividade de teste a partir do uso da tecnica teoria fundamentada em cinco empresas
brasileiras.
3. Identificacao de fatores relevantes para a atividade de teste. Observou-se que a
estrutura organizacional direciona a escolha das tecnicas e ferramentas, bem como
o tipo do sistema; o prazo e orcamento condicionam a utilizacao de tecnicas de
automatizacao.
6.3 Trabalhos futuros
Este trabalho e o inıcio de um esforco de pesquisa qualitativa que visa caracterizar
a atividade de teste na pratica. Ele baseou-se apenas nas informacoes dos gestores de
teste. Porem, ele pode ser estendido por meio da coleta de dados dos desenvolvedores. Por
exemplo, eles podem ser observados in loco realizando as atividades de teste; entrevistas
e questionarios especıficos para esses atores podem ser utilizados. Dessa maneira, sera
possıvel caracterizar a atividade de teste de outro ponto de vista.
Alem disso, estudos qualitativos semelhantes podem ser realizados considerando
empresas desenvolvedoras de software especıficos (e.g., sistemas embarcados), empresas
nas quais a tecnologia e a atividade fim, empresas nas quais a tecnologia e atividade meio
e empresas com modelo de negocio baseado em fabrica de software.
65
Referencias1
AMMANN, P.; OFFUTT, J. Introduction to Software Testing. 2. ed. New York, NY, USA:Cambridge University Press, 2017. Citado 3 vezes nas paginas 18, 21 e 22.
ATLAS.ti Scientific Software Development GmbH. Atlas.ti. 2017. Disponıvel em:〈http://atlasti.com〉. Citado 3 vezes nas paginas 50, 53 e 63.
BECK, K. Test Driven Development: By Example. [S.l.]: Addison-Wesley Professional,2002. Citado 2 vezes nas paginas 22 e 34.
BECK, K.; ANDRES, C. Extreme Programming Explained: Embrace Change (2NdEdition). [S.l.]: Addison-Wesley Professional, 2004. ISBN 0321278658. Citado na pagina22.
BERLOWSKI, J. et al. Highly automated agile testing process: An industrial case study.e-Informatica Software Engineering Journal, v. 10, n. 1, p. 69–87, 2016. Citado 2 vezesnas paginas 34 e 37.
COLEMAN, G.; O’CONNOR, R. Investigating software process in practice: A groundedtheory perspective. Journal of Systems and Software, v. 81, n. 5, p. 772–784, 2008. Citado2 vezes nas paginas 34 e 38.
CRUZES, D. et al. How is security testing done in agile teams? a cross-case analysis offour software teams. Lecture Notes in Business Information Processing, v. 283, p. 201–216,2017. Citado 2 vezes nas paginas 34 e 40.
DEAK, A.; STALHANE, T. Organization of testing activities in norwegian softwarecompanies. In: 2013 IEEE Sixth International Conference on Software Testing, Verificationand Validation Workshops. [S.l.: s.n.], 2013. p. 102–107. Citado 2 vezes nas paginas 34e 35.
DELAMARO M. E.; MALDONADO, J. C. M. Introducao ao teste de software. [S.l.]:Elsevier, 2007. Citado 2 vezes nas paginas 15 e 24.
DELAMARO M. E.;CHAIM, M. L. A. M. R. Tecnicas e Ferramentas de Teste deSoftware. 1. ed. [S.l.]: BOOKMAN, 2010. Citado 2 vezes nas paginas 30 e 31.
GREILER, M.; DEURSEN, A. van; STOREY, M. A. Test confessions: A study oftesting practices for plug-in systems. In: 2012 34th International Conference on SoftwareEngineering (ICSE). [S.l.: s.n.], 2012. p. 244–254. ISSN 0270-5257. Citado 2 vezes naspaginas 34 e 37.
HENDRICK, D. Using Grounded Theory to Develop a Framework for Software TestingBest Practice in a Telecommunications Company. Tese (Doutorado) — Dublin Institute ofTechnology, 2013. Citado 2 vezes nas paginas 34 e 39.
IEEE. IEEE Standard Glossary of Software Engineering Terminology (IEEE Std610.12-1990). 1990. Disponıvel em: 〈http://www.mit.jyu.fi/ope/kurssit/TIES462/Materiaalit/IEEE SoftwareEngGlossary.pdf〉. Citado na pagina 18.
1 De acordo com a Associacao Brasileira de Normas Tecnicas. NBR 6023.
66
JUNIT. JUnit 5 Testing Framework. 2018. Http://www.junit.org/. Acessado em 02 defevereiro de 2018. Citado na pagina 31.
MATHUR, A. P. Foundations of software testing. 2. ed. [S.l.]: Pearson, 2009. Citado 2vezes nas paginas 15 e 23.
MCCABE, T. A complexity measure. v. 2, n. 4, p. 308–320, dez. 1976. Citado na pagina27.
MCGREGOR, J. D. Test early, test often. v. 6, n. 4, p. 7–14, maio 2007. Available on-lineat: 〈http://www.jot.fm/issues/issue 2007 05/column1〉 [08-08-2007]. Citado na pagina 22.
MOCKUS, A.; NAGAPPAN, N.; DINH-TRONG, T. T. Test coverage and post-verificationdefects: A multiple case study. In: 2009 3rd International Symposium on EmpiricalSoftware Engineering and Measurement. [S.l.: s.n.], 2009. p. 291–301. ISSN 1949-3770.Citado 2 vezes nas paginas 34 e 36.
MOIR, K. Releng of the nerds: Open source release engineering. SDK code coveragewith JaCoCo. 2011. Disponıvel em: 〈http://relengofthenerds.blogspot.com.br/2011/03/sdk-code-coverage-with-jacoco.html〉. Citado na pagina 29.
MYERS G. J.;SANDLER, C. T. T. The Art of Software Testing. [S.l.]: Wiley, New York,2004. Citado 3 vezes nas paginas 15, 24 e 25.
PRESSMAN, R. S. Engenharia de Software. 6. ed. [S.l.]: McGraw-Hill, 2006. Citado 4vezes nas paginas 22, 24, 30 e 31.
ROBSON, C. Real World Research. 3. ed. [S.l.]: Wiley, 2011. Citado 3 vezes nas paginas43, 44 e 45.
SELENIUM. Selenium IDE – Integrated development environment for Selenium tests.2018. Http://www.seleniumhq.org/projects/ide/. Acessado em 01 de fevereiro de 2018.Citado na pagina 31.
SOMMERVILE, I. Engenharia de Software. 9. ed. [S.l.]: Addison-Wesley Brasil, 2011.Citado 2 vezes nas paginas 21 e 23.
STRAUSS A.;CORBIN, J. Pesquisa Qualitativa - Tecnicas e procedimentos para odesenvolvimento de pesquisa fundamentada. 2. ed. [S.l.]: BOOKMAN, 2008. Citado 4vezes nas paginas 17, 42, 45 e 46.
TAIPALE, O.; SMOLANDER, K. Improving software testing by observing practice. In:Proceedings of the 2006 ACM/IEEE International Symposium on Empirical SoftwareEngineering. New York, NY, USA: ACM, 2006. (ISESE ’06), p. 262–271. ISBN1-59593-218-6. Citado 2 vezes nas paginas 34 e 40.
THOMSON, C. D.; HOLCOMBE, M.; SIMONS, A. J. H. What makes testing work: Ninecase studies of software development teams. In: 2009 Testing: Academic and IndustrialConference - Practice and Research Techniques. [S.l.: s.n.], 2009. p. 167–175. Citado napagina 34.
VINCENZI, A. M. R. et al. Automatizacao de Teste de Software com Ferramentas deSoftware Livre. Primeira. Rio de Janeiro: Elsevier, 2018. No prelo. Citado na pagina 21.
67
ZELLER, A. Why Programs Fail:A Guide to Systematic Debugging. [S.l.]: MorganKaufmann Publishers Inc, 2005. Citado 2 vezes nas paginas 18 e 20.
68
Apendice A – Utilizacao da ferramenta JaCoCo
A EclEmma/JaCoCo coleta as informacoes de cobertura de fluxo de controle por
meio da execucao do programa. Ha varias formas de executar o programa e obter a
cobertura de codigo, sendo as mais comuns por meio da execucao do programa como
uma aplicacao Java local ou a execucao de casos de teste automatizados por meio de
bibliotecas como JUnit1, TestNG2 e SWTBot3. Como EclEmma/JaCoCo instrumenta
o codigo compilado em Bytecodes, a ferramenta tambem pode coletar a cobertura de
aplicacoes escritas em Scala4.
O exemplo de utilizacao da EclEmma/JaCoCo obtem a cobertura por meio de
uma chamada ao metodo CalcularMDC() utilizando a biblioteca JUnit. A classe com a
chamada do teste esta descrita na Figura 9.
Figura 9 – Classe de teste do metodo calcularMDC
1 package Programa . Exemplo ;23 import s t a t i c org . j u n i t . Assert . ∗ ;4 import org . j u n i t . Test ;56 pub l i c% c l a s s MDCTest {78 Publ ic void testCalcularMDC ( ) {9
10 a s s e r tEqua l s (8 , MDC. calcularMDC (8 , 1 6 ) ) ;1112 }13 }
Fonte: Sergio Luis Barbieri, 2018
Por padrao, EclEmma/JaCoCo executa todos os metodos com a anotacao @Test
da biblioteca Junit. Ao clicar no botao de cobertura o teste e executado e a cobertura
coletada para todo o codigo. E possıvel determinar as classes que serao avaliadas com
relacao a analise de cobertura. Para tanto, deve-se utilizar o submenu disponıvel no botao
de cobertura e selecionar a opcao Coverage Configurations... Outra alternativa e executar
1 〈http://junit.org/junit4/〉2 〈http://testng.org/doc/index.html〉3 〈http://www.eclipse.org/swtbot/〉4 〈https://www.scala-lang.org/〉
69
o teste no menu Run as JUnit Test e apos a finalizacao dos testes, gerar a cobertura no
menu Run Coverage Last Launched.
A.1 Relatorios Gerados e Analise dos Dados Produzidos
Ao termino da cobertura o Eclipse abre automaticamente a perspectiva Coverage.
A Figura 10 apresenta uma visao geral sobre os testes executados. No exemplo, sao
apresentados os resultados para o metodo calcularMDC(). Note-se que com a execucao
do teste (calculo do maximo divisor comum entre 8 e 16) foi obtida a cobertura de
16,7% considerando o criterio complexidade (Complexity), ou seja, o metodo possui cinco
caminhos e o teste percorreu apenas um caminho.
Figura 10 – Cobertura de complexidade utilizando a EclEmma/JaCoCo
Fonte: Sergio Luis Barbieri, 2018
Trocando a visao de cobertura para instrucoes (Instructions) utilizando o menu
View (Figura 11), verifica-se que o metodo calcularMDC() possui 43 instrucoes e o teste
teve uma cobertura de 28 instrucoes. Observe-se que o numero de instrucoes e maior que
o numero de linhas do Programa 14. Isso ocorre porque a EclEmma/JaCoCo instrumenta
o codigo compilado em Bytecodes que, por sua vez, possui mais instrucoes. A Figura 12
mostra a visao de ramos (Branches) que apresenta cobertura de 50%, ou seja, metade dos
ramos foram cobertos pelo caso de teste.
A Figura 13 apresenta o resultado em forma de resumo da analise de cobertura,
chamada de Session pela EclEmma/JaCoCo. A janela e apresentada utilizando a opcao
Properties a partir de qualquer “Elemento” da perspectiva Coverage. Note-se que alem
das coberturas discutidas nas Figuras 10, 11 e 12 o resumo tambem apresenta a cobertura
70
Figura 11 – Cobertura de instrucoes utilizando a EclEmma/JaCoCo
Fonte: Sergio Luis Barbieri, 2018
Figura 12 – Cobertura de ramos utilizando EclEmma/JaCoCo
Fonte: Sergio Luis Barbieri, 2018
de linhas, metodos e tipos (classes). As informacoes de cobertura da Figura 13 envolvem
todo o programa e nao apenas o metodo calcularMDC().
A Figura 14 apresenta a cobertura no codigo para a execucao do metodo calcularMDC-
() com os valores 8 e 16 para os parametros valor1 e valor2, respectivamente. Para todos
os metodos executados o sistema registra qual foi a cobertura para cada linha de codigo:
linhas em vermelho — nao exercitadas; linhas em verde — totalmente exercitada; e linha
em amarelo — parcialmente exercitada. As linhas amarelas estao associadas a comandos de
decisao. Uma linha amarela nesses casos significa que apenas uma das condicoes associadas
ao comando foi exercitada pelos casos de teste.
Adicionalmente, ao lado esquerdo da linha, e apresentado um ıcone diamante com
informacoes adicionais em relacao a cobertura. Ao passar o mouse sobre o ıcone da linha
11 sera apresentado o numero de desvios nao cobertos.
71
Figura 13 – Resumo da analise de cobertura realizada pela EclEmma/JaCoCo
Fonte: Sergio Luis Barbieri, 2018
Para obter-se 100% da cobertura dos desvios e necessario o conjunto de testes
apresentado na Figura 15:
72
Figura 14 – Analise de cobertura realizada pela EclEmma/JaCoCo no codigo fonte
Fonte: Sergio Luis Barbieri, 2018
Figura 15 – Trecho de codigo para cobertura de 100% do metodo calcularMDC
1 Publ ic void testCalcularMDC ( ) {23 a s s e r tEqua l s (8 , MDC. calcularMDC (8 , 1 6 ) ) ;4 a s s e r tEqua l s (1 , MDC. calcularMDC (7 , 4 ) ) ;5 a s s e r tEqua l s (10 , MDC. calcularMDC (10 , 1 0 ) ) ;6 a s s e r tEqua l s (−1 , MDC. calcularMDC (0 , 2 ) ) ;7 a s s e r tEqua l s (−1 , MDC. calcularMDC (2 , 0 ) ) ;89 }
10 }
Fonte: Sergio Luis Barbieri, 2018
73
Apendice B – Termo de consentimento livre e esclarecido
A seguir e apresentado o modelo original do termo submetido aos participantes das
entrevistas.
TERMO DE CONSENTIMENTO LIVRE E ESCLARECIDO
Título do projeto de pesquisa: Teste de software na indústria: Um estudo
qualitativo.
Pesquisador: Sérgio Luis Barbieri.
O (a) Sr. (a) está sendo convidado (a) a participar da pesquisa “Teste de software
na indústria: Um estudo de caso qualitativo”. Nesta pesquisa pretendemos identificar as
técnicas de teste utilizadas pelas equipes de desenvolvimento, práticas adotadas, quais
métricas e critérios são definidos nos processos de aceite e quais ferramentas são
adotadas. O objetivo da pesquisa é entender como a indústria aplica as técnicas de teste e
quais ferramentas de teste são adotadas no ciclo de desenvolvimento de sistemas.
O (a) Sr. (a) tem o direito de interromper sua participação na pesquisa a qualquer
momento. Os riscos associados à sua participação são mínimos.
A participação compreende em uma entrevista que terá a duração de 30 minutos
direcionada aos gestores da área, a aplicação do questionário de 15 minutos para os
profissionais envolvidos no processo de teste e o acompanhamento de uma sessão de teste
como observador.
Leia atentamente os itens a seguir e assine no campo adequado deste termo caso
aprove as seguintes condições:
1. A entrevista será gravada e uma transcrição será realizada.
2. Você receberá a transcrição da entrevista e poderá corrigir seu conteúdo
caso haja erros na transcrição.
3. A transcrição da entrevista será realizada e analisada pelo pesquisador
principal do projeto: Sérgio Luis Barbieri.
4. O acesso à transcrição da entrevista será limitado ao pesquisador principal
do projeto, a acadêmicos e demais colaboradores desta pesquisa.
5. As sessões de teste serão observadas e transcritas pelo pesquisador
principal do projeto: Sérgio Luís Barbieri.
6. O acesso à transcrição das sessões de teste observadas será limitado ao
pesquisador principal do projeto, a acadêmicos e demais colaboradores desta pesquisa.
7. Resumos do conteúdo das entrevistas e sessões de teste ou citações diretas
a trechos delas, utilizados em publicações acadêmicas ou outros meios acadêmicos serão
apresentados de forma anônima de maneira a garantir que sua identidade não seja
revelada. Além disso, cautelas serão tomadas para que qualquer outra informação da
entrevista ou da sessão de teste que possa levar sua identificação seja omitida.
74
8. A gravação da entrevista será mantida para registro da pesquisa e possível
análise por outros pesquisadores durante um período de cinco anos. Durante esse período,
todos os cuidados de sigilo serão mantidos quanto à utilização do conteúdo da entrevista.
9. O questionário não necessitará da identificação do respondente.
10. Qualquer alteração dos itens acima ocorrerá apenas com a sua aprovação.
Acordo de citação
No que diz respeito a ser citado, favor assinalar ao lado de qualquer uma
das declarações com as quais concorda.
Em relação a citação, entendo que minhas palavras podem ser citadas diretamente. Desejo rever as notas, transcrições ou outros dados relacionados à minha participação, recolhidos durante a entrevista ou sessão de teste. Concordo em ser citado diretamente. Concordo em ser citado diretamente se meu nome não for publicado e um pseudônimo for utilizado. Concordo que os pesquisadores podem publicar documentos que contenham citações minhas.
Todo ou parte do conteúdo da entrevista poderá ser usado:
1. Em eventos acadêmicos.
2. Em artigos acadêmicos e apresentações de trabalhos.
3. Em nosso website e outros meios de divulgação como apresentações e
eventos de discussão científica.
4. Em um arquivo do projeto conforme observado acima.
Ao assinar este formulário eu concordo que: 1. Participo voluntariamente deste projeto.
2. Eu entendo que posso interromper minha participação na entrevista ou da
sessão de teste a qualquer momento.
3. A entrevista ou sessão de teste transcrita ou os seus fragmentos podem ser
utilizados como descrito acima.
4. Não espero receber qualquer benefício ou pagamento por minha
participação.
75
5. Posso solicitar uma cópia da transcrição da minha entrevista ou da sessão
de teste que participei, bem como realizar alterações para assegurar a eficácia o acordo
de confidencialidade.
6. Posso fazer perguntas antes, durante e depois da entrevista ou sessão de teste.
7. Tive oportunidade de perguntar qualquer dúvida que tenha surgido e que
sou livre para entrar em contato com o pesquisador a qualquer momento, sanando
possíveis dúvidas em relação a entrevista que possam surgir no futuro.
Os procedimentos éticos para pesquisas acadêmicas exigem que os entrevistados
concordem explicitamente em serem entrevistados e como as informações contidas em
sua entrevista serão usadas
__________________________________________ _____/______/______
Assinatura do participante Data
__________________________________________ _____/______/______
Assinatura do pesquisador Data Informações de contato
Em caso de dúvidas sobre este estudo, por favor entre em contato:
Nome do pesquisador: Sérgio Luis Barbieri.
Endereço: Rua Professor Pedreira de Freitas, 179 AP 131. Bairro: Tatuapé, São Paulo - SP, CEP: 03312-052
Tel.: (11) 94071-8994
E-mail: [email protected].
Este termo de consentimento encontra-se impresso em duas vias originais, sendo que uma será arquivada pelo pesquisador responsável, na Universidade de São Paulo e a outra será fornecida ao (a) Sr. (a). Os dados e instrumentos utilizados na pesquisa ficarão arquivados com o pesquisador responsável por um período de 5 (cinco) anos, e após esse tempo serão destruídos. Em caso de dúvidas e problemas o (a) Sr. (a) poderá se dirigir diretamente ao pesquisador principal desse projeto.
76
Top Related