Vikten av prestandatester kan kännas överdriven när man köper en SaaS tjänst så som Dynamics 365 for Finance & Operations (D365FO). I och med att Microsoft ansvarar för driften och att lösningen ligger i Azure som i sin tur har stöd för ”auto-scaling” borde väl detta vara standard? Det kan man tycka men så är inte fallet. Antaganden så som ”skalar inte lösningen per automatik i takt med att min affär växer…” är en vanliga kommentarer man stöter på när vi pratar med våra kunder. Dock är detta långt ifrån sanningen och jag vill istället mena på att prestandatester aldrig varit viktigare och därmed bör vara en naturligt del i varje ERP implementation av D365FO.

Låt mig förklara detta närmare genom att belysa fyra fundamentala frågeställningar:

Untitled picture

Varför utföra prestandatester?

Det finns många svar på denna fråga. Några av dem är att Microsoft inte tillhandahåller några prestanda bechmarking- siffror för D365FO. Istället dimensioneras respektive miljö baserat på en estimering av förväntade transaktionsvolymer. Det finns således inget ”facit”. En annan anledning är att en ERP implementation normalt sätt inte bara består av ett affärssystem utan man har även en integrationsplattform samt ett antal kringliggande system där man utbyter information via integrationer. Även om prestandan i affärssystemet är god kan det finnas flaskhalsar i integrationslagret eller i det externa systemet vilket i slutändan påverkar användarupplevelsen och är något man kan identifiera under prestandatestet. Vidare så kan dålig prestanda även vara ett resultat av dåligt skrivna anpassningar eller partnerlösningar som integrerats med standardprodukten. I grund och botten handlar det om att riskminimera inför en go-live genom att fånga upp prestandaproblem så tidigt så möjlig för att kunna åtgärda problem innan en go-live. Prestandatesterna bör även kunna gå att spåra tillbaka till den effekthämtagning man definierat som målet för hela projektet. Någonstans vill man rimligtvis bli mer produktiv vilket i sin tur är baserat på ett system med rimliga svarstider.

Vad skall jag prestandatesta?

Utgå från dina befintliga testfall, identifiera nyckeflöden som ”kandidater” för dina prestandatester. Tänk på att inkludera olika beröringspunkter med systemet så som användargränssnittet, batchjobb, rapporter och integrationer. Just vad gäller integrationer är det viktigt att se över samtliga integrationspunkter i syfte att identifiera integrationer som potentiellt kan innehålla stora datavolymer alternativt höga frekvenser. Dessa bör inkluderas i prestandatesterna. Definiera ”entry”- och ”exit” värden för dina prestandatester för att tydligt kunna definiera dem som godkända eller ej. Vad noga med att ta höjd för toppar i dina transaktioner. Exempelvis vilken timme, på vilken dag, under ett helt år kommer man att sälja absolut mest? Använd denna siffra som utgångspunkt för ditt prestandatest. Börja med enklare tester, lägg därefter på ytterligare volymen och avsluta med ”a day in life” där ett antal flöden testas parallellt.

Var bör prestandatester ske?

För att maximera värdet av prestandatesterna så bör de ske i en miljö som är så produktionslik så möjligt. Detta är inte en ”one-box”- DEV miljö vilket kör SQL Server och alltså inte Azure SQL vilket innebär att topologi:n kommer att skilja sig mot produktionsmiljön. Rekommendationen är att alltid genomföra prestandatester i någon av Tier-2 till Tier-5 miljöerna beroende på vilka datavolymer man tror sig ha.

När skall jag utföra mina prestandatester?

Det enkla svaret på denna fråga är att prestandatester skall vara en naturlig del av varje implementationsprojekt och skall således påbörjas redan i analysfasen. Förberedelser kan sedan fortgå under designfasen för att lämna utrymma till själva prestandatesterna under själva testfasen. Viktigt att man skapar utrymme för prestandatester innan go-live för att under kontrollerade former kunna analysera avvikelser samt ha tid att implementera lämpliga åtgärder.

Hör av er till oss på Acando om ni vill veta mer kring prestandatester för Dynamics 365.

/Tobias Lång

Dynamics 365 Chief Solution Architect @ Acando