Image for post
Image for post
Rui Lopes Rodrigues | Test Specialist Leader | everis Brasil

Inteligência na evolução da qualidade de software

Já venho há algum tempo trabalhando com desenvolvimento de software. Nos últimos dez anos, estive fortemente focado em processos, testes e qualidade com um olhar mais técnico, que é o meu background. Fui desenvolvedor por mais de dez anos antes de migrar meu ponto de vista.

Pessoas que são jovens há mais tempo, como eu, já tiveram a oportunidade de ver mudanças profundas em todo o processo de criação de software, mas especialmente na qualidade.

As expectativas mudaram muito. Há algum tempo, duas semanas era o tempo que se levava para marcar as primeiras reuniões de planejamento de funcionalidades de um novo sistema, e não o tempo para entregar um pequeno produto viável. Estes prazos mais curtos geram uma forte pressão nos processos de qualidade, que precisam entregar já e funcionando.

Não havia uma dependência tão forte do software. Há 35 anos, em 1985, as máquinas autenticadoras dos bancos eram eletromecânicas. O registro das transações era a fita de papel que copiava cada autenticação executada; além disto, os saldos de contas correntes chegavam em uma listagem pela manhã na agência, e a cada débito ou crédito que ocorria os funcionários faziam uma anotação a caneta na listagem. Por outro lado, se faltava energia, os bancos continuavam trabalhando, com os caixas usando manivelas para operar as autenticadoras. Uma falha no fornecimento de energia elétrica (ou qualquer outra falha que seja show stopper) hoje é praticamente o caos, porque não podemos fazer circular as informações com a velocidade necessária à exigência atual. Pressão enorme na qualidade.

Outra fonte de pressão é a disponibilidade de alternativas. Falando de maneira simples e concreta, se o seu aplicativo falhar ou for lento, o risco de que o usuário o desinstale e procure uma alternativa de um concorrente é imensa. A chance de ele encontrar esta alternativa de forma muito fácil também é imensa.

Não digo que somente a qualidade foi afetada. Todo o processo de desenvolvimento teve que evoluir de maneira vertiginosa, e felizmente o fez. Vou limitar o escopo desta conversa, entretanto, à qualidade; mesmo assim já teremos que nos manter em um nível de abstração um tanto alto, para que possamos, no escopo de um artigo, discutir as possibilidades de aplicar métodos, abordagens e processos inteligentes na qualidade de software.

É fato que já avançamos muito, mas ainda há muito a ser feito, e a perspectiva é que a velocidade da mudança continuará aumentando e exigindo cada vez mais eficiência.

Falando de inteligência no esforço de qualidade, alguns temas me vêm à mente:

· O investimento tem que ser adequado à necessidade do negócio. As necessidades de um hotsite que terá quatro meses de vida, de um CRM e de um software de monitoramento de UTI são totalmente diferentes.

· De acordo com as características do meu negócio, preciso colocar mais investimento onde a relação custo/benefício é maior.

· O feedback da qualidade tem que ser leve (poder ser executado quando necessário) para que seja frequente e traga as perguntas e respostas quando necessário.

· As informações relevantes têm que chegar ao destino de forma rápida.

· Falhas em produção têm que ser proporcionais à tolerância de cada negócio. Se não há tolerância, não pode haver falha.

· Falhas e falta de eficiência na qualidade: quem observa o observador?

· Repetitividade: a regressão de funcionalidades não pode existir; uma nova funcionalidade não pode fazer deixar de funcionar uma outra que já existia.

Levando estes pontos todos em conta, a primeira palavra que me passa pela cabeça (e espero que pela de vocês também) é Automatização. Ela é necessária e fundamental; sem ela, não é possível dar conta de conta de todas estas necessidades com sucesso. Entretanto, além de necessária e fundamental ela é exigente. Quando falamos de automação de qualidade, precisamos pensar nas necessidades do seu negócio e do seu sistema em várias dimensões diferentes. Por exemplo:

· Automatização de testes funcionais e não funcionais: normalmente, o primeiro ponto que nos vêm à cabeça sobre automação de qualidade. São vários tipos e níveis diferentes de validações e verificações aplicáveis a situações e contextos diferentes. A relação custo / benefício de cada tipo e nível de automatização de teste varia muito, e precisamos ter em mente que devemos fazer com os testes mais “caros” somente o que não pode ser feito de outra forma. De forma simplista, este é o resumo da teoria de pirâmide de testes; apresentada por Mike Cohn em 2009 e defendida de maneira brilhante por Martin Fowler em vários artigos. Infelizmente, ainda é um tema no qual muita gente boa ainda erra e acaba consumindo mais tempo e recursos para validar seus sistemas do que o necessário.

· Automatização do ciclo de construção e publicação do software: não é à toa que se fala tanto de DevOps, DevSecOps, SRE…. É aqui que fazemos as verificações de qualidade do código, aderência a padrões, executamos o build de maneira automatizada e independente do desenvolvedor e de sua máquina, executamos os testes adequados para a resposta rápida da pergunta “Quebrou alguma coisa que não podia quebrar neste build? ”. Fundamental para que o feedback rápido que comentamos antes seja viável. Com um processo afinado, nosso débito técnico não cresce, as respostas sobre a qualidade chegam antes das perguntas e o time to market se reduz de forma impressionante. Pode, entretanto, ser um ralo de recursos e um gargalo se for mal implementada.

· Automatização da coleta de resultados: o que não é mensurado, informado e repetível não existe. Melhorou? Piorou? Quantas falhas ocorreram em tempo de desenvolvimento? E de homologação? E em produção? Quais são as áreas do sistema que são mais frágeis e geram mais problemas? A quantidade de problemas tem uma relação direta com o volume de entregas ou há outras questões envolvidas?

Esta coleta de resultados fica ainda mais importante quando pensamos em um universo que começa a obter benefícios da inteligência artificial. Os processos de IA se constroem com dados; sem dados históricos não há insights, não há treinamento de modelos inteligentes, não há resultados.

· Automatização da geração de casos de testes: ainda parece um pouco com ficção científica, mas já é bastante viável a facilitação da geração de casos de testes utilizando inteligência artificial. Na everis já temos ferramentas que nos apoiam na conversão de linguagem natural em testes automatizados de forma concreta.

· Automatização da geração da massa de dados: quem trabalha com testes ou desenvolvimento há mais de duas semanas e nunca teve problemas com massa de dados pode atirar a primeira pedra. Seja um backup ou snapshot, uma ferramenta de virtualização ou de extração mascarada, um gerador automático ou um time especializado: todos necessitam de uma forma de apoio para a geração das suas massas de dados, caso contrário a verificação e validação é inviável.

· Automatização de ambientes: mesma questão acima. Quem é “do métier” e nunca teve problemas com a criação de ambientes? Muita gente se justifica dizendo que ter ambientes para executar os testes é muito caro, por isto não é viável; alguma vez já pararam para pensar no custo de não executar os testes? Pensem nisto. Seja na nuvem, em contêineres, on premises, máquinas virtuais ou serviços virtualizados… Qual é o “sabor” de automatização de ambientes que atende de forma perfeita a sua necessidade?

· Automatização das verificações de segurança: é um subtipo especializado dos testes funcionais, mas que merece uma atenção destacada. Qual é o valor dos seus dados, do seu sistema ou da ausência deles? Se é baixo, ignore esta preocupação. Caso contrário…. Se não está tomando nenhuma atitude concreta, preocupe-se. It’s a jungle out there.

Não tive a menor intenção de fechar o tema. Meu objetivo é trazer à tona que há muitas possibilidades e várias abordagens diferentes para trazer mais eficiência ao processo de qualidade.

A boa notícia é que há muitas alternativas para avaliarmos, algumas mais recentes e outras já anciãs. Procurei associar com cada dimensão acima uma série de respostas que se aplicam em alguns cenários. Devemos, entretanto, verificar a sinergia entre nossas escolhas de cada dimensão, de acordo com as características do sistema em teste.

Por fim, vocês podem me dizer: “mas Rui, estamos falando de qualidade e você só fala de automatização. Não há mais valor nos testes manuais? ”. Claro que há. Eles são fundamentais nos testes exploratórios, naquelas (poucas) situações em que não é possível automatizar e para trazer aquele olhar experiente de tester acostumado a localizar problemas. Entretanto, coloco os testes manuais no contexto da pirâmide de testes que comentei anteriormente; é o teste mais caro que temos no “menu”, e deve ser utilizado somente onde necessário.

Sorria, amanhã será mais difícil, com necessidades mais desafiadoras. É isto que mantém o mundo de qualidade (e de software) tão divertido.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store