Porque é que um CRM precisa de testes de regressão
Depois do go-live, o seu CRM continua a mudar, mesmo quando a sua própria equipa não muda nada. A Salesforce e a Microsoft atualizam a plataforma para todos os clientes. A maioria das alterações são melhorias. Algumas mudam uma página, uma definição padrão ou a forma como uma funcionalidade trabalha, e de vez em quando uma estraga algo de que o seu negócio depende.
Um teste de regressão responde a uma pergunta: o que o negócio aceitou no go-live ainda funciona? Não é um novo UAT. É uma verificação curta e focada dos processos mais importantes, feita antes de a alteração chegar aos seus utilizadores, por pessoas que conhecem o trabalho.
As suas próprias releases precisam da mesma verificação. Uma nova integração, um novo campo na proposta comercial, uma alteração ao encaminhamento de casos de suporte: cada uma pode afetar algo que funcionava antes.
Salesforce: três releases por ano
O Salesforce tem três grandes releases por ano: Spring, Summer e Winter. A release Winter chega no outono e leva o número do ano seguinte. Todas as orgs são atualizadas, em datas que a Salesforce publica com antecedência.
- A sandbox preview. As sandboxes numa instância de preview recebem a nova release algumas semanas antes da produção. É essa a sua janela para testar. Antes de cada release, a Salesforce indica que instâncias estão na preview e o que fazer para manter lá uma sandbox. Um refresh pode colocar uma sandbox dentro ou fora da preview, por isso verifique-o a tempo.
- As release notes. Leia-as para as clouds e funcionalidades que usa. Procure o que é ativado automaticamente para si, e o que muda o aspeto das páginas em que os seus utilizadores trabalham.
- Release updates. Algumas alterações são anunciadas no Setup com uma data a partir da qual são impostas. Teste-as na sandbox antes dessa data, para que não o surpreendam em produção.
Assim, para o Salesforce o ritmo está dado: um ciclo de regressão na janela de preview de cada release, três vezes por ano.
No UAT StudioEscolha Salesforce como CRM do projeto. A partir de cerca de dois meses antes de uma release, a página de projetos mostra Coming CRM releases, com a data da sandbox preview, a data em produção e um link para as release notes. A Salesforce ainda pode mudar estas datas, por isso consulte as release notes.
Dynamics 365: atualizações durante todo o ano
A Microsoft já não agrupa as alterações do Dynamics 365 em duas release waves por ano. As novas funcionalidades e alterações chegam ao longo de todo o ano. Os release plans foram arquivados em outubro de 2026; o que está para vir encontra-se agora no roadmap da Microsoft em aka.ms/AIatWorkRoadmap.
Isto significa que já não há um grande momento por ano em torno do qual planear os testes. As alterações chegam em passos mais pequenos, com mais frequência. Esperar por uma grande release já não funciona, e testar depois de cada alteração é demasiado.
Escolha um ritmo fixo
A resposta é um ciclo de regressão com um ritmo fixo, seja o que for que a Microsoft lance entretanto:
- Todos os meses quando o CRM é central para o negócio, usa muitas apps e funcionalidades, ou ativa novas funcionalidades com frequência.
- Todos os trimestres para uma configuração estável com poucas alterações próprias.
- Um ciclo extra antes de uma alteração própria entrar em produção, ou quando uma alteração da Microsoft afeta claramente um dos seus processos essenciais.
Ponha as datas na agenda dos testers para o ano inteiro. Um ritmo fixo é mais fácil de manter do que um ciclo planeado de cada vez que surge alguma coisa.
Antes de cada ciclo
- Leia o roadmap da Microsoft e as mensagens para os seus administradores no Microsoft 365 admin center, e anote que alterações afetam os seus processos.
- Experimente primeiro as funcionalidades em preview num ambiente sandbox, antes de chegarem aos seus utilizadores.
- Garanta que a sandbox em que testa tem a mesma versão e as mesmas soluções que a produção.
No UAT StudioEscolha Dynamics 365 como CRM do projeto, e comece cada ciclo com Start a regression round, a partir do projeto do seu go-live ou do seu último ciclo.
No UAT StudioEm Setup, escolha Check the Dynamics 365 updates: Every quarter ou Every month. A página de projetos mostra então o período atual com um link para o roadmap, e os administradores recebem um email por período, duas semanas antes de começar.
Escolher o que retestar
Um ciclo de regressão não é o sítio para testar tudo outra vez. Escolha, por esta ordem:
- Os casos de teste Must. O que tem de funcionar todos os dias: criar uma proposta comercial, converter um lead, encaminhar um caso de suporte, as aprovações. Teste-os em todos os ciclos.
- O que a alteração afeta. Leia as release notes ou o roadmap com a lista dos seus processos ao lado. Uma alteração às propostas comerciais significa os casos de teste de propostas, também os Should e Could.
- Integrações e automação. As ligações ao ERP, ao website ou ao email, e os fluxos que correm em segundo plano. Falham sem dar nas vistas, por isso teste-os de propósito.
- Os casos de teste Should, quando houver tempo.
Depois veja o que a sua própria equipa alterou desde o último ciclo. Tudo o que construiu e que ninguém testou em conjunto com a alteração da plataforma também pertence ao ciclo.
Mantenha uma lista curta do que é crítico
Deixe por escrito, uma vez, os dez a vinte processos sem os quais o negócio não consegue passar um dia. São o núcleo de cada ciclo de regressão. Reveja a lista a cada seis meses com os donos dos processos, e depois de cada grande alteração própria.
No UAT StudioCom o módulo Release readiness, Review the release mostra que casos de teste uma release do Salesforce ou atualização do Dynamics 365 afeta, com o motivo, propõe casos de teste para o que ainda não está coberto e lista as atualizações obrigatórias com as suas datas. O ciclo de regressão recebe então exatamente os casos de teste Must, os afetados que mantém e os novos que aprova. Uma falha no ciclo indica com que alteração veio. €99 por mês: adicione-o em Plan & billing.
Reutilize os seus casos de teste
O melhor teste de regressão que tem é o conjunto de casos de teste do UAT do seu go-live. Descrevem exatamente o que o negócio aceitou, com os passos, os dados de teste e os resultados esperados. Não escreva casos novos para cada ciclo.
- Guarde os casos de teste depois do go-live, num só lugar, com a sua prioridade.
- Atualize-os quando o seu próprio processo mudar, para que o próximo ciclo teste o CRM como é agora, e não como era no go-live.
- Verifique os dados de teste antes de cada ciclo. Um refresh da sandbox ou uma cópia da produção pode remover ou alterar os itens que os casos de teste usam.
- Acrescente um caso de teste para cada ocorrência grave encontrada em produção, para que seja detetada da próxima vez.
Aqui compensa ter casos de teste que os testers do negócio conseguem seguir: são reutilizados vezes sem conta. Veja Escrever casos de teste que os testers do negócio entendem.
No UAT StudioStart a regression round copia os casos de teste do projeto de onde parte, com os seus passos, dados de teste e resultados esperados. Escolha quais seguem: Must and Should, Only Must ou All test cases in scope; um caso de teste sem prioridade conta como Should. O novo projeto recebe os grupos e as definições, e convida os testers em Setup. Nada é inventado nem alterado.
Quem testa, e quanto tempo
Quem
Um ciclo de regressão precisa de menos pessoas do que um UAT, mas elas devem continuar a vir do negócio. Peça um ou dois key users por processo: pessoas que fazem o trabalho todos os dias e percebem de imediato quando algo não está bem. O administrador do CRM prepara o ciclo e testa o que corre em segundo plano, mas não deve ser o único tester.
Deixe as mesmas pessoas testar ciclo após ciclo. Ficam mais rápidas, e reparam em pequenas alterações que um tester novo não veria.
Duração
- Preparação: um ou dois dias para ler as alterações, escolher os casos de teste e verificar os dados de teste.
- Testes: algumas horas por tester, distribuídas por um ou dois dias num ciclo mensal, até uma semana para uma release do Salesforce com muitas alterações.
- Correções e retestes: reserve alguns dias antes de a alteração chegar à produção, para as ocorrências que encontrar.
No Salesforce, isso tem de caber na janela de preview. Comece cedo na janela, não na última semana.
Registar o que encontra
Abra as ocorrências como no UAT: o passo, o que esperava, o que aconteceu em vez disso, um screenshot e o link para o item. Faça a triagem todos os dias com a equipa do CRM. Para uma ocorrência causada pela plataforma, procure primeiro nas release notes ou no roadmap: muitas vezes é uma alteração conhecida com uma definição a ajustar.
No UAT StudioCada ciclo guarda a sua release, build e ambiente, para que o relatório de go/no-go diga o que foi testado. Depois das correções, Start round 2 no dashboard com Failed and blocked only retesta apenas o que correu mal; os resultados do ciclo anterior são mantidos.
Sign-off antes da produção
Um ciclo de regressão termina como um UAT, com uma decisão, só que mais curta. Combine os critérios de saída uma vez, e use-os em todos os ciclos:
- Todos os casos de teste Must passaram.
- Nenhuma ocorrência Critical está aberta.
- Cada ocorrência High aberta tem uma solução alternativa que o negócio aceita, ou uma correção antes de a alteração chegar à produção.
O dono de cada processo dá o sign-off da sua parte: aceite, aceite com condições ou rejeitado. Numa release do Salesforce não pode travar a atualização, por isso uma rejeição significa uma correção ou uma solução alternativa antes da data de produção, e uma mensagem aos utilizadores. Numa alteração própria, uma rejeição significa que ela espera.
Guarde o resultado de cada ciclo. Ao fim de um ano tem um registo claro do que foi testado depois de cada alteração, e de quem o aceitou. Para saber como preparar a decisão, veja A decisão de go/no-go.
No UAT StudioUm ciclo de regressão é um projeto próprio, com a release como Release, para que o seu relatório de go/no-go diga de que release do CRM se trata. Os donos dos processos dão o sign-off por grupo, e o sign-off pertence a esse ciclo.
De uso gratuito
A checklist de UAT para um go-live de CRM também funciona para um ciclo de regressão, como arquivo Excel gratuito. Para cada plataforma, veja UAT para Salesforce e UAT para Dynamics 365.
Salesforce é uma marca comercial da Salesforce, Inc. Microsoft e Dynamics 365 são marcas comerciais do grupo de empresas Microsoft. O UAT Studio não é afiliado nem endossado pela Salesforce nem pela Microsoft.