Como preparo e testo os meus lançamentos

Os lançamentos e a gestão de lançamentos são uma parte essencial do nosso trabalho. Lançar o produto certo para os clientes irá deixá-los satisfeitos. Fazer um lançamento tranquilo irá deixar-nos satisfeitos a nós, os envolvidos no lançamento. 

Como podemos conseguir um lançamento tranquilo? 

Depois de ter participado num grande número de lançamentos, posso dizer que existem alguns pontos fundamentais que podem ajudar a conseguir uma gestão de lançamentos bem-sucedida. 

Deixe-me dizer-lhe quais são.

Um lançamento bem-sucedido começa durante o desenvolvimento.

Identificação dos casos de teste

Uma boa gestão de lançamentos começa muito antes do dia do lançamento, desde o momento em que a funcionalidade a lançar se encontra na fase de desenvolvimento. Durante este período, a funcionalidade tem de ser aprovada pela equipa de QA. Isto significa que precisamos de testar todos os cenários possíveis em que conseguimos pensar, que façam sentido para a funcionalidade em questão, de modo a validar que esta funciona de acordo com os requisitos. Alguns destes cenários serão testados por testes automatizados, enquanto, para outros, é demasiado difícil ou não compensa criar automatização. 

Quando identificamos o tipo de testes que precisamos de realizar para a funcionalidade em questão, devemos considerar o seguinte: na primeira vez que esta funcionalidade entrar em produção, precisamos de a testar completamente. Temos de garantir que os clientes não encontrarão problemas críticos. Precisamos de validar os requisitos. E temos de assegurar o bom desempenho da funcionalidade. 

Os atrasos e os problemas nos testes podem afetar gravemente os prazos durante a preparação de lançamentos de software. Incorporar práticas eficazes de gestão de lançamentos ajudará a garantir que os testes e a implementação continuam a ser fiáveis e previsíveis.

Mas, depois de a funcionalidade entrar em produção, a menos que sejam necessárias algumas atualizações, não precisamos de a testar tão exaustivamente em cada lançamento futuro da mesma base de código. O comportamento da funcionalidade só mudaria se o código subjacente tivesse sido alterado ou se tivesse ocorrido uma alteração externa numa das dependências que utiliza. No resto do tempo, será suficiente realizar testes de verificação básica da funcionalidade, sendo que estes testes incluiriam, naturalmente, os casos de teste mais importantes. 

Dito isto, quando a funcionalidade está em desenvolvimento, certifique-se de que avalia: quantos casos de teste precisa de testar; quanto tempo tem disponível para os testes; quais dos casos de teste são críticos; quais dos casos de teste executaria em cada lançamento.

Desta forma, pode identificar quais são os casos de teste que irá automatizar. Concentre-se em garantir que, pelo menos, a funcionalidade crítica fica abrangida pela automatização. Para os restantes testes, deve criar casos de teste escritos, quer no seu sistema de acompanhamento de projetos (por exemplo, Jira), quer na ferramenta de gestão de testes que está a utilizar. Desta forma, não se perderão nem serão esquecidos e poderão ser executados sempre que um lançamento o exigir.

Execução dos testes na CI

Assim que tiver os testes automatizados, deve começar a executá-los através da CI, nos ambientes de desenvolvimento, de forma periódica. À medida que outras funcionalidades são desenvolvidas antes de ocorrer o lançamento, é boa prática garantir que a funcionalidade que pretende lançar continua a funcionar corretamente, especialmente se já tiver sido aprovada durante o sprint. Executar os testes da funcionalidade em que está interessado, por exemplo diariamente, irá fornecer-lhe rapidamente informações sobre quaisquer correções que tenham de ser aplicadas à funcionalidade, devido a erros causados por outras alterações no sistema.

A deteção precoce de potenciais erros na funcionalidade a lançar dará bastante tempo para aplicar as correções e voltar a testar a funcionalidade, sem o stress de ter de o fazer no tempo limitado de que dispõe durante a fase de lançamento. Quanto maior for a cobertura dos requisitos nos seus testes automatizados, maior será a probabilidade de encontrar apenas um pequeno número de erros durante a fase de lançamento.

A pré-produção é importante e deve incluir uma margem de segurança.

Prazos 

A fase de lançamento consiste normalmente num período dedicado a testes num ambiente de integração de pré-produção, separado do dia ou período de lançamento em produção. Enquanto pessoa responsável pelos testes envolvida no lançamento, certifico-me sempre de pedir os intervalos de tempo adequados para o lançamento, de forma a que a fase de pré-produção me permita testar corretamente as funcionalidades a lançar. 

Também considero sempre uma margem de tempo, porque espero que surjam problemas imprevistos durante o processo de gestão de lançamentos, quer sejam erros nas funcionalidades a lançar, quer sejam fatores externos. Para mencionar apenas um desses fatores, os ambientes de pré-produção são ambientes de teste e estão sujeitos a não serem tão fiáveis quanto deveriam. Muitas vezes, funcionam muito lentamente ou ficam indisponíveis durante algum tempo, precisamente quando ocorrem os testes do lançamento. 

