PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
Dissertação de Mestrado
Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao
RECIFE, MARÇO/2014
“
GERENCIAMENTO DE EQUIPES DE TESTE
DE SOFTWARE DISTRIBUÍDAS: DESAFIOS E
BOAS PRÁTICAS”
Por
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
DÁCIO NERY DE MENDONÇA NETO
“
GERENCIAMENTO DE EQUIPES DE TESTE DE SOFTWARE
DISTRIBUÍDAS: DESAFIOS E BOAS PRÁTICAS”
ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA COMPUTAÇÃO.
ORIENTADOR: HERMANO PERRELLI DE MOURA
Catalogação na fonte
Bibliotecário Joana D’Arc L. Salvador, CRB 4-572
Mendonça Neto, Dácio Nery de.
Gerenciamento de equipes de teste de software distribuídas: desafios e boas práticas / Dácio Nery de Mendonça Neto. – Recife: O Autor, 2014.
127 f.: fig., tab., quadro.
Orientador: Hermano Perrelli de Moura.
Dissertação (Mestrado) - Universidade Federal de Pernambuco. CIN. Ciência da Computação, 2014.
Inclui referências e apêndices.
1. Software - Testes. 2. Gerenciamento de projetos. 3. Desenvolvimento distribuído de software. I. Moura, Hermano Perrelli de (orientador). II. Título.
Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título “GERENCIAMENTO DE EQUIPES DE TESTE DE
SOFTWARE DISTRIBUÍDAS: DESAFIOS E BOAS PRÁTICAS” orientada pelo Prof. Hermano Perrelli de Moura e aprovada pela Banca Examinadora formada pelos
professores:
_______________________________________________ Prof. Alexandre Marcos Lins de Vasconcelos
Centro de Informática / UFPE
_______________________________________________ Prof. José Gilson Almeida Teixeira Filho
Departamento de Ciências Administrativas / UFPE
_______________________________________________ Prof. Hermano Perrelli de Moura
Centro de Informática / UFPE
Visto e permitida a impressão. Recife, 17 de março de 2014.
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
Dedico este trabalho aos meus pais Antonio Nery e Ivanilda Bastos pela plena dedicação, apoio e presença em todos os momentos mais importantes da minha vida.
A minha esposa, Suzane Mendonça que sempre me confortou e incentivou nos momentos mais difíceis com bastante carinho e amor.
Primeiramente, agradeço a Deus que me proporcionou a vida, e por me cercar de pessoas especiais, sem as quais este trabalho não teria sido concluído.
Agradeço a minha esposa Suzane Mendonça, pelo carinho, pelo apoio, pela paciência e pela compreensão durante os altos e baixos vivenciados durante o desenvolvimento deste trabalho.
A todos os entrevistados, pela rica contribuição e disponibilidade. Aos meus colegas de mestrado, pelas discussões e trabalhos.
Quero agradecer as pessoas que estiveram presentes ao meu lado durante os dois anos de dura caminhada. Quero destacar entre elas: Professor Hermano Perrelli de Moura, meu orientador que me aceitou como seu orientando, confiando no meu trabalho. Além de outros amigos que também colaboraram com a minha trajetória.
“Try to learn something about everything and everything about something." Thomas Henry Huxley.
A área de teste de software é muito importante, pois o teste é um dos instrumentos utilizados para determinar a qualidade do software. As empresas de software vêm adotando muitas estratégias em busca de diferenciais para manter-se competitivas no mercado. Nos últimos anos, os projetos de desenvolvimento de software estão se tornando cada vez mais distribuídos. Existem vários desafios relacionados a equipes de teste, principalmente quando as mesmas estão distribuídas, devido especialmente a aspectos como a dispersão geográfica, dispersão temporal e diferenças culturais. Embora a área de teste esteja ganhando cada vez mais notoriedade, existe uma carência de estudos empíricos que permitem enumerar medidas confiáveis relacionadas com o gerenciamento de teste em ambientes distribuídos. O objetivo desta dissertação é identificar os desafios no gerenciamento de equipes de teste distribuídas no intuito de levantar boas práticas para minimizar os desafios encontrados. Para identificar os desafios, foram realizadas nove entrevistas semiestruturadas com gerentes e líderes que têm experiência no gerenciamento de equipes de teste distribuídas em empresas privadas tanto no Brasil quanto nos Estados Unidos. Após a análise dos dados das entrevistas, foram levantados 31 desafios separados em dez grandes áreas. Para minimizar os desafios encontrados foram indicados dez grupos de boas práticas baseados na literatura, os artigos foram retirados dos sites de buscas como: IEEE, Science Direct, Google Scholar e ACM Digital Library, posteriormente os grupos de boas práticas foram avaliados por oito profissionais que atuam em cargo de liderança em equipes de teste distribuídas através de um questionário. O propósito principal da avaliação foi identificar se os entrevistados acreditam que os grupos de boas práticas indicados ajudam a minimizar os desafios em equipes de teste distribuídas e levantar quais as recomendações já são utilizadas pelos mesmos. A avaliação positiva dos entrevistados quanto aos grupos de boas práticas, indica que as recomendações podem ajudar no gerenciamento das equipes de teste distribuídas. Este trabalho contribuiu com o levantamento dos desafios no gerenciamento de equipes de teste distribuídas, indicação de dez grupos de boas práticas e no levantamento das recomendações já utilizadas nas grandes empresas. Apesar de algumas recomendações já serem utilizadas, é necessário cada vez mais difundir boas práticas para apoiar esse tipo de gerenciamento.
Palavras-chave: Teste de Software, Gerenciamento de Projetos, Desenvolvimento
The software testing area is very important, because the test is one of the instruments used to determine the quality of software. Software companies have adopted many strategies in search of differential to remain competitive in the market. In recent years, software development projects are becoming increasingly distributed. There are several challenges related to testing teams, mainly when they are distributed, due to aspects such as geographical dispersion, temporal dispersion and cultural differences. Although the test area is gaining, more notoriety, there is a lack of empirical studies that allow enumerate reliable measures related to test management in distributed environments. The objective of this dissertation is to identify the challenges in managing distributed testing teams in order to identify good practices to minimize the challenges encountered. To identify the challenges nine semi-structured interviews with managers and leaders who have experience managing test teams distributed in private companies both in Brazil and in the United States were made. After analyzing the data from the interviews, were identified 31 challenges divided into ten major areas. To minimize the challenges encountered were indicated ten groups of good practices based on the literature, the papers were taken out from the search sites like: IEEE, Science Direct, Google Scholar and the ACM Digital Library, later the group of good practices were assessed by eight professionals that possess leadership role in distributed testing teams through a questionnaire. The main purpose of the evaluation was to identify whether respondents believe that groups of good practices indicated help to minimize challenges in a distributed testing team and raise which recommendations are already being used by them. The positive evaluation of the respondents as to the groups of good practice indicates that recommendations can help in the management of distributed testing teams. This work contributed to the survey of the challenges in managing test teams distributed, indicating ten groups of good practice and mapping the recommendations already used in companies. Although some recommendations already in use, it is necessary to disseminate best practices to support this type of management.
Keywords: Software Testing, Project Management, Distributed Software Development,
Figura 2.1. Grupos de processo. ... 21
Figura 2.2. Fases de Desenvolvimento e Teste no Modelo V. ... 24
Figura 2.3. Ciclo de Vida: processo de desenvolvimento com verificação. ... 25
Figura 2.4. Métodos de testes por abordagens. ... 26
Figura 2.5. Processo de teste fundamental. ... 27
Figura 2.6. Modelo de integração entre os processos de desenvolvimento e teste. ... 29
Figura 2.7. Desafios de DDS... 33
Figura 2.8. Desafios de DDS por categorias. ... 34
Figura 3.1. Etapas da pesquisa. ... 41
Figura 4.2. Desafios extraídos das entrevistas semiestruturadas. ... 57
Figura 4.3. Principais desafios específicos da área de teste. ... 76
Gráfico 6.1. Opinião sobre os Grupos de Boas Práticas. ... 99
Gráfico 6.2. Recomendações mais utilizadas por GBP... 100
Gráfico 6.3. Recomendações menos ou não utilizadas por GBP. ... 101
Quadro 1.1. Objetivos da pesquisa. ... 16
Quadro 2.1. Desafios de uma experiência industrial... 35
Quadro 3.1. Classificação da pesquisa. ... 39
Quadro 4.1. Desafios levantados na literatura ... 49
Quadro 4.2. Perfil dos entrevistados da pesquisa. ... 50
Quadro 4.3. Coleta de dados. ... 51
Quadro 4.4. Comparação das áreas de desafios com trabalhos relacionados. ... 75
AIPM – Australian Institute of Project Management APM – Association for Project Management CMMI – Capability Maturity Model Integration DDS – Desenvolvimento de Software Distribuído DGS – Desenvolvimento Global de Software GBP – Grupo de Boas Práticas
ICB – IPMA Competence Baseline
IEC – International Electrotechinical Commission IPMA – Associação Internacional de Gestão de Projetos ISO – International Organization for Standardization MPS.BR – Melhoria de Processos do Software Brasileiro PMBOK – Project Management Body of Knowledge PMI – Project Management Institute
PRINCE2 – PRojects IN Controlled Environments RM – Requisição de Mudança
RUP – Rational Unified Process XP – Extreme Programming
1 - INTRODUÇÃO ... 13 1.1 Contexto ... 13 1.2 Motivação ... 14 1.3 Descrição do Problema ... 15 1.4 Objetivos ... 16 1.5 Delimitações ... 16 1.6 Estrutura ... 17 2 - REVISÃO DA LITERATURA ... 18 2.1 Gerenciamento de Projetos ... 18 2.2 Teste de Software ... 22
2.3 Desenvolvimento Distribuído de Software ... 30
2.4 Gerenciamento de Teste em Equipes Distribuídas ... 35
2.5 Considerações Finais ... 38 3 - MÉTODO DE PESQUISA ... 39 3.1 Classificação da Pesquisa ... 39 3.2 Etapas de Pesquisa ... 40 3.3 Participantes ... 42 3.4 Coleta de Dados ... 42 3.5 Análise de Dados ... 44
3.6 Definição dos Grupos de Boas Práticas ... 45
3.7 Limitação do Método de Pesquisa ... 46
3.8 Ameaças à Validade ... 46
3.9 Considerações Finais ... 47
4 - ANÁLISE E INTERPRETAÇÃO DAS ENTREVISTAS ... 48
4.1 Desafios Levantados da Literatura... 48
4.2 Características dos Participantes das Entrevistas ... 50
4.3 O Gerenciamento das Equipes de Teste Distribuídas ... 52
4.4 Desafios no Gerenciamento de Equipes de Teste em DDS ... 56
4.5 Discussão e Trabalhos Relacionados ... 73
4.6 Considerações Finais ... 76
5 - PROPOSTA DE GRUPOS DE BOAS PRÁTICAS ... 77
5.1 GBPs para Equipes de Teste Distribuídas ... 77
5.2 Considerações Finais ... 95
6 - AVALIAÇÃO DOS GRUPOS DE BOAS PRÁTICAS PROPOSTOS ... 97
6.1 Perfil dos Avaliadores ... 97
6.2 Avaliação ... 98
6.3 Considerações Finais ... 102
7 - CONCLUSÕES E TRABALHOS FUTUROS ... 104
7.1 Contribuições ... 104 7.2 Limitações ... 105 7.3 Trabalhos Futuros ... 105 7.4 Conclusões ... 106 REFERÊNCIAS ... 107 APÊNDICES ... 113
1 -
INTRODUÇÃO
Este capítulo apresenta uma visão geral da pesquisa, o mesmo contém: o contexto da pesquisa; a motivação e a justificativa para realização desta pesquisa; aponta o direcionamento para o problema de pesquisa a ser analisado e respondido; o objetivo geral da pesquisa e também os objetivos específicos que devem ser alcançados; a delimitação do campo de atuação desta pesquisa e a exposição de como os capítulos estão organizados.
1.1
Contexto
As atividades de teste possuem um papel fundamental no processo de desenvolvimento de um software, pois correspondem a um último momento de corrigir eventuais problemas no produto antes da sua entrega ao usuário final (PRESSMAN, 2005). De acordo com Perez & Kaiser (2010), teste de software é um processo de verificação e validação, e envolve métodos para testar os riscos de software, sucessos e falhas em vários níveis de granularidade que dividem o desenvolvimento e o processo de integração em várias fases.
É cada vez mais comum as equipes de projeto de software serem compostas por pessoas que trabalham geograficamente distribuídas. O desenvolvimento distribuído trata-se da cooperação entre várias equipes localizadas em diferentes lugares (PHALNIKAR et al., 2009). Várias razões levaram a este cenário: redução de custos, melhor utilização global da disponibilidade limitada de recursos humanos, a maior quantidade de horas de trabalho disponíveis de acordo com os diferentes fusos horários, os incentivos para investimentos em mercados emergentes e um crescimento significativo na demanda de software (HERBSLEB & MOITRA, 2001).
De acordo com Sengupta et al. (2006) as questões críticas em desenvolvimento de software distribuído (DDS) são a incapacidade de se comunicar eficazmente através da distância, cultura e fusos horários. Podendo dar origem a outros problemas como: falta de entendimento comum, fluxos irregulares de informação e, finalmente, coordenação fraca.
Em Engenharia de Software, a fase de teste de software, muitas vezes envolve a colaboração de testadores, desenvolvedores e até usuários finais. Uma ampla gama de tecnologias de comunicação e colaboração são utilizadas para coordenar os trabalhos do
projeto. Em testes co-localizados como em colaborativos é necessário que os testadores verifiquem as funções do software e examinem as saídas. O processo é inerentemente cooperativo, exigindo esforços coordenados de muitos testadores (TUNG & TSENG, 2013).
O processo de teste é uma fase em que muitos artefatos podem ser produzidos e requeridos nas etapas de planejamento, monitoramento, controle e execução do processo tais como: cenários de testes, casos de testes, stubs, drivers de testes e resultados de testes. O gerenciamento desses artefatos não é uma tarefa trivial e se torna mais complexa quando o desenvolvimento de software ocorre entre equipes distribuídas que ocupam localizações físicas diferentes (LOPES & FERNANDES, 2009).
A identificação dos desafios enfrentados por profissionais de teste de software que têm experiência em liderança de equipes de teste distribuídas irá contribuir para o levantamento de um conjunto de boas práticas que podem ajudar na melhoria dos processos do gerenciamento de equipes de teste distribuídas.
1.2
Motivação
O recente aumento no desenvolvimento global de software resultou na formação de equipes distribuídas, em diferentes zonas econômicas, temporais e sociais para colaborar com a autoria compartilhada da evolução de produtos de software (MATHRANI & MATHRANI, 2012). Nos últimos anos, por razões comerciais, os projetos de desenvolvimento de software estão se tornando cada vez mais distribuídos. No entanto, o desenvolvimento de software é um processo intrinsecamente colaborativo, estudos indicam que sua distribuição em vários locais é repleta de desafios (SENGUPTA et al., 2006).
De acordo com Lopes & Fernandes (2009), existem problemas em um ambiente distribuído em relação aos artefatos de teste tais como a concorrência que ocorre quando diversas transações desejam realizar ações de leitura e escrita em dados de maneira intercalada, a maneira como as equipes irão se comunicar, o modo de armazenamento, o compartilhamento, a entrega, dentre outros.
Segundo Mathrani & Mathrani (2012), a literatura discute sobre questões relacionadas aos processos técnicos em aplicação de scripts de teste. No intuito de avaliar as funcionalidades do sistema, o design de componentes, e o código de software para resolver defeitos. Pouco se sabe sobre as práticas de software utilizadas na definição de processos de teste em ambientes
distribuídos. Como, por exemplo, planejamento de execução de teste, a aplicação de planos de teste, ou o uso de dispositivos de monitoramento de segurança em ambientes distribuídos onde o desenvolvimento de componentes é distribuído em diferentes países.
Jiménez et al. (2009), observaram uma carência de estudos empíricos que permitem enumerar medidas confiáveis. Assim, mais artigos relacionados a teste em ambientes distribuídos são necessários. O trabalho de Pehmöller et al. (2010) também afirma a necessidade de mais investigações e soluções no campo de teste globalmente distribuídos no desenvolvimento de software personalizado.
Esta área merece ser pesquisada, pois, como afirmam os trabalhos citados anteriormente (JIMÉNEZ et al. (2009); PEHMÖLLER et al. (2010)), existem poucos estudos relacionados à área de teste em ambientes distribuídos. Assim, é importante estudar os seus desafios para que boas práticas possam ser levantadas para melhorar a área em questão. Muitos dos artigos encontrados analisam projetos de teste distribuídos em outros países que não incluem o Brasil (BONDI & ROS (2009); PEHMÖLLER et al. (2010)). Neste trabalho serão captados os desafios segundo a percepção de gerentes e líderes de teste de software que trabalham em equipes distribuídas no Brasil, como também em outros países.
1.3
Descrição do Problema
A partir das considerações levantadas, surgiu, então, o real problema desta pesquisa:
Problema de pesquisa: quais os desafios enfrentados no gerenciamento de equipes de
teste distribuídas de acordo com a percepção de gerentes e líderes de teste?
Relevância:
A relevância do problema apresentado é decorrente da “carência” de trabalhos científicos específicos para o gerenciamento de equipes de teste distribuídas.
Os grupos de boas práticas propostos por esta dissertação visam ajudar os gerentes e líderes a superarem os desafios encontrados no gerenciamento de equipes de teste quando as equipes estão geograficamente distribuídas.
1.4
Objetivos
O objetivo geral desta pesquisa é identificar os desafios no gerenciamento de equipes de teste distribuídas a partir da percepção de gerentes e líderes de teste no intuito de levantar boas práticas para minimizar os desafios encontrados. O Quadro 1.1 resume os objetivos da pesquisa utilizando o template da abordagem GQM Goal/Question/Metric definido por Basili (1984).
Quadro 1.1. Objetivos da pesquisa.
Analisar O gerenciamento em equipes de teste distribuídas
Com o propósito de Identificar os desafios enfrentados, visando à recomendação de grupos de boas práticas para minimizá-los
Do ponto de vista De gerentes e líderes de teste
Num contexto de Empresas privadas que possuem equipes de teste distribuídas
Para que o objetivo geral da pesquisa pudesse ser alcançado, os seguintes objetivos específicos foram definidos:
Estudar a base teórica, envolvendo DDS, teste de software, gerenciamento de projetos e gerenciamento de equipes de teste distribuídas.
Coletar os desafios no gerenciamento de equipes de teste distribuídas.
Identificar as boas práticas utilizadas em ambientes distribuídos.
Avaliar os grupos de boas práticas do ponto de vista de gerentes, líderes e pontos focais de teste.
1.5
Delimitações
O estudo restringe-se, em termos teóricos, ao campo de projetos desenvolvidos por empresa privadas que possuem equipes de teste geograficamente distribuídas. As opiniões a cerca dos desafios estão exclusivamente ligadas à percepção de pessoas que gerenciam equipes na área de teste de software. Quaisquer outras abordagens fora desse contexto não foram consideradas. Diante do exposto, são apresentadas as exclusões deste trabalho:
Detalhar e identificar desafios e boas práticas relacionadas às áreas da Engenharia de Software diferentes da área de testes.
1.6
Estrutura
Capítulo 1 – Introdução: apresenta esta introdução, no qual é oferecida uma visão geral da
dissertação, contexto, justificativas, descrição do problema, objetivos da mesma e delimitação, bem como informações sobre a organização do documento.
Capítulo 2 – Revisão da Literatura: apresenta a base conceitual para o desenvolvimento
do trabalho e relaciona as quatro principais áreas do estudo: Gerenciamento de Projetos, Teste de software, Desenvolvimento Distribuído de Software e Gerenciamento de Equipes de Teste Distribuídas.
Capítulo 3 – Metodologia: apresenta a metodologia proposta, com a classificação da
pesquisa junto ao quadro metodológico e demonstra como foi sua aplicação nesta pesquisa, buscando detalhar cada passo, seus benefícios e resultados.
Capítulo 4 – Análise e Interpretação das Entrevistas: apresenta os resultados do estudo e a
análise das entrevistas semiestruturadas realizadas para identificar os desafios enfrentados no gerenciamento de equipes de teste distribuídas. Identifica como as equipes de teste estão sendo gerenciadas e os desafios no gerenciamento de equipes de teste distribuídas.
Capítulo 5 – Proposta de Grupos de Boas Práticas: apresenta os grupos de boas práticas e
recomendações retiradas da literatura para minimizar os desafios encontrados relacionados ao gerenciamento de equipes de teste distribuídas.
Capítulo 6 – Avaliação dos Grupos de Boas Práticas: apresenta avaliações dos
profissionais de teste de software quanto os grupos de boas práticas indicados.
Capítulo 7 – Conclusões e Trabalhos Futuros: apresenta uma síntese dos objetivos e
2 - REVISÃO DA LITERATURA
Este capítulo apresenta a base conceitual para o desenvolvimento do trabalho e relaciona as quatro principais áreas do estudo que são: Gerenciamento de Projetos, Teste de software, DDS e Gerenciamento de Equipes de Teste Distribuídas. O capítulo contém: os principais conceitos e definições de gerenciamento de projetos; uma visão geral da área de teste, modelos, níveis e estratégias, além, do gerenciamento específico da área de teste; uma visão geral e desafios relacionados à DDS; uma visão geral e ferramentas de gerenciamento de teste distribuído. Por fim, são apresentadas as considerações finais pertinentes ao capítulo.
2.1
Gerenciamento de Projetos
Esta seção apresenta a revisão da literatura relacionada a gerenciamento de projetos. Inicialmente será apresentada uma visão geral, o ciclo de vida e por fim os importantes métodos para o gerenciamento de projetos.
2.1.1
Visão Geral
Um empreendimento é considerado como projeto de acordo com o PMI (2013) se o mesmo for um esforço temporário realizado no intuito de criar um produto, serviço ou resultado exclusivo, ou seja, os projetos possuem um início e um fim bem definidos. De acordo com Kerzner (2006, p.15) “projeto é um empreendimento com objetivo bem definido, que consome recursos e opera sob pressão de prazos, custos e qualidade”. Para que um projeto obtenha sucesso, os seguintes fatores são importantes: sua conclusão dentro de um prazo determinado, dentro do custo pré-fixado, atendendo os níveis de desempenho e tecnologia especificados, e aceitos pelo cliente.
Os projetos de acordo com Desouza & Evaristo (2004), podem ser divididos por tipos: co-localizados, distribuídos e múltiplos projetos. Os projetos co-localizados são vários projetos sendo executados simultaneamente em um único local. Nos projetos distribuídos os esforços individuais são realizados em vários locais, muitas vezes envolvendo diferentes organizações. E os múltiplos projetos são vários projetos localizados em vários locais.
Segundo o PMI (2013, p.5), “o gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto, a fim de atender aos seus requisitos”. Sendo realizado por meio da integração dos seguintes processos: iniciação, planejamento, execução, monitoramento e controle, e encerramento. De acordo com o IPMA, um conjunto de processos de gerenciamento voltados para o planejamento, organização e o controle de todos os aspectos de um projeto, assim como para a motivação de todos os elementos envolvidos, com o intuito de alcançar os objetivos estabelecidos, com segurança e dentro dos prazos acordados é caracterizado como gerenciamento de projetos (ICB, 2006).
De acordo com as definições mencionadas, o gerenciamento de projeto pode ser entendido como a execução de um conjunto de atividades integradas que visam atingir com êxito os objetivos do projeto. Seguindo dessa forma os processos de iniciação, planejamento, execução, monitoramento e controle, e o encerramento do projeto.
Os projetos são frequentemente utilizados como meio de atingir o plano estratégico de uma organização e são geralmente autorizados a partir de uma demanda de mercado, uma necessidade estratégica de negócios, uma solicitação de um cliente, um avanço tecnológico ou um requisito legal (PMI, 2013). Um dos fatores que impulsionaram e impulsionam o gerenciamento de projetos é o crescimento da competitividade, por isso, é indispensável à utilização de um modelo de gerenciamento baseado em prioridades e objetivos, para atender as necessidades dos clientes em um cenário que muda constantemente (VARGAS, 2009).
Diante do exposto o gerenciamento de projetos tem se tornado vital para as organizações, sendo importante conhecer boas práticas para que a organização consiga atingir seus objetivos estratégicos entregando seus projetos no prazo, no custo pré-fixado e com qualidade.
2.1.2
Ciclo de Vida
O ciclo de vida do projeto é a sequência de processos que vão do início ao término do projeto. A análise do ciclo de vida proporciona uma visão sistêmica do projeto, em todos os seus processos. De acordo com Maximiano (2002) as fases do ciclo de vida são: iniciação ou concepção, planejamento, execução, controle e encerramento do projeto.
Kerzner (2006), afirma que o ciclo de vida do projeto define as fases que ligam o seu início ao seu fim, tornando-se um instrumento de qualidade, pois implica na sua condução, em que as expectativas de qualidade são estabelecidas entre as fases.
De acordo com o PMI (2013), o ciclo de vida de um projeto consiste em fases, que em geral são sequenciais e que às vezes se sobrepõem, onde o nome e número são determinados de acordo com as necessidades para o gerenciamento e controle das empresas envolvidas, a natureza do projeto em si e sua área de aplicação. O mesmo deve ser definido de acordo com os aspectos de cada organização, indústria ou tecnologia empregada, mostrando assim, não existe apenas uma única maneira de estabelecer um ciclo de vida ideal do projeto.
Apesar de não ter um número fixo de fases determinadas a todos os projetos, independente disto, todas as fases possuem características similares como (PMI, 2013):
O trabalho tem um foco diferente de quaisquer outras fases.
É necessário o uso de controles ou processos exclusivos para a fase ou suas atividades para atingir a entrega e o objetivo principal.
O encerramento ocorre com alguma forma de transferência ou entrega do produto. O final desta fase representa um ponto natural para reavaliação do esforço em curso e de modificação ou término, caso necessário.
Diante do exposto, é importante ter bases conceituais sobre fases do ciclo de vida do projeto, para que a empresa consiga um modelo que atenda as suas necessidades, já que, não existe um modelo pré-definido para todos e quaisquer projetos.
2.1.3
Métodos de Gerenciamento de Projetos
De acordo com Patah (2010), os métodos atualmente mais difundidos e disponibilizados por institutos e associações dedicados ao estudo de projetos são: Project Management Body of Knowledge (PMBOK), ICB – IPMA Competence Baseline, AIPM – Professional, Competency Standards for Project Management, APM Body of Knowledge Projects In Controlled Environments (PRINCE2).
“O PMBOK é um conjunto de métodos desenvolvido para diversos tipos de projetos, sendo, portanto, bastante genérico. Estruturado por áreas de conhecimento de um projeto. O ICB é estruturado por competências que o projeto necessita desenvolver, divididas em: contextuais, comportamentais e técnicas. Este documento (AIPM), é publicado pelo instituto australiano de projetos, é bastante similar em sua estrutura ao PMBOK, dividido por áreas de conhecimento. O APM é um dos mais completos conjuntos de métodos, este documento apresenta conteúdos relacionados a projetos, valor, escritório de projetos e aspectos estratégicos da
gestão de projetos. PRINCE2 é um conjunto de métodos estruturados por etapas de um projeto e nas atividades a serem conduzidas pela equipe de gestão do mesmo.” (PATAH, 2010, (p.36)).
O Guia PMBOK é um padrão baseado em ciclos de vida, desenvolvido pelo Project Manager Institute, reconhecido mundialmente para a profissão de gerenciamento de projetos. Este padrão é um documento formal que descreve normas, métodos, processos e práticas estabelecidas. O mesmo está organizado em dez áreas de conhecimento: integração, escopo, tempo, custo, qualidade, recursos humanos, comunicações, riscos, aquisições e partes interessadas. Cada área de conhecimento é dividida em um número de processos. O total número de processos é 47, cada processo apresenta entradas, ferramentas ou técnicas e gera uma ou mais saídas. Os grupos de processos estão divididos em cinco: iniciação, planejamento, execução, monitoramento e controle, e encerramento (ver Figura 2.1) (PMI, 2013).
Figura 2.1. Grupos de processo.
Fonte: PMI (2013).
De acordo com Lianying et al. (2012), o PRINCE2 é um tipo de abordagem baseada em processo estruturada que auxilia no gerenciamento de projetos de forma eficaz. A mesma fornece uma metodologia de gestão de projeto facilmente personalizada e escalável para a gestão de todos os tipos de projetos. Segundo Turley (2010), o PRINCE2 estabelece e define as responsabilidades em nove papéis entre os quais distribui as atividades necessárias para cumprir as responsabilidades da organização durante o ciclo de vida do projeto.
De acordo com o exposto, existem métodos conceituados que podem ser utilizados para gerenciamento de projetos, sendo aconselhado se aprofundar nos mesmos para verificar qual se encaixa melhor no contexto da empresa. Foi apresentado um importante e conhecido método que é o PMBOK, que pode ser seguido pelos gerentes de projetos para alcançar o êxito do mesmo.
2.2
Teste de Software
Esta seção apresenta a revisão da literatura relacionada a teste de software. Inicialmente será apresentada uma visão geral, os modelos, níveis e estratégias de teste e por fim o gerenciamento de teste.
2.2.1
Visão Geral
Teste é uma atividade em que um sistema ou componente é executado sob condições específicas, os resultados são posteriormente observados, e uma avaliação é feita de alguns aspectos do mesmo. O processo de teste de software determina se os resultados de uma atividade estão de acordo com os requisitos especificados e se o produto desenvolvido satisfaz o uso pretendido e a necessidade do usuário. As atividades de teste são realizadas em paralelo com o desenvolvimento do software e do sistema (ANSI/IEEE Std P829-2007).
De acordo com Bassetti & Lewis (2004), o teste de software é uma atividade realizada para descobrir o maior número de defeitos potenciais quanto possível antes que o software seja entregue ao cliente. Para isso é feita uma série de execuções dinâmicas nos programas de software após o código fonte ser desenvolvido. Para Myers (2004), o software deve ser consistente e previsível e teste de software é um processo, ou uma série de processos, com intuito de certificar se o código faz o que foi projetado para fazer e não faz nada não intencional.
O teste de software é um dos instrumentos utilizados para determinar a qualidade do software (HUTCHESON, 2003). Durante o desenvolvimento do ciclo de vida, a etapa de teste de software é importante, pois um teste apropriado pode aumentar a qualidade do produto. Atualmente, teste de software tornou-se uma atividade de avaliação de qualidade. Portanto, tornou-se imperativo testar os componentes de software e o software como um todo para
garantir a integridade, capacidade, confiabilidade, eficiência, portabilidade, manutenabilidade, compatibilidade e usabilidade do software (KHAN & CHOUDHARY, 2011).
A área de teste é essencial, mas muitas vezes subutilizada na Engenharia de Software. Uma variedade de técnicas de teste foram desenvolvidas para identificar efetivamente bugs no código fonte, mas estas técnicas não são sempre utilizadas na prática (PARVEEN et al., 2007). Atualmente, grande parte dos esforços de investigação sobre teste de software estão focados na concepção de novas técnicas, bem como a investigação da sua eficácia no verdadeiro contexto de desenvolvimento. No entanto, durante toda a história de desenvolvimento de software, métodos e técnicas de teste têm lutado para acompanhar a evolução e as tendências cada vez mais rápidas em paradigmas de desenvolvimento de software (CAUSEVIC et al., 2010).
Segundo Mayers (2004), existem dez importantes princípios de teste de software, os quais são classificados como vitais pelo autor e muitas vezes negligenciados pelas equipes apesar de alguns parecerem óbvios:
1° Uma parte necessária de um caso de teste é a definição do resultado esperado. 2° Um programador deve evitar a tentativa de testar o seu próprio programa. 3° A empresa desenvolvedora não deve testar o seu próprio programa. 4º Inspecione os resultados de cada teste.
5° Casos de teste devem ser escritos para as condições de entrada que são inválido e inesperado, bem como para aqueles que são válidos e esperados.
6° Examinar se o programa não faz o que deve fazer e ver se o programa faz o que não deve fazer.
7° Evite casos de teste descartáveis a menos que o programa seja um programa descartável.
8° Não planejar um esforço de teste sob a suposição tácita que nenhum erro será encontrado.
9° A probabilidade da existência de mais erros numa seção de um programa é proporcional ao número de erros já encontrados nessa seção.
10° O teste é uma tarefa extremamente criativa e intelectualmente desafiadora.
Estudos na área de teste de software estão crescendo no Brasil, o trabalho de Lemos et. al. (2011) analisou as publicações do Brazilian Symposium on Software Engineering (SBES) ao
longo de 25 anos e conseguiu constatar que a comunidade nacional melhorou nas suas pesquisas nos últimos anos significativamente, com o aumento no número de publicações relacionadas a teste de software.
Mediante o exposto, pode-se constatar que estudos sobre teste de software estão crescendo e que esta área é de grande importância, pois, o teste de software é uma atividade realizada para descobrir defeitos, ganhar confiança, prevenir defeito no intuito de melhorar a qualidade dos produtos de softwares desenvolvidos.
2.2.2
Modelos, Níveis e Estratégias de Teste
Durante todo o ciclo de vida de um produto de software os testes são realizados em diferentes níveis, envolvendo o sistema ou partes dele. Um sistema de software atravessa quatro fases de teste antes de ser realmente implantado. Estas quatro fases são conhecidas como unidade (componente), integração, sistema e teste de nível de aceitação. As quatro fases de teste são ilustradas sob a forma do que é chamado o modelo V clássico da Figura 2.2. (NAIK & TRIPATHY, 2008).
Figura 2.2. Fases de Desenvolvimento e Teste no Modelo V. Fonte: Adaptado de Naik & Tripathy (2008).
De acordo com Muller (2011), da International Software Testing Qualifications Board (ISTQB), o teste de unidades verifica o funcionamento do software e busca por defeitos que são testáveis separadamente. O teste de integração verifica as interfaces entre os
componentes, interações de diferentes partes de um sistema. O teste de sistema verifica o comportamento do sistema que deve corresponder ao máximo possível do objetivo. O teste de aceite pretende estabelecer a confiança no sistema, frequentemente é de responsabilidade do cliente ou do usuário do sistema.
No modelo citado por Mayers (2004), o ciclo de teste é estruturado para modelar o ciclo de desenvolvimento. Em outras palavras, deve ser capaz de estabelecer um-para-um entre os processos de desenvolvimento e teste (Figura 2.3). De acordo com o autor uma das vantagens de usar o processo de teste em correspondência ao desenvolvimento é que está estrutura evita testes redundantes e impede que seja negligenciada grandes classes de erros. Diferentemente do modelo V, ele apresenta mais níveis de teste e fases no processo de desenvolvimento.
Figura 2.3. Ciclo de Vida: processo de desenvolvimento com verificação. Fonte: Adaptado de Mayers (2004).
As estratégias predominantes em teste de software são testes caixa branca e testes caixa preta. A estratégia caixa branca, deriva de dados de teste a partir de um exame da lógica do programa, ou seja, permite examinar a estrutura interna do programa. A estratégia caixa preta
se concentra em encontrar circunstâncias em que o programa não se comporta de acordo com as suas especificações, e diferentemente da estratégia caixa branca, os testes são feitos completamente indiferentes sobre o comportamento interno e uma estrutura de programa (MAYERS, 2004).
Para Mayers (2004), é possível desenvolver testes rigorosos utilizando metodologias de design de casos de testes orientados a estratégia de caixa preta e em seguida, completar estes casos de teste, examinando a lógica do programa, utilizando métodos de caixa branca. Na Figura 2.4mostra os métodos que podem ser utilizados nas diferentes abordagens de testes. Os testes de lógica de cobertura são métodos de caixa branca que estão relacionados com o grau em que os casos de teste exercem ou cobrem à lógica (código-fonte) do programa.
Figura 2.4. Métodos de testes por abordagens. Fonte: Mayers (2004).
Black (2008) designa todos os métodos apresentados como técnicas de design de caixa branca e de caixa preta. Quanto às técnicas de caixa preta: na partição de equivalência os casos de teste são projetados para executar representantes de partições de equivalência. Em princípio, os casos de teste são projetados para cobrir cada partição, pelo menos uma vez. Na análise de valor limite os casos de teste são projetados com base em valores de limite. No gráfico de causa-efeito os casos de teste são projetados a partir de gráficos. Na suposição de erro, é usada a experiência do testador para antecipar defeitos e projetar testes para expô-los (BLACK et al., 2012).
Diante do exposto, pode-se verificar que existem diferentes modelos de ciclo de vida que associam as etapas de desenvolvimento com as etapas de testes de softwares. Esses modelos podem ser utilizados de acordo com o perfil e objetivos das empresas. A definição das estratégias e os níveis de testes que serão utilizados ajudam na estruturação do processo como também na execução do mesmo em busca da qualidade do software.
2.2.3
Gerenciamento de Teste
De acordo com Spillner et al. (2007), o gerenciamento de teste é de particular importância, ele compreende métodos clássicos de projeto e gerenciamento de risco, bem como o conhecimento do uso adequado dos métodos de teste bem definidos. Assim, o gerente de teste pode escolher e implementar estratégias adequadas para assegurar a qualidade esperada do produto. O processo fundamental de teste consiste em fases: planejamento e controle de teste, modelagem e análise, implementação e execução, avaliação e relatório, e por fim atividades de encerramento (Figura 2.5). O gerente de teste é responsável por administrar o processo de teste, infraestrutura e documentos de teste.
Figura 2.5. Processo de teste fundamental. Fonte: Adaptado de Spillner et al. (2007).
Na etapa de planejamento os papéis devem ser bem definidos, é necessário identificar os recursos necessários incluindo pessoal para a execução de tarefas, tempo estimado, habilidades e ferramentas, devem ser documentadas no plano de testes, as especificações associadas. O controle regular é necessário para verificar se o planejamento e o andamento do projeto estão de acordo com o planejado (SPILLNER et al., 2007).
Durante o planejamento de teste, é possível detectar riscos e problemas de qualidade antes mesmo da execução dos testes, como por exemplo, a falta de informações sobre o desempenho e confiabilidade nos requisitos do produto, além disso, pode apontar problemas no plano de projeto e em outros produtos de trabalho do projeto e identificar oportunidades para ajustar a equipe de teste, orçamento, cronograma, esforço e recurso (BLACK, 2008).
Na etapa de análise é necessário verificar se todos os documentos exigidos são detalhados e precisos para ser capaz de usar as técnicas de teste de acordo com as estratégias planejadas. A modelagem de teste é usada para obter os pré-requisitos e requisitos dos casos de testes (SPILLNER et al. 2007). A etapa de implementação inclui assegurar que os procedimentos de teste são organizados e acessíveis para os testadores, após esta etapa os testadores executam os testes de acordo com os procedimentos acordados (BLACK, 2008). Na etapa de avaliação e relatório é verificado se os critérios de saída definidos no plano de testes foram cumpridos (SPILLNER et al., 2007; BLACK, 2008).
De acordo com Rios (2007), o ciclo de vida da execução dos testes é composto, basicamente, pelas etapas de: Procedimentos Iniciais, Especificação, Execução e Entrega. Assim, o processo de teste deve andar em paralelo e de forma integrada com o projeto de desenvolvimento dos sistemas como mostra a Figura 2.6. O autor acredita que o projeto de teste pode se enquadrar nas áreas de conhecimento do PMBOK como: gerência de riscos, gerência de qualidade, gerência de escopo, gerência de custos, gerência de prazo e gerência de contratação.
Figura 2.6. Modelo de integração entre os processos de desenvolvimento e teste. Fonte: Rios (2007).
O gerenciamento de teste é um termo amplo que pode incluir a gestão do processo, gestão de dados e a gestão de recurso de teste. De acordo com Jun-feng et al. (2006), o processo de gerenciamento de teste de software é composto de três partes: plano de testes, projeto de teste e execução de testes.
Já para Parveen et al. (2007), o gerenciamento de teste é um método de organização de recursos e artefatos de teste, como requisitos de teste, casos de teste e resultados de teste que permitem acessibilidade e reutilização. Para o gerenciamento ser eficaz é importante à comunicação entre as diferentes partes envolvidas no processo, um dos pontos é definir as terminologias utilizadas no processo.
Os gerentes de teste servem a dois tipos de clientes, a equipe de testadores e a gestão empresarial. Quanto à equipe, o gerente ajuda a fornecer o conhecimento e desenvolver estratégias de teste. Para a gestão, o gerente reúne informações sobre o produto, para que seja
decidido se o produto está pronto para a implantação (MATHUR & MALIK, 2010). Para Katara et al. (2006), “O gerente de teste, é quem cuida do planejamento, ou seja, cronograma, estratégias de teste e acompanhamento básico das atividades, bem como relatórios para outras partes interessadas”.
Em Farrell-Vinay (2008), é retratado alguns princípios do gerenciamento de teste colhidos através da experiência do autor como gerente de teste. Alguns dos princípios são:
Qualquer um deve ser livre para levantar um bug. Se os defeitos são duplicados, o gerente de teste pode eliminar duplicatas diariamente na reunião de relatoria de bug.
Você deve ter acesso a todos os bugs reportados.
Testadores podem se concentrar em detalhes: você deve ser capaz de tanto ter uma visão geral, e concentrar-se em detalhes.
Se os processos estão errados, você sempre deverá lutar contra eles.
Diante do exposto, o gerenciamento de teste é importante para ajudar a equipe de teste a seguir o planejamento acordado no intuito de assegurar a qualidade do produto que está sendo desenvolvido. Além disso, o gerente de teste deve acompanhar todo o processo, fornecer o conhecimento e desenvolver estratégias de teste.
2.3
Desenvolvimento Distribuído de Software
Esta seção apresenta a revisão da literatura relacionada ao desenvolvimento distribuído de software. Inicialmente será apresentada uma visão geral e posteriormente os desafios relacionados ao DDS.
2.3.1
Visão Geral
A gestão, desenvolvimento e manutenção de software têm evoluído durante as duas últimas décadas em se concentrar em um único local para ser distribuído geograficamente (SENGUPTA et al., 2006). De acordo com Cavrak et al. (2012, p.1) “a demanda de mercado para o desenvolvimento de software distribuído, conhecimento e habilidades é alta e crescente”. Segundo os autores os projetos estão cada vez mais multidisciplinares o que torna difícil encontrar especialistas no mesmo lugar.
O processo distribuído de software é uma prática que está cada vez mais presente em organizações ao redor do mundo (AUDY & PRIKLADNICKI, 2007). As empresas de software vêm adotando muitas estratégias em busca de diferenciais para manter-se no mercado. Dentre elas uma que vem adquirindo muitos adeptos e estimulando muitas pesquisas é o DDS (LIVIERO, 2007). As equipes virtuais ou distribuídas são equipes dispersas geograficamente que trabalham em conjunto com o auxílio da tecnologia da informação e da comunicação no intuito de realizar as atividades atribuídas (POWELL et al. 2004).
A distribuição das equipes em DDS pode ser estabelecida de acordo com a distância, tais como a nacional, continental e global. A distância nacional é caracterizada pela localização das equipes no mesmo país, podendo haver diferenças de fuso horário e aspectos culturais que são mais gerenciáveis; na distância continental, as diferenças de fuso e culturais já podem gerar dificuldades no projeto, pois, a mesma é caracterizada pela distribuição dos membros dentro de um mesmo continente; e na distância global, a comunicação entre os membros podem ser limitadas devido a grandes distâncias temporais e diferenças culturais mais acentuadas, criando obstáculos para o sucesso do projeto (AUDY & PRIKLADNICKI, 2007). Existem várias razões para o crescimento de projetos de software com equipes distribuídas, entre elas: vantagens competitivas em termos de custos, melhor utilização global da disponibilidade limitada de recursos humanos, qualidade e flexibilidade no desenvolvimento de software, maior quantidade de horas de trabalho disponíveis de acordo com os diferentes fusos horários, incentivos para investimentos em mercados emergentes, um crescimento significativo na demanda de software no mundo e diminuição de riscos do projeto (SENGUPTA et al. (2006); HERBSLEB & MOITRA (2001)).
Devido aos benefícios mostrados, diversas empresas estão distribuindo seus projetos de desenvolvimento de software, tanto local quanto globalmente. De acordo com Carmel (1999), quando a distância física entre os atores em um ambiente de DDS envolve mais de um país colaborando ativamente em um projeto comum, pode ser chamada de DGS (Desenvolvimento Global de Software).
De acordo com Farias Júnior et al. (2010), o número de empresas em busca de certificações de qualidade, como por exemplo, os modelos de maturidade Capability Maturity Model Integration (CMMI) e Melhoria de Processos do Software Brasileiro (MPS.BR) é notório e de acordo com os autores esses modelos não dão uma atenção satisfatória para o DDS, apesar desses modelos manterem algumas práticas de maturidade para os processos de
comunicação, as variáveis externas, como geográfica e/ ou dispersão temporal e as diferenças culturais têm um grande impacto e não são devidamente contempladas, sendo assim, não é possível fornecer um processo de comunicação adequado para a DDS.
O desenvolvimento distribuído de software pode basicamente se enquadrar em quatro modelos de negócio. Onshore Insourcing, Offshore Insourcing, Onshore Outsourcing e Offshore Outsourcing. O modelo Onshore Insourcing é caracterizado quando há um departamento dentro da empresa ou uma subsidiária da empresa no mesmo país. No modelo Offshore Insourcing há uma subsidiária da empresa que fornece serviços de desenvolvimento de software em um país diferente da empresa contratante desses serviços. No modelo Onshore Outsourcing há a contratação de uma empresa terceirizada localizada no mesmo país da empresa contratante. E o modelo Offshore Outsourcing aborda contratação de uma empresa terceirizada localizada em um país diferente da contratante (AUDY; PRIKLADNICKI, 2007). Do ponto de vista de operacionalização do DDS nas organizações, o desenvolvimento Offshore tem sido considerado uma das formas mais comuns para caracterizar o DDS (PRIKLADNICKI, 2009).
Diante do exposto, o DDS está sendo adotado por várias empresas devido às vantagens que este tipo de desenvolvimento proporciona como: a baixa dos custos e o aumento da produtividade, incentivo entre outros.
2.3.2
Desafios de DDS
De acordo com Carmel (1999), os profissionais de Engenharia de Software possuem diversas dificuldades, independente se os mesmos trabalham com o desenvolvimento de software tradicional quanto com o distribuído, sendo as principais diferenças entre eles: a dispersão geográfica; dispersão temporal; e diferenças culturais entre os membros.
A literatura relata vários desafios relacionados com o DDS. Sengupta et al. (2006), apresenta em seu trabalho alguns desafios como comunicação inadequada onde a frequência da comunicação diminui com a distância física, diferenças de fuso horário que em alguns casos reduz significativamente a comunicação entre equipes distribuídas, diferenças culturais que impedem a comunicação fácil, falta de confiança e gestão de conhecimento. Quanto à área de teste os autores descobriram novos desafios devido à privacidade de dados de testes por causa do aumento da preocupação com a segurança, o tamanho da base de dados de
produção e imprecisão de documentos de interface. De acordo com a pesquisa, a indisponibilidade de dados reais devido à privacidade dos mesmos dificulta a realização de testes de unidade mais abrangentes de seus módulos.
O trabalho de Damian & Zowghi (2002), estudou os desafios encontrados nas atividades de engenharia de requisitos como elicitação, priorização, negociação, validação entre outras em equipes distribuídas. Como o trabalho de Sengupta et al. (2006), eles encontraram os mesmos desafios de comunicação inadequada, gestão do conhecimento, diversidade cultural e diferença de tempo.
Herbsleb et al. (2005), relata que sutis diferenças culturais, podem muitas vezes levar à frustração e mal-entendidos complicando a comunicação. Em Damian et al. (2007), são apresentados desafios de awareness, que representa a necessidade de conhecer o trabalho de outros colegas, permitindo uma melhor coordenação das equipes. Como por exemplo, saber quem é especialista em um módulo, quem trabalhou recentemente em uma determinada atividade.
A partir de uma revisão sistemática apresentada por Jiménez et al. (2007), alguns desafios do DDS foram levantados. Os desafios de comunicação encontrados estão relacionados às diferenças culturais que implicam diferentes terminologias que pode causar erros de mensagens e erros de tradução, definição dos requisitos e segurança das comunicações. Os outros desafios encontrados podem ser observados na Figura 2.7.
Figura 2.7. Desafios de DDS. Fonte: Adaptado de Jiménez et al. (2007).
Prikladnicki (2009) menciona os principais desafios encontrados na literatura de DDS, os mesmos estão organizados em categorias diferentes: pessoas, projetos e organização. Os desafios de pessoas estão relacionados a habilidades interpessoais, coordenação e comunicação. Os desafios de projetos incluem o uso de ferramentas, métodos, dados e processos necessários. Os desafios de organização estão relacionados à estrutura organizacional, responsabilidades, papéis, princípios operacionais e métodos de gestão de uma organização. Os desafios por categorias são mostrados na Figura 2.8.
Figura 2.8. Desafios de DDS por categorias. Fonte: Adaptado de Prikladnicki (2009).
Os desafios de uma equipe de desenvolvedores e testadores em preparar e executar testes de desempenho relatadas em Bondi & Ros (2009) foram às diferenças culturais, uma grande diferença de tempo, além da necessidade de explicar à distância as ferramentas, práticas, procedimentos de medição, necessidade de documentações relacionadas aos de testes de desempenho.
Pehmöller et al. (2011), investigaram os problemas em teste no desenvolvimento global de software, dentre todos os problemas levantados, o controle na transferência de conhecimento a partir de especificação para equipe de testes, comunicação na abertura e fechamento de defeitos no software, descoberta tardia de defeitos e/ou funcionalidades erradas, falta de habilidades para estratégias de teste e fornecimento de dados de teste necessários foram alguns dos problemas mencionados.
Em Collins et al. (2012), é apresentada uma experiência industrial de uma equipe de teste distribuída seguindo um método ágil, os desafios encontrados nesta experiência são mostrados no Quadro 2.1.
Quadro 2.1. Desafios de uma experiência industrial. Desafios
Comunicação e coordenação Disponibilidade da informação Processos de teste
Dependência das ferramentas Fonte: Collins et al. (2012).
Diante do exposto, pode-se verificar que existem vários desafios quando se fala em equipes de teste distribuídas. É notável que os desafios mais citados foram: comunicação inadequada, gestão do conhecimento, diferenças culturais e dispersão geográfica e temporal. Em trabalhos relacionados a teste de software também foram citados estes desafios e outros quanto ao processo, organização da equipe de teste entre outros.
2.4
Gerenciamento de Teste em Equipes Distribuídas
Esta seção apresenta a revisão da literatura relacionada ao gerenciamento de teste em equipes distribuídas. Inicialmente será apresentada uma visão geral e posteriormente uma apresentação de algumas ferramentas que podem ser utilizadas para ajudar no gerenciamento.
2.4.1
Visão Geral
Segundo Zage et al. (2005), as empresas contam com o outsourcing global para as suas necessidades de teste e para mitigar as limitações de orçamento e tempo. A etapa de teste fora
do local do contratante pode diminuir os custos para a empresa e fornecer uma capacidade necessária.
O gerente de teste tem a função de providenciar adequadamente os processos de teste, inclusive as atividades e os produtos de trabalho relacionados, além de colaborar com o gestor de desenvolvimento para garantir que os testadores se integrem e se adaptem às atividades como a criação de testes automáticos. Em muitos casos, parte dos trabalhos de teste ou até mesmo a totalidade deles é realizada por pessoas em locais diferentes, sendo assim os trabalhos de teste são distribuídos. Os problemas de comunicação e expectativas são aguçados pelos aspectos como: o local, o fuso horário, diferenças culturais e linguísticas. No gerenciamento de teste é necessário o alinhamento de metodologias das equipes envolvidas. O gerente deve fazer em vários locais a divisão dos trabalhos de maneira inteligente explícita e decidida e as expectativas de cada uma das equipes devem ser claramente comunicadas (BLACK et al., 2012).
No gerenciamento de equipes de teste distribuídas é importante que haja a utilização de uma ferramenta visual para comunicação nas reuniões; certificar que os testadores possuem uma voz igual dentro da equipe do projeto, para que os mesmos possam se sentir seguros ao pedir ajuda; passar a responsabilidade de qualidade para todas as equipes do projeto; e promover treinamentos remotos (CRISPIN, 2013).
O trabalho de Lopes & Fernandes (2009), apresenta uma arquitetura para contribuir com o gerenciamento de artefatos no processo de testes em ambientes de desenvolvimento distribuído. Os módulos gerenciadores tratam os problemas de concorrência e controle, um canal de comunicação permite a troca de mensagens entre as equipes e um barramento de dados possibilita o tráfego de artefatos armazenados em repositórios.
Diante do exposto, o gerente de teste deve providenciar todos os processos que devem ser seguidos pela equipe, além disso, deve gerenciar os problemas de comunicação, confiança entre outros que são agravados quando o gerenciamento de teste é realizado em equipes distribuídas, principalmente pela distância, fuso horário, diferenças culturais e linguísticas das equipes.
2.4.2
Ferramentas de Gerenciamento de Teste Distribuído
Pela necessidade de um gerenciamento de teste mais eficaz, após uma pesquisa Zage et al. (2005), decidiu desenvolver o seu próprio ambiente de acesso de teste global (GATE), que
__________________________________ ¹ http://sourceforge.net/projects/firescrum/ 2 http://testlink.org/ 3 http://www.mantisbt.org/ 4 http://subversion.apache.org/ 5 http://atlassian.com/software/jira 6 http:/www.twiki.org 7 http://docs.google.com 8 http://www.ibm.com/software/lotus
fornece uma solução para gerenciar as informações relacionadas ao teste e, assim, apoiar os testes eficazes no DGS. O mesmo contém cinco componentes: gerenciamento de usuários, gerenciamento de teste, gerenciamento de defeitos, gestão da mudança, e colaboração e ferramentas de comunicação. O GATE é uma aplicação open-source, que contém ferramentas de compartilhamento de informações, elaboração de relatórios, métricas, a retenção permanente de informações de teste e ferramentas de construção de equipe.
SilkCentral é uma ferramenta de gerenciamento de teste desenvolvida pela empresa Borland (Micro Focus, 2011) que proporciona uma estrutura unificada para a integração dos requisitos, ferramentas de automação de teste (unitários, funcionais e de desempenho), acompanhamento de problemas e atividades de teste manuais. Permite, monitoramento de qualidade, direto das atividades em tempo real, assim, a visibilidade de todas as atividades de teste podem ser acompanhadas pelas equipes que são co-localizadas ou distribuídas.
A ferramenta TestLink² é open source e ajuda no gerenciamento de teste, permitindo a criação de planos e casos de testes, assim como, o controle de execução dos testes. Com ela é possível que as equipes de teste trabalhem de forma sincronizada, ajudando assim as equipes de teste distribuídas.
Nos trabalhos de Maia et al. (2012) e Collins et al. (2012), para minimizar a distância das equipes de teste, foi necessário fornecer uma infraestrutura de teste, que permitisse o acesso às informações do projeto de forma eficiente, com isso foram utilizadas as seguintes ferramentas: FireScrum¹, TestLink², Mantis³, Subversion4, e-mail e chats.
Para o gerenciamento de bugs uma ferramenta que pode ser utilizada é o Jira5 criado pela empresa Atlassian. De acordo com Rodríguez et al. (2010), a mesma é aconselhada para ambientes distribuídos de software, possui um alto nível de integração através de plug-ins, oferecendo acompanhamento de problemas de forma fácil e gerenciamento ágil de projetos.
Em teste de software, é importante gerenciar a documentação necessária do projeto, para isso o trabalho de Rodríguez et al. (2010), levantou algumas ferramentas que permitem a documentação ou gerenciamento de documentos para equipes distribuídas. As citadas foram: Twiki6, Google Docs7 e Lotus Notes8.
Diante do exposto, é possível perceber que existem várias ferramentas que apoiam o gerenciamento de equipes de teste distribuídas, as mesmas estão relacionadas à gestão de tarefas, gestão de planos de teste, gestão de defeitos, versionamento, gestão da comunicação. Essas ferramentas podem ser eficazes mesmo quando as equipes de teste estão distribuídas.
2.5
Considerações Finais
Para que as organizações tenham maior chance de sucesso em seus projetos é importante conhecer boas práticas em gerenciamento de projetos. Existem métodos conceituados como o PMBOK e ICB que podem ser utilizados para gerenciamento de projetos.
A área de teste é de grande importância no processo de engenharia de software. O intuito desta área é descobrir defeitos, ganhar confiança e prevenir defeitos visando melhorar a qualidade dos produtos de softwares desenvolvidos antes que sejam entregues aos clientes.
No gerenciamento de teste os recursos e artefatos de testes são planejados e criados. O gerente de teste pode escolher e implementar estratégias adequadas para assegurar a qualidade esperada do produto. Ele é responsável por administrar o processo de teste, infraestrutura e documentos de teste.
Muitas empresas estão adotando o DDS devido às vantagens competitivas que são proporcionadas por esse tipo de desenvolvimento como: custos baixos, aumento da produtividade entre outros. Apesar dos benefícios muitos desafios são enfrentados em relação à comunicação inadequada, gestão do conhecimento, diferenças culturais e dispersão geográfica e temporal.
3 - MÉTODO DE PESQUISA
Este capítulo apresenta os principais procedimentos metodológicos adotados para fazer o levantamento sobre os desafios no gerenciamento de equipes de teste distribuídas e avaliação do grupo de boas práticas indicados. O capítulo contém: a classificação da pesquisa; as etapas realizadas para desenvolver a pesquisa; os participantes da pesquisa; a coleta de dados; análise dos dados; limitação do método utilizado; as ameaças à validade referentes à pesquisa; e as considerações finais pertinentes ao capítulo.
3.1
Classificação da Pesquisa
Quanto ao objetivo, a pesquisa pode ser considerada como exploratória, onde o objetivo é ter nova visão do fenômeno, desenvolver novas ideias e obter conhecimento sobre o mesmo (CERVO & BERVIAN, 2006; GIL 2008). Apesar de existirem artigos relacionados com desenvolvimento distribuído em teste, alguns autores como Jiménez et al. (2009) e Pehmöller et al. (2010), admitem que ainda é necessário descobrir aspectos relacionados ao tema. De acordo com Gil (2008), muitas vezes a pesquisa exploratória é a primeira etapa de uma investigação, para isso é necessário realizar uma consistente revisão da literatura, discussão com especialistas e outros procedimentos. O quadro metodológico dessa pesquisa encontra-se resumido no Quadro 3.1.
Quadro 3.1. Classificação da pesquisa. Quanto ao Objetivo Exploratória
Método de Abordagem Indutivo
Método de Procedimento Pesquisa bibliográfica, entrevista semiestruturada e
questionário Natureza das Variáveis Qualitativa
De acordo com Prodanov & Freitas (2013), o método de pesquisa é a forma de abordagem em nível de abstração dos fenômenos, pode ser entendido como o caminho, a forma, o modo de pensamento. Esta pesquisa utiliza o método de abordagem indutivo baseado em dados de natureza qualitativa. Este método parte de algo particular para uma questão mais ampla. De acordo com Lakatos e Marconi (2007, p.86), “... o objetivo dos argumentos indutivos é levar a conclusões cujo conteúdo é muito mais amplo do que o das premissas nas quais se baseara”. Para Gil (2008, p.10) “o método indutivo procede inversamente ao dedutivo: parte do particular e coloca a generalização como um produto posterior do trabalho de coleta de dados particulares”.
O método de procedimento utilizado foi de pesquisa bibliográfica para estudar o fenômeno pretendido, entrevista semiestruturada e questionário. De acordo com Prodanov & Freitas (2013), as técnicas de questionário e entrevista constituem de um levantamento de dados primários e dão grande importância à descrição verbal de informantes. Para as entrevistas semiestruturadas, foi criado um roteiro de perguntas flexíveis. Segundo Merriam (2009), nas entrevistas semiestruturadas não necessariamente todas as questões devem ser perguntadas e no meio das entrevistas podem surgir novas questões.
A pesquisa qualitativa estuda o objeto de análise em seu ambiente natural, assim existem diferentes formas de interpretar os fatos observados (WOHLIN et al. 2000). Os pesquisadores que usam a abordagem qualitativa estão em busca de perceber qual o significado atribuído às suas experiências e como são interpretados (MERRIAM, 2009). De acordo com Seaman (2008), nos métodos qualitativos, é obrigatório captar e descrever realidades socialmente construídas, e a principal vantagem de utilizá-lo é que o pesquisador é forçado a aprofundar na complexidade do problema em vez de abstraí-lo, obtendo assim, resultados mais ricos e mais informativos.
3.2
Etapas de Pesquisa
A pesquisa foi dividida em sete etapas, desde a revisão da literatura até a avaliação dos grupos de boas práticas levantadas, a revisão da literatura foi realizada desde o começo da pesquisa e continuou ao longo da mesma, todas as etapas são mostradas na Figura 3.1.
