Impacto?? Só para melhor!

Ao longo de quase 10 anos de carreira dedicados a liderança e gestão de equipes de Qualidade de Softwares, tive a oportunidade de vivenciar uma série de situações enriquecedoras atuando nas mais diversas linhas de negócio. Porém posso afirmar que, independente da área de negócio, seja a empresa focada em serviços de TI ou não, o desafio que sempre se fez presente, e que efetivamente é crucial para o sucesso do trabalho de um Gestor de Quality Assurance, é como evitar que a área de QA se torne o “gargalo” das entregas de TI.

O intuito aqui não é discorrer sobre os tipos de metodologias empregadas no desenvolvimento de softwares, nem comparar, por exemplo, Waterfall X Agile. Que em qualquer cenário, a equipe de QA é (ou deveria ser!) responsável por zelar pela qualidade das entregas de TI, é mais do que óbvio. O que nem sempre é óbvio, para quem não olha as esteiras de desenvolvimento como um todo, são os pontos de impacto existentes ao longo do percurso e que recaem sobre as equipes de teste. Ainda hoje, para muitas empresas, o escopo de uma área de QA resume-se a atividades de validação realizadas como etapa final pré-produção e que, por clara consequência, obriga as equipes envolvidas a absorverem os impactos ocorridos em todas as fases anteriores, desde a concepção do projeto até a implantação do código nos ambientes de homologação.

Por mais que existam estudos comprobatórios indicando que quanto mais cedo introduzirmos as atividades e, especialmente, os profissionais especialistas em Qualidade de Software na esteira de desenvolvimento, menores serão os custos de correções e as chances de problemas impeditivos para a entrada em produção (e principalmente erros críticos pós implantação), isso ainda não é realidade em muitas companhias, e mudar essa realidade é, por muitas vezes, tentar mudar uma cultura já enraizada nas mais diversas áreas que atuam na entrega de uma demanda. Possível, obviamente é, mas no melhor cenário, apenas a longo prazo.

E é aqui que chegamos ao ponto que motivou este artigo: como então, a médio e principalmente a curto prazo, o responsável pela área de testes pode, mesmo tendo que por muitas vezes absorver impactos prévios, garantir a qualidade das entregas sem impactar o time to market? A resposta: ADAPTABILIDADE. A gestão dos profissionais de qualidade, dos recursos financeiros e tecnológicos e dos processos deve ser orquestrada para atender as necessidades individuais de cada empresa. Pegar as melhores práticas e aplicar o que for possível aonde for possível, e não pregar o “by the book” como verdade absoluta. Muitas vezes concessões precisam ser feitas, e elas não são necessariamente ruins. A adequação dos processos internos de QA é essencial, e deve ser fundamentada após conhecida e entendida a cultura de cada empresa.

Quero deixar claro que não estou dizendo que o responsável por QA tem que dizer amém para qualquer tipo de situação que lhe seja apresentada, nem tão pouco submeter sua equipe a incessantes apagares de incêndio. Devemos sim nos adaptar, mas uma das nossas principais responsabilidades é mostrar de forma muito bem embasada os impactos que estão sendo absorvidos pela equipe, as ações que estão sendo tomadas para absorver estes impactos e, neste momento, indicar quais ações preventivas devem ser tomadas e, principalmente, quais os ganhos estas ações trarão para o processo como um todo. Neste escopo inclui-se, por exemplo, a revisão de níveis de esforços e serviços, de dimensionamento de equipe, e a utilização de ferramentas de gestão/automação.

Não existem soluções mágicas para Qualidade de Software. O que existem são soluções construídas dentro do contexto correto! O primeiro passo é sim arrumar a cozinha, fazendo com que ela atenda às necessidades da casa, para depois poder “vender o peixe” e expandir a utilização de boas práticas ao longo de todo o processo. Adaptações internas a curto prazo para que consigamos melhorias mais profundas ao longo do tempo. Isso é QA agregando valor!

Abraços e até o próximo artigo!