Post on 25-Mar-2021
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
Gráfico 25 - Nível da qualidade de software ............................................................ 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
Tabela 26 - Distribuição da porcentagem de qualidade em software ...................... 74
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
APÊNDICE A – Instrumento de pesquisa ................................................. 83
11
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
12
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
13
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.
14
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:
15
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.
16
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.
17
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
18
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.
19
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
20
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.
21
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
22
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.
23
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.
24
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
25
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
26
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
27
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).
28
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
29
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
30
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.
31
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
32
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;
33
● 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
34
questionário, a versão final foi divulgada e a coleta oficial foi iniciada, conforme
detalhado no tópico 4.
35
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.
36
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.
37
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.
38
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.
39
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.
40
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.
41
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.
42
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
43
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.
44
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.
45
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
46
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.
47
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.
48
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.
49
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.
50
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
Fonte: Dados da pesquisa, 2018.
51
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
Fonte: Dados da pesquisa, 2018.
52
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
53
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
54
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.
55
Pontos de observação:
1. A maioria 70% afirmam praticar métodos ágeis em seu ambiente de trabalho.
Entretanto, observa-se que 21,74% ainda executam testes manuais em sua
rotina de trabalho. Apesar do uso de métodos ágeis;
2. Se as empresas são praticantes de métodos ágeis, porque o índice tão alto em
não automatização de testes 21,74%?;
3. Das que empresas que automatizam os testes, percebe-se que a maior
porcentagem está na opção da automação somente à nível de interface
13,04%. Entender os benefícios do uso de métodos ágeis combinados com
práticas de prevenção de erros, como por exemplo, ter a cultura de automatizar
vários níveis de testes principalmente níveis médios (serviços e APIs) e baixo
(unitário) provém a antecipação da descoberta dos bugs, gera ganhos de
tempo, prevenção e investimentos para todo o time envolvido no projeto.
Analisando todo o contexto, mediante informações pouco expressivas de
automação em níveis médio e baixo pode ser considerado um ponto negativo
para as empresas.
5.2 Evidenciar os procedimentos adotados de realização de testes e a garantia
da qualidade pelas empresas desenvolvedoras
Neste tópico, serão apresentados os resultados e a análise que representam o
objetivo específico de evidenciar os procedimentos adotados para realização de testes
e a garantia da qualidade pelas empresas.
Tabela 9 - Distribuição da porcentagem do modelo de gestão de requisitos
Modelo de Gestão de Requisitos (%)
Casos de uso, estórias de usuário 2,17
Estórias de usuário, outros 2,17
Não há 2,17
56
Casos de uso 4,35
Estórias de usuário, regras de negócio 10,87
Regras de negócio 17,39
Estórias de usuário 19,39
Casos de usuário, regras de negócio 19,57
Casos de uso, estórias de usuário e regras de negócio 23,91
Total 100,0
Fonte: Dados da pesquisa, 2018.
Quanto à utilização de método para a gestão de requisitos, identifica-se que a grande
maioria dos respondentes usam a abordagem através de determinados modelos,
agrupados da seguinte forma: casos de uso, estórias de usuário e regras de negócio,
sendo 23,91% do total de respostas.
Tabela 10 - Distribuição da porcentagem de insumos para plano de teste
Insumo de plano de Teste (%)
Não há 2,17
Documentação de requisito e levantamento com usuário e interação entre
DEV e QA e engenharia reversa.
4,35
Levantamento com usuário e interação entre DEV e QA 6,52
Interação entre DEV e QA 8,70
Levantamento com usuário 10,87
Documentação de requisito e interação entre DEV e QA 13,04
57
Documentação de requisito e levantamento com usuário e interação entre
DEV e QA
13,04
Documentação de requisito e levantamento com usuário 19,57
Documentação de requisito 21,74
Total 100,0
Fonte: Dados da pesquisa, 2018.
Para insumo de plano de testes, percebe-se que o método mais utilizado é a
documentação de requisitos com 21,74%. Observa-se que houve grande aderência
da prática de interação entre equipes 13,04% e usuários de negócio (19,57%)
conjugado ao modelo de documentação de requisito, conforme demonstra os
percentuais de maior destaque. Este comportamento demonstrado acima, de
interações entre equipes e usuários de negócio, vem a confirmar o que os autores
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 e
mapeamento dos testes automatizados desde o início do projeto, escrevendo testes
antes que os desenvolvedores iniciem seus trabalhos nessas funcionalidades, visto
que o objetivo é fornecer uma boa abrangência do comportamento de modo a garantir
que as funcionalidades sejam completamente implantadas e de forma correta.
Ponto de observação:
Observa-se que 21,74% informam que o método utilizado para insumo de plano de
teste seria: Documentação de Requisitos. Segundo Meszaros e Wesley (2007), em
um projeto ágil os desenvolvedores e testadores devem 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. Diante desta informação, é importante que este insumo
para a criação e manutenção do plano de testes seja compartilhado entre toda a
equipe do projeto desde seu início proporcionando um melhor entendimento para
todos os envolvidos, evitando retrabalho.
58
5.3 Identificar principais vulnerabilidades no processo de testes de software
Neste tópico, serão apresentados os resultados e a análise que representam o
objetivo específico de identificar principais vulnerabilidades no processo de testes de
software nas empresas dos respondentes, no que diz respeito à preparação do
ambiente, realização e automação dos testes. Os resultados referem-se à
disponibilidade de recursos de infraestrutura para execução dos testes, interação junto
às equipes e ferramentas de gestão de aplicações utilizadas.
Diante da apresentação de resultados obtidos pela pesquisa junto aos respondentes
e de acordo com os autores Meszaros e Wesley (2007) onde ambos defendem que
testes automatizados são práticos de tornar os testes de software independentes da
intervenção humana, criando scripts ou programas simples de computador que
exercitam o sistema em teste, capturam os efeitos colaterais e fazem verificações,
tudo automaticamente e dinamicamente, pode-se chegar a algumas reflexões
importantes:
Observa-se pontos positivos, negativos e de melhorias no processo que envolve
desde a concepção até a disponibilização do entregável no ambiente de produção,
pelas empresas.
• Se há um percentual de respostas de empresas que já praticam métodos ágeis
em seus processos: 70%.
• Se a grande maioria das empresas são desenvolvedoras de softwares: 52,17%.
• Se a grande maioria das empresas possui orçamento destinado
especificamente à área de TI 78,26%, o que falta para se obter a qualidade,
tecnologia e melhores práticas em automação dos testes em DevOps?
Diante destes dados percebe-se a aderência às metodologias ágeis e práticas
DevOps pelas empresas. Observa-se, entretanto, algumas vulnerabilidades e
deficiências. Porque então existem as vulnerabilidades destacadas?
● Observa-se que ainda há falta de interação, comunicação e cultura DevOps
onde equipes de desenvolvimento e operação estejam sincronizados para
atender a um mesmo objetivo, ou seja atender ao mesmo projeto, conforme
defende o autor Sharma (2014), onde assim falhas serão imperceptíveis, já que
59
o domínio do processo está ao alcance de todos e não na responsabilidade de
um indivíduo.
● Se existe a preocupação da alta direção na transformação por novos métodos,
novas práticas ágeis para melhorar seus processos internos e satisfação dos
clientes, porque este contraponto e realizar tantos processos manuais como
aponta os resultados?
● De acordo com o autor Bernardo (2011), os testes manuais exigem uma grande
diligência e esforço para a execução dos mesmos onde mediante tempo e
demanda, eles 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.
Como assegurar a qualidade, através da insegurança? Como satisfazer o cliente se
não é possível ter 100% de eficácia de rastreabilidade?
Um ponto muito importante a ser observado na pesquisa, é que mesmo com a alta
aderência, “praticantes por métodos ágeis”, existe ainda pouco investimento em
ferramentas de automatização dos processos, por exemplo, ferramenta para uma
rastreabilidade e gestão dos casos de testes, cultura da automação de testes para
concentrar esforços da equipe responsável pela qualidade somente em demandas
novas nos níveis de testes: interface, serviços e unitário. Segundo defende 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. Essas ferramentas maximizam o tempo, reduzem custos, geram
excelência e garantem qualidade e geram satisfação dos clientes. A utilização de
ferramentas de teste é fundamental para o sucesso do projeto, no entanto, verifica-se
a falta de maturidade das organizações para investimentos nestas ferramentas.
60
Tabela 11 - Distribuição da porcentagem dos responsáveis pelas atividades de
testes que envolvem desenvolvedores
Responsáveis pelas atividades de testes que envolvem os desenvolvedores
(%)
Desenvolvedores, analista de sistemas/analistas de negócio. 2,17
Desenvolvedores, testadores e analista de negócio. 2,17
Desenvolvedores e analistas de negócio. 2,17
Desenvolvedores, testadores, analistas de sistemas/analistas de
negócio.
6,52
Desenvolvedores e testadores. 6,52
Desenvolvedores, analistas de sistemas/negócio. 6,52
Desenvolvedores. 6,52
Total 32,59
Fonte: Dados da pesquisa, 2018.
Tabela 12 - Distribuição da porcentagem do grau de independência dos testes que
envolvem uma equipe de QA
Grau de independência dos testes que envolvem uma equipe de QA
(%)
Teste executado por outro desenvolvedor, teste executado por equipe
de QA interna.
2,17
Teste executado por equipe de QA interna, teste executado por
usuário de negócio e PM também faz teste.
2,17
Teste executado pelo desenvolvedor autor do código, teste executado
por equipe de QA externa, (outsourcing), teste executado por usuário
de negócio.
2,17
61
Teste executado pelo desenvolvedor autor do código, teste executado
por equipe de QA interna, teste executado por equipe de QA externa
(outsourcing).
2,17
Teste executado por equipe de QA interna, teste executado por
equipe de QA externa (outsourcing).
4,35
Teste executado pelo desenvolvedor autor do código, teste executado
por outro desenvolvedor, teste executado por equipe de QA interna
4,35
Teste executado pelo desenvolvedor ator do código, teste executado
por equipe de QA externa (outsourcing).
4,35
Teste executado por equipe de QA interna, teste executado por
usuário de negócio.
6,52
Teste executado por equipe de QA externa (outsourcing). 6,52
Teste executado pelo desenvolvedor autor do código, teste executado
por equipe de QA interna, teste executado por usuário de negócio.
6,52
Teste executado pelo desenvolvedor autor do código, teste executado
por equipe de QA interna.
6,52
Teste executado por equipe de QA interna. 19,57
Total 100,0
Fonte: Dados da pesquisa, 2018.
62
Tabela 13 - Distribuição da porcentagem da fase do ciclo de vida do software em que
os responsáveis são envolvidos
Fase do ciclo de vida do software em que os responsáveis são envolvidos
(%)
Homologação, nenhuma das opções. 2,17
Especificação de requisitos, término do desenvolvimento,
homologação.
2,17
Desenvolvimento de código, homologação. 2,17
Desenvolvimento de código. 2,17
Nenhuma das opções. 4,35
Especificação de requisitos, desenvolvimento do código, término do
desenvolvimento.
4,35
Especificação de requisitos, desenvolvimento do código,
homologação.
4,35
Especificação de requisitos, homologação. 6,52
Especificação de requisitos, desenvolvimento do código. 6,52
Especificação de requisitos. 6,52
Término do desenvolvimento, Homologação. 8,70
Desenvolvimento do código, término do desenvolvimento,
Homologação.
10,87
Homologação. 15,22
Especificação de requisitos, desenvolvimento do código, término do
desenvolvimento e Homologação.
15,22
Total 100,0
63
Fonte: Dados da pesquisa, 2018.
Através dos dados demonstrados acima, percebe-se que há empate 15,22% junto aos
entrevistados quando se questiona em qual parte do processo os “responsáveis pelos
testes” são envolvidos. Este empate é caracterizado por fases de extrema importância
da participação deste papel do responsável pelo teste, e é onde se identifica a maior
participação deles. As fases em destaque são:
Tabela 14 - Distribuição da porcentagem da parte do processo em que os
responsáveis pelos testes são envolvidos
Em qual parte do processo os responsáveis pelos testes são envolvidos
(%)
Especificação de requisitos, desenvolvimento do código, término do
desenvolvimento e Homologação.
15,22
Homologação. 15,22
Fonte: Dados da pesquisa, 2018.
Conforme defende Softex (2012), para a realização das atividades de teste, algumas
atividades se fazem necessárias, dentre elas mencionamos: especificação de casos
de testes, execução dos casos de testes especificados, registro de falhas, melhorias
e reporte dos resultados obtidos. Sendo assim, entende-se que a participação do
papel do responsável pelo teste desde o início do projeto, com todo o entendimento e
especificação do requisito é de suma importância para melhor elaboração do
planejamento do teste e consequentemente realização dos mesmos.
Ponto de observação:
Observa-se que a interação da equipe de testes não se faz presente em toda fase do
projeto, podendo ser considerado um ponto negativo. No contexto de métodos ágeis,
Telles (2014) defende que surgirão 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.
64
Tabela 15 - Distribuição da porcentagem das atividades que consomem maior esforço
pelos responsáveis pelos testes
Atividade que consome maior esforço pelos responsáveis pelos testes
(%)
Execução de testes automatizados. 4,35
Execução de testes manuais e automatizados. 21,74
Execução de testes manuais. 73,91
Total 100,0
Fonte: Dados da pesquisa, 2018.
No quesito onde é avaliado qual atividade consome maior esforço em todo processo
de testes pelos “responsáveis pelos testes”, identifica-se que o maior esforço 73,91%
é na execução de testes manuais.
Tabela 16 - Distribuição da porcentagem de elaboração de casos de teste
Elaboração de casos de testes (%)
Documento de texto 6,52
Excel 2,17
Winrunner 2,17
Ferramenta específica para gestão de testes 10,87
Behavior Development Driven - BDD 15,22
Utilizam ferramenta no mercado para gestão de testes 28,26
Não há este processo na organização 34,78
Total 100,0
65
Fonte: Dados da pesquisa, 2018.
Na questão que trata a forma de elaboração dos casos de teste, percebe-se que
34,78% relatam que não há um processo definido em sua empresa para tal atividade,
enquanto 28,26% dizem usar ferramenta de mercado para gestão dos testes.
Ponto de observação:
Observamos neste quesito, que mesmo a grande maioria dos respondentes 70% ao
afirmarem que suas empresas praticam métodos ágeis, 34,78% ainda não possuem
práticas de elaboração de casos de testes de qualquer maneira. Conforme cita Softex
(2012), a atividade de testes requer etapas além da execução em si do teste, como a
etapa de especificação de casos de testes. Criados, na especificação, os casos de
testes permitem criar uma rastreabilidade entre regras de negócios e o que está sendo
testado, permitindo a geração de métricas ao final de sprints ou projetos. Desta forma,
a falta dele pode ser considerada um ponto negativo.
Tabela 17 - Distribuição da porcentagem sobre a forma de execução do teste
automatizados
Forma de execução dos testes automatizados (%)
Automática no processo de integração contínua 17,39
Manual 39,13
Automática por agendamento de serviços 21,74
Não há nenhum método 21,74
Total 100,0
Fonte: Dados da pesquisa, 2018.
Quanto à forma de execução dos testes automatizados, identifica-se que, dos
respondentes que relatam que têm processos de automação de testes em suas
empresas, 39,13% executam esses testes automatizados de forma manual, ou seja,
não há rotinas ou ferramentas automáticas para chamadas à execução dos mesmos.
66
Ponto de observação:
Observa-se que grande parte das empresas ainda não utiliza ferramentas e processos
automatizados voltados para a sua execução, seja através de um pipeline integrado
aos demais processos que envolvem o desenvolvimento de software ou agendamento
de serviços rotineiros para checagem diária ou conforme frequência requerida.
Bernardo e Kon (2008) explicam que a utilização de testes automatizados executados
repetitivamente ao decorrer de entregas pode garantir cenários que feitos de maneira
manual pelo testador levaria tempo e podendo ser falhos. Fica um questionamento
sobre qual o motivo das empresas que praticam automação em testes apresenta um
considerável percentual 39,13% em execução de testes automatizados de maneira
manual, a qual pode estar sujeita a erros humanos. Essa prática pode ser considerada
um ponto negativo. Segundo os autores Meszaros e Wesley (2007), a automação
dos testes vem tornar mais simples o método de testes de software, tornando os
independentes da intervenção humana, criando scripts ou programas simples de
computador que exercitam o sistema em teste, capturam os efeitos colaterais, falhas
nocivas, inconsistências que irão determinar o sucesso ou o fracasso do
produto/serviço.
Tabela 18 - Distribuição da porcentagem da forma de controle de versão de código
Controle de versões de código (%)
Ferramenta de mercado para gestão de configuração 65,22
Manual 15,22
Ferramenta própria 10,87
Não há 8,70
Total 100,0
Fonte: Dados da pesquisa, 2018.
Quanto à questão que aborda a forma com que as empresas realizam o controle de
versão de códigos, identifica-se que a maioria delas 65,22% utilizam ferramentas de
67
mercado para gerenciar a configuração. Um ponto importante é que outra parte
15,22% realizam essa atividade de forma manual.
Ponto de observação:
Observa-se que para controle de versões, há um percentual de empresas, que
gerenciam manualmente seus artefatos produzidos no ciclo de desenvolvimento,
sendo um ponto negativo e de atenção a ser observado tornando o projeto com uma
grande falta de segurança nas informações, vulnerabilidade de perda de versões de
código, dificuldade para realização de trabalho em paralelo pela equipe e não
conformidade para garantia da qualidade dos artefatos: código fonte, ambientes,
scripts ou demais conforme ressalta o autor Filho (2009). Veja que para gerar
executáveis, foram obtidas as respostas que 15,22% entrevistados que utilizam
métodos manuais e 10,87% não utilizam nenhum método para este processo. Sendo
um total de 70,00% de empresas desenvolvedoras de software nesta pesquisa
realizada.
Tabela 19 - Distribuição da porcentagem da forma de geração dos executáveis
Geração dos executáveis (%)
Ferramenta de mercado para geração de Builds 63,48
Manual 15,22
Ferramenta de mercado para geração de builds 13,04
Não há 10,87
Total 100,0
Fonte: Dados da pesquisa, 2018.
Quanto à forma de geração dos executáveis pelas empresas, percebe-se que a
maioria delas 63,48% utilizam ferramentas de mercado para geração dos builds
(entregáveis de projeto/código). Um ponto importante é que uma parte 15,22%
realizam essa atividade de forma manual.
68
Ponto de observação:
Em relação à geração dos executáveis, existe um considerável ponto positivo nas
empresas, isto porque já que investem em ferramentas que fazem a gestão da
construção do software gerando os executáveis. Estes são preparados de forma
automática para serem disponibilizados nos ambientes de testes ou produção,
conforme processo individual de cada empresa.
Tabela 20 - Distribuição da porcentagem da forma de deploy dos executáveis
Deploy dos executáveis (%)
Utilizam ferramentas de mercado para gestão de releases 34,78
Utilizam ainda métodos manuais para gestão de releases 28,26
Ferramenta própria 17,39
Não há 10,87
Utilizam ferramentas específica para gestão de releases 8,70
Total 100,0
Fonte: Dados da pesquisa, 2018.
Percebe-se a aderência da maior parte das empresas 60,87% às técnicas de
automatização da gestão de releases, ou seja, utilizam de ferramentas para promover
os executáveis em ambientes, mas existe uma grande representatividade de
empresas 39,13% que ainda fazem sua gestão em métodos manuais ou até mesmo
não fazem essa gestão.
Ponto de observação:
Observa-se que apesar da maioria das empresas utilizarem ferramentas para gestão
de releases, isto pode não caracterizar a prática de entrega contínua de executáveis
em ambientes. 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
69
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.
Tabela 21 - Distribuição da porcentagem de métricas
Métricas (%)
São utilizadas para melhoria contínua do processo de qualidade 45,65
Não existem métricas implementadas 41,30
São geradas, porém não são utilizadas 13,04
Total 100,0
Fonte: Dados da pesquisa, 2018.
Percebe-se que há a aderência de muitas empresas 45,65% no processo de melhoria
contínua de seus processos através da utilização de métricas, que é um dos pilares
dos métodos ágeis. Entretanto, existe um percentual alto de empresas que não
possuem nenhum tipo de métrica implementada 41,30%. Segundo Chappell (2013), é
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.
Ponto de observação:
Observa-se que 13,04% das empresas geram as métricas, mas não as utilizam para
nenhum fim, fato que pode ser considerado como ponto negativo, já que podem com
estes dados mensurar pontos importantes para melhorias de seus processos e
identificar problemas que poderão estar sendo negligenciados. O uso de algum tipo
de métrica para mensurar a qualidade dos processos de testes que foram executados
é de extrema importância. Evoluir com possíveis falhas, cria nos ambientes e novos
mindsets para mudanças de comportamento:
70
Tabela 22 - Distribuição da porcentagem de atividades que geram gargalos no ciclo de
vida do Software
Atividades que geram gargalos no ciclo de vida do
Software
(%)
Preparação do ambiente para testes 56,52
Versionamento dos produtos de trabalho 15,22
Deploy de builds/ releases 8,70
Outros 6,52
Deploy de aplicação 4,35
Total 100,0
Fonte: Dados da pesquisa, 2018.
Identifica-se que a maior parte 56,52% relata que a atividade que gera mais gargalos
no ciclo de vida do Software é a preparação do ambiente para testes, seguida da
atividade de versionamento de produtos de trabalho 15,22%.
Ponto de observação:
Observa-se que, diante de vários resultados já apresentados, a grande maioria das
empresas são adeptas ao desenvolvimento de software utilizando métodos ágeis,
possuem infraestrutura disponibilizada de acordo com as necessidades de cada
projeto, ou seja, ambientes criados para testes, homologação e produção. Existe uma
infraestrutura organizada para atendimento de acordo com as respostas obtidas.
Porém, entende-se que pode haver dificuldades que geram pontos negativos pelas
empresas, que levam a questões como: por que a demora em disponibilizar estes
serviços de preparação de ambientes e de versionamento? Praticam-se interação
entre equipes e utilizam práticas ágeis e DevOps, qual o sentido de entregas tão
morosas? Segundo Sharma (2014), em DevOps a equipe é integrada, possui o
mesmo objetivo e interage o tempo todo. Defende Hutterrmann e Michael (2012) que
DevOps é interação entre desenvolvimento e operações.
71
Tabela 23 - Distribuição da porcentagem de infraestrutura de testes
Infraestrutura dos testes (%)
Ambiente segregado e preparado (teste, homologação e produção) 63,41
IAAS - Ambiente em tempo real 12,20
Ambiente segregado e preparado (teste, homologação e produção),
estação de trabalho
9,76
Estação de trabalho 7,32
IAAS - Ambiente em tempo real, estação de trabalho. 7,32
Total 100,0
Fonte: Dados da pesquisa, 2018.
Percebe-se que 63,41% relatam que os serviços oferecidos pela área de suporte e
operações na TI ainda são realizados de forma manual, sendo ambientes segregados
como: teste, homologação e produção contra somente 12,20% preparam a
infraestrutura em tempo real - IAAS. Segundo Wootton (2013), processos manuais
são propensos a erros/falhas e o caminho é a automação.
Ponto de observação:
Para assegurar a qualidade em automação dos testes, sua eficácia e eliminação no
percentual de falhas é de grande importância a disponibilização de infraestrutura em
tempo real - IAAS. Com o investimento em automatização de ambientes ainda
pequeno, quando se trata de 70% que afirmam que suas empresas praticam métodos
ágeis em desenvolvimento de software, ficam as seguintes questões: como mensurar
o serviço oferecido? A expectativa do cliente, quanto à prazo e qualidade, é atendida?
As equipes estão interagindo por um bem comum? Existem interação e cultura
DevOps? Este ponto pode ser considerado negativo.
72
Tabela 24 - Distribuição da porcentagem de retrospectiva e aprendizado
Retrospectiva e aprendizado (%)
Há feedback através de reuniões previamente agendadas 36,96
Não há uma grande interação entre as equipes para prover reuniões 21,74
Há feedback imediato 13,04
Feedback através de reuniões 8,70
Feedback não é uma prioridade 8,70
Feedback imediato 6,52
Não há uma grande integração entre as equipes para prover reuniões. 4,35
Total 100,0
Fonte: Dados da pesquisa, 2018.
Percebe-se que para a maioria 36,96%, em suas empresas há processo de
retrospectiva para discutir as lições aprendidas e feedbacks sobre os projetos e
processos realizados. Segundo Chappell (2013), logo após cada entrega, as equipes
devem estimular as retrospectivas, trabalhar as lições aprendidas para que nas
próximas iterações erros e desafios possam ser minimizados e tratados de maneira
mais eficiente. Observa-se também que existem percentuais altos 21,74% que relatam
que não há uma grande interação entre as equipes para prover reuniões de feedback
e uma porcentagem 8,70% não considera o feedback uma prioridade. Segundo
(ROCHA et al., 1994), este processo deve ser construído e ser constante e
trabalhando entre todos envolvidos do processo.
73
Tabela 25 - Distribuição da porcentagem de maturidade em testes
Maturidade em Testes (%)
Nível 1 2,17
Nível 2 13,04
Nível 3 50,00
Nível 4 26,09
Nível 5 4,35
Nível 6 4,35
Total 100,0
Fonte: Dados da pesquisa, 2018.
Ao relatarem o nível de maturidade em testes em uma escala de 1 (muito imaturo) a
6 (muito maturo), os entrevistados identificam em sua maioria 50% que suas empresas
possuem o nível é 3, seguido do nível 4 - 26,09%.
Ponto de observação:
Foi identificado que os resultados da pesquisa refletem um certo impacto nos
resultados do nível de maturidade em testes, sobretudo aplicar métodos ágeis, em
desenvolvimento de software envolve interação de equipes, envolve automatização
de processos que automaticamente irá elevar a maturidade de todo ciclo produtivo e
dos projetos das organizações. Segundo 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.
74
Tabela 26 - Distribuição da porcentagem de qualidade em software
Qualidade em Software (%)
Nível 1 4,35
Nível 2 2,17
Nível 3 21,74
Nível 4 54,35
Nível 5 10,87
Nível 6 6,52
Total 100,0
Fonte: Dados da pesquisa, 2018.
Percebe-se que, os entrevistados relataram que o nível de qualidade de software, em
uma escala de 1 (muito imaturo) a 6 (muito maduro), em sua maioria 54,35% que suas
empresas possuem o nível é 4, seguido do nível 3 21,74%.
Ponto de observação:
Observa-se que ainda não há uma aderência na excelência de qualidade na entrega
do software pelas empresas. Mas cabe um ponto de reflexão: qual seria então o
dificultador para alcançar a eficiência da qualidade neste processo? Segundo
Pressman (2010), a qualidade é conformidade e o nível com que um produto atende
às suas especificações. Conforme defende o autor Chappell (2013), promover
qualidade, deve-se ampliar a visão e fornecer igual ênfase na qualidade funcional,
qualidade estrutural e qualidade do processo. Deve-se incluir as necessidades que
são as mais do ciclo de um projeto: As três partes interessadas: Os usuários, as
equipes de desenvolvimento e Patrocinadores dos produtos. Para avaliar a qualidade,
é preciso existir formas de medi-la. Ou seja, é preciso obter uma medida que possa
calcular o grau de alcance de uma característica de qualidade.
Para se alcançar a maturidade em seus processos entende-se que se faz necessária
a prática da agilidade.
75
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
Mediante respostas levantadas e análises feitas, foi possível disponibilizar práticas
recomendadas para alguns pontos observados na pesquisa. O Quadro 1 apresenta
essas informações:
Quadro 1 - Guia de boas práticas
Ponto observado na
pesquisa
Práticas recomendadas
Insumo para
planejamento dos
testes
Interação entre equipes de desenvolvimento e usuário
de negócio, conjugados à documentação de requisitos
facilitam o mapeamento dos testes a serem
realizados, garantindo a qualidade da entrega de
forma abrangente e correta.
Insumo para
entendimento do
projeto
Em um projeto ágil, os desenvolvedores e testadores
devem compreender os requisitos do projeto para
conseguirem 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. Para esse
entendimento antecipado, sugere-se o estudo da
documentação de requisito.
Envolvimento do
responsável pelos
testes em todas as
fases do projeto
No contexto DevOps, com participação integrada dos
times, entende-se que a participação do papel do
responsável pelo teste desde o início do projeto, com
todo o entendimento e especificação do requisito é de
suma importância para melhor elaboração do
76
planejamento do teste e consequentemente realização
dos mesmos.
Investimento em
elaboração de
testes
automatizados
desde a criação do
software
No contexto de automação de testes, uma prática
recomendada é que sejam criados testes
automatizados confiáveis capazes de sustentar
diretrizes do conceito de qualidade do software que
está sendo validado. Propõem-se a elaboração de
testes automatizados principalmente nos níveis
unitário e serviços. Uma vez que a facilidade de
encontrar erros precocemente nestas etapas torna-os
valiosos comparado ao nível de interface.
Uso de
especificação de
testes em apoio à
entrega da
qualidade
Realizar a criação e uso de casos de teste
documentados mesmo que de maneira simplificada,
permitindo assim criar uma rastreabilidade entre
regras de negócios e o que está sendo testado.
Pouco investimento
em execução
automatizada dos
projetos de testes
automatizados
O mercado oferece uma gama de ferramentas
gratuitas ou pagas que permitem que os responsáveis
pela manutenção dos testes automatizados possam
criar processos automáticos de execução periódicas
para seus projetos com rastreabilidade e status dos
testes. Crie um processo simples e que traga feedback
imediato em caso de sucessos e falhas na execução.
Geração de
executáveis dos
projetos de maneira
automatizada
Visto uma boa aderência das empresas em utilizar
ferramentas e processos que facilitem a
disponibilização do código construído (build), gerir
uma esteira (pipeline) de passos que incluem também
a execução automatizada sequencial de testes
77
automatizados em diferentes níveis, torna ainda mais
confiável e rápida a coleta de feedback de status.
Aprendizado ao
decorrer das
entregas
Na cultura DevOps, o mindset da equipe tem que estar
voltado para uma boa comunicação entre partes
distintas do projeto, dessa maneira viabiliza a entrega
do produto satisfazendo as necessidades do cliente.
Sugere-se que sejam feitas reuniões de aprendizado
para discutir pontos em que a equipe pode evoluir até
a próxima entrega, envolvendo testadores,
desenvolvedores e equipe do projeto.
Extração de
métricas de testes
para melhoria
contínua
Uma das formas de revisar e melhorar o processo de
trabalho principalmente no que se trata de testes, é o
uso de métricas. Recomenda-se criar processos de
trabalho que permitam a extração de métricas: esforço
de atividades produtivas, retrabalho, impedimentos
durante os testes, rastreabilidade de casos de testes
mais executados e demais insumos que se avaliados
ao decorrer do tempo permitam identificar
possibilidades de melhorias e pontos chaves dos
sistemas para automatizar testes, assim gerando valor
para o cliente.
Fonte: Dados da pesquisa, 2018.
78
6 CONCLUSÃO
A preocupação com qualidade dos entregáveis nas empresas de tecnologia vem
sendo um procedimento rotineiro a fim de garantir uma competitividade comercial e
alvo de investimentos. Observou-se uma grande aderência pelas empresas
entrevistadas em adotar metodologias ágeis em seus processos de desenvolvimento
de software, mas ainda há um grande caminho a ser percorrido em relação as práticas
de automação dos processos, já que conforme demonstrado nas respostas, há pouco
investimento em automação de testes, procedimentos adotados de análise,
mapeamento dos requisitos, preparação e execução dos testes de maneira
automatizada, para assim permitir uma boa rastreabilidade e garantia da qualidade do
software entregue, tornando possível identificar pontos vulneráveis conforme
demostrado no artigo, que fragilizam o processo evolutivo e as entregas de um produto
com qualidade.
Conclui-se que, para garantir excelência na entrega do produto, as empresas
precisam buscar uma transformação cultural, maturidade e aprimorar seus
procedimentos internos para satisfazer as expectativas de seu cliente. Algumas
mudanças culturais são essenciais para promover a melhoria contínua dos processos.
Isso condiz fortemente com as práticas DevOps. Portanto, identificou-se que é
essencial a busca por novos investimentos, tecnologia, capacitação, práticas e
métodos ágeis para realização dos testes para garantia e entrega do produto e,
principalmente, com foco na automatização de processos, como a automação de
testes que faz parte da essência desse trabalho.
Avaliou-se a criação de um guia de boas práticas com sugestões norteadoras para
garantir a automação de testes, qualidade e entrega final do produto. Este foi o
principal desafio deste trabalho.
Identificou-se como trabalhos futuros, alguns tópicos avançados podem ser
explorados, como por exemplo, quais ferramentas de mercado são mais utilizadas na
automação de processos de teste com objetivo de alcançar melhores níveis de
79
maturidade das entregas. Este trabalho pode servir de fonte para outros estudos
dentro do contexto de teste de software, agilidade, automação e práticas DevOps.
80
REFERÊNCIAS
ABRAHAMSSON, P. et al. Agile Software Development Methods. VTT technical Research Centre of Finland, 2002. Disponível em: <https://www.vtt.fi/inf/pdf/publications/2002/P478.pdf>. Acesso em: 1 abr. 2018.
AMBLER, S. Agile modeling: Best practices for the unified process and extreme programming. New York: John Wiley & Sons, 2002.
BERNARDO, P. C; KON, F. A Importância dos Testes Automatizados. Engenharia de Software Magazine. Disponível em: https://www.ime.usp.br/~kon/papers/EngSoftMagazine-IntroducaoTestes.pdf. Acesso em: 10 abr. 2018.
BERNARDO, P. C. Padrões de testes automatizados. 2011. 221 p. Dissertação (Mestrado em Ciência da Computação) - Instituto de Matemática e Estatística, Universidade de São Paulo, São Paulo, 2011.
BRAGA, F. A. M. Um panorama sobre o uso de práticas DevOps nas indústrias de software. 2015. 123 f. Dissertação (Mestrado em Ciência da Computação). Universidade Federal de Pernambuco, Pernambuco, 2015.
CHAPPELL, David. The three aspects of software Quality: functional, structural, and process. 2013. Disponível em: <http://www.davidchappell.com/writing/white_papers/The_Three_Aspects_of_Software_Quality_v1.0-Chappell.pdf>. Acesso em: 1 abr. 2018. COHEN, D.; LINDVALL, M.; COSTA, P. An introduction to agile methods. In Advances in Computers. [S.l.: s.n.], 2004.
FILHO, W. P. P. Engenharia de Software: fundamentos, métodos e padrões, 3.ed. - LTC. 2009. 370 p.
FOWLER, M. Deployment Pipeline. 30 maio 2013. Disponível em: <https://martinfowler.com/bliki/DeploymentPipeline.html>. Acesso em 10 abr. 2018.
FOWLER, M. Test Pyramid. 1 maio 2012. Disponível em: <https://martinfowler.com/bliki/TestPyramid.html>. Acesso em 10 abr. 2018.
GIL, A. C. Como Elaborar Projetos de Pesquisa. 5ª ed. São Paulo: Atlas, 2010. HUMBLE J.; FARLEY D. Continuous Delivery: Reliable Software Release Through Build, Test and Deployment Automation. 1. ed. Addison-Wesley Professional, 2010. 512 p.
HUTTERRMANN, M. DevOps for Developers. Disponível em: <http://huettermann.net/> Acesso em 10 abr. 2018.
81
KLEIN, A. Z. et. al. Metodologia de pesquisa em administração: Uma abordagem prática. Atlas, São Paulo, 2015.
KOCIANSKI, A.; SOARES, M. D. S. Qualidade de Software. 2a. ed. São Paulo: Novatec, v. I, 2007. KOSKELA, L. Test Driven: Pratical TDD and Acceptance TDD for Java Developers. [S.l.]: Manning Publications, 2007. Citado na página 29. MENDONÇA, J. M; SILVA, R. M. S. Técnicas de usabilidade e testes automatizados em processos de desenvolvimento de software empírico. 2014. 113f. Monografia (Bacharelado em Engenharia de Software). Universidade de Brasília, Brasília, 2014. MESZAROS, G.; WESLEY, A. XUnit Test Patterns: Refactoring Test Code. [S.l.: s.n.], 2007. NEGRELLO, Ana. Métodos Ágeis e Qualidade: Como Conciliar? 2013. Disponível em: <https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/m_c3_a9todos__c3_a1geis_e_qualidade_como_conciliar2?lang=en>. Acesso em: 11 mai. 2018. NERUR, S.; MAHAPATRA, R.; MANGALARAJ, G. Challenges of migrating to agile methodologies. [S.l.: s.n.], 2005.
NORTH, D. (2003). Introducing BDD. Disponível em: <http://dannorth.net/introducing-bdd/> acessado em 10.04.2018.
OLIVEIRA, B. H. Qualidade de software no desenvolvimento com métodos ágeis. 2014. 105 f. Dissertação (Mestrado em Ciências - Ciências de Computação e Matemática Computacional). Instituto de Ciências Matemáticas e de Computação - ICMC-USP, São Paulo, 2014.
POTEL, M.; COTTER, S. Incide Saliente Technology. [Sol.]: Saliente Press, 1995. 476 p.
PRESSMAN, R. S. Engenharia de Software. 5. ed. Rio de Janeiro: McGraw-Hill, 2002.
PRESSMAN, R. S. Engenharia de Software – 6 ed. São Paulo: McGrawHill, 2006.
REZENDE, D. A. Planejamento de informações públicas municipais: sistemas de informação e de conhecimento, informática e governo eletrônico integrados aos planejamentos das prefeituras e municípios. Revista de Administração Pública, Rio de Janeiro, v.41, n.3, maio/junho 2007.
82
ROCHA, A. R. et al. Uma experiência na definição do processo de desenvolvimento e avaliação de software segundo as Normas ISO. Curitiba: 1994. 93 p.
SATO, D. DevOps na Prática: entrega de software confiável e automatizada. 1. ed. Casa do Código, 2013
SHARMA, S. DevOps For Dummies®, IBM Limited Edition. John Wiley & Sons, Inc, 2014. 51 p.
SOARES, I. Desenvolvimento orientado por comportamento (BDD). Um novo olhar sobre TDD. Junho 2011. Disponível em: <http://www.devmedia.com.br/desenvolvimento-orientado-porcomportamento-bdd-artigo-java-magazine-91/21127 > Acesso em: 24 abr. 2018.
SOFTEX (2012). Guia Geral MPS.BR de Software. Disponível em: <http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_Software_2012.pdf>. Acesso em: 10 de maio de 2018.
SOMMERVILLE, I. Software Engineering. 9th ed. Pearson Addison Wesley, 2011.
STALLMAN, R. M. Free Software: Freedom and Cooperation. 2001. Disponível em: <http://www.gnu.org/events/rms-nyu-2001-transcript.txt> Acesso em: 10 abr. 2018. TELLES, F. DevOps leva agilidade, cooperação e eficiência para os departamentos de TI. 2014. Disponível em: <https://www.tecmundo.com.br/tecnologia-da-informacao/115857-devops-leva-agilidade-cooperacao-eficiencia-departamentos-ti.htm> Acessado em: 11 abr. 2018. VELOSO, L. M. Testes automatizados asseguram a qualidade dos softwares. 2014. Disponível em: <http://www.administradores.com.br/artigos/tecnologia/testes-automatizados-asseguram-a-qualidade-dos-softwares/80350/> Acessado em 10 abr. 2018.
WOOTTON B. Preparing for Continuous Delivery. 2013. Disponível em: < https://dzone.com/refcardz/preparing-continuous-delivery?chapter=1>. Acessado em 17 abr. 2018.
WYNNE, M.; HELLESOY, A. The Cucumber Book: Behaviour-Driven, Development for Testers and Developers. The Pragmatic Bookshelf. 1. ed. 2012. 336 p.
83
APÊNDICE A – Instrumento de pesquisa
84
Orientações gerais
85
86
87
88
89
90
91
92
Autorização de Divulgação de Trabalho Técnico
AUTORIZAÇÃO DE PUBLICAÇÃO
AUTORIZO A PUBLICAÇÃO DO TRABALHO TÉCNICO NA INTERNET, JORNAIS E
REVISTAS TÉCNICAS EDITADAS PELO IETEC.
NÃO AUTORIZO A PUBLICAÇÃO OU DIVULGAÇÃO DO TRABALHO TÉCNICO.
Belo Horizonte, _ __/____/_2018_
CURSO: Métodos Ágeis e Práticas DevOps
SEMESTRE/ANO: 2º/2018 TURMA: 01
TÍTULO DO TRABALHO:
NOME DADOS DA PESQUISA (LEGÍVEL)
ASSINATURA