Regressionstest efter en CRM-release

Varför ett CRM behöver regressionstest

Efter go-live fortsätter ditt CRM att förändras, även när ditt eget team inte ändrar något. Salesforce och Microsoft uppdaterar plattformen för varje kund. De flesta ändringar är förbättringar. Vissa ändrar en sida, en standardinställning eller hur en funktion fungerar, och då och då förstör en något som din verksamhet är beroende av.

Ett regressionstest besvarar en fråga: fungerar det som verksamheten godkände vid go-live fortfarande? Det är ingen ny UAT. Det är en kort, fokuserad kontroll av de processer som betyder mest, gjord innan ändringen når dina användare, av personer som kan arbetet.

Dina egna releaser behöver samma kontroll. En ny integration, ett nytt fält på offerten, en ändring i dirigeringen av ärenden: var och en kan påverka något som fungerade tidigare.

Salesforce: tre releaser per år

Salesforce har tre större releaser per år: Spring, Summer och Winter. Winter-releasen kommer på hösten och bär numret för nästa år. Varje org uppgraderas, på datum som Salesforce publicerar i förväg.

• Förhandsversionen i sandbox. 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 meddelar Salesforce vilka instanser som ingår i förhandsversionen och vad du ska göra för att behålla en sandbox där. En refresh kan flytta en sandbox in i eller ut ur förhandsversionen, så kontrollera det i tid.
• Releaseanteckningarna. Läs dem för de clouds och funktioner som du använder. Leta efter det som slås på automatiskt för dig, och det som ändrar utseendet på sidor som dina användare arbetar i.
• Release updates. Vissa ändringar aviseras i Setup med ett datum då de tillämpas. Testa dem i sandboxen före det datumet, så att de inte överraskar dig i produktion.

För Salesforce är rytmen alltså given: en regressionsrunda i förhandsversionens fönster för varje release, tre gånger per år.

I UAT StudioVälj Salesforce som projektets CRM. Från ungefär två månader före en release visar projektsidan Coming CRM releases, med datum för förhandsversionen i sandbox, datum för produktion och en länk till releaseanteckningarna. Salesforce kan fortfarande flytta dessa datum, så kontrollera releaseanteckningarna.

Dynamics 365: uppdateringar hela året

Microsoft samlar inte längre ändringarna i Dynamics 365 i två release waves per år. Nya funktioner och ändringar rullas ut hela året. Releaseplanerna arkiverades i oktober 2026; det som kommer finns nu i Microsofts roadmap på aka.ms/AIatWorkRoadmap.

Det betyder att det inte längre finns ett stort tillfälle per år att planera testningen kring. Ändringar kommer i mindre steg, oftare. Att vänta på en stor release fungerar inte längre, och att testa efter varje enskild ändring är för mycket.

Välj en fast rytm

Svaret är en regressionsrunda med en fast rytm, oavsett vad Microsoft släpper däremellan:

• Varje månad när CRM:et är centralt för verksamheten, du använder många appar och funktioner, eller ofta slår på nya funktioner.
• Varje kvartal för en stabil konfiguration med få egna ändringar.
• En extra runda innan en egen ändring går live, eller när en ändring från Microsoft tydligt berör någon av dina nyckelprocesser.

Lägg in datumen i testarnas kalender för hela året. En fast rytm är lättare att hålla än en runda som planeras varje gång något dyker upp.

Före varje runda

• Läs Microsofts roadmap och meddelandena till dina administratörer i Microsoft 365 administrationscenter, och notera vilka ändringar som berör dina processer.
• Prova funktioner i förhandsversion i en sandbox-miljö först, innan de når dina användare.
• Se till att sandboxen du testar i har samma version och samma lösningar som produktion.

I UAT StudioVälj Dynamics 365 som projektets CRM, och starta varje runda med Start a regression round, från projektet för din go-live eller din senaste runda.

I UAT StudioVälj under Setup vid Check the Dynamics 365 updates: Every quarter eller Every month. Projektsidan visar då den aktuella perioden med en länk till roadmapen, och admins får ett e-postmeddelande per period, två veckor innan den börjar.

Välja vad som ska testas om

En regressionsrunda är inte rätt tillfälle att testa allt igen. Välj, i den här ordningen:

1. Must-testfallen. Det som måste fungera varje dag: skapa en offert, konvertera ett lead, dirigera ett ärende, godkännandena. Testa dem varje runda.
2. Det som ändringen berör. Läs releaseanteckningarna eller roadmapen med listan över dina processer bredvid. En ändring av offerter betyder offerttestfallen, även Should- och Could-testfallen.
3. Integrationer och automatisering. Kopplingarna till affärssystemet, webbplatsen eller e-posten, och flödena som körs i bakgrunden. De går sönder i det tysta, så testa dem medvetet.
4. Should-testfallen, när det finns tid.

Titta sedan på vad ditt eget team har ändrat sedan förra rundan. Allt som ditt team har byggt självt och som ingen har testat tillsammans med plattformsändringen hör också hemma i rundan.

Håll en kort lista över det som är kritiskt

