Teste de Software: O Futuro está só na Automação?

Há alguns dias eu discutia com um colega sobre para onde está se encaminhando a qualidade/teste de software nas empresas de TI. É bastante recorrente esse tipo de assunto nos corredores atualmente. Depois de vermos um grande "boom" no setor, no que diz respeito a técnicas e processos de teste de software, parece que o mercado está, de uns tempos para cá, mudando o seu rumo, ou pelo menos se adaptando a novas necessidades.

Embora recente, se comparada a outras áreas tradicionais (pelo menos academicamente, em termos de livros e discussões geradas a partir dela), a área de testes é uma das que mais ganhou ênfase dentro dos projetos. É difícil você pensar em um novo software sem considerar que seu desenvolvimento precisará de ciclos de testes para garantir a entrega do produto final com o melhor resultado possível em termos de confiabilidade, estabilidade, funcionalidade, etc. Nos projetos em que trabalhei, sempre foi assim. Algumas vezes isso foi bem elaborado, outras nem tanto. O que chama a atenção é uma aparente movimentação na área relativa a uma ênfase ainda maior em automação de testes.

Obviamente, quem lê sobre o assunto já deve ter visto uma grande quantidade de textos falando de automação. Parênteses aqui: pra mim, esse termo, no sentido da origem da palavra, seu radical, estaria equivocado, pois "automação" subentende algo que faz tudo sozinho, de forma automática, coisa que nenhum teste é capaz de fazer. No meu entendimento, o mais correto seria falar em "autonomação", que vem de "autonomia" e que depende de participação humana. Aliás, que coisa horrível essa mania de querermos aportuguesar termos técnicos. "Inicializar" é outra palavra que me dói nos ouvidos. Mas tudo bem, o mercado já se acostumou a falar assim e temos seguir o padrão, sob o risco de não sermos compreendidos. Quem sou eu para contestar isso? Vamos em frente com o raciocínio.

Quando surgiu esse conceito de automação de testes ou de testes automatizados, parecia que o mercado iria migrar para duas correntes distintas de profissionais: Os que tinham perfil mais analítico e que iriam se encarregar da criação de scripts e testes manuais, mas com altas doses de regras de negócio compreendidas neles, e os com perfil mais de programador, que iriam automatizar os testes manuais criados pelos analistas, usando ferramentas e linguagens adequadas. Sim, porque, partindo de um princípio básico, devemos entender a automação de testes como uma FERRAMENTA, que vai trabalhar a partir de algo que já exista (testes manuais) e não como um processo, que vai criar algo do zero. Esse talvez seja um dos grandes erros cometidos pelas empresas nessa área. É uma lógica muito parecida com aquela de se comprar um ERP (ainda se fala em ERP?): Primeiro tenha processos bem definidos e funcionais, depois construa/adquira um sistema que se molde a eles e não o inverso. 

Mas isso não significa que um software só deve ser testado depois de pronto. Todo mundo que trabalha nessa área sabe que o teste deve estar envolvido no projeto desde suas primeiras definições até o post-install Mas a automação em si precisa de uma análise de custo-benefício prévia para saber onde melhor pode ser aplicada.

Essa área tem ganhado muito espaço, mais até do que se imaginava antes. Todo mundo agora parece falar mais em automação do que em qualquer outra coisa. De fato, parece haver certo direcionamento das empresas e do mercado para focar mais nessa área, afinal, um dos seus grandes benefícios está em aumentar escopo e diminuir o tempo de teste, agilizando assim o tempo final do projeto e aumentando a eficiência do software. Isso significa que o papel de analista, que criava testes manuais vai desaparecer? Acredito que não. E nem deveria, pois testes manuais sempre serão necessários, uma vez que há testes que só um ser humano pode realizar, especialmente aqueles que envolvem decisões, julgamentos ou regras de negócio mais subjetivas. Há ainda aqueles que não valem a pena serem automatizados, por apresentarem um custo-benefício baixo em termos de esforço de automação versus ganhos apresentados. Para esses casos, sempre serão necessários testes manuais. Ou, ao menos, a possibilidade de tê-los.

