O papel do QA em decisões de deploy

Nem toda decisão de deploy é apenas técnica. Muitas vezes ela envolve avaliar riscos que podem não estar visíveis à primeira vista.

Em alguns momentos do desenvolvimento de software surge uma pergunta que parece simples, mas que envolve várias decisões: quando subir uma mudança para produção?

Dependendo do contexto, o deploy pode acontecer em diferentes horários: durante o expediente, à noite ou em horários de menor uso da aplicação. E é justamente nesse tipo de situação que o papel do QA vai além de apenas testar funcionalidades.

Recentemente passei por um cenário que me fez refletir sobre isso.

A mudança que seria enviada para produção envolvia um fluxo crítico entre dois sistemas. A alteração em si não era grande, era uma mudança de regra de negócio e o time estava focado em realizar o deploy o quanto antes para conseguir seguir com outras demandas.

Ao olhar para a mudança com mais calma, comecei a pensar no contexto do fluxo. Como envolvia integração entre sistemas, existia a possibilidade de algum comportamento inesperado aparecer depois do deploy, mesmo que a alteração em si parecesse pequena.

Quando um fluxo envolve mais de um sistema, pequenas mudanças podem gerar efeitos colaterais difíceis de prever. Integrações, dependências entre serviços e regras de negócio compartilhadas podem fazer com que uma alteração aparentemente simples impacte outras partes da aplicação, como inconsistência de dados entre sistemas ou comportamentos inesperados em etapas posteriores do fluxo.

Foi nesse momento que levantei esse ponto para o time: será que aquele era realmente o melhor momento para realizar o deploy?

A ideia não era impedir a entrega, mas trazer visibilidade para os possíveis riscos e impactos envolvidos naquela mudança.

Isso abriu espaço para persarmos sobre o contexto da alteração e sobre qual seria o momento mais adequado para subir aquela mudança com mais segurança.

No fim, o time decidiu adiar o deploy para um horário mais apropriado, em que seria possível acompanhar melhor o comportamento do sistema após a liberação.

Também discutimos como seria feito o acompanhamento após o deploy, garantindo que o time pudesse observar rapidamente o comportamento da aplicação e agir caso algo inesperado acontecesse.

Foi nesse tipo de situação que uma coisa ficou muito clara para mim: o papel do QA não é decidir o deploy sozinho.

O papel do QA também é sobre ajudar o time a enxergar os riscos envolvidos em uma mudança.

Isso passa por observar alguns pontos importantes, como por exemplo:

• se o fluxo envolve mais de um sistema ou integração
• se houve mudança de regra de negócio
• se já existiram incidentes parecidos anteriormente
• qual pode ser o impacto caso algo não funcione como esperado
• se existem validações ou smoke tests planejados após o deploy
• se existe um plano de ação caso seja necessário reverter a mudança

Esse tipo de análise ajuda o time a entender melhor o contexto da mudança antes de levá-la para produção.

A partir disso, a decisão deixa de ser individual e passa a ser uma decisão coletiva, envolvendo desenvolvimento, produto e outras pessoas do time.

Em muitos casos, o QA acaba contribuindo justamente com essa visão mais voltada para risco e impacto das mudanças, ajudando o time a pensar não apenas se a funcionalidade funciona, mas também como ela pode se comportar em produção.

Uma coisa que aprendi com essa experiência é que, muitas vezes, o trabalho do QA não é apenas validar se algo funciona ou não. É também ajudar o time a refletir sobre qualidade, impacto e possíveis efeitos colaterais antes que uma mudança chegue aos usuários.

No fim, entendi que decisões de deploy não são apenas decisões técnicas, elas também são decisões de risco.

E garantir que esses riscos estejam claros para o time também faz parte do trabalho de quem se preocupa com qualidade.