Større omskrivning eller ny arkitektur

En omskrivning af produktet eller et skift til en ny arkitektur gør noget, en almindelig release ikke gør: den udskifter det fundament, som den seneste pentest byggede sine konklusioner på. Brugerfladen kan se ens ud, men login, adskillelsen mellem kunderne og vejen fra brugerens klik til databasen er nye, og så beskriver den gamle rapport reelt et andet system.

Konsekvensen for et softwarehus er ikke kun teknisk. Kunderne har modtaget rapporten, svaret i deres spørgeskemaer bygger på den, og nogle kontrakter henviser måske til den. Når fundamentet skiftes, skal både testen og kommunikationen planlægges.

Hvorfor den gamle rapport mister sin værdi

En pentest beskriver produktet, som det så ud i testperioden. Den britiske NCSC skriver, at en test kun kan vise, at systemerne ikke var sårbare over for kendte problemer på dagen for testen. Ved en almindelig release er spørgsmålet, hvor meget af det testede der er ændret. Ved en ny arkitektur er svaret ofte: det meste af det, der betyder noget.

Eksempler er en monolit, der deles op i mange mindre tjenester, et skift fra én database pr. kunde til en fælles database, en ny måde at håndtere login på, eller en flytning fra egne servere til en cloudplatform. I alle tilfælde er de mekanismer, der holder kunderne adskilt og styrer adgangen, bygget om. → Multi-tenant: test af adskillelsen

Det betyder ikke, at den gamle rapport er værdiløs. Den viser, at I har testet før, og hvordan I håndterede fundene. Men den kan ikke længere bruges som dokumentation for det produkt, kunderne bruger efter skiftet. → Hvilke ændringer kræver en ny test?

Planlæg testen sammen med omlægningen

En omlægning sker ikke nødvendigvis på én dag. Gammel og ny arkitektur kan køre side om side i en periode, og kunderne flyttes gradvist. Det giver mulighed for at lægge testen klogt:

Før de første kunder flyttes · test den nye arkitektur i et miljø, der svarer til det, kunderne skal over på, så fund kan rettes, før de første data ligger der.
Når flytningen er afsluttet · vurder, om der er kommet ændringer undervejs, som testen ikke dækkede, og om en supplerende test er nødvendig.
Når den gamle arkitektur lukkes · sørg for, at gamle adgange, kopier af data og forbindelser mellem de to verdener er fjernet.

Det første punkt er det vigtigste. En ny arkitektur, der testes efter, at kunderne er flyttet, kan kun give et svar bagud. Lav derfor en plan, hvor testens tidspunkt følger flytningen af kunderne og ikke omvendt. Rykker flytningen, rykker testen med, og hvis den nye arkitektur ændres væsentligt mellem testen og den første flytning, skal det vurderes, om testen stadig dækker det, kunderne flytter over på.

Arkitekturen kan også flytte grænsen til det, der ellers hører under driften: platformen, netværket og de tjenester, produktet hviler på. Hvor meget af den del der skal med i en test af produktet, er beskrevet for sig. → Infrastrukturen bag produktet

Hvad testen skal have fokus på

En test af en ny arkitektur er en fuld test af produktet, ikke en afgrænset test af det nye. Men den kan med fordel lægge vægt på de steder, hvor omlægningen har ændret mest:

Adskillelsen mellem kunderne · især hvis datamodellen er ændret.
Login og sessioner · især hvis der er kommet en ny løsning til identitet.
Kommunikationen mellem dele · når én applikation er blevet til flere tjenester, er der nye forbindelser, som ikke fandtes før.
API’et · nye tjenester kan have nye kald, og gamle kald kan være genskabt med en anden logik.
Overgangen · midlertidige løsninger, der skal få gammel og ny arkitektur til at tale sammen.

Fortæl testeren, hvad der er nyt, og hvad der er overført uændret. Det hjælper testeren til at bruge tiden, hvor risikoen er størst. → Testens omfang for et SaaS-produkt

Kommunikationen til kunderne

Kunder, der har den gamle rapport, bør ikke blive overrasket. Når omlægningen er planlagt, kan I fortælle de kunder, der har krav om test i kontrakten eller har fået rapporten, at en ny test er planlagt i forbindelse med skiftet, og omtrent hvornår den forventes. Det er stærkere end at vente, til en kunde selv opdager, at rapporten beskriver den gamle udgave.

Indtil den nye rapport foreligger, kan I i spørgeskemaerne svare præcist: den seneste test dækker den tidligere arkitektur, omlægningen sker i denne periode, og en test af den nye er planlagt. Undgå at give den gamle rapport ud som dokumentation for det nye produkt uden at sige det. → Meget er udgivet siden testen

Forestil jer et softwarehus med et system til booking af lokaler, der flytter fra én installation pr. kunde til en fælles løsning med alle kunder i samme database. For kunderne ser systemet ens ud, men adskillelsen mellem dem er nu et spørgsmål om logik i koden frem for separate installationer. Den gamle rapport kunne ikke sige noget om den slags adskillelse, fordi den ikke fandtes. Testen af den nye løsning lægges, før de første kunder flyttes, og rapporten bliver en del af det materiale, kunderne får ved flytningen.

Omfanget af en test af en ny arkitektur afhænger af, hvor mange dele produktet er delt op i, hvor mange roller og integrationer der er, og om testen skal dække både gammel og ny udgave i overgangen. Det er grundlaget for → pris og tilbud.

Det skal I lade være med

Bruge den gamle rapport om det nye produkt · uden at sige, hvilken arkitektur den dækker.
Teste efter, at kunderne er flyttet · så kommer fundene for sent til at beskytte de første.
Glemme overgangen · midlertidige forbindelser og kopier af data kan blive stående.
Nøjes med en afgrænset test · når fundamentet er skiftet, er det hele produktet, der er nyt.
Vente med at fortælle kunderne det · til de selv spørger.

Hvad kan og ikke kan konkluderes

En test af den nye arkitektur viser, hvad testeren fandt i den version og det miljø, der blev testet. Den siger ikke noget om den gamle arkitektur, og den dækker ikke ændringer, der er kommet efter testen eller under flytningen. Den gamle rapport viser jeres historik, men ikke tilstanden af det nye produkt.