UAT para Salesforce: um guia prático

Quando precisa de um UAT no Salesforce

Um teste de aceitação responde a uma pergunta: o negócio consegue fazer o seu trabalho nesta versão do Salesforce? Quem faz o trabalho testa-o, com as suas próprias palavras, antes de chegar à produção. Precisa de um nestes momentos.

• Um go-live. O primeiro Sales Cloud ou Service Cloud, ou a migração a partir de outro CRM.
• Uma nova cloud ou uma grande alteração. Acrescentar o Service Cloud ao Sales Cloud, o CPQ, uma nova integração com o ERP, ou uma nova forma de encaminhar casos.
• Cada release do Salesforce. O Salesforce tem três releases por ano: Spring, Summer e Winter. A release Winter chega no outono e leva o número do ano seguinte. Cada release pode mudar o funcionamento da sua org, mesmo que não tenha alterado nada.
• 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, o Salesforce publica que instâncias estão na preview e o que fazer para manter lá uma sandbox. Verifique-o a tempo, porque um refresh pode pôr uma sandbox dentro ou fora da preview.

Um go-live precisa de um UAT completo. Uma release precisa de um teste de regressão mais curto dos processos mais importantes. Mais sobre isso em Depois do go-live.

A sandbox

Nunca teste em produção. O Salesforce tem quatro tipos de sandbox. Dois deles servem para um UAT.

Planeie o refresh

Um refresh substitui tudo na sandbox por uma nova cópia da produção. Cada tipo de sandbox tem um intervalo mínimo entre refreshes, e uma sandbox Full tem o mais longo. Por isso, planeie-o:

• Faça o refresh antes do UAT, nunca durante. Verifique quando a sandbox pode ter o próximo refresh.
• Faça o deploy da release na sandbox depois do refresh. O trabalho que só existia na sandbox desaparece.
• Execute os passos após um refresh: aponte as integrações e as named credentials para sistemas de teste, não para a produção, e desligue os jobs agendados que não devem correr.
• Verifique a email deliverability. Uma sandbox nova ou com refresh só envia emails de sistema. As respostas de web-to-lead, as aprovações e os emails de casos precisam de mais, mas uma sandbox Full contém os endereços de email reais dos seus contactos. Use endereços de teste antes de a abrir.

Dados de teste

Os testers perdem horas quando os dados não estão prontos. Prepare-os antes do primeiro dia de testes:

• Contas e contactos para cada tipo de cliente que testa, com o proprietário, a região e o tipo de registo certos.
• Produtos e tabelas de preços. Um produto precisa de um preço na tabela de preços padrão antes de poder estar noutra tabela de preços. Verifique se as tabelas de preços de cada equipa de vendas estão ativas.
• Itens em aberto para trabalhar: oportunidades em diferentes fases, casos em aberto, e casos perto de um marco se testar entitlements.
• Sem dados pessoais reais sempre que o possa evitar. Uma sandbox Full copia tudo, por isso mascare ou anonimize o que os testers não precisam de ver.

Utilizadores por perfil e permission set

Um UAT prova que cada função consegue fazer o seu trabalho, e só o seu trabalho. Crie um utilizador de teste para cada combinação de perfil, função e permission sets que testa, como um comercial, um diretor comercial e um agente de suporte. Cada tester recebe o seu próprio utilizador, para que duas pessoas nunca trabalhem com o mesmo utilizador ao mesmo tempo.

Após um refresh, o Salesforce acrescenta o nome da sandbox a cada nome de utilizador e .invalid ao endereço de email de cada utilizador. Defina o email de cada utilizador de teste para um endereço que o tester lê, ou as redefinições de palavra-passe e os emails de aprovação não chegam a ninguém.

Log in as permite a um administrador ver o Salesforce pelos olhos de outro utilizador. É uma boa forma de analisar um problema que um tester comunica. Para o teste em si, os testers usam o seu próprio utilizador de teste: é assim que se sabe que o perfil e os permission sets estão corretos.

O que dizer aos testers sobre a sandbox

• O endereço da sandbox. Contém o nome da sandbox, ou entram através de test.salesforce.com. A página de login normal do Salesforce abre a produção.
• O seu nome de utilizador, que termina com o nome da sandbox, e como recebem a palavra-passe.
• Que os dados são dados de teste: nada do que fazem chega a um cliente real, e nada do que veem está atualizado.
• A quem ligar quando não conseguem entrar, antes de perderem uma manhã.

No UAT StudioCada tester recebe um Test role e um Test account, mostrados no topo dos seus testes como Log in as …. As Notes for testers contêm o endereço da sandbox, as caixas de correio de teste e quem contactar.

Casos de teste a partir de user stories e processos

Comece pelos processos do negócio, não pelos objetos do Salesforce. Dois processos cobrem a maior parte de um UAT de Salesforce:

• Lead to cash. Um lead entra por web-to-lead, é atribuído e convertido. A oportunidade recebe produtos da tabela de preços, é feita e aprovada uma proposta, o negócio é ganho, e a encomenda ou o contrato passa para a equipa ou o sistema seguinte.
• Gestão de casos. Um caso entra por email-to-case ou pelo portal, é encaminhado para a fila ou o agente certo, segue o seu entitlement e os seus marcos, é resolvido com um artigo de conhecimento, escalado quando necessário, e fechado.

Divida cada processo em casos de teste com um cenário de negócio cada, como Converter um lead com uma conta existente. Depois verifique se cada user story no âmbito tem pelo menos um caso de teste.

Passos que os testers de negócio entendem

Escreva cada passo como uma ação e um resultado esperado, nas palavras do tester. Acrescente dados de teste quando importa. Um tester nunca deve ter de adivinhar se um passo passou.

Prioridade e risco

Nem todos os casos de teste são igualmente importantes. Marque cada um como Must, Should ou Could: Must é o que tem de funcionar no primeiro dia, como criar uma proposta ou encaminhar um caso. Acrescente o risco: quanto custa se isto falhar depois do go-live. Os testers começam por Must e risco alto, para que os testes importantes fiquem feitos mesmo quando o tempo acaba.

Acrescente também os unhappy paths: um campo obrigatório deixado vazio, um desconto acima do limite, um utilizador que não deveria ver um item.

No UAT StudioImporte os seus casos de teste do Excel com as colunas Priority e Risk, ou comece pelos scripts de Salesforce da biblioteca de modelos, um módulo para todos os planos pagos. Os testers veem primeiro os seus casos de teste Must.

Testers

Escolha pessoas que fazem o trabalho todos os dias: comerciais, agentes de suporte, e os seus gestores para aprovações, previsões e relatórios. Inclua testers de cada equipa e de cada país que usa o Salesforce, porque os seus processos e tabelas de preços são diferentes.

Quanto tempo

Peça o tempo por tester, não por equipa, e acorde-o com o respetivo gestor. Planeie os scripts para que cada tester saiba quanto há para fazer. Reserve tempo para retestes depois das correções. Testers que continuam a atender chamadas ou a visitar clientes não vão terminar.

Uma reunião de kick-off

Comece com um kick-off curto: porque é que o teste deles importa, como entrar na sandbox, como registar um resultado e como registar uma ocorrência. Deixe cada tester entrar uma vez durante o kick-off. A maioria dos problemas com utilizadores e palavras-passe aparece aí, não no dia de testes.

Um dia de testes ou uma semana

• Um dia de testes, numa sala ou numa chamada, dá foco e respostas rápidas. Adequa-se a um âmbito pequeno e a testers difíceis de libertar por mais tempo.
• Distribuído por uma semana, em blocos de algumas horas, deixa espaço para correções e retestes entre os blocos. Adequa-se a um go-live com muitos processos.

Em qualquer dos casos, marque uma hora para a triagem todos os dias.

Durante o UAT

Abrir ocorrências

Uma boa ocorrência pode ser corrigida sem reunião. Peça aos testers:

• O passo, o que esperavam e o que aconteceu em vez disso.
• Uma captura de ecrã da página.
• O link para o item. Está na barra de endereço do navegador e leva o programador diretamente à oportunidade ou ao caso onde algo falhou.
• O utilizador com que testaram, para que a equipa saiba que perfil e que permission sets foram usados.

No UAT StudioA extensão do navegador para Chrome e Edge mostra os testes num painel lateral ao lado do Salesforce. Um passo falhado leva consigo a captura de ecrã, o link para o item e as mensagens de erro da página. Uma ocorrência mostra o item como link, sandbox incluída.

Triagem

Analise as novas ocorrências todos os dias, com o negócio e a equipa de Salesforce em conjunto. Dê a cada uma uma gravidade e alguém que a corrija, e decida:

• Corrigir: um problema real, corrigido nesta release.
• Rejeitar: o Salesforce funciona como foi concebido, ou o teste estava errado.
• Pedido de alteração: um desejo, não um defeito. Vai para o backlog, não para esta release.

Reteste

Quando uma correção é instalada na sandbox, o tester que encontrou a ocorrência testa o passo de novo. Anote em que build foi feito cada reteste. Depois de uma correção grande, teste também de novo os processos à volta.

Estado diário

Envie todos os dias à direção do projeto um estado curto: o progresso face ao plano, as ocorrências abertas por gravidade, e o que bloqueia. Limite-se aos factos. Sem surpresas na reunião de go/no-go.

No UAT StudioA triagem decorre num ecrã partilhado com Fix, Reject e Change request. Ready for retest envia um email a quem faz o reteste. Um resumo diário por email, ou no Microsoft Teams, mostra os resultados e as ocorrências do dia anterior.

Sign-off e go/no-go

O UAT termina com uma decisão do negócio. Acorde os critérios de saída antes do primeiro dia de testes, para que ninguém discuta sobre eles no fim:

• Nenhuma ocorrência Critical está aberta.
• Todos os casos de teste Must passaram.
• Cada ocorrência High aberta tem uma solução de contorno ou uma data de correção que o negócio aceita.
• Cada caso de teste do âmbito tem um resultado.

Quem assina

O responsável de cada processo faz o sign-off, como o diretor comercial para o lead to cash e o responsável do apoio ao cliente para a gestão de casos. Escolhem: aceite, aceite com condições, ou rejeitado. Anote cada condição, com quem a cumpre e até quando. A direção do projeto decide então sobre o go-live.

O que entra no relatório

• O que estava no âmbito, e o que não foi testado.
• Os resultados por processo ou equipa, e por prioridade.
• A sandbox, a release e o build que foram testados.
• As ocorrências abertas por gravidade, com a decisão sobre cada uma.
• Os sign-offs, com as suas condições, e os riscos conhecidos para as primeiras semanas.

No UAT StudioSign-off por grupo: Accepted, Accepted with conditions ou Rejected. Por defeito, ninguém pode aceitar enquanto houver uma ocorrência Critical aberta. O relatório de go/no-go fica pronto em PDF ou em slides quando chega o último resultado.

Um ciclo de regressão para cada release do Salesforce

Depois do go-live, as releases continuam a chegar: três por ano. Cada uma pode mudar uma página, um flow ou uma permissão. Os seus casos de teste do UAT são o melhor teste de regressão que tem, porque descrevem exatamente o que o negócio aceitou.

• Guarde os casos de teste depois do go-live, com os seus passos, dados de teste e resultados esperados.
• Leia as release notes da próxima release, e verifique que funcionalidades são ativadas automaticamente para si.
• Verifique se a sua sandbox de UAT está na sandbox preview, e planeie o ciclo na janela da preview.
• Teste de novo os casos de teste Must, e Should se houver tempo, com alguns testers do negócio.
• Registe as ocorrências como no UAT, e corrija-as antes de a release chegar à produção.

No UAT StudioEscolha Salesforce como CRM do projeto. A página de projetos mostra então as próximas releases do Salesforce, com a data da sandbox preview, a data em produção e as release notes. Start a regression round copia os casos de teste que escolher: Must and Should, Only Must ou All test cases in scope.

De uso gratuito

Para tudo o que há a preparar antes, durante e depois do UAT, veja a checklist de UAT para um go-live de CRM, também como Excel gratuito. Para o que o UAT Studio faz num UAT de Salesforce, veja UAT para Salesforce.

Salesforce, Sales Cloud e Service Cloud são marcas comerciais da Salesforce, Inc. O UAT Studio não está associado à Salesforce nem é endossado por ela.