FACULDADE IETEC
Amanda da Silva Pinto Ana Cláudia Grossi de Oliveira
Izabella Amim Gomes Luciene Martins
Saymon Cristian Alves Oliveira
A IMPORTÂNCIA DA AUTOMAÇÃO DE TESTES EM DEVOPS
Belo Horizonte 2018
Amanda da Silva Pinto Ana Cláudia Grossi de Oliveira
Izabella Amim Gomes Luciene Martins
Saymon Cristian Alves Oliveira
A IMPORTÂNCIA DA AUTOMAÇÃO DE TESTES EM DEVOPS
Trabalho de conclusão de
aperfeiçoamento apresentado ao Curso Métodos Ágeis e Práticas DevOps da Faculdade Ietec, turma nº1702_T2, como requisito parcial à obtenção do título de Aperfeiçoamento em Métodos Ágeis e Práticas DevOps.
Orientador: Prof. Dr. Fernando H. Zaidan
Belo Horizonte 2018
RESUMO
A Engenharia de Software tem como seus objetivos propor a melhoria na produtividade dos processos de desenvolvimento de software, assim como garantir a qualidade do produto. Para estes processos foram criados mecanismos de qualidade, que recomendam métricas e atividades que passam a ser rotina do desenvolvimento de projetos em fábricas de softwares. Diferentemente da gestão de projetos de desenvolvimento de software tradicional, a gestão ágil possui um modelo de desenvolvimento interativo, onde são criados pequenos incrementos de software, e consequentemente, frequentes entregas de valor, emergindo os problemas mais rapidamente, eliminando assim os problemas de forma ágil e resultando em alta qualidade do produto. As metodologias ágeis e as práticas DevOps buscam utilizar meios de automatizar as etapas do ciclo de desenvolvimento para melhor atender às rápidas entregas. Nesse contexto de ciclos curtos e adaptáveis de desenvolvimento, o objetivo deste trabalho é avaliar através de questionário de pesquisa, como as empresas estão alinhando o desenvolvimento de software às práticas de automação de testes e qualidade da entrega do produto. Ao final do trabalho, como resultado da pesquisa, será demonstrada a importância do desenvolvimento de software aliado a automação de testes e sua entrega com qualidade utilizando práticas DevOps e é proposto um guia de boas práticas para obter entregas eficientes e eficazes em todas as etapas do ciclo de desenvolvimento de software.
Palavras-chave: Automatização de testes. Metodologias Ágeis. Qualidade. Scrum. DevOps.
LISTA DE ILUSTRAÇÕES
Figura 1 - Estágios de testes em um pipeline de implantação ... 24 Figura 2 - Pirâmide de testes automatizados ... 27 Quadro 1 - Guia de boas práticas ... 75
LISTA DE GRÁFICOS
Gráfico 1 - Porte da empresa ... 35
Gráfico 2 - Ramo da empresa ... 36
Gráfico 3 - Empresas que possuem ou não orçamento específico na área de TI . 36 Gráfico 4 - Entrevistados por cargo ... 37
Gráfico 5 - Tempo de vida da empresa ... 37
Gráfico 6 - Utilização de métodos ágeis na empresa ... 38
Gráfico 7 - Tipo de modelo de gestão de requisitos utilizado(s) ... 38
Gráfico 8 - Forma de insumo para plano de testes utilizado(s) ... 39
Gráfico 9 - Responsáveis pelas atividades de testes envolvendo os desenvolvedores na empresa ... 39
Gráfico 10 - Grau de independência dos testes que envolvem uma equipe de QA na empresa ... 40
Gráfico 11 - Grau de independência dos testes que não envolvem uma equipe de QA na empresa ... 41
Gráfico 12 - Fase do ciclo de vida que os responsáveis pelos testes são envolvidos na empresa ... 42
Gráfico 13 - Atividade que consome maior esforço dos responsáveis pelos testes 43 Gráfico 14 - Forma de elaboração de casos de testes ... 43
Gráfico 15 - Porcentagem por níveis de testes, que são automatizados ... 44
Gráfico 16 - Forma que os testes automatizados são executados ... 45
Gráfico 17 - Forma em que a infraestrutura dos testes é gerenciada pelas empresas ... 45
Gráfico 18 - Forma de controle de versão ... 46
Gráfico 19 - Forma de geração de executáveis na empresa ... 46
Gráfico 20 - Forma em que o deploy é realizado ... 47
Gráfico 21 - Atividades que geram gargalos ... 47
Gráfico 22 - Utilização de métricas ... 48
Gráfico 23 - Forma que é realizada a retrospectiva e aprendizagem ... 48
Gráfico 24 - Nível de maturidade em testes ... 49
LISTA DE TABELAS
Tabela 1 - Distribuição percentual e quantitativa de entrevistados por porte de empresa ... 50 Tabela 2 - Distribuição da porcentagem de empresas por ramo ... 51 Tabela 3 - Distribuição da porcentagem do tempo de vida da área de TI na
empresa ... 51 Tabela 4 - Distribuição da porcentagem do cargo ocupado ... 52 Tabela 5 - Distribuição da porcentagem do orçamento específico para área de
TI ... 52 Tabela 6 - Distribuição da porcentagem das empresas que utilizam métodos ágeis
no desenvolvimento de software ... 53 Tabela 7 - Distribuição da porcentagem das empresas que utilizam a automação de
teste ... 53 Tabela 8 - Distribuição da porcentagem dos níveis de testes que são
automatizados ... 53 Tabela 9 - Distribuição da porcentagem do modelo de gestão de requisitos ... 55 Tabela 10 - Distribuição da porcentagem de insumos para plano de teste ... 56 Tabela 11 - Distribuição da porcentagem dos responsáveis pelas atividades de
testes que envolvem desenvolvedores ... 60 Tabela 12 - Distribuição da porcentagem do grau de independência dos testes que
envolvem uma equipe de QA ... 60 Tabela 13 - Distribuição da porcentagem da fase do ciclo de vida do software em que
os responsáveis são envolvidos ... 62 Tabela 14 - Distribuição da porcentagem da parte do processo em que os
responsáveis pelos testes são envolvidos ... 63 Tabela 15 - Distribuição da porcentagem das atividades que consomem maior
esforço pelos responsáveis pelos testes ... 64 Tabela 16 - Distribuição da porcentagem de elaboração de casos de teste ... 64 Tabela 17 - Distribuição da porcentagem sobre a forma de execução do teste
automatizados ... 65 Tabela 18 - Distribuição da porcentagem da forma de controle de versão de
código ... 66 Tabela 19 - Distribuição da porcentagem da forma de geração dos executáveis ... 67
Tabela 20 - Distribuição da porcentagem da forma de deploy dos executáveis ... 68
Tabela 21 - Distribuição da porcentagem de métricas ... 69
Tabela 22 - Distribuição da porcentagem de atividades que geram gargalos no ciclo de vida do Software... 70
Tabela 23 - Distribuição da porcentagem de infraestrutura de testes ... 71
Tabela 24 - Distribuição da porcentagem de retrospectiva e aprendizado ... 72
Tabela 25 - Distribuição da porcentagem de maturidade em testes ... 73
LISTA DE ABREVIATURAS E SIGLAS
AM Agile Modeling
API Application Programming Interface BDD Behavior Driven Development DEV Desenvolvedor
GUI Grafics User Interface IaaS Infrastructure as service PM Product Manager
QA Quality Assurance SVN Subversion
TDD Test Driven Development XP eXtreme Programming
SUMÁRIO 1 INTRODUÇÃO ... 11 1.1 Questão da Pesquisa ... 13 1.2 Objetivos ... 13 1.2.1 Objetivo geral ... 14 1.2.2 Objetivos específicos ... 14 1.3 Justificativa ... 14 1.4 Estrutura do trabalho ... 15 2 REVISÃO DE LITERATURA ... 16 2.1 Métodos Ágeis ... 16 2.1.1 Scrum ... 17 2.1.2 eXtreme Programming (XP) ... 18 2.1.3 Kanban ... 18 2.2 DevOps ... 19 2.3 Integração Contínua ... 21 2.4 Controle de Versões ... 21 2.5 Pipeline de entrega ... 22 2.6 Testes automatizados ... 24
2.6.1 Técnicas de desenvolvimento de testes automatizados ... 27
3 METODOLOGIA... 31
3.1 Delineamento da pesquisa ... 31
3.2 Instrumento de pesquisa ... 32
3.3 Piloto do instrumento da pesquisa ... 33
4 LEVANTAMENTO DE DADOS ... 35
5 DISCUSSÃO DOS RESULTADOS ... 50
5.1 Avaliar a utilização de métodos ágeis no desenvolvimento e automação de testes pelas organizações ... 50
5.2 Evidenciar os procedimentos adotados de realização de testes e a garantia da qualidade pelas empresas desenvolvedoras ... 55
5.3 Identificar principais vulnerabilidades no processo de testes de software .... 58
5.4 Levantar as melhores práticas e monitoramento aplicados para garantir a automação de testes, qualidade e entrega final do produto a fim de satisfazer as necessidades do cliente ... 75
6 CONCLUSÃO... 78
REFERÊNCIAS ... 80
1 INTRODUÇÃO
A adoção das práticas ágeis vem se tornando cada vez mais comuns nas empresas de tecnologia. Baseados em modelos ou metodologias, os processos definem qual a forma de organização e gerenciamento que cada projeto será trabalhado. Modelos ou metodologias são abordagens organizadas por meio de passos estabelecidos para atingir objetivos específicos. Segundo Rezende (2007) a metodologia é um roteiro que permite uma ou várias técnicas por opção dos desenvolvedores do sistema de informação ou software.
A gestão ágil de projetos de software é um modelo de desenvolvimento altamente iterativo, onde são criados pequenos “pedaços” de software, e consequentemente, frequentes entregas de valor, emergindo os problemas mais rapidamente, possibilitando corrigi-los, amenizando ou eliminando os impactos na produtividade do projeto, prazo de entrega, aumento de custos e perda de oportunidades de mercado, resultando em um produto de alta qualidade.
As equipes de desenvolvimento de software se tornaram mais eficientes com entregas mais rápidas em um período menor, assim, de acordo com Pressman (2006), o modelo ágil ressalta quatro tópicos chaves: a importância de equipes auto organizadas que tem controle sobre o trabalho que executam, comunicação e colaboração entre os membros da equipe, reconhecimento de que codificações representam oportunidade e uma ênfase na entrega rápida do software. Para Pressman (2006), agilidade é mais do que uma resposta efetiva a modificação, encoraja estruturas e atitudes da equipe que tornam a comunicação mais fácil, enfatiza a rápida entrega de software operacional e dá menos importância para produtos de trabalhos intermediários; adota os clientes como parte da equipe de desenvolvimento; reconhece que o planejamento em mundo incerto tem seus limites e que um plano de projeto deve ser flexível.
Contudo, existe no mercado uma grande dificuldade em entregar novas funcionalidades (features) para um sistema já em produção: os conflitos de interesses entre equipes de desenvolvimento e operação se tornaram cada vez mais frequentes, pois o time de desenvolvimento almeja entregar de forma ágil, enquanto a equipe de
operações busca manter a estabilidade do software, já que a mudança de uma funcionalidade pode trazer risco para o pleno funcionamento do sistema e continuidade de seus serviços. Problemas de performance ou até mesmo um bug crítico encontrado na aplicação geram conflitos entre as equipes na busca de um responsável: equipe de desenvolvimento ou equipe de operação.
Surgiram movimentos para estreitar as relações entre as equipes de desenvolvimento e de operações de forma que elas pudessem colaborar entre si desde a concepção do projeto até a entrega final do software, ou seja, durante todo o seu ciclo de vida. Segundo Telles (2014), surgiram novos conceitos e técnicas a fim de agilizar a comunicação entre setores empresariais e estes eventos disseminaram uma cultura baseada na união e cooperação entre diferentes equipes de uma mesma empresa. Surgiu-se então o conceito de DevOps com o objetivo de transformar o processo de liberação de software em um sistema automatizado, confiável, com qualidade e entrega contínua. Ainda segundo Telles (2014) esse tipo de produção exige agilidade, facilidade de comunicação e eficiência de todos os envolvidos – tanto as equipes de infraestrutura quanto as de desenvolvimento precisam ter um só objetivo: entregar o produto ao cliente dentro do prazo e com a qualidade desejada. Assim o início da evolução da automatização dos processos de software está dentro da cultura denominada de DevOps, onde toda concepção, desenvolvimento, testes e entrega de produto poderá ser gerenciada por ferramentas automatizadas as quais promovem integração entre toda a equipe com um benefício da qualidade da entrega do produto e do feedback imediato.
Para Pressman (2002), o teste de software é um elemento crítico da garantia de qualidade de software e representa a revisão final da especificação, projeto e geração de código. A qualidade dos sistemas reflete diretamente ao bom atendimento das necessidades dos clientes, deste modo, os negócios precisam ter seus sistemas e aplicativos funcionando perfeitamente. Nesta continuação, a automação de testes busca assegurar a qualidade dos softwares visando que as empresas tenham uma boa eficiência, eficácia e efetividade. Em um mercado cada vez mais competitivo, qualidade é o que diferencia sua empresa de outra, onde sempre é necessário satisfazer e inclusive superar as expectativas dos seus clientes na qualidade da solução que é produzida. Nessa perspectiva, este trabalho busca demonstrar como
os testes de software automatizados podem garantir a qualidade da sua empresa em utilização com boas práticas provindas da cultura de DevOps e como podem esclarecer dúvidas crescentes sobre este serviço inovador.
Para Veloso (2014), um teste automatizado é o uso da inteligência de software que controla a execução e a aderência dos resultados obtidos comparando-os com os resultados esperados, tentando alcançar através de ferramentas e técnicas adequadas um processo de qualidade aceitável. Além de avaliar a aplicação à procura de “defeitos” que possam de alguma forma influenciar negativamente na qualidade do serviço que podem causar grandes impactos se não dominado com antecedência.
O mesmo autor informa que com esta série de benefícios fica evidente que a automação de testes é uma ferramenta muito poderosa e um diferencial de mercado marcante, que atende às necessidades do cliente, tanto pela segurança que fornece durante a execução do projeto, quanto pela forma com que faz a aderência entre o projeto realizado e o projeto idealizado. Com certeza os resultados obtidos através da utilização desse método serão percebidos pelos usuários e pelos clientes, que atribuirão qualidade à empresa, e assim a organização estará atendendo seu ativo mais importante: os seus clientes.
1.1 Questão da Pesquisa
Visto a necessidade de garantir a qualidade do software desenvolvido pelas empresas, assim como segurança e aderência entre projeto e execução e a satisfação dos clientes, este estudo pode ser representado pela seguinte questão:
Como os testes automatizados podem ajudar a garantir a qualidade de software?
1.2 Objetivos
Neste tópico serão apresentados o objetivo geral e os objetivos específicos que nortearam esta pesquisa.
1.2.1 Objetivo geral
Demonstrar a importância do desenvolvimento de software aliado a automação de testes e sua entrega com qualidade utilizando práticas DevOps.
1.2.2 Objetivos específicos
a) Avaliar a utilização de métodos ágeis no desenvolvimento e automação de testes pelas organizações;
b) Evidenciar os procedimentos adotados de realização de testes e a garantia da qualidade pelas empresas desenvolvedoras;
c) Identificar principais vulnerabilidades no processo de testes de software; d) Levantar as melhores práticas e monitoramento aplicados para garantir a
automação de testes, qualidade e entrega final do produto a fim de satisfazer as necessidades do cliente.
1.3 Justificativa
Um dos maiores problemas de qualidade de software é sua gestão, percebe-se que poucas pessoas possuem informação ou conhecimento necessário para garantir a qualidade de um produto. Neste sentido, Pressman (2010) explica que para alguns desenvolvedores, a preocupação com o conceito de qualidade de um produto vem somente após o produto estar finalizado.
Portanto, o tema mostra sua relevância à medida que possibilita a formação de um corpo de conhecimento sobre um assunto ainda pouco aplicado, mas de extrema importância, não só para a saúde financeira de uma empresa detentora de software, mas também aos clientes finais que receberão um produto certificado com qualidade. Este conhecimento será extremamente útil para as empresas desenvolvedoras de software que desejam contribuir de forma mais relevante para o cumprimento das boas práticas e métricas de qualidade e assegurar um padrão de qualidade e melhoria contínua na entrega de seu produto:
a) demonstrar às organizações quais os impactos causados pela falta de comunicação entre as equipes de desenvolvimento e testes;
b) apresentar os impactos e prejuízos causados às fábricas de softwares devido a erros de produtos causados por falta de procedimentos de testes;
c) falta de investimento em tecnologia para automação de testes; d) qualificação de mão de obra;
e) alta taxa de insatisfação do cliente final com produto entregue; f) apoio da alta direção - cultura organizacional.
Qualidade de projeto se refere às características que projetistas planejam para um item, como por exemplo, indicadores de tolerância e desempenho. A qualidade de conformidade é o nível com que um produto atende às suas especificações (PRESSMAN, 2010, p.26).
1.4 Estrutura do trabalho
O trabalho está organizado como segue: após os contextos acima, a seção 2 contém a revisão de literatura na qual se elucidou os conceitos de Métodos Ágeis, DevOps, Integração e Entrega Contínuas, Testes Automatizados e suas técnicas. A seção 3 contém a metodologia de pesquisa utilizada, detalhando a construção, validação e verificação do questionário da pesquisa quantitativa. A seção 4 mostra o levantamento de dados, assim como o diagnóstico que foi feito do cenário atual das empresas nas quais os respondentes do questionário trabalham. A seção 5 traz o resultado da pesquisa, a discussão dos resultados feita após a coleta dos dados do questionário. A seção 6 descreve a conclusão do trabalho, limitações do estudo e recomendações de continuidade do mesmo.
2 REVISÃO DE LITERATURA
Este capítulo aborda conceitos relacionados às Metodologias Ágeis de desenvolvimento de software, como Scrum, XP, Kanban e conceitos de DevOps, como Integração Contínua, Controle de Versões, Pipeline de Entregas Contínuas e Testes Automatizados. Estes conceitos são fundamentais para o entendimento e objetivos deste trabalho.
2.1 Métodos Ágeis
A utilização de métodos ágeis no desenvolvimento de software tem como características intrínsecas a flexibilidade e rapidez nas respostas a mudanças. A agilidade, para uma organização de desenvolvimento de software, é a habilidade de adotar e reagir rapidamente e apropriadamente a mudanças no seu ambiente e por exigências impostas pelos clientes (NERUR; MAHAPATRA; MANGALARAJ, 2005).
Os métodos ágeis compartilham valores como comunicação, feedback constante, colaboração com o cliente e constante adaptação são baseados no manifesto ágil. Os quatro princípios básicos do manifesto ágil mostram o que se espera de qualquer método de desenvolvimento desta categoria:
1. Indivíduos e interações sobre processos e ferramentas; 2. Software funcionando sobre documentação extensiva; 3. Colaboração com o cliente sobre negociação de contrato; 4. Responder às mudanças sobre seguir um planejamento.
De acordo com Mendonça e Silva (2014, p. 24), o papel do cliente é crucial para participar das validações quando se trata projetos ágeis, também determina em conjunto com a equipe de desenvolvimento o que será prioridade para se desenvolver. Se tratando em participação de diferentes papéis dentro da equipe, nos projetos ágeis é feito a prática de entregas de releases com menor espaço de tempo, com isso, permite um feedback imediato de satisfação do cliente. A equipe de desenvolvimento deverá focar em atualizar o software após alguma mudança de requisitos, diminuindo o risco de grandes impactos em produção.
Da perspectiva do produto, métodos ágeis são mais adequados quando os requisitos estão emergindo e mudando rapidamente, embora não exista um consenso completo neste ponto. De uma perspectiva organizacional, a aplicabilidade pode ser expressa examinando três dimensões chaves da organização: cultura, pessoal e comunicação. Em relação a estas áreas, inúmeros fatores chave do sucesso podem ser identificados (COHEN; LINDVALL; COSTA, 2004).
Com a divulgação do manifesto ágil, fora publicado um conjunto de princípios, valores e práticas de modelagem de software adaptadas a nova proposta de desenvolvimento ágil, que denominou a modelagem ágil (AMBLER, 2002).
Nos sub tópicos seguintes serão detalhados alguns métodos e frameworks que conduzem as melhores práticas para cada empresa a qual queira se inserir nesta cultura.
2.1.1 Scrum
De acordo com Oliveira (2014) uma opção é o framework Scrum que é um dos métodos ágeis em destaque e muito utilizado em empresas de médio porte. Neste método um membro fica responsável pela gestão, assim sendo denominado de Scrum Master, coordenando iterações chamadas sprints por períodos definidos de trinta dias, neste ciclo toda a equipe é envolvida e trabalha. O termo Scrum é derivado de uma estratégia no jogo de rugby, explica Abrahamsson et al. (2002), nessa jogada é necessário que o time trabalhe de forma colaborativa, ou seja, em equipe para que seja efetivo. Assim as três fases deste framework são: pré-jogo (planejamento), desenvolvimento e pós jogo.
Na fase de planejamento é feito uma definição do que será desenvolvido, com o apoio direto e ativo do cliente cria-se uma lista de backlog de trabalho conforme prioridades pré-estabelecidas e estimativas de esforços da equipe. Onde, na etapa de desenvolvimento, esta lista sofrerá constantes atualizações à medida que o projeto for sendo incrementado, minimizando problemas futuros e garantindo um feedback imediato do cliente. Neste sentido Abrahamsson et al. (2002) define que o controle das mudanças é um dos objetivos deste framework, permitindo flexibilizar o time sob
oscilações dos requisitos. Esta etapa é imprevisível, existir variáveis que influenciam diretamente nas priorizações (prazo, custo, tempo, recurso). Por último é feito a fase pós-jogo, que é alcançada assim que os requisitos tenham sido concluídos, nesta etapa a preparação para publicação no ambiente de produção estará como uma das tarefas bem como uma validação com testes de sistemas e integração.
2.1.2 eXtreme Programming (XP)
A eXtreme Programming (XP) é uma metodologia ágil, orientada para equipes pequenas e médias, que desenvolvem softwares baseados em requisitos vagos, que se modificam rapidamente (KOSCIANSKI; SOARES, 2007). Algumas das principais diferenças da XP para as outras metodologias são:
a) feedback constante; b) abordagem incremental;
c) encorajamento de comunicação face a face.
O modelo poderá trazer vários benefícios para que o processo de desenvolvimento se torne mais flexível e ágil. A comunicação com o cliente, no XP, é mais intensa que nos métodos tradicionais, devendo o cliente estar sempre disponível para tirar as dúvidas, rever requisitos e atribuir prioridades. As equipes devem se manter integradas com os projetos, melhorando a comunicação e a produtividade. Outra característica importante do XP é que o código é sempre escrito em duplas, visando a melhorar a qualidade do código por um custo baixo. O código deve estar padronizado, para que todos na equipe possam entender o que está sendo escrito e possa ser validado durante todo o desenvolvimento, tanto pelos desenvolvedores quanto pelos clientes, a fim de se saber se os requisitos estão sendo ou não atendidos conforme informado por (BECK, 1999).
2.1.3 Kanban
É uma técnica japonesa, integrada no conceito just in time, com origem nos cartões utilizados em fábricas automobilísticas, com intuito de solicitar componentes a uma outra equipe pertencente a uma mesma linha de produção.
Conforme Anderson (citado por KNIBERG; SKARIN, 2009, p. 10), Kanban é baseado em uma ideia simples, na qual atividades são limitadas. Uma atividade nova só pode ser iniciada quando outra atividade for liberada, os cartões do Kanban são sinais visuais indicando que novo trabalho pode ser iniciado e que atividade atual não coincide com o limite acordado.
Na visão de Anderson (citado por KNIBERG; SKARIN, 2009, p. 11), Kanban é uma abordagem para mudança gerencial, não é um processo ou ciclo de vida de gerenciamento de software. É uma abordagem para introduzir mudanças em um ciclo de desenvolvimento ou metodologia de gerenciamento.
Utilizado como um mecanismo de controle visual para acompanhar o trabalho à medida que ele flui através de um quadro branco ou sistema de cartões eletrônicos, o Kanban vai além da transparência, expõe gargalos, filas, variabilidade e desperdício. Tudo que impacta o desempenho da organização em termos de quantidade de trabalho de valor entregue e o tempo de ciclo necessário para que seja entregue. Proporciona a visibilidade sobre os efeitos de suas ações ou falta de ações (Anderson, 2009, p. 12, apud KNIBERG; SKARIN).
Carlos (2012) afirma que a visibilidade de gargalos, desperdícios, variabilidade e seus impactos o Kanban proporciona a evolução incremental de processos existentes, evolução que é geralmente alinhada a valores ágeis e lean, através de discussões e melhorias identificadas e iniciadas rapidamente pela equipe.
2.2 DevOps
Segundo Wootton (2013), existe certa dificuldade das empresas desenvolvedoras na entrega de qualidade de seus produtos e satisfação dos seus clientes. Entregar software em produção é um processo que tem que se tornado cada vez mais difícil nas empresas de T.I. Equipes ágeis encontram barreiras com o processo de entrega, mesmo o software estando “pronto” ao final de cada interação. A tecnologia por si só não oferece vantagem competitiva; as organizações estão descobrindo que os modelos tradicionais de desenvolvimento de software e de entrega não são suficientes
e que as relações entre as equipes de desenvolvimento e operações que estão envolvidas nos projetos promovem grandes ganhos.
No entanto, a entrega de inovação de base tecnológica pode ser um diferencial competitivo e, quando sustentada ao longo do tempo, torna-se uma competência essencial. Inovação sustentada significa desenvolver continuamente novas ideias em software inovador, que por sua vez melhora continuamente o valor entregue aos usuários e que para o mesmo autor, “os processos manuais são propensos a erros, quebras, desperdício e atraso de resposta às necessidades” assim ficando evidente para determinados processos que envolvem atividades do software, a busca por automação evita e reduz falhas humanas.
Neste contexto para Hutterrmann e Michael (2012), DevOps envolve inúmeras atividades e aspectos, tais como a cultura, automação, medição e o compartilhamento de conhecimentos. DevOps é, em muitos aspectos, um conceito abrangente que se refere a qualquer coisa que suaviza a interação entre desenvolvimento e operações.
No entanto, as ideias por trás do DevOps são muito mais profundas. DevOps é uma abordagem baseada em princípios lean e ágil - consideradas práticas principais em DevOps - em que as organizações e as equipes de desenvolvimento, operações e departamentos de controle de qualidade colaboraram para entregar software de forma contínua, permitindo a empresa aproveitar mais rapidamente as oportunidades de mercado e reduzir o tempo para obter o feedback do cliente. (BRAGA, 2015, p.25).
Em se tratando de DevOps, segundo Sharma (2014), a sua essência vai além de técnicas, processos e ferramentas, pois trata-se de uma mudança de mindset cultural que deverá ser criado dentro da empresa que queira adotá-lo. Possuir uma maturidade automatizada em processos através de ferramentas evitando falhas manuais é eficiente, contudo se torna inútil se for usado por pessoas de maneira incorreta ou que não buscam um objetivo da organização. A cultura DevOps deverá ir além de ferramentas automatizadas, o objetivo da equipe de projetos deverá se focar na organização invés de equipes separadas.
2.3 Integração Contínua
Conforme Sato e Danilo (2013) apresentam, aquilo que a essência de DevOps busca promover e otimizar a colaboração entre equipes de desenvolvimento e operações, onde uma das principais atividades para os desenvolvedores é criar códigos confiável e robustos. Com o apoio de metodologias como a XP, este desenvolvimento se torna viável para softwares em constante mudanças por conta de práticas como: refatoração, Test Driven Development (TDD), propriedade coletiva de código, design incremental, programação em pares, padrões de código e integração contínua. A integração contínua, é uma prática que contribui para a resolução de problemas de disponibilidade de mudanças de maneira ágil onde é possível identificar rapidamente adversidades e de forma vertiginosa corrigi-las.
Nesta etapa, fica claro que o código e a gestão da informação estão contidos para toda a equipe, assim de maneira compartilhada a equipe de desenvolvimento adota um processo de garantia de versionamento através de ferramentas como Git ou Subversion (SVN). Com o código versionado, o processo segue com a construção ou build do projeto localmente para garantir que a parte unitária de cada desenvolvedor estará funcionando e quando for se integrar no resto do código da equipe não apresente falhas.
Ainda segundo Sato e Danilo (2013), o servidor de integração contínua, o qual é responsável por monitorar o repositório central de código, funcionando como um radiador de informações em tempo real, ao iniciar um build do projeto toda vez que detectar um novo commit, assim, o resultado poderá ser sucesso ou falha, em caso de falha é esperado que as ferramentas tenham uma forma de feedback rápido como painéis de controle, integrações com ferramentas de comunicação ou envio de e-mail para que a equipe receba a informação da ocorrência, se motive e busque resolver.
2.4 Controle de Versões
O trabalho de desenvolvimento de software feito em equipe envolve disciplina desde que as equipes possuem mais de um desenvolvedor atuando no mesmo projeto. Sendo necessário uma forma de versionamento de código permitindo trabalho em
paralelo e rastreabilidade do que está sendo criado e publicado em produção. Atualmente existe no mercado diversas ferramentas que oferecem suporte para gerir o versionamento local ou remoto tais como GitHub, bitbucket, svn, gitlab e no caso da ferramenta gitlab ainda é possível incluir práticas DevOps de pipeline de trabalho com atividades de integração contínua até entrega contínua com feedback imediato.
Conforme Sato e Danilo (2013), práticas de controle de versão de código se estendem além do código fonte e são utilizadas para códigos de infraestrutura e até configurações de ambientes, servidores envolvendo assim as equipes de desenvolvimento e operações. O controle de versão está diretamente ligado à cultura DevOps, que se tratando de processo de desenvolvimento, é iniciado ao desenvolvedor realizar o check-in ou commit no repositório pertencente à um pipeline de entrega contínua em DevOps exigindo disciplina e colaboração da equipe envolvida no projeto.
2.5 Pipeline de entrega
Segundo Fowler (2013), um dos desafios de um ambiente de teste e compilação automatizado é o desejo de uma compilação rápida, para que seja dado um feedback rápido, mas testes abrangentes demoram muito para ser executados. Um pipeline de implantação é uma maneira de lidar com isso, dividindo sua compilação em etapas. Cada estágio ou etapa, fornece confiança crescente, geralmente ao custo do tempo extra. Os estágios iniciais podem encontrar a maioria dos problemas que produzem feedback mais rápido, enquanto os estágios posteriores fornecem mais lento e mais através da sondagem utilizando ferramentas de análise. As condutas de implantação são uma parte central da entrega contínua.
Geralmente, a primeira etapa de um pipeline de implantação fará qualquer compilação e fornecerá binários para fases posteriores. Os estágios posteriores podem incluir verificações manuais, como qualquer teste que não possa ser automatizado. As etapas podem ser automáticas, por exemplo no processo de deploy contínuo ou exigem autorização humana para prosseguir no caso de um pipeline de entrega contínua, elas podem ser paralelizadas em várias máquinas para acelerar a compilação. A implantação em produção geralmente é o estágio final de um pipeline.
Mais amplamente, segundo Fowler (2013) o trabalho do pipeline da implantação é detectar quaisquer mudanças que levem a problemas na produção. Estes podem incluir problemas de desempenho, segurança ou usabilidade. Um pipeline de implantação deve permitir a colaboração entre os vários grupos envolvidos na entrega de software e fornece visibilidade a todos sobre o fluxo de mudanças no sistema, juntamente com uma trilha de auditoria completa.
Para Fowler (2013), uma boa maneira de iniciar uma mudança DevOps através de um processo completo de entrega contínua será modelar seu processo de entrega atual em um processo de pipeline de implantação e após verificar as possibilidades de melhorias, pontos que podem ser automatizados e formas de feedback que favoreçam a comunicação entre as equipes do projeto.
Humble e Farley (2010) afirmam que no mundo DevOps e de entrega contínua, testadores colaboram com os desenvolvedores e usuários para a escrita de testes automatizados desde o início do projeto, escrevendo testes antes que os desenvolvedores iniciem seus trabalhos nessas funcionalidades. O objetivo é fornecer uma boa abrangência do comportamento de modo a garantir assim que as funcionalidades sejam completamente implantadas e de forma correta.
Assim, a Figura 1 faz relação dos estágios que envolvem cada atividade de teste dentro de um processo de pipeline e demonstra onde cada integrante da equipe atua. É possível verificar que o testador é o integrante mais envolvido em diversos níveis de testes para garantir uma boa qualidade daquilo que será disponibilizado no ambiente de testes ou de produção. A qualidade dos feedbacks e um Quality Gate que funciona como um assegurador de qualidade entre etapas, garante ainda mais que as etapas da esteira (pipeline) só avancem se critérios forem atingidos.
Figura 1- Estágios de testes em um pipeline de implantação
Fonte: HUMBLE; FARLEY, 2010.
2.6 Testes automatizados
Á medida que o time de desenvolvimento libera e avança nas entregas de software de maneira ágil, a equipe responsável por garantir a qualidade do software através de testes e verificações de comportamentos não esperados são os testadores. O conceito de testar, cita Bernardo (2011), como uma prática intrínseca ao desenvolvimento e é antiga a necessidade de criar programas para testar cenários específicos, a partir da década de 1970 foi iniciado como objeto de estudo a fim de obter melhorias na qualidade do software.
O foco da etapa de testes é garantir que o software atenda aos requisitos especificados conforme defende Softex (2012). Para a execução dessa atividade, algumas atividades se fazem necessárias, dentre as quais podem ser mencionadas: especificação de casos de testes, execução dos casos de testes especificados, registro de falhas, melhorias e reporte dos resultados obtidos. Cada uma dessas atividades necessita de um esforço grande e dependendo do tipo de software testado, requer que os mesmos testes sejam executados em diferentes configurações, aumentando ainda mais esse esforço. Muitas vezes o cliente desse software exige um feedback rápido, comprometendo a qualidade e sua satisfação. Ainda, segundo o autor do artigo, além disso, usualmente coloca-se toda a responsabilidade pela atividade de teste somente no analista de testes, sobrecarregando esse papel. Certas falhas em fluxos básicos são encontradas somente na fase de testes, porém poderiam ter sido previamente identificadas ainda na fase de desenvolvimento. Desse modo, o
analista de testes, ao invés de focar em testes com cenários bem elaborados e alternativos, foca em garantir que os fluxos principais funcionam conforme o previsto.
Bernardo (2011) afirma que se tratando de testes manuais e o processo contínuo de desenvolvimento de software, é exigido uma grande diligência para a execução dos testes de maneira manual onde mediante tempo e demanda, os mesmos não são executados novamente a cada correção de um erro, assim podendo tornar ainda mais complexo o fluxo de prevenção de erros através de testes regressivos, dificultando a verificação por defeitos adicionados em alguma manutenção ominosa no sistema.
Conforme cita Bernardo e Kon (2008), o controle da qualidade do projeto de maneira constante busca prevenir defeitos ao invés de identificar e corrigir, é uma das principais abordagens de muitos métodos ágeis como Scrum ou XP, ao utilizar scripts de testes automatizados que podem ser executados repetitivamente no decorrer das entregas garantindo o cenário do teste regressivos falhos se executados de maneira manual pelo testador.
Para Meszaros e Wesley (2007), uma forma de tornar os testes de software mais independentes comparados com a intervenção humana, é o uso de testes automatizados como uma boa prática que consiste na criação de scripts que verificam um sistema em teste, desta forma é possível capturar comportamentos e retornos de maneira automática e dinâmica.
O autor defende que os testes automatizados afetam diretamente a qualidade dos sistemas de software, portanto agrega valor ao produto, mesmo que os artefatos adicionais produzidos não sejam visíveis para os usuários finais dos sistemas. Estes testes podem ser divididos em diversos tipos, o que facilita a manutenção dos mesmos.
Defende o autor, que o testador em um projeto ágil deve compreender os princípios que sustentam tal projeto e trabalhar de uma maneira integrada com a equipe inteira, visando uma boa comunicação, até mesmo antes de iniciar o desenvolvimento e com frequência para que sejam feitas análise e remoção dos defeitos de maneira antecipada, reduzindo custos. Com o uso de integração contínua, entende-se que o
software será codificado e disponibilizado para ser testado de maneira mais eficiente e frequente. Para acompanhar tal mudança no processo de concepção de versões do software, os testadores utilizam dos testes automatizados como forma de checar de maneira antecipada o que foi codificado e liberar um feedback rápido de bugs para a equipe tratar os erros.
Para Potel e Cotter (1995) a automação de testes é uma prática ágil, eficaz e de baixo custo para melhorar a qualidade dos sistemas de software. No entanto utilizar testes automatizados como uma premissa básica do desenvolvimento é um fenômeno relativamente recente, com início em meados da década de 1990. A automação de testes é uma técnica bastante utilizada pelas equipes que fazem uso de metodologias ágeis de desenvolvimento. Para as funcionalidades já existentes e estáveis, os testes automatizados são recursos visados para executar testes de regressão, enquanto os testadores concentram seus esforços em testes nas novas funcionalidades que, após a implantação em produção, serão incluídos como novos recursos de testes automatizados, garantindo assim mais cobertura nos testes.
Existem diversas partes ou camadas do software cujos testes podem ser automatizados, conforme Fowler (2012), o ideal é que o ponto de maior investimento deverá ser em testes automatizados de médio e baixo nível comparado aos criados em alto nível (GUI), uma vez que as facilidades de criação dos testes automatizados de alto nível não tornam uma fácil escalabilidade e manutenibilidade, pois são propícios a falhas por mudanças simples na interface. A Figura abaixo representa a pirâmide de testes, Fowler (2012) explica que os testes automatizados mais próximos da interface devem funcionar como uma segunda linha de defesa e investimento, assim a camada intermediária ou camada de serviços e camada de baixo nível (unitária) podem fornecer muitas vantagens e também rápidas respostas de execução ao validar serviços (WebServices ou APIs) e unidades de software (funções e métodos).
De acordo com Sommerville (2011), o processo de teste em métodos ágeis, como o XP, por exemplo, leva muito em consideração o teste de aceitação como um parâmetro de qualidade. O cliente participando do processo ajuda também na elaboração dos critérios para aceitação e o nível de qualidade desejado. Segundo o
autor isso nem sempre é possível, já que o cliente está envolvido com o negócio e tem pouco tempo para apoiar esta atividade. A falta de comprometimento muitas vezes pode acabar fazendo com que o cliente fique relutante ao processo de teste.
No Extreme Programming os requisitos são escritos na forma de histórias do usuário, através dos cartões de cenários, o que facilita também a abordagem do test-first, pois, a decomposição em tarefas permite que sejam escritos testes para cada tarefa (SOMMERVILLE, 2011, p. 47).
Figura 2- Pirâmide de testes automatizados
Fonte: FOWLER 2012. (Adaptado pelos autores).
2.6.1 Técnicas de desenvolvimento de testes automatizados
Segundo o autor Filho (2009), a automação dos testes consiste na utilização de aplicativos específicos capazes de testar exaustivamente um software através de scripts de teste pré configurados. Não representa 100% de cobertura, uma vez que algumas falhas lógicas só ocorrem através de combinações específicas de entradas de dados. A utilização de ferramentas de teste é fundamental para o sucesso do projeto, no entanto, a tarefa de definição de scripts de teste eficazes necessita de profissional qualificado. Além de qualificação para definição do domínio dos testes, é necessário ainda domínio da ferramenta utilizada e tempo para configuração de cada teste, assim como análise dos resultados obtidos versus resultados esperados. A combinação desses fatores é o fator complicador para aplicação de testes automatizados, neste sentido para Filho (2009), existem técnicas que otimizam e simplificam o processo e atividades, como Test Driven Development (TDD) e Behavior Driven Development (BDD).
2.6.1.1 Test Driven Development (TDD)
Desenvolvimento dirigido por testes, também conhecido como TDD (Test-Driven Development) é uma técnica de desenvolvimento de software que se dá pela repetição disciplinada de um ciclo curto de passos de implementação de testes e do sistema (KOSKELA, 2007). O ciclo de TDD é definido pelos seguintes passos:
a) Implementar um caso de teste;
b) Implementar um trecho do código suficiente para o novo caso de teste ter sucesso de tal modo que não quebre os testes previamente escritos;
c) Se necessário, refatorar o código produzido para que ele fique mais organizado.
2.6.1.2 Behavior Driven Development (BDD)
Para Soares (2011), o desenvolvimento Guiado por Comportamento é uma técnica de desenvolvimento Ágil que encoraja colaboração entre desenvolvedores, setores de qualidade e pessoas não-técnicas ou de negócios num projeto de software. Foi originalmente concebido em 2003. Para North (2003), este desenvolvimento segue como uma resposta ao TDD e tem se expandido bastante nos últimos anos. As práticas de BDD segundo North (2003), incluem:
● Envolver as partes interessadas no processo através de Outside-in Development (Desenvolvimento de Fora para Dentro);
● Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código;
● Automatizar os exemplos para prover um feedback rápido e testes de regressão;
● Usar deve (should em inglês) na hora de descrever o comportamento de softwares para ajudar esclarecer responsabilidades e permitir que funcionalidades do software sejam questionadas;
● Usar simuladores de teste (mocks, stubs, fakes, dummies, spies) para auxiliar na colaboração entre módulos e códigos que ainda não foram escritos.
Para mensurar qualidade em desenvolvimento de software, a mesma pode ser entendida como um conjunto de características a serem atendidas em um
determinado grau, de modo que o software atenda aos requisitos explícitos e implícitos de seus usuários segundo (ROCHA et al., 1994), porém, para o autor não se obtém qualidade do produto de forma simples, ela precisa ser construída. Assim, a qualidade do produto depende fortemente da qualidade de seu processo de desenvolvimento. No processo de qualidade de software é necessário que se tenham testes dos produtos desenvolvidos para que o processo de qualidade e entrega do produto fiquem de acordo com os requisitos do cliente, claro que utilizando a atividade de testes por si só, não é capaz de tornar o software livre defeitos. Contudo, quando formalmente feita pode reduzir o número de não conformidades e ainda fornecer dados importantes para uma estimativa da confiabilidade do software. Sua implementação exige, além da capacitação técnica da equipe de desenvolvimento para torná-la capaz de gerar casos de testes consistentes e de alta probabilidade de evidenciar erros, uma estrutura organizacional que permita incorporar a atividade de testes às atividades do ciclo de desenvolvimento e a participação de pessoas isentas na execução dos testes.
De acordo com Chappell (2013) a qualidade de software possui três aspectos principais a serem seguidos, são eles: qualidade funcional, qualidade estrutural e processos de qualidade, o mesmo autor cita que existem muitas ligações entre estes três aspectos de qualidade de software. Por exemplo, melhorar o processo de qualidade com métodos ágeis de desenvolvimento aumenta as chances de conseguir os requisitos do projeto, que também melhora a qualidade funcional do produto, fornece igual ênfase na qualidade funcional, qualidade estrutural e qualidade do processo, podem ampliar a visão de um projeto para incluir as necessidades que são importantes para todas as três partes interessadas: os usuários, as equipes de desenvolvimento e patrocinadores dos produtos. O autor informa que para avaliar a qualidade, é preciso existir formas de medi-la. Ou seja, métricas, é preciso obter uma medida que possa calcular o grau de alcance de uma característica de qualidade. Deste modo, para computar uma característica de qualidade, é necessário estabelecer uma métrica capaz de calcular e fazer uma medição para determinar a medida, resultado da aplicação da métrica escolhida.
De acordo com Negrello (2013), a qualidade do próprio processo de desenvolvimento adotado contribui para a qualidade do produto. Porém, muitas vezes não existe uma
definição clara de papéis e responsabilidades para cada pessoa no time a respeito da qualidade do produto, que atividades e artefatos e ferramentas estão sob sua responsabilidade e como compartilham os mesmos. Mas a resistência da utilização das metodologias ágeis existe por diversos fatores, primeiramente porque ainda existe empresas que esperam os produtos ficarem prontos para posteriormente iniciar o processo de qualidade.
3 METODOLOGIA
Este capítulo apresenta todo o detalhamento da metodologia utilizada para se realizar a pesquisa com as empresas sobre o seu ciclo de desenvolvimento de software, como foi construído o formulário de pesquisa, a fase piloto de validação do questionário e a fase oficial de coleta de dados.
3.1 Delineamento da pesquisa
Esta pesquisa se baseou em um estudo da documentação citada na revisão de literatura, sobre a importância da automação de testes em DevOps, bem como a melhoria contínua nos processos e obtenção de qualidade na entrega do produto de software. Foi utilizada também a pesquisa exploratória com o objetivo de proporcionar familiaridade com o tema da pesquisa envolvendo o levantamento bibliográfico necessário para melhor compreensão sobre a automação de testes em DevOps, melhoria contínua e as melhores práticas adotadas para obtenção de qualidade e entregas eficientes e eficazes junto aos clientes.
O método para realização do estudo fundamentou-se através da abordagem quantitativa baseando-se no exame das informações de forma intuitiva. A obtenção das informações foi feita baseada num determinado grupo de pessoas, com um método conhecido como pesquisa Survey. Segundo Gil (2010) apud Klein et. al (2015), este tipo de método tem o aspecto pela interrogação direta dos respondentes, cujo comportamento, opinião ou características se desejam conhecer com a pesquisa.
Para permitir identificar os atuais cenários que as organizações possuem frente aos processos de realização de testes dos softwares e mensuração de qualidade e nível de satisfação dos clientes, foi realizada uma pesquisa através de questionário / formulário divulgado através do envio de e-mail e mensagens, para os perfis voltados ao desenvolvimento de software, tais como diretores, gerentes, coordenadores e analistas totalizando 46 entrevistados. Pelo fato dos profissionais gestores serem de áreas de disciplinas diferentes como QA, testes, desenvolvimento, requisitos, infra, dentre outras, o formulário de pesquisa foi desenvolvido pelos próprios autores, baseados em suas experiências profissionais e de outras vivências, de forma genérica
a fim de atender a todo esses perfis, para que fosse possível responder o mais naturalmente possível, porém de forma direcionada para contribuir com informações relevantes para o tema foco deste trabalho.
Buscando uma melhor interação e agilidade na coleta de dados, foi realizada por meio eletrônico na ferramenta TypeForm, esta ferramenta permite a criação de formulários de pesquisa altamente legíveis e fácil relação humano-sistema. Para a análise dos dados foram feitas interpretações dos resultados através do adequado tratamento das respostas coletadas no formulário permitindo confrontar as informações e gerar as estatísticas e diante dos resultados obtidos, propor melhores práticas de automação de testes, metodologias, softwares, segurança, permitindo caracterizar o nível de maturidade das organizações em relação ao tema da importância da automação de testes em DevOps.
As atividades executadas para desenvolvimento desta pesquisa estão listadas abaixo, em sua ordem de execução:
1. Revisão bibliográfica: revisão dos conceitos de métodos ágeis, testes automatizados e DevOps.
2. Instrumento de pesquisa: elaboração do questionário e validação em piloto com especialistas.
3. Coleta de dados: divulgação do questionário para o público alvo de gestores e monitoramento das respostas;
4. Análise dos dados: confiabilidade, validade e resultados. 5. Conclusão: considerações, limitações e sugestões futuras.
3.2 Instrumento de pesquisa
Conforme Apêndice A o questionário criado na ferramenta TypeForm [typeform.com] foi dividido em dois tópicos principais agrupando as perguntas, onde:
● Inicialmente, ao acessar o formulário, foi apresentado uma imagem que representa o ciclo do DevOps juntamente com algumas orientações gerais aos entrevistados que iniciaram a utilizar o questionário;
● No primeiro tópico foram apresentados um grupo de 5 perguntas relativas aos dados gerais da empresa onde o entrevistado trabalha, todas objetivas com respostas pré-definidas;
● No segundo tópico até o final do questionário, foram apresentadas 20 perguntas que envolvem dados específicos sobre o desenvolvimento de software da empresa em que o mesmo atua e seus modelos de gestão, métodos e papéis utilizados e envolvidos nas atividades de testes do software produzido. Dessas perguntas, 19 são objetivas com respostas pré-definidas, sendo duas delas com escala (de baixa à alta 0 a 6), e ao final, uma questão aberta para que o entrevistado pudesse compartilhar sua experiência com testes de software e a forma de trabalho que sua equipe gerencia os projetos de desenvolvimento e operações.
3.3 Piloto do instrumento da pesquisa
Antes de iniciar a coleta de dados, o questionário passou por uma validação piloto, para isso, o tipo de validação utilizada foi a Validade Aparente ou de Face, onde é realizado um pré-teste com um grupo restrito a fim de se verificar se as questões apresentadas estão claras e adequadas na visão dos entrevistados. Isso possibilita que sejam feitas melhorias no instrumento de pesquisa, antes de sua aplicação (KLEIN et. al, 2015). A validação piloto foi feita da seguinte forma:
● Validação: 10 especialistas (gestores e analistas da área de desenvolvimento de software) foram convidados a validar o questionário entre os dias 23 de março de 2018 a 26 de março de 2018;
● Foi inserida uma questão aberta no final do questionário piloto para que o convidado pudesse apresentar sua percepção a respeito das perguntas e das variáveis apresentadas;
Com base nessas percepções, foram feitos os seguintes ajustes no questionário: (i) alterações no convite; (ii) alterações nas orientações gerais; (iii) alterações na descrição de variáveis das perguntas; (iv) alterações em variáveis de respostas pré-definidas; (v) alteração da ordem de apresentação de algumas perguntas; (vi) alteração na lógica de algumas respostas para evitar que estas fossem deixadas em branco ou fossem parcialmente respondidas. Após realizados os ajustes no
questionário, a versão final foi divulgada e a coleta oficial foi iniciada, conforme detalhado no tópico 4.
4 LEVANTAMENTO DE DADOS
O público-alvo dessa pesquisa é composto por profissionais que atuam ou que atuaram como gestores e/ou analistas em equipes de desenvolvimento de software em empresas brasileiras de pequeno, médio e grande, porte sendo a TI a área fim ou meio da empresa.
A coleta oficial de dados ocorreu no período de 09 de abril de 2018 a 17 de abril de 2018 através do questionário eletrônico, elaborado via ferramenta Typeform, e disponibilizado no endereço https://saymowan.typeform.com/to/zGQyMW.
Foi obtido um total de 46 respostas, sendo mais de 25 empresas distintas onde todos responderam completamente o questionário, portanto todos as respostas foram consideradas válidas. Todas as respostas obtidas neste trabalho foram analisadas e demonstradas como forma de gráficos (pizza, barras ou colunas) para que se torne o mais entendível para o leitor. Abaixo é possível visualizar todas as perguntas com suas respectivas respostas obtidas na pesquisa deste presente trabalho:
Gráfico 1 - Porte da empresa
Fonte: Dados da pesquisa, 2018.
O Gráfico 1 apresenta o resultado obtido com a pergunta, referente à informação do tipo do porte da empresa, baseada na quantidade de funcionários.
Gráfico 2- Ramo da empresa
Fonte: Dados da pesquisa, 2018.
O Gráfico 2 apresenta o resultado obtido com a pergunta referente à informação se o ramo da empresa é voltado para desenvolvimento de software ou não.
Gráfico 3 - Empresas que possuem ou não orçamento específico na área de TI
Fonte: Dados da pesquisa, 2018.
O Gráfico 3 apresenta o resultado obtido com a pergunta referente à informação de um orçamento específico para a área de TI da empresa.
Gráfico 4 - Entrevistados por cargo
Fonte: Dados da pesquisa, 2018.
O Gráfico 4 apresenta o resultado obtido com a pergunta referente ao cargo ocupado pelos entrevistados.
Gráfico 5 - Tempo de vida da empresa
Fonte: Dados da pesquisa, 2018.
O Gráfico 5 apresenta o resultado obtido com a pergunta referente ao tempo de vida da empresa.
Gráfico 6 - Utilização de métodos ágeis na empresa
Fonte: Dados da pesquisa, 2018.
O Gráfico 6 apresenta o resultado obtido com a pergunta referente ao uso ou não de métodos ágeis no desenvolvimento de software na empresa.
Gráfico 7 - Tipo de modelo de gestão de requisitos utilizado(s)
Fonte: Dados da pesquisa, 2018.
O Gráfico 7 apresenta o resultado obtido com a pergunta referente à (s) forma (s) de gestão de requisitos utilizado (s) no desenvolvimento de software na empresa.
Gráfico 8 - Forma de insumo para plano de testes utilizado(s)
Fonte: Dados da pesquisa, 2018.
O Gráfico 8 apresenta o resultado obtido com a pergunta referente à(s) forma(s) de insumo(s) utilizado(s) para gestão do plano de teste na empresa.
Gráfico 9 - Responsáveis pelas atividades de testes envolvendo os desenvolvedores na empresa
Fonte: Dados da pesquisa, 2018.
O Gráfico 9 apresenta o resultado obtido com a pergunta referente há quem do time está responsável pelas atividades de testes na empresa, envolvendo também os desenvolvedores nas respostas.
Gráfico 10 - Grau de independência dos testes que envolvem uma equipe de QA na empresa
Fonte: Dados da pesquisa, 2018.
O Gráfico 10 apresenta o resultado obtido com a pergunta referente há quem do time está responsável pelas atividades de testes na empresa envolvendo também a equipe de QA nas respostas.
Gráfico 11 - Grau de independência dos testes que não envolvem uma equipe de QA na empresa
Fonte: Dados da pesquisa, 2018.
O Gráfico 11 apresenta o resultado obtido com a pergunta referente ao grau de independência nos testes na empresa que não envolvem uma equipe de QA nesta atividade.
Gráfico 12 - Fase do ciclo de vida que os responsáveis pelos testes são envolvidos na empresa
Fonte: Dados da pesquisa, 2018.
O Gráfico 12 apresenta o resultado obtido com a pergunta referente à qual fase a equipe responsável pelos testes são envolvidos na empresa
Gráfico 13 - Atividade que consome maior esforço dos responsáveis pelos testes
Fonte: Dados da pesquisa, 2018.
O Gráfico 13 apresenta o resultado obtido com a pergunta referente à atividade que demanda maior esforço pelos responsáveis pelos testes na empresa.
Gráfico 14 - Forma de elaboração de casos de testes
Fonte: Dados da pesquisa, 2018.
O Gráfico 14 apresenta o resultado obtido com a pergunta referente à forma que feito a elaboração dos casos de testes na empresa.
Gráfico 15 - Porcentagem por níveis de testes, que são automatizados
Fonte: Dados da pesquisa, 2018.
O Gráfico 15 apresenta o resultado obtido com a pergunta referente ao (s) nível (is) de testes que são automatizados pelas empresas.
Gráfico 16 - Forma que os testes automatizados são executados
Fonte: Dados da pesquisa, 2018.
O Gráfico 16 apresenta o resultado obtido com a pergunta referente à forma em que são realizadas as execuções de testes automatizados pelas empresas.
Gráfico 17 - Forma em que a infraestrutura dos testes é gerenciada pelas empresas
Fonte: Dados da pesquisa, 2018.
O Gráfico 17 apresenta o resultado obtido com a pergunta referente de como é gerenciado a infraestrutura dos testes na empresa
Gráfico 18 - Forma de controle de versão
Fonte: Dados da pesquisa, 2018.
O Gráfico 18 apresenta o resultado obtido com a pergunta referente à forma que é feito o controle das versões dos códigos pelas empresas.
Gráfico 19 - Forma de geração de executáveis na empresa
Fonte: Dados da pesquisa, 2018.
O Gráfico 19 apresenta o resultado obtido com a pergunta referente à forma que é feito a geração dos executáveis pelas empresas.
Gráfico 20 - Forma em que o deploy é realizado
Fonte: Dados da pesquisa, 2018.
O Gráfico 20 apresenta o resultado obtido com a pergunta referente à forma de como são feitos os processos de deploy dos executáveis pelas empresas.
Gráfico 21 - Atividades que geram gargalos
Fonte: Dados da pesquisa, 2018.
O Gráfico 21 apresenta o resultado obtido com a pergunta referente à qual(s) atividade(s) geram o maior gargalo no ciclo de vida do software pelas empresas.
Gráfico 22 - Utilização de métricas
Fonte: Dados da pesquisa, 2018.
O Gráfico 22 apresenta o resultado obtido com a pergunta referente à maneira em que as métricas são utilizadas ou não nas empresas.
Gráfico 23 - Forma que é realizada a retrospectiva e aprendizagem
Fonte: Dados da pesquisa, 2018.
O Gráfico 23 apresenta o resultado obtido com a pergunta referente à maneira que são tratadas as retrospectivas e aprendizados durante o desenvolvimento de software na empresa.
Gráfico 24 - Nível de maturidade em testes
Fonte: Dados da pesquisa, 2018.
O Gráfico 24 apresenta o resultado obtido com a pergunta referente à escala de maturidade em testes. Onde o valor 1 indica o valor mais imaturo e o valor 6 apresenta o valor mais maduro no quesito testes.
Gráfico 25 - Nível da qualidade de software
Fonte: Dados da pesquisa, 2018.
O Gráfico 25 apresenta o resultado obtido com a pergunta referente à escala de qualidade do software construído pelas empresas. Onde o valor 1 indica o valor mais imaturo e o valor 6 apresenta o valor mais maduro no quesito qualidade.
5 DISCUSSÃO DOS RESULTADOS
Nesta seção são apresentados os resultados da análise realizada sobre os dados coletados na pesquisa. Inicialmente apresentam-se os resultados referentes ao perfil das empresas. Na sequência são apresentados os resultados das questões específicas sobre o desenvolvimento de software. Os resultados são apresentados em formato de tabela, representando as questões do formulário da pesquisa aplicada. Os percentuais calculados são baseados num total de 46 entrevistados. A análise e discussão destes resultados estão agrupados de forma a representar uma ou mais tabela e relacionando cada objetivo específico desta pesquisa, apresentados nos tópicos seguintes.
5.1 Avaliar a utilização de métodos ágeis no desenvolvimento e automação de testes pelas organizações
Neste tópico, serão apresentados os resultados e a análise que representam o objetivo específico de avaliar a utilização de métodos ágeis e automação de testes pelas organizações.
Tabela 1 - Distribuição percentual e quantitativa de entrevistados por porte de empresa
Porte da Empresa Quantidade de entrevistados
(%)
Grande (Mais de 100 funcionários) 35 76,09
Média (De 50 a 99 funcionários) 07 15,22
Pequena (De 10 a 49 funcionários) 03 6,52
Micro (Até 09 funcionários) 01 2,17
Total 46 100,0
Tabela 2 - Distribuição da porcentagem de empresas por ramo Empresas do ramo de desenvolvimento de software (%)
Sim 52,17
Não 47,83
Total 100,0
Fonte: Dados da pesquisa, 2018.
Tabela 3 - Distribuição da porcentagem do tempo de vida da área de TI na empresa Tempo de vida da área de TI na
empresa Quantidade de entrevistados (%) Acima de 20 anos 17 36,96 De 01 a 5 anos 10 21,74 De 06 a 10 anos 05 10,87 De 11 a 20 anos 14 30,45 Total 46 100,0
Tabela 4 - Distribuição da porcentagem do cargo ocupado Cargo ocupado pelos respondentes Quantidade de
entrevistados (%) Analistas 18 39,13 Gerentes 15 32,61 Coordenadores 07 15,22 Diretores 06 13,04 Total 46 100,0
Fonte: Dados da pesquisa, 2018.
Quanto aos critérios de identificação das empresas em que os entrevistados atuam, foi anotado que 76,09% trabalham em empresas de grande porte, sendo que 52,17% do total, trabalham em empresas cuja prestação de serviço é na área de desenvolvimento de software. Identifica-se também que 39,13% ocupam cargo de analista e que 36,95% são de empresas em que área de tecnologia da informação possui mais de 20 anos de existência.
Tabela 5 - Distribuição da porcentagem do orçamento específico para área de TI Orçamento específico para área de TI (%)
Sim 78,26
Não 21,74
Total 100,0
Fonte: Dados da pesquisa, 2018.
A maioria das empresas possuem orçamento específico na área de TI de 78,26%. Neste sentido, quando tratamos de possíveis investimentos para a etapa de testes na área de TI, Fowler (2012), indica que o ideal é que o ponto de maior investimento
financeiro em capacitação da equipe e dedicação de tempo de desenvolvimento em testes automatizados deverá ser feito nos níveis médio e baixo comparado aos criados em alto nível (GUI), uma vez que a facilidade de criação dos testes automatizados de alto nível não tornam uma fácil escalabilidade e manutenabilidade, pois são propícios à falhas facilmente por mudanças simples na interface.
Tabela 6 - Distribuição da porcentagem das empresas que utilizam métodos ágeis no desenvolvimento de software
Utiliza métodos ágeis no desenvolvimento de Software (%)
Sim 70
Não 30
Total 100,0
Fonte: Dados da pesquisa, 2018.
Tabela 7 - Distribuição da porcentagem das empresas que utilizam a automação de teste
Automação de testes (%) Automatizam um ou vários níveis de testes 78,24
Não automatizam 21,74
Total 100,0
Fonte: Dados da pesquisa, 2018.
Tabela 8 - Distribuição da porcentagem dos níveis de testes que são automatizados Níveis de testes que são automatizados (%)
Testes de integração (Serviços e APIs), teste de performance 2,17 Testes unitários, teste de interface 2,17
Teste de interface, teste de performance 4,35 Testes unitários, teste de integração (serviços e APIs) testes de
interface, testes de performance
4,35
Teste unitário, teste de interface e teste de performance 4,35
Teste unitário, teste de interface e teste de performance 4,35 Testes unitários, testes de integração (Serviços e APIs) 6,52 Testes de integração (serviços e APIs) 6,52 Testes unitários e testes de performance 8,70
Teste de interface 13,04
Não há 21,74
Total 100,0
Fonte: Dados da pesquisa, 2018.
Quanto aos níveis de testes que são automatizados pelas empresas, percebe-se que a maioria dos entrevistados 78,26% relatam que automatizam em um ou mais níveis de teste, conforme apresentado.
Com base nos resultados obtidos nas questões acima, identificou-se que grande parte das empresas 70% adotam métodos ágeis, sendo elas do ramo de desenvolvimento de software 52% ou não 47% e a maior parte delas 78,24% possui a cultura da automação de testes em um ou vários níveis. Bernardo e Kon (2008), indica que o uso de métodos ágeis como Scrum ou XP é aplicado como uma forma de prevenção de defeitos invés de adotar práticas do modelo tradicional que consiste em somente corrigir defeitos. Os usos da automação de testes nos métodos ágeis são importantes para introduzir uma forma de garantia da prevenção de bugs através de scripts dos testes regressivos que antes eram realizados pelos testadores.