O fato é que a automação tem mais lógica (ou razão de ser) quando aplicada a testes que terão alto índice de reuso (testes de regressão, por exemplo), pois, não raro, a construção de bom um teste automatizado leva bem mais tempo do que a de um teste manual. Fora isso, a tendência é ter um custo elevado demais para se justificar no escopo do projeto. Aí entra a análise prévia de custo-benefício que comentei antes. Sempre ajuda.

O que eu particularmente enxergo como uma tendência, é que esses dois papéis, de Analista de Testes e de Engenheiro de Testes (como algumas empresas chamam o Automatizador), não sejam mais executados por pessoas diferentes. Aquela história de time de testes manuais e time de automação separados parece estar acabando. Não estou dizendo que é o melhor caminho. Até acho que algumas funções poderiam ser compartilhadas, mas a especialização que difere os dois papéis ainda é muito útil. O fato é que é cada vez mais se caminha para isso. Os profissionais acabarão tendo de acumular as duas habilidades. A questão é a qualidade com a qual serão capazes de executar as duas coisas ao mesmo tempo. Esse parece ser o próximo movimento do mercado. Até por uma questão de custo, pois manter dois times distintos em termos de especialização dentro do mesmo projeto é bem mais caro e não necessariamente mais eficiente. 

Alguns dirão: - Lá vem o capitalismo selvagem, querendo fazer com que menos pessoas façam mais e produzam mais. Não se esqueçam de que essa também é uma lógica da TI em si, portanto, não há como ser diferente. A TI é capitalista na sua essência e uma das grandes viabilizadoras deste sistema econômico, queiram ou não.

Falando em capitalismo, vemos que existem diversas ferramentas para automatizar testes. Umas têm licenças caríssimas. Mas há também aquelas open source, gratuitas, e que, até com certo sucesso, vêm sendo utilizadas em muitos lugares. Não tive contato com todas elas, mas pude observar algumas que fazem parte dos dois grupos. Por essa experiência, até o momento, as ferramentas pagas ainda me parecem ser melhores, pois oferecem mais recursos, embora as gratuitas tenham evoluído. Ao optar por um dos dois grupos, deve-se considerar o retorno trazido pelo investimento feito. Para empresas grandes, com mais recursos financeiros e que precisem de resultados melhores, as ferramentas pagas ainda tentem a serem as escolhidas como melhor opção. Já para as empresas menores, provavelmente o custo, principalmente das licenças, não compense. Tudo dependerá das necessidades de automação de cada empresa e o quanto se está disposto a investir nisso.

Retomando a questão sobre profissionais de teste que possuem habilidades de análise e automação, eu já observo esse comportamento em diversas organizações de TI (especialmente as americanas) e, como sempre acontece, acho que teremos uma fase de transição onde, num primeiro momento, encontraremos dois tipos de empresas: 1) as de vanguarda, que enxergaram esse movimento há mais tempo e que saíram na frente, ajustando seus processos de teste e seu gerenciamento de projetos para contemplar mudanças e; 2) as empresas "retardatárias", que ainda irão operar da forma "antiga", e para onde provavelmente irão migrar aqueles profissionais que não acompanharam ou não quiseram acompanhar as mudanças.

Não estou dizendo aqui que um método vai ser melhor que o outro. Dependendo da empresa, qualquer um deles pode funcionar. Apenas estou tratando da questão de como as novidades chegam às organizações e de como o mercado se regula naturalmente. E todos sabemos que o ritmo das mudanças não é igual para todas. Porém, mais cedo ou mais tarde, é possível que tenhamos todas trabalhando com profissionais que possuam perfis/habilidades para executar tarefas tanto em testes manuais quanto em automatizados. Isso, obviamente, irá exigir um nível de conhecimento muito maior desses profissionais. Há de se saber ainda se os salários irão acompanhar essas exigências. 

Creio (e isso é apenas uma impressão minha, diga-se) que as organizações deverão apostar e investir mais nesse conceito nos próximos anos, sem eliminar os testes manuais, mas deixando a ênfase maior na automação. Riscos relativos à empregabilidade tendem a aparecer mais para os profissionais que não quiserem aprender sobre o tema. Acho que, para aqueles que ainda não começaram, essa é a hora para iniciar essa mudança, agregar mais conhecimentos e buscar capacitação sobre o assunto. Faz parte desse universo o surgimento de novos conceitos. E deve fazer parte da natureza dos profissionais de TI estarem sempre atentos a isso.

* Adaptação do texto escrito em 03/10/2008