Ter uma margem de segurança adicional é sempre uma boa ideia e, mesmo que não utilize esse tempo extra, não há problema. Pode dar a sua aprovação antes de terminar o tempo de testes atribuído, uma vez que pode passar o tempo restante a trabalhar noutra coisa. É pior não ter uma margem de segurança e precisar dela, pois, nesse caso, terá de conseguir incluir de alguma forma todos os testes necessários num período de tempo mais curto. Isto pode levar a que alguns casos de teste não sejam executados, o que, por sua vez, pode fazer com que alguns erros só sejam detetados diretamente em produção.

Âmbito

Outro aspeto importante da versão de pré-produção, na minha perspetiva, é ter um coordenador dedicado à gestão de versões. Para mim, isto significa alguém que trata de determinados aspetos, sendo o primeiro deles verificar o âmbito da versão. Antes de começar a testar qualquer versão, o responsável pelos testes precisa de saber o que deve testar. Isto resume-se ao âmbito da versão. 

As pessoas responsáveis pelo produto, também conhecidas como POs ou BAs, esperam que determinadas funcionalidades sejam incluídas na versão, e isto é acordado quando o desenvolvimento começa. No entanto, o código incluído na versão pode nem sempre abranger exatamente o âmbito esperado pela equipa de produto. Por vezes, as pessoas esquecem-se de enviar código para o ramo a partir do qual a compilação da versão é criada. Ou, pior ainda, podem enviar para esse ramo código que não deveria ser enviado. Isto pode representar funcionalidades que ainda não estão concluídas e aprovadas pela QA, ou funcionalidades que não fazem parte do âmbito atual.

Para garantir que o âmbito será cumprido, o coordenador da versão deve comparar o âmbito esperado com o âmbito real. Para isso, o âmbito esperado deve ser fornecido pelas pessoas responsáveis pelo Produto e estar claramente indicado em algum tipo de documento (e talvez no seu plano de garantia da qualidade). Por exemplo, pode ter algum tipo de documentos de planeamento que mostrem os marcos do projeto e o que está incluído em cada marco. 

Quanto ao âmbito real, deve ser extraído um registo de alterações do VCS (Sistema de Controlo de Versões, por exemplo, Git) utilizado pelo projeto. O registo de alterações refletirá todas as confirmações efetuadas durante a fase de desenvolvimento no ramo que irá gerar a compilação da versão. Esperemos que, se estiver a trabalhar de forma organizada, cada confirmação tenha uma descrição que aponte para um item do Jira ao qual o código se refere. Desta forma, poderá ver todos os itens do Jira que têm código correspondente a entrar na compilação da versão e quais desses itens não deveriam ter sido incluídos nesta compilação. Naturalmente, se verificar que estas confirmações estão relacionadas com correções de erros necessárias, isso é perfeitamente aceitável. O que não pretende é que estas confirmações representem trabalho inacabado de funcionalidades ou trabalho relacionado com funcionalidades que não deveriam entrar em produção com a versão atual.

À medida que se aprofunda nas técnicas avançadas de gestão de versões, descobrirá que integrar os seus processos com soluções de gestão de testes concebidas para o Jira pode proporcionar um fluxo de trabalho mais coeso e eficiente

Sempre que for encontrada uma discrepância entre o âmbito esperado e o âmbito real, o coordenador da gestão de versões deve articular-se com a equipa de produto e com os responsáveis pelas equipas de desenvolvimento, para identificar qual é a melhor abordagem. Se as confirmações identificadas como não pertencendo ao âmbito representarem trabalho inacabado de funcionalidades, é melhor removê-las. Isto deve-se ao facto de já estar na fase de versão de pré-produção e não querer correr o risco de permitir que o código restante seja escrito e testado à pressa, apenas para acabar por ser incluído na versão. É arriscado, pois esta pressa pode levar a que casos de teste sejam esquecidos e não sejam executados, bem como a que erros críticos cheguem à produção. Neste caso, é melhor permitir que o trabalho restante destas funcionalidades seja devidamente concluído numa versão futura.

Os testes

Assim que o âmbito estiver claro, deve começar a fase de testes. Durante a fase de testes de pré-produção, precisa de voltar a validar toda a funcionalidade que está a lançar. Deve imaginar que é a primeira vez que a está a analisar e testar todos os cenários que testou durante a fase de desenvolvimento. Execute os testes automatizados que já escreveu, mas no ambiente de pré-produção, e não se esqueça dos cenários não automatizados. Efetue uma regressão completa desta funcionalidade, pelo simples facto de que, quando está nesta fase de gestão de versões e no ambiente de pré-produção, é provável que existam outras equipas que também precisem de efetuar lançamentos durante o mesmo período que a sua equipa. Esta é, basicamente, a primeira vez que todas as dependências se juntam, com código pronto para produção, no mesmo ambiente. E esta é, em teoria, a configuração que será executada em produção a partir do lançamento da versão.

