När rätt lön blir ett facit

En förändring i en lönemotor ska lösa ett problem – inte skapa tre nya någon annanstans.

Det låter självklart. Men ju större ett regelverk blir, desto svårare blir det att veta vilka konsekvenser en förändring faktiskt får.

Säg till exempel att vi förändrar hur innevarande semester beräknas. Då behöver vi naturligtvis kontrollera att den nya semesterberäkningen blir rätt.

Men det räcker inte.

Samma förändring kan också påverka en deltidsanställd, någon som varit frånvarande under en del av månaden, en person som bytt sysselsättningsgrad eller en helt annan löneart som använder samma underliggande funktion.

Den svåra frågan är därför inte bara:

”Blev den nya regeln rätt?”

Utan också:

”Är allt som redan var rätt fortfarande rätt?”

Sparade löneberäkningar som facit

I WORC använder jag testcase för att hantera just det problemet.

När en löneberäkning är kontrollerad och jag vet att resultatet är korrekt kan den sparas som ett testcase.

Det innebär i praktiken att jag sparar ett facit för hur lönemotorn ska tolka en viss situation.

När jag senare förändrar regler, funktioner eller beräkningslogik kan jag köra de sparade fallen igen och jämföra resultatet med det tidigare facit.

Om resultatet plötsligt förändras blir det synligt.

Det betyder inte automatiskt att den nya beräkningen är fel.

Ibland har jag ändrat en regel just för att resultatet ska bli annorlunda. Då behöver även facit förändras.

Det viktiga är att förändringen inte sker obemärkt.

Jag vill veta vad som förändrades, varför det förändrades och om förändringen var avsedd.

Ju mer motorn utvecklas, desto viktigare blir historiken

Det fina är att testcasebiblioteket blir mer värdefullt över tid.

Varje verifierad situation kan bli ytterligare ett facit: olika anställningsformer, frånvaro, semester, deltider, förändrade sysselsättningsgrader och kombinationer som man kanske inte tänker på när nästa funktion byggs.

På så sätt behöver jag inte försöka komma ihåg och manuellt återskapa varje gammal situation varje gång någonting förändras i lönemotorn.

De situationer som redan har konstaterats fungera finns kvar och kan kontrolleras igen.

För mig är det en ganska viktig del av hur man bygger en lönemotor som ska kunna fortsätta utvecklas utan att osäkerheten växer i samma takt som funktionaliteten.

Komplexiteten försvinner inte.

Men den går att göra kontrollerbar.

Rätt lön ska inte bara kunna räknas fram. Den ska kunna förklaras.