a importÂncia da automaÇÃo de testes em devops...5.3 identificar principais vulnerabilidades no...

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.

https://saymowan.typeform.com/to/zGQyMW

36

Gráfico 2- Ramo da empresa


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


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


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


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


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)


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)


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


por equipe de QA interna, teste executado por equipe de QA externa

(outsourcing).

2,17


equipe de QA externa (outsourcing).

4,35


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


usuário de negócio.

6,52

Teste executado por equipe de QA externa (outsourcing). 6,52


por equipe de QA interna, teste executado por usuário de negócio.

6,52


por equipe de QA interna.

6,52

Teste executado por equipe de QA interna. 19,57

Total 100,0


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


desenvolvimento e Homologação.

15,22

Total 100,0

63


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

(%)


desenvolvimento e Homologação.

15,22

Homologação. 15,22


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.


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


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


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.


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


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


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


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.


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


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


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


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.


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


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.


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


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%.


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


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.


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


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


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%.


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


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%.


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.


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

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

a importÂncia da automaÇÃo de testes em devops...5.3 identificar principais vulnerabilidades no...

Documents