5 DISCUSSÃO DOS RESULTADOS
5.3 Identificar principais vulnerabilidades no processo de testes de software
Neste tópico, serão apresentados os resultados e a análise que representam o objetivo específico de identificar principais vulnerabilidades no processo de testes de software nas empresas dos respondentes, no que diz respeito à preparação do ambiente, realização e automação dos testes. Os resultados referem-se à disponibilidade de recursos de infraestrutura para execução dos testes, interação junto às equipes e ferramentas de gestão de aplicações utilizadas.
Diante da apresentação de resultados obtidos pela pesquisa junto aos respondentes e de acordo com os autores Meszaros e Wesley (2007) onde ambos defendem que testes automatizados são práticos de tornar os testes de software independentes da intervenção humana, criando scripts ou programas simples de computador que exercitam o sistema em teste, capturam os efeitos colaterais e fazem verificações, tudo automaticamente e dinamicamente, pode-se chegar a algumas reflexões importantes:
Observa-se pontos positivos, negativos e de melhorias no processo que envolve desde a concepção até a disponibilização do entregável no ambiente de produção, pelas empresas.
• Se há um percentual de respostas de empresas que já praticam métodos ágeis em seus processos: 70%.
• Se a grande maioria das empresas são desenvolvedoras de softwares: 52,17%. • Se a grande maioria das empresas possui orçamento destinado especificamente à área de TI 78,26%, o que falta para se obter a qualidade, tecnologia e melhores práticas em automação dos testes em DevOps?
Diante destes dados percebe-se a aderência às metodologias ágeis e práticas DevOps pelas empresas. Observa-se, entretanto, algumas vulnerabilidades e deficiências. Porque então existem as vulnerabilidades destacadas?
● Observa-se que ainda há falta de interação, comunicação e cultura DevOps onde equipes de desenvolvimento e operação estejam sincronizados para atender a um mesmo objetivo, ou seja atender ao mesmo projeto, conforme defende o autor Sharma (2014), onde assim falhas serão imperceptíveis, já que
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.
Tabela 11 - Distribuição da porcentagem dos responsáveis pelas atividades de testes que envolvem desenvolvedores
Responsáveis pelas atividades de testes que envolvem os desenvolvedores
(%)
Desenvolvedores, analista de sistemas/analistas de negócio. 2,17
Desenvolvedores, testadores e analista de negócio. 2,17
Desenvolvedores e analistas de negócio. 2,17
Desenvolvedores, testadores, analistas de sistemas/analistas de negócio.
6,52
Desenvolvedores e testadores. 6,52
Desenvolvedores, analistas de sistemas/negócio. 6,52
Desenvolvedores. 6,52
Total 32,59
Fonte: Dados da pesquisa, 2018.
Tabela 12 - Distribuição da porcentagem do grau de independência dos testes que envolvem uma equipe de QA
Grau de independência dos testes que envolvem uma equipe de QA
(%)
Teste executado por outro desenvolvedor, teste executado por equipe de QA interna.
2,17
Teste executado por equipe de QA interna, teste executado por usuário de negócio e PM também faz teste.
2,17
Teste executado pelo desenvolvedor autor do código, teste executado por equipe de QA externa, (outsourcing), teste executado por usuário
de negócio.
Teste executado pelo desenvolvedor autor do código, teste executado por equipe de QA interna, teste executado por equipe de QA externa
(outsourcing).
2,17
Teste executado por equipe de QA interna, teste executado por equipe de QA externa (outsourcing).
4,35
Teste executado pelo desenvolvedor autor do código, teste executado por outro desenvolvedor, teste executado por equipe de QA interna
4,35
Teste executado pelo desenvolvedor ator do código, teste executado por equipe de QA externa (outsourcing).
4,35
Teste executado por equipe de QA interna, teste executado por usuário de negócio.
6,52
Teste executado por equipe de QA externa (outsourcing). 6,52
Teste executado pelo desenvolvedor autor do código, teste executado por equipe de QA interna, teste executado por usuário de negócio.
6,52
Teste executado pelo desenvolvedor autor do código, teste executado por equipe de QA interna.
6,52
Teste executado por equipe de QA interna. 19,57
Total 100,0
Tabela 13 - Distribuição da porcentagem da fase do ciclo de vida do software em que os responsáveis são envolvidos
Fase do ciclo de vida do software em que os responsáveis são envolvidos
(%)
Homologação, nenhuma das opções. 2,17
Especificação de requisitos, término do desenvolvimento, homologação.
2,17
Desenvolvimento de código, homologação. 2,17
Desenvolvimento de código. 2,17
Nenhuma das opções. 4,35
Especificação de requisitos, desenvolvimento do código, término do desenvolvimento.
4,35
Especificação de requisitos, desenvolvimento do código, homologação.
4,35
Especificação de requisitos, homologação. 6,52
Especificação de requisitos, desenvolvimento do código. 6,52
Especificação de requisitos. 6,52
Término do desenvolvimento, Homologação. 8,70
Desenvolvimento do código, término do desenvolvimento, Homologação.
10,87
Homologação. 15,22
Especificação de requisitos, desenvolvimento do código, término do desenvolvimento e Homologação.
15,22
Fonte: Dados da pesquisa, 2018.
Através dos dados demonstrados acima, percebe-se que há empate 15,22% junto aos entrevistados quando se questiona em qual parte do processo os “responsáveis pelos testes” são envolvidos. Este empate é caracterizado por fases de extrema importância da participação deste papel do responsável pelo teste, e é onde se identifica a maior participação deles. As fases em destaque são:
Tabela 14 - Distribuição da porcentagem da parte do processo em que os responsáveis pelos testes são envolvidos
Em qual parte do processo os responsáveis pelos testes são envolvidos
(%)
Especificação de requisitos, desenvolvimento do código, término do desenvolvimento e Homologação.
15,22
Homologação. 15,22
Fonte: Dados da pesquisa, 2018.
Conforme defende Softex (2012), para a realização das atividades de teste, algumas atividades se fazem necessárias, dentre elas mencionamos: especificação de casos de testes, execução dos casos de testes especificados, registro de falhas, melhorias e reporte dos resultados obtidos. Sendo assim, entende-se que a participação do papel do responsável pelo teste desde o início do projeto, com todo o entendimento e especificação do requisito é de suma importância para melhor elaboração do planejamento do teste e consequentemente realização dos mesmos.
Ponto de observação:
Observa-se que a interação da equipe de testes não se faz presente em toda fase do projeto, podendo ser considerado um ponto negativo. No contexto de métodos ágeis, Telles (2014) defende que surgirão novos conceitos e técnicas a fim de agilizar a comunicação entre setores empresariais e estes eventos disseminaram uma cultura baseada na união e cooperação entre diferentes equipes de uma mesma empresa.
Tabela 15 - Distribuição da porcentagem das atividades que consomem maior esforço pelos responsáveis pelos testes
Atividade que consome maior esforço pelos responsáveis pelos testes
(%)
Execução de testes automatizados. 4,35
Execução de testes manuais e automatizados. 21,74
Execução de testes manuais. 73,91
Total 100,0
Fonte: Dados da pesquisa, 2018.
No quesito onde é avaliado qual atividade consome maior esforço em todo processo de testes pelos “responsáveis pelos testes”, identifica-se que o maior esforço 73,91% é na execução de testes manuais.
Tabela 16 - Distribuição da porcentagem de elaboração de casos de teste Elaboração de casos de testes (%)
Documento de texto 6,52
Excel 2,17
Winrunner 2,17
Ferramenta específica para gestão de testes 10,87
Behavior Development Driven - BDD 15,22
Utilizam ferramenta no mercado para gestão de testes 28,26
Não há este processo na organização 34,78
Fonte: Dados da pesquisa, 2018.
Na questão que trata a forma de elaboração dos casos de teste, percebe-se que 34,78% relatam que não há um processo definido em sua empresa para tal atividade, enquanto 28,26% dizem usar ferramenta de mercado para gestão dos testes.
Ponto de observação:
Observamos neste quesito, que mesmo a grande maioria dos respondentes 70% ao afirmarem que suas empresas praticam métodos ágeis, 34,78% ainda não possuem práticas de elaboração de casos de testes de qualquer maneira. Conforme cita Softex (2012), a atividade de testes requer etapas além da execução em si do teste, como a etapa de especificação de casos de testes. Criados, na especificação, os casos de testes permitem criar uma rastreabilidade entre regras de negócios e o que está sendo testado, permitindo a geração de métricas ao final de sprints ou projetos. Desta forma, a falta dele pode ser considerada um ponto negativo.
Tabela 17 - Distribuição da porcentagem sobre a forma de execução do teste automatizados
Forma de execução dos testes automatizados (%)
Automática no processo de integração contínua 17,39
Manual 39,13
Automática por agendamento de serviços 21,74
Não há nenhum método 21,74
Total 100,0
Fonte: Dados da pesquisa, 2018.
Quanto à forma de execução dos testes automatizados, identifica-se que, dos respondentes que relatam que têm processos de automação de testes em suas empresas, 39,13% executam esses testes automatizados de forma manual, ou seja, não há rotinas ou ferramentas automáticas para chamadas à execução dos mesmos.
Ponto de observação:
Observa-se que grande parte das empresas ainda não utiliza ferramentas e processos automatizados voltados para a sua execução, seja através de um pipeline integrado aos demais processos que envolvem o desenvolvimento de software ou agendamento de serviços rotineiros para checagem diária ou conforme frequência requerida. Bernardo e Kon (2008) explicam que a utilização de testes automatizados executados repetitivamente ao decorrer de entregas pode garantir cenários que feitos de maneira manual pelo testador levaria tempo e podendo ser falhos. Fica um questionamento sobre qual o motivo das empresas que praticam automação em testes apresenta um considerável percentual 39,13% em execução de testes automatizados de maneira manual, a qual pode estar sujeita a erros humanos. Essa prática pode ser considerada um ponto negativo. Segundo os autores Meszaros e Wesley (2007), a automação dos testes vem tornar mais simples o método de testes de software, tornando os independentes da intervenção humana, criando scripts ou programas simples de computador que exercitam o sistema em teste, capturam os efeitos colaterais, falhas nocivas, inconsistências que irão determinar o sucesso ou o fracasso do produto/serviço.
Tabela 18 - Distribuição da porcentagem da forma de controle de versão de código Controle de versões de código (%)
Ferramenta de mercado para gestão de configuração 65,22
Manual 15,22
Ferramenta própria 10,87
Não há 8,70
Total 100,0
Fonte: Dados da pesquisa, 2018.
Quanto à questão que aborda a forma com que as empresas realizam o controle de versão de códigos, identifica-se que a maioria delas 65,22% utilizam ferramentas de
mercado para gerenciar a configuração. Um ponto importante é que outra parte 15,22% realizam essa atividade de forma manual.
Ponto de observação:
Observa-se que para controle de versões, há um percentual de empresas, que gerenciam manualmente seus artefatos produzidos no ciclo de desenvolvimento, sendo um ponto negativo e de atenção a ser observado tornando o projeto com uma grande falta de segurança nas informações, vulnerabilidade de perda de versões de código, dificuldade para realização de trabalho em paralelo pela equipe e não conformidade para garantia da qualidade dos artefatos: código fonte, ambientes, scripts ou demais conforme ressalta o autor Filho (2009). Veja que para gerar executáveis, foram obtidas as respostas que 15,22% entrevistados que utilizam métodos manuais e 10,87% não utilizam nenhum método para este processo. Sendo um total de 70,00% de empresas desenvolvedoras de software nesta pesquisa realizada.
Tabela 19 - Distribuição da porcentagem da forma de geração dos executáveis
Geração dos executáveis (%)
Ferramenta de mercado para geração de Builds 63,48
Manual 15,22
Ferramenta de mercado para geração de builds 13,04
Não há 10,87
Total 100,0
Fonte: Dados da pesquisa, 2018.
Quanto à forma de geração dos executáveis pelas empresas, percebe-se que a maioria delas 63,48% utilizam ferramentas de mercado para geração dos builds (entregáveis de projeto/código). Um ponto importante é que uma parte 15,22% realizam essa atividade de forma manual.
Ponto de observação:
Em relação à geração dos executáveis, existe um considerável ponto positivo nas empresas, isto porque já que investem em ferramentas que fazem a gestão da construção do software gerando os executáveis. Estes são preparados de forma automática para serem disponibilizados nos ambientes de testes ou produção, conforme processo individual de cada empresa.
Tabela 20 - Distribuição da porcentagem da forma de deploy dos executáveis
Deploy dos executáveis (%)
Utilizam ferramentas de mercado para gestão de releases 34,78
Utilizam ainda métodos manuais para gestão de releases 28,26
Ferramenta própria 17,39
Não há 10,87
Utilizam ferramentas específica para gestão de releases 8,70
Total 100,0
Fonte: Dados da pesquisa, 2018.
Percebe-se a aderência da maior parte das empresas 60,87% às técnicas de automatização da gestão de releases, ou seja, utilizam de ferramentas para promover os executáveis em ambientes, mas existe uma grande representatividade de empresas 39,13% que ainda fazem sua gestão em métodos manuais ou até mesmo não fazem essa gestão.
Ponto de observação:
Observa-se que apesar da maioria das empresas utilizarem ferramentas para gestão de releases, isto pode não caracterizar a prática de entrega contínua de executáveis em ambientes. Para Fowler (2013), uma boa maneira de iniciar uma mudança DevOps através de um processo completo de entrega contínua será modelar seu processo de
entrega atual em um processo de pipeline de implantação e após verificar as possibilidades de melhorias, pontos que podem ser automatizados e formas de feedback que favoreçam a comunicação entre as equipes do projeto.
Tabela 21 - Distribuição da porcentagem de métricas
Métricas (%)
São utilizadas para melhoria contínua do processo de qualidade 45,65 Não existem métricas implementadas 41,30 São geradas, porém não são utilizadas 13,04
Total 100,0
Fonte: Dados da pesquisa, 2018.
Percebe-se que há a aderência de muitas empresas 45,65% no processo de melhoria contínua de seus processos através da utilização de métricas, que é um dos pilares dos métodos ágeis. Entretanto, existe um percentual alto de empresas que não possuem nenhum tipo de métrica implementada 41,30%. Segundo Chappell (2013), é preciso obter uma medida que possa calcular o grau de alcance de uma característica de qualidade. Deste modo, para computar uma característica de qualidade, é necessário estabelecer uma métrica capaz de calcular e fazer uma medição para determinar a medida, resultado da aplicação da métrica escolhida.
Ponto de observação:
Observa-se que 13,04% das empresas geram as métricas, mas não as utilizam para nenhum fim, fato que pode ser considerado como ponto negativo, já que podem com estes dados mensurar pontos importantes para melhorias de seus processos e identificar problemas que poderão estar sendo negligenciados. O uso de algum tipo de métrica para mensurar a qualidade dos processos de testes que foram executados é de extrema importância. Evoluir com possíveis falhas, cria nos ambientes e novos mindsets para mudanças de comportamento:
Tabela 22 - Distribuição da porcentagem de atividades que geram gargalos no ciclo de vida do Software
Atividades que geram gargalos no ciclo de vida do Software
(%)
Preparação do ambiente para testes 56,52
Versionamento dos produtos de trabalho 15,22
Deploy de builds/ releases 8,70
Outros 6,52
Deploy de aplicação 4,35
Total 100,0
Fonte: Dados da pesquisa, 2018.
Identifica-se que a maior parte 56,52% relata que a atividade que gera mais gargalos no ciclo de vida do Software é a preparação do ambiente para testes, seguida da atividade de versionamento de produtos de trabalho 15,22%.
Ponto de observação:
Observa-se que, diante de vários resultados já apresentados, a grande maioria das empresas são adeptas ao desenvolvimento de software utilizando métodos ágeis, possuem infraestrutura disponibilizada de acordo com as necessidades de cada projeto, ou seja, ambientes criados para testes, homologação e produção. Existe uma infraestrutura organizada para atendimento de acordo com as respostas obtidas. Porém, entende-se que pode haver dificuldades que geram pontos negativos pelas empresas, que levam a questões como: por que a demora em disponibilizar estes serviços de preparação de ambientes e de versionamento? Praticam-se interação entre equipes e utilizam práticas ágeis e DevOps, qual o sentido de entregas tão morosas? Segundo Sharma (2014), em DevOps a equipe é integrada, possui o mesmo objetivo e interage o tempo todo. Defende Hutterrmann e Michael (2012) que DevOps é interação entre desenvolvimento e operações.
Tabela 23 - Distribuição da porcentagem de infraestrutura de testes
Infraestrutura dos testes (%)
Ambiente segregado e preparado (teste, homologação e produção) 63,41
IAAS - Ambiente em tempo real 12,20
Ambiente segregado e preparado (teste, homologação e produção), estação de trabalho
9,76
Estação de trabalho 7,32
IAAS - Ambiente em tempo real, estação de trabalho. 7,32
Total 100,0
Fonte: Dados da pesquisa, 2018.
Percebe-se que 63,41% relatam que os serviços oferecidos pela área de suporte e operações na TI ainda são realizados de forma manual, sendo ambientes segregados como: teste, homologação e produção contra somente 12,20% preparam a infraestrutura em tempo real - IAAS. Segundo Wootton (2013), processos manuais são propensos a erros/falhas e o caminho é a automação.
Ponto de observação:
Para assegurar a qualidade em automação dos testes, sua eficácia e eliminação no percentual de falhas é de grande importância a disponibilização de infraestrutura em tempo real - IAAS. Com o investimento em automatização de ambientes ainda pequeno, quando se trata de 70% que afirmam que suas empresas praticam métodos ágeis em desenvolvimento de software, ficam as seguintes questões: como mensurar o serviço oferecido? A expectativa do cliente, quanto à prazo e qualidade, é atendida? As equipes estão interagindo por um bem comum? Existem interação e cultura DevOps? Este ponto pode ser considerado negativo.
Tabela 24 - Distribuição da porcentagem de retrospectiva e aprendizado
Retrospectiva e aprendizado (%)
Há feedback através de reuniões previamente agendadas 36,96 Não há uma grande interação entre as equipes para prover reuniões 21,74
Há feedback imediato 13,04
Feedback através de reuniões 8,70
Feedback não é uma prioridade 8,70
Feedback imediato 6,52
Não há uma grande integração entre as equipes para prover reuniões. 4,35
Total 100,0
Fonte: Dados da pesquisa, 2018.
Percebe-se que para a maioria 36,96%, em suas empresas há processo de retrospectiva para discutir as lições aprendidas e feedbacks sobre os projetos e processos realizados. Segundo Chappell (2013), logo após cada entrega, as equipes devem estimular as retrospectivas, trabalhar as lições aprendidas para que nas próximas iterações erros e desafios possam ser minimizados e tratados de maneira mais eficiente. Observa-se também que existem percentuais altos 21,74% que relatam que não há uma grande interação entre as equipes para prover reuniões de feedback e uma porcentagem 8,70% não considera o feedback uma prioridade. Segundo (ROCHA et al., 1994), este processo deve ser construído e ser constante e trabalhando entre todos envolvidos do processo.
Tabela 25 - Distribuição da porcentagem de maturidade em testes Maturidade em Testes (%) Nível 1 2,17 Nível 2 13,04 Nível 3 50,00 Nível 4 26,09 Nível 5 4,35 Nível 6 4,35 Total 100,0
Fonte: Dados da pesquisa, 2018.
Ao relatarem o nível de maturidade em testes em uma escala de 1 (muito imaturo) a 6 (muito maturo), os entrevistados identificam em sua maioria 50% que suas empresas possuem o nível é 3, seguido do nível 4 - 26,09%.
Ponto de observação:
Foi identificado que os resultados da pesquisa refletem um certo impacto nos resultados do nível de maturidade em testes, sobretudo aplicar métodos ágeis, em desenvolvimento de software envolve interação de equipes, envolve automatização de processos que automaticamente irá elevar a maturidade de todo ciclo produtivo e dos projetos das organizações. Segundo Pressman (2006), agilidade é mais do que uma resposta efetiva a modificação, encoraja estruturas e atitudes da equipe que tornam a comunicação mais fácil, enfatiza a rápida entrega de software operacional e dá menos importância para produtos de trabalhos intermediários; adota os clientes como parte da equipe de desenvolvimento; reconhece que o planejamento em mundo