Skriv ner, en gång, de tio till tjugo processer som verksamheten inte klarar sig utan en enda dag. De är kärnan i varje regressionsrunda. Gå igenom listan varje halvår med processägarna, och efter varje stor egen ändring.

I UAT StudioMed tillägget Release readiness visar Review the release vilka av dina testfall en Salesforce-release eller Dynamics 365-uppdatering berör, med skälet, föreslår testfall för det som inte är täckt än och listar de obligatoriska uppdateringarna med sina datum. Regressionsrundan får då exakt Must-testfallen, de berörda du behåller och de nya du godkänner. Ett fail i rundan säger vilken ändring det kom med. €99 per månad: lägg till det under Plan & billing.

Återanvänd dina testfall

Det bästa regressionstestet du har är uppsättningen testfall från din go-live-UAT. De beskriver exakt vad verksamheten godkände, med stegen, testdata och de förväntade resultaten. Skriv inte nya för varje runda.

• Spara testfallen efter go-live, på ett ställe, med deras prioritet.
• Uppdatera dem när din egen process ändras, så att nästa runda testar CRM:et som det är nu, inte som det var vid go-live.
• Kontrollera testdata före varje runda. En refresh av sandboxen eller en kopia av produktion kan ta bort eller ändra de poster som testfallen använder.
• Lägg till ett testfall för varje allvarligt ärende som hittas i produktion, så att det upptäcks nästa gång.

Testfall som verksamhetstestare kan följa är värda mödan här: de återanvänds om och om igen. Se Skriva testfall som verksamhetstestare förstår.

I UAT StudioStart a regression round kopierar testfallen från projektet du utgår från, med deras steg, testdata och förväntade resultat. Välj vilka som följer med: Must and Should, Only Must eller All test cases in scope; ett testfall utan prioritet räknas som Should. Det nya projektet får grupperna och inställningarna, och du bjuder in testarna under Setup. Inget hittas på eller ändras.

Vem som testar, och hur länge

Vem

En regressionsrunda behöver färre personer än en UAT, men de bör ändå komma från verksamheten. Be en eller två nyckelanvändare per process: personer som gör arbetet varje dag och direkt märker när något är fel. CRM-administratören förbereder rundan och testar det som körs i bakgrunden, men bör inte vara den enda testaren.

Låt samma personer testa runda efter runda. De blir snabbare, och de märker små ändringar som en ny testare skulle missa.

Hur länge

• Förberedelse: en dag eller två för att läsa ändringarna, välja testfallen och kontrollera testdata.
• Testning: några timmar per testare, fördelat över en eller två dagar för en månatlig runda, upp till en vecka för en Salesforce-release med många ändringar.
• Rättningar och omtester: avsätt några dagar innan ändringen når produktion, för de ärenden du hittar.

För Salesforce måste det rymmas i förhandsversionens fönster. Börja tidigt i fönstret, inte den sista veckan.

Registrera det du hittar

Registrera ärenden som i UAT:n: steget, vad du förväntade dig, vad som hände i stället, en skärmbild och länken till posten. Gör triage på dem varje dag med CRM-teamet. För ett ärende som orsakas av plattformen, titta först i releaseanteckningarna eller roadmapen: ofta är det en känd ändring med en inställning att justera.

I UAT StudioVarje runda sparar sin release, build och miljö, så att go/no-go-rapporten säger vad som testades. Efter rättningarna testar Start round 2 på dashboarden med Failed and blocked only om bara det som gick fel; resultaten från den tidigare rundan sparas.

Godkännande före produktion

En regressionsrunda slutar som en UAT, med ett beslut, bara kortare. Kom överens om slutkriterierna en gång, och använd dem varje runda:

• Alla Must-testfall har gått igenom.
• Inget Critical-ärende är öppet.
• Varje öppet High-ärende har en tillfällig lösning som verksamheten accepterar, eller en rättning innan ändringen når produktion.

Ägaren till varje process godkänner sin del: accepterat, accepterat med villkor eller avvisat. För en Salesforce-release kan du inte stoppa uppgraderingen, så ett avvisande betyder en rättning eller en tillfällig lösning före produktionsdatumet, och ett meddelande till användarna. För en egen ändring betyder ett avvisande att den får vänta.

Spara resultatet av varje runda. Efter ett år har du en tydlig dokumentation av vad som testades efter varje ändring, och vem som godkände det. För hur du förbereder beslutet, se Go/no-go-beslutet.

I UAT StudioEn regressionsrunda är ett eget projekt, med releasen som dess Release, så att dess go/no-go-rapport säger vilken CRM-release den gäller. Processägarna godkänner per grupp, och godkännandet hör till den rundan.

Gratis att använda

UAT-checklistan för en CRM-go-live fungerar också för en regressionsrunda, som en gratis Excel-fil. För varje plattform, se Salesforce UAT och Dynamics 365 UAT.

Salesforce är ett varumärke som tillhör Salesforce, Inc. Microsoft och Dynamics 365 är varumärken som tillhör Microsoft-koncernen. UAT Studio är inte anknutet till eller godkänt av Salesforce eller Microsoft.