Salesforce UAT: en praktisk guide

När du behöver en UAT i Salesforce

Ett acceptanstest besvarar en fråga: kan verksamheten göra sitt arbete i den här versionen av Salesforce? De som gör arbetet testar det, med sina egna ord, innan det når produktion. Du behöver ett vid de här tillfällena.

• En go-live. Det första Sales Cloud eller Service Cloud, eller en flytt från ett annat CRM.
• Ett nytt moln eller en stor ändring. Service Cloud bredvid Sales Cloud, CPQ, en ny integration med affärssystemet (ERP) eller ett nytt sätt att dirigera kundärenden.
• Varje Salesforce-release. Salesforce har tre releaser om året: Spring, Summer och Winter. Winter-releasen kommer på hösten och har nästa års nummer. Varje release kan ändra hur din org fungerar, även om du inte själv har ändrat något.
• Sandbox preview. Sandboxar på en preview-instans får den nya releasen några veckor före produktion. Det är ditt fönster för att testa. Före varje release publicerar Salesforce vilka instanser som ingår i preview och vad du ska göra för att behålla en sandbox där. Kontrollera det i tid, eftersom en refresh kan flytta en sandbox in i eller ut ur preview.

En go-live kräver en fullständig UAT. En release kräver ett kortare regressionstest av de processer som betyder mest. Mer om det under Efter go-live.

Sandboxen

Testa aldrig i produktion. Salesforce har fyra typer av sandbox. Två av dem passar för en UAT.

Planera din refresh

En refresh ersätter allt i sandboxen med en ny kopia av produktion. Varje sandboxtyp har en minsta tid mellan två refresh, och en Full sandbox har den längsta. Planera det därför:

• Gör en refresh före UAT:n, aldrig under den. Kontrollera när sandboxen kan få nästa refresh.
• Driftsätt releasen i sandboxen efter din refresh. Arbete som bara fanns i sandboxen är borta.
• Gör stegen efter en refresh: peka integrationer och named credentials mot testsystem, inte mot produktion, och stäng av schemalagda jobb som inte ska köras.
• Kontrollera e-postleveransen. En ny eller uppdaterad sandbox skickar bara systemmejl. Svar via web-to-lead, godkännanden och mejl för kundärenden kräver mer, men en Full sandbox innehåller dina kontakters riktiga e-postadresser. Använd testadresser innan du öppnar upp den.

Testdata

Testare förlorar timmar när data inte är klara. Förbered dem före den första testdagen:

• Konton och kontakter för varje typ av kund du testar, med rätt ägare, region och posttyp.
• Produkter och prisböcker. En produkt behöver ett pris i standardprisboken innan den kan finnas i en annan prisbok. Kontrollera att varje säljteams prisböcker är aktiva.
• Öppna poster att arbeta med: affärsmöjligheter i olika steg, öppna kundärenden, och kundärenden nära en milstolpe om du testar entitlements.
• Inga riktiga personuppgifter där du kan undvika det. En Full sandbox kopierar allt, så maskera eller anonymisera det som testarna inte behöver se.

Användare per profil och permission set

En UAT visar att varje roll kan göra sitt arbete, och bara sitt arbete. Skapa en testanvändare för varje kombination av profil, roll och permission sets som du testar, till exempel en säljare, en säljchef och en servicehandläggare. Varje testare får en egen användare, så att två personer aldrig arbetar i samma användare samtidigt.

Efter en refresh lägger Salesforce till sandboxens namn i varje användarnamn och .invalid i varje användares e-postadress. Ange en adress som testaren läser som e-post för varje testanvändare, annars hamnar mejl om lösenordsåterställning och godkännanden ingenstans.

Med Log in as kan en administratör se Salesforce genom en annan användares ögon. Det är ett bra sätt att titta på ett problem som en testare rapporterar. Under själva testet använder testarna sin egen testanvändare: så vet du att profilen och permission sets stämmer.

Vad du ska berätta för testarna om sandboxen

• Sandboxens adress. Den innehåller sandboxens namn, eller så loggar de in via test.salesforce.com. Salesforces vanliga inloggningssida öppnar produktion.
• Deras användarnamn, som slutar med sandboxens namn, och hur de får sitt lösenord.
• Att data är testdata: inget de gör når en riktig kund, och inget de ser är aktuellt.
• Vem de ska ringa när de inte kan logga in, innan de förlorar en förmiddag.

I UAT StudioVarje testare får en Test role och ett Test account, som visas överst i deras tester som Log in as …. Notes for testers innehåller sandboxens adress, testbrevlådor och vem man ska ringa.

Testfall från user stories och processer

Utgå från verksamhetens processer, inte från objekten i Salesforce. Två processer täcker det mesta av en Salesforce-UAT:

• Lead to cash. En lead kommer in via web-to-lead, tilldelas och konverteras. Affärsmöjligheten får produkter från prisboken, en offert tas fram och godkänns, affären vinns, och ordern eller avtalet går vidare till nästa team eller system.
• Ärendehantering. Ett kundärende kommer in via email-to-case eller portalen, dirigeras till rätt kö eller handläggare, följer sitt entitlement och sina milstolpar, löses med en kunskapsartikel, eskaleras vid behov och stängs.

Dela upp varje process i testfall med ett affärsscenario vardera, till exempel Konvertera en lead med ett befintligt konto. Kontrollera sedan att varje user story i omfattningen har minst ett testfall.

Steg som verksamhetstestare förstår

Skriv varje steg som en åtgärd och ett förväntat resultat, med testarens ord. Lägg till testdata där det spelar roll. En testare ska aldrig behöva gissa om ett steg gick igenom.

Prioritet och risk

Alla testfall är inte lika viktiga. Märk vart och ett med Must, Should eller Could: Must är det som måste fungera från dag ett, till exempel att skapa en offert eller dirigera ett kundärende. Lägg till risken: vad det kostar om det går fel efter go-live. Testarna börjar med Must och hög risk, så att de viktiga testerna blir gjorda även när tiden tar slut.

Lägg också till de olyckliga vägarna: ett obligatoriskt fält som lämnas tomt, en rabatt över gränsen, en användare som inte ska se en post.

I UAT StudioImportera dina testfall från Excel med kolumnerna Priority och Risk, eller börja från Salesforce-skripten i mallbiblioteket, ett tillägg till alla betalda paket. Testarna ser sina Must-testfall först.

Testare

Välj personer som gör arbetet varje dag: säljare, servicehandläggare och deras chefer för godkännanden, prognoser och rapporter. Ta testare från varje team och land som använder Salesforce, eftersom deras processer och prisböcker skiljer sig åt.

Hur mycket tid

Be om tiden per testare, inte per team, och få den godkänd av deras chef. Planera skripten så att varje testare vet hur mycket det finns att göra. Spara tid för omtester efter rättningarna. Testare som samtidigt tar samtal eller besöker kunder blir inte klara.

En kick-off

Börja med en kort kick-off: varför deras test spelar roll, hur de loggar in i sandboxen, hur de registrerar ett resultat och hur de registrerar ett ärende. Låt varje testare logga in en gång under kick-offen. De flesta problem med användare och lösenord dyker upp där, inte på testdagen.

En testdag eller en vecka

• En testdag, i ett rum eller ett samtal, ger fokus och snabba svar. Det passar en liten omfattning och testare som är svåra att frigöra längre.
• Utspritt över en vecka, i block på några timmar, ger utrymme för rättningar och omtester mellan blocken. Det passar en go-live med många processer.

Hur du än gör: bestäm en tid för triagen varje dag.

Under UAT:n

Registrera ärenden

Ett bra ärende kan åtgärdas utan ett möte. Be testarna om:

• Steget, vad de förväntade sig och vad som hände i stället.
• En skärmbild av sidan.
• Länken till posten. Den finns i webbläsarens adressfält och tar utvecklaren direkt till affärsmöjligheten eller kundärendet där det gick fel.
• Användaren de testade med, så att teamet vet vilken profil och vilka permission sets som användes.

I UAT StudioWebbläsartillägget för Chrome och Edge visar testerna i en sidopanel bredvid Salesforce. Ett misslyckat steg tar med skärmbilden, länken till posten och sidans felmeddelanden. Ett ärende visar posten som en länk, inklusive sandboxen.

Triage

Gå igenom de nya ärendena varje dag, med verksamheten och Salesforce-teamet tillsammans. Ge vart och ett en allvarlighetsgrad och någon som åtgärdar det, och besluta:

• Fix: ett verkligt problem, som åtgärdas i den här releasen.
• Reject: Salesforce fungerar som det är tänkt, eller så var testet fel.
• Change request: ett önskemål, inte ett fel. Det går till backloggen, inte in i den här releasen.

Omtest

När en rättning har driftsatts i sandboxen testar testaren som hittade ärendet steget igen. Skriv upp vilken build varje omtest gjordes på. Efter en stor rättning testar du också processerna runt omkring igen.

Daglig status

Skicka en kort status till styrgruppen varje dag: framsteg mot planen, öppna ärenden efter allvarlighetsgrad och vad som blockerar. Håll dig till fakta. Inga överraskningar på go/no-go-mötet.

I UAT StudioTriagen körs på en delad skärm med Fix, Reject och Change request. Ready for retest mejlar den som ska testa om. En daglig översikt via e-post, eller i Microsoft Teams, visar resultaten och ärendena från dagen innan.

Godkännande och go/no-go

UAT:n avslutas med ett beslut av verksamheten. Kom överens om slutkriterierna före den första testdagen, så att ingen bråkar om dem i slutet:

• Inget Critical-ärende är öppet.
• Alla Must-testfall har gått igenom.
• Varje öppet High-ärende har en tillfällig lösning eller ett datum för rättningen som verksamheten accepterar.
• Varje testfall som ingår har ett resultat.

Vem som skriver under

Ägaren till varje process ger sitt godkännande, till exempel försäljningsdirektören för lead to cash och chefen för kundservice för ärendehantering. De väljer: godkänt, godkänt med villkor eller avvisat. Skriv upp varje villkor, med vem som gör det och när. Styrgruppen beslutar sedan om go-live.

Vad som ska stå i rapporten

• Vad som ingick i omfattningen, och vad som inte testades.
• Resultaten per process eller team, och per prioritet.
• Sandboxen, releasen och den build som testades.
• De öppna ärendena efter allvarlighetsgrad, med beslutet för vart och ett.
• Godkännandena, med deras villkor, och de kända riskerna för de första veckorna.

I UAT StudioGodkännande per grupp: Accepted, Accepted with conditions eller Rejected. Som standard kan ingen godkänna medan ett Critical-ärende är öppet. Go/no-go-rapporten är klar som PDF eller som bilder när det sista resultatet har kommit in.

En regressionsrunda för varje Salesforce-release

Efter go-live fortsätter releaserna att komma: tre om året. Var och en kan ändra en sida, ett flow eller en behörighet. Dina UAT-testfall är det bästa regressionstest du har, eftersom de beskriver exakt vad verksamheten har godkänt.

• Behåll testfallen efter go-live, med deras steg, testdata och förväntade resultat.
• Läs release notes för den kommande releasen, och kontrollera vilka funktioner som slås på automatiskt för dig.
• Kontrollera att din UAT-sandbox ingår i sandbox preview, och planera rundan i preview-fönstret.
• Testa Must-testfallen igen, och Should om det finns tid, med några testare från verksamheten.
• Registrera ärenden som i UAT:n, och åtgärda dem innan releasen når produktion.

I UAT StudioVälj Salesforce som projektets CRM. Projektsidan visar då de kommande Salesforce-releaserna, med datum för sandbox preview, datum för produktion och release notes. Start a regression round kopierar de testfall du väljer: Must and Should, Only Must eller All test cases in scope.

Gratis att använda

För allt som ska ordnas före, under och efter UAT:n, se UAT-checklistan för en CRM-go-live, även som en gratis Excel-fil. För vad UAT Studio gör för en Salesforce-UAT, se Salesforce UAT.

Salesforce, Sales Cloud och Service Cloud är varumärken som tillhör Salesforce, Inc. UAT Studio är inte anknutet till eller godkänt av Salesforce.