En liten kodeendring kan ha stor oppgjørsvirkning. En ny fraksjon, et annet desimaltegn eller et API-felt med endret betydning må behandles som en endring med test og godkjenning.
Gjør endringen etterprøvbar
| Del | Dokumentasjon |
|---|---|
| Før og etter | Hva endres i data eller beregning? |
| Berørte løp | Hvilke kunder, anlegg og perioder påvirkes? |
| Test | Normaltilfelle og minst ett avvik |
| Godkjenning | Fag, avtale og økonomi etter behov |
| Gjenoppretting | Hvordan stoppes eller rulles endringen tilbake? |
Anta at en leverandør endrer vekt fra tonn til kilogram uten å endre feltnavnet. En teknisk gyldig import kan da gi tusen ganger feil mengde. Et representativt testsett og en volumkontroll skal oppdage dette før fakturering.
Bevar oppsettet som forklarer historikken
Lagre versjon av feltkobling og beregningsregler som ble brukt i hver kjøring. Da kan en gammel faktura fortsatt forklares etter at dagens oppsett er endret.
Avklar med leverandøren hvordan endringer varsles og hvor lenge gammelt grensesnitt fungerer. Kritiske oppdateringer trenger en driftsplan, ikke bare en e-post som ingen har ansvar for å lese.
Se akseptansetest og støtte og overlevering.
Bruk et representativt kontrollsett
Behold et sett med normalleveranser, korreksjoner og avvisninger som har dokumentert forventet resultat. Når feltkobling eller beregning endres, kjøres settet på nytt i testmiljø. Sammenlign ikke bare om programmet kjører, men om kunde, periode, enhet og beløp fortsatt er riktig.
For en produksjonsendring bør ansvarlig kunne vise når ny versjon begynte å gjelde. Hvis et gammelt oppgjør må gjenskapes, må det være kjent hvilket oppsett som ble brukt den gangen.
Ved tilbakeføring skal også dataendringer vurderes. Å rulle tilbake programkode fjerner ikke nødvendigvis fakturaer eller føringer som allerede er laget. Avtal derfor hvordan berørte hendelser identifiseres og korrigeres med økonomisk sporbarhet.