Porque é que os testers do negócio precisam de outros casos de teste
Um teste de sistema é feito por pessoas que construíram o sistema ou o conhecem bem. Um teste de aceitação é feito por pessoas que o usam: conhecem o trabalho, não a configuração. Não sabem que campo é novo, que fluxo corre em segundo plano, nem o que o programador quis dizer.
Por isso, um caso de teste de UAT tem de funcionar para alguém que:
- conhece o processo de negócio de cor, mas não os novos ecrãs;
- tem algumas horas entre outro trabalho, não uma semana;
- nunca deveria ter de adivinhar se um passo passou ou falhou;
- vai parar e esperar quando um passo não é claro, e perder tempo.
Cada hora gasta em casos de teste claros poupa muitas horas nos dias de teste: menos perguntas, menos ocorrências que afinal são mal-entendidos, e resultados em que pode confiar no go/no-go.
A partir de user stories e processos
Os casos de teste vêm de dois sítios, e precisa de ambos.
User stories e os seus critérios de aceitação
Uma user story diz o que alguém quer fazer e porquê: Como comercial, quero converter um lead qualificado, para ficar com uma conta, um contacto e uma oportunidade. Os seus critérios de aceitação dizem quando está concluída. Cada critério de aceitação é candidato a um passo ou a um caso de teste.
Verifique a cobertura: cada user story do âmbito precisa de pelo menos um caso de teste. Uma story sem nenhum é uma lacuna, e as lacunas são encontradas em produção.
Processos de negócio, de ponta a ponta
As user stories são cortadas em partes pequenas para os programadores. O negócio trabalha em processos que atravessam muitas stories: lead to cash, quote to order, gestão de casos de suporte do email à resolução. Uma story pode passar sozinha enquanto o processo falha na passagem entre duas equipas.
Por isso, acrescente casos de teste de ponta a ponta que seguem um processo do início ao fim, entre funções: o comercial faz a proposta comercial, o gestor aprova-a, a encomenda segue para as finanças. Muitas vezes são estes os casos de teste mais importantes para o negócio.
No UAT StudioLeia as user stories do Jira ou do Azure DevOps no cartão User stories, e marque Only stories without test cases para ver as lacunas. Com o módulo AI test design, a IA propõe casos de teste a partir das suas stories ou de uma descrição de processo, também no modelo da sua própria empresa. Nada se torna caso de teste até que o aprove. Sem o módulo, Prepare with your own AI dá um prompt para colar na IA da sua empresa; os passos marcados com [CHECK] são pressupostos a verificar.
Um objetivo por caso de teste
Um caso de teste testa um cenário de negócio, com um objetivo. O seu título diz o que o tester consegue fazer, nas palavras do negócio:
- Converter um lead com uma conta existente
- Aprovar uma proposta comercial com um desconto acima de 20%
- Encaminhar um email de um cliente conhecido para a fila certa
Não Testar o objeto lead, nem Leads, oportunidades e propostas comerciais. Quando um caso de teste tem vários objetivos, uma falha bloqueia todos, e o resultado diz pouco: o que falhou, e o que ainda funciona?
Que tamanho tem um caso de teste?
Regra geral, um caso de teste tem entre três e quinze passos, e leva a um tester cinco a vinte minutos. Muito mais longo, e provavelmente tem mais de um objetivo: divida-o. Muito mais curto, e talvez pertença a um caso vizinho.
Os casos de teste de ponta a ponta são a exceção. Seguem um processo inteiro e podem ser mais longos. Mantenha-os, mas garanta que cada parte do processo tem também o seu próprio caso de teste mais curto, para que uma falha seja fácil de localizar.
Passos com um resultado esperado
Cada passo tem duas partes: uma ação (o que o tester faz) e um resultado esperado (o que deve acontecer). É o resultado esperado que torna um passo testável. Sem ele, o tester decide o que é suficientemente bom, e dois testers decidem de forma diferente.
Escreva a ação
- Uma ação por passo. Abra o lead e clique em Convert está bem; cinco cliques num passo não.
- Comece com um verbo: abra, clique, preencha, escolha, guarde.
- Use as etiquetas tal como aparecem no ecrã, a negrito ou entre aspas.
- Diga o quê, não como o sistema funciona por dentro. Guarde a proposta comercial, e não acione o fluxo de aprovação.
Escreva o resultado esperado
- Diga o que o tester vê: uma mensagem, um valor num campo, um novo item, um estado.
- Seja específico. A oportunidade está na fase Qualification, e não funciona.
- Indique o que não deve acontecer quando isso é relevante: Não é criada uma segunda conta.
- Para o que o sistema faz sozinho, diga onde procurar: O caso de suporte aparece na fila Benelux Support em menos de um minuto.
Dados de teste e funções
Dados de teste
Os testers perdem mais tempo à procura de dados do que em qualquer outra parte de um UAT. Ponha os dados no caso de teste sempre que forem relevantes: que cliente, que produto, que tabela de preços ou price book, que montante. Prepare esses dados no ambiente de teste antes do primeiro dia de teste.
- Use nomes que sejam claramente dados de teste, como Jansen Logistics (test).
- Dê a cada tester os seus próprios itens quando alteram dados, para que duas pessoas não editem a mesma oportunidade.
- Acrescente valores nos limites: um desconto logo abaixo e logo acima do limite, um campo obrigatório vazio.
- Não use dados pessoais reais de clientes quando puder evitá-lo.
Funções
Num CRM, o que uma pessoa pode ver e fazer depende da sua função: um profile e permission sets no Salesforce, security roles e uma business unit no Dynamics 365. Um UAT prova que cada função consegue fazer o seu trabalho, e apenas o seu trabalho. Por isso, cada caso de teste diz que função o testa, e o tester entra com um utilizador de teste que tem exatamente essa função.
Nunca teste com um administrador. Um administrador vê e pode fazer tudo, por isso os problemas que um UAT deveria encontrar ficam escondidos.
No UAT StudioCada passo tem uma ação, um resultado esperado e, opcionalmente, dados de teste. Cada tester recebe um Test role e uma Test account, mostrados no topo dos seus testes como Log in as …, e a função aparece junto ao seu nome em cada ocorrência que abre.
Prioridade e risco
Nunca há tempo suficiente para testar tudo igualmente bem. Marque cada caso de teste para que os importantes sejam testados primeiro, e concluídos mesmo quando o tempo acaba.
| Prioridade | O que significa | Exemplo |
|---|---|---|
| Must | Tem de funcionar no primeiro dia. Se falhar, o go-live está em risco. | Criar e enviar uma proposta comercial; encaminhar um caso de suporte para a fila certa. |
| Should | Importante, mas o negócio consegue viver com uma solução alternativa durante pouco tempo. | Um dashboard para o gestor comercial. |
| Could | Bom de ter. Testado quando houver tempo. | Uma vista de lista ordenada por região. |
Acrescente o risco ao lado: quanto custa se isto correr mal depois do go-live. Um preço errado numa fatura é risco alto; uma etiqueta errada num relatório é risco baixo. Dentro da mesma prioridade, os testers começam pelo risco alto.
Seja rigoroso com o Must. Quando metade dos casos de teste é Must, a etiqueta não significa nada: reserve-a para aquilo sem o qual o negócio não consegue trabalhar. Combine as prioridades com os donos dos processos: são eles que também decidem no go/no-go, onde os casos de teste Must que não passaram são os que mais contam.
No UAT StudioDefina Priority (Must, Should, Could) e Risk (High, Medium, Low) no editor ou numa coluna ao importar. Os valores de outras ferramentas também são lidos: Critical e High tornam-se Must, Medium e Normal Should, Low Could. Os testers veem primeiro os seus casos de teste Must, com o risco alto primeiro dentro de cada prioridade.
Um exemplo
Caso de teste 12: Aprovar uma proposta comercial com um desconto acima de 20%
Prioridade Must, risco High. User story CRM-118. Função: comercial (passos 1 a 3) e gestor comercial (passos 4 e 5).
| Passo | Action | Resultado esperado | Dados de teste |
|---|---|---|---|
| 1 | Abra a oportunidade e crie uma nova proposta comercial. | Abre-se uma proposta comercial, associada à oportunidade, com os seus produtos. | Oportunidade Jansen Logistics – Support |
| 2 | Defina o desconto como 25% e guarde. | A proposta comercial é guardada. Mostra o estado Needs approval. | Desconto 25% |
| 3 | Tente enviar a proposta comercial ao cliente. | Não é possível enviar. Uma mensagem indica que a proposta comercial precisa de aprovação. | |
| 4 | Entre como gestor comercial e abra o pedido de aprovação. | O pedido mostra a proposta comercial, o desconto e o comercial. | Utilizador de teste Sales manager Benelux |
| 5 | Aprove o pedido. | A proposta comercial mostra Approved, e o comercial recebe um email. |
Repare no que faz isto funcionar: um objetivo no título, uma ação por passo, um resultado esperado que um tester consegue verificar, os dados e a função indicados, e um unhappy path no passo 3. Acrescente um segundo caso de teste para um desconto abaixo do limite, que não deve precisar de aprovação.
Erros comuns
- Sem resultado esperado, ou funciona como esperado. O tester tem de adivinhar o que era esperado.
- Linguagem técnica. Nomes de campos da base de dados, nomes de objetos, ou verifique se o trigger dispara. Use as palavras do ecrã.
- Demasiados objetivos num caso de teste. Uma falha bloqueia o resto, e o resultado diz-lhe pouco.
- Só o happy path. Acrescente um campo obrigatório deixado vazio, um valor acima de um limite, uma pessoa que não deveria ver um item.
- Dados de teste em falta. Abra uma oportunidade: qual? Em que fase, com que produtos?
- Sem função. O tester usa a conta que tiver, muitas vezes uma com demasiados direitos.
- Copiado do teste de sistema. Escrito para programadores, com passos que os testers do negócio não conseguem seguir.
- Tudo é Must. Então nada é, e os testes importantes não são feitos primeiro.
- Escrito uma vez, nunca lido. Os scripts que ninguém verificou antes dos dias de teste estão cheios de etiquetas antigas e menus errados.
Peça a um key user que os reveja
Antes dos dias de teste, peça a um key user do negócio que leia os casos de teste e experimente dois ou três no ambiente de teste. Encontra o que quem os escreveu não consegue ver: um passo que pressupõe conhecimento, uma etiqueta que mudou, um processo que funciona de forma diferente noutro país.
Verifique ao mesmo tempo se cada user story do âmbito tem um caso de teste, se cada função do âmbito testa alguma coisa, e se os dados de teste existem. Depois guarde os casos de teste após o go-live: são o seu teste de regressão para a próxima release do CRM.
No UAT StudioImporte casos de teste do Excel, do Azure DevOps, do Jira com Xray ou Zephyr Scale, ou do TestRail, ou escreva-os no editor. A biblioteca de modelos, um módulo para todos os planos pagos, tem scripts prontos para Salesforce e Dynamics 365 para adaptar à sua própria configuração.
De uso gratuito
Para tudo o resto a organizar antes, durante e depois do UAT, veja a checklist de UAT para um go-live de CRM, também como arquivo Excel gratuito.