Detecção e Correção de Problemas ao longo do processo de desenvolvimento de Software
Recentemente voltei a ler o livro “High Output Management” e logo no início do livro ele comenta um ponto que apesar de óbvio, é muitas vezes negligenciado no mundo de software, particularmente no Brasil:
“A common rule we should always try to heed is too detect and fix any problem in a production process at the lowest-value stage possible”
Por quê eu digo que é negligenciado? Muitas das vezes, ao se deparar com problemas de qualidade em um software, a primeira coisa que vem a cabeça é fazer testes ANTES DE ENTREGAR O SOFTWARE PARA O CLIENTE. Ou seja, se faz o teste no ponto onde é mais caro corrigi-lo.
O que precisa ser feito, é termos um processo de identificação de causa-raiz, e para as causas detectadas, instaurar um conjunto de planos de ações e medições de qualidade ao longo de todo o processo de desenvolvimento.
Outra abordagem complementar é a utilizada por métodos ágeis, onde você faz todo o ciclo em 2-3 semanas, e com isso você consegue pegar os problemas de forma bem mais rápida e antes que eles se tornem muito caros. O seu ciclo de feedback curto faz com que os problemas mais estruturais surjam de forma mais rápida.
Além disso, existe um conjunto bastante grande de práticas e ferramentas de engenharia de software que podem auxiliar nesse processo. Mas o importante é ter em mente que testar só no final (apesar de funcionar no curto prazo) não funciona no longo prazo.
Esse não é o trabalho da Integração Contínua?
Sim e não. Sem dúvida a integração continua ajuda bastante a detectar os problemas rápido (assim que eles forem "introduzidos"). Porém, para a integração continua funcionar, você precisa ter um conjunto relevante de testes (em todos os níveis: unitários, de integração, de interface, etc), de forma que os bugs introduzidos sejam detectáveis. E é ai que eu vejo problema na realidade brasileira.
De forma geral, a grande maioria das startups de tecnologia no Brasil tendem a relegar a prática de testes, como sendo um trabalho melhor. Pouquíssimas empresas levam a disciplina de testes a serio. Poucas empresas pensam em arquitetar o software de forma que seja mais fácil testar. Normalmente o teste vem no final (no processo e no mindset do developer).
Assim, o que eu vejo acontecendo é que apesar de você colocar todo o processo de integração continua no ar (seja com Jenkins, com TFS ou com qualquer outra ferramenta), as coisas que você testa no processo de integração se constituem no maior gargalo para a detecção precoce dos bugs.
Outro ponto importante é que a integração contínua só endereça uma classe de problemas. Se você tem um problema sério de UX, enquanto seu código estiver correto, sua integração continua estará indicando um software OK. O mesmo para problemas ocasionados na concepção da história ou dos use cases (ou das especificações, caso você use um modelo tradicional). Ou seja, a integração contínua não é a solução de todos os problemas.
Como resolver esse problema?
Infelizmente não existe receita de bolo para isso. O que existe são as famosas melhores práticas.
Para identificar problemas de UX você pode usar ferramentas como teste A/B, testes de usabilidade, análise de mapa de calor de click, etc. O mesmo acontece com problemas de especificação. Para testar se você está resolvendo de verdade o problema que você quer resolver você pode usar protótipos funcionais, desenvolvimento iterativo, MVPs, entre outras.Para entender onde sua arquitetura está falhando você pode fazer alguns testes/entrevistas com os usuários para validar os limites dos casos de uso, por exemplo.
O importante é entendermos que a forma de resolver o problema é estrutural, e não pontual. Você precisar estar constantemente monitorando e avaliando o seu processo de desenvolvimento buscando formas de detectar o problema o mais cedo possível. É uma jornada e não um destino.