A menos que sejam detetados alguns problemas durante os testes e sejam necessárias correções. Se isso acontecer, precisa de considerar o que deve voltar a testar. Independentemente de a correção estar no seu código ou no código de alguma dependência externa, se as alterações afetarem a sua funcionalidade de alguma forma, precisa de considerar uma nova ronda de testes. Certifique-se de que volta a testar, pelo menos, a funcionalidade crítica da funcionalidade.

Isto pode parecer aborrecido, especialmente se ocorrerem muitas correções durante esta fase. No entanto, não pode prever com precisão o impacto que as correções poderão ter nas diferentes partes da sua funcionalidade.

Pequenas alterações podem causar efeitos secundários enormes, por isso é melhor ficar aborrecido, mas confiante de que a funcionalidade crítica continua a funcionar corretamente, do que arrepender-se de não ter testado o suficiente.

E, naturalmente, se algum erro encontrado durante esta fase de testes for menor, não se preocupe em corrigi-lo durante esta fase. Mais uma vez, não quer apressar qualquer implementação ou teste efetuado numa funcionalidade que, de outro modo, funciona perfeitamente, de forma a não introduzir o risco de a danificar.

Durante o lançamento, a comunicação e os testes são fundamentais.

Assim que a funcionalidade tiver sido aprovada no ambiente de pré-produção, está pronta para avançar para o ambiente de produção.

Comunicação

No que diz respeito ao lançamento em produção, o coordenador de gestão do lançamento tem algumas tarefas a realizar. Antes de mais, a data e a hora do lançamento devem ser devidamente definidas com antecedência e comunicadas a todas as partes envolvidas. Considero muito útil ter a data e a hora do lançamento definidas como uma reunião nos calendários dos participantes para a gestão do lançamento, de modo a que os participantes possam organizar o seu dia, uma tarefa que pode ser realizada pelo coordenador.

No dia do lançamento, o coordenador deve relembrar todas as pessoas envolvidas nos prazos do lançamento. Idealmente, a comunicação deve ser feita num canal que todos utilizem, por exemplo, Slack. Ter um canal dedicado no Slack onde são comunicados todos os aspetos importantes garante que todas as pessoas envolvidas têm o mesmo entendimento sobre que etapa do lançamento foi concluída e quando, qual é o âmbito, que problemas foram detetados e quem pode ajudar a resolvê-los. Esta comunicação garante que alguém que precise de conhecer determinados aspetos do lançamento verá essa informação, ao contrário da comunicação verbal (em que essa pessoa pode estar ausente, sem que a pessoa que comunica a informação se aperceba de que está em falta). 

O coordenador de gestão do lançamento deve acompanhar e anunciar neste canal os marcos do lançamento, como o início do lançamento e o momento em que o lançamento foi aprovado. Além disso, todas as partes envolvidas no lançamento devem comunicar através deste canal que estão a executar as etapas que lhes foram atribuídas, para que todas as outras pessoas estejam a par do estado e do progresso do lançamento. Caso alguma das partes necessária em qualquer momento do lançamento não esteja disponível, o coordenador do lançamento deve contactar as pessoas adequadas, de modo a garantir que tudo decorre sem problemas.

Os testes

Durante o lançamento em produção, os testes da nova funcionalidade devem ser novamente realizados na íntegra. Isto deve-se ao facto de, embora a funcionalidade tenha sido aprovada noutros ambientes de teste, esses ambientes não serem 100% idênticos aos de produção em termos de configuração e recursos.

Para evitar um comportamento inadequado imprevisto da funcionalidade lançada, é importante executar todos os testes automatizados disponíveis, juntamente com as partes não automatizadas para as quais escreveu casos de teste. Nunca dê a aprovação em produção sem ter testado uma funcionalidade.

Partir simplesmente do princípio de que a funcionalidade funciona em produção não significa que funcione realmente.

Certifique-se de que funciona: teste-a.

Após o lançamento

O lançamento está concluído. No entanto, garantir que a funcionalidade funciona corretamente exige mais trabalho do que simplesmente testá-la durante a fase de lançamento.

Assim que terminar essa tarefa, certifique-se de que os seus testes automatizados estão a ser executados na integração contínua (CI), para produção. Isto detetará qualquer comportamento indesejado causado por alterações externas de que não tenha conhecimento.

Monitorize constantemente o desempenho da funcionalidade, para garantir que a carga em produção e a utilização por parte dos clientes não estão a causar uma degradação do desempenho.  Além disso, certifique-se de que acompanha quaisquer relatórios de problemas enviados pelos seus clientes. Estes podem indicar áreas que não estão a funcionar corretamente, para que possa agendar rapidamente uma atualização futura, caso seja necessário.

E, caso o lançamento não tenha corrido como esperado, certifique-se de realizar uma reunião de retrospetiva pós-lançamento. Nessa reunião, poderá abordar todos os problemas ocorridos no processo de gestão do lançamento e atribuir ações às pessoas relevantes, para que qualquer lançamento futuro decorra de forma tranquila e bem-sucedida.