Flere produkter i porteføljen: hvilket skal testes først?

Et softwarehus med tre eller fire produkter kan stå med et budget, der rækker til én test ad gangen, mens kunderne spørger efter rapporter til dem alle. Rækkefølgen hviler på to spørgsmål: hvilke produkter kunderne faktisk kræver dokumentation for nu, og hvilke produkter der ville gøre mest skade, hvis noget gik galt.

Det produkt, der fylder mest i omsætningen, er ikke nødvendigvis det, der skal først. Et mindre produkt med kundedata, adgang fra internettet og en stor aftale på vej kan veje tungere end flagskibet, som blev testet sidste år og ikke har ændret sig meget siden.

Start med kundekravene, I allerede har

Gennemgå de krav, der ligger på bordet, også dem, der kun er nævnt mundtligt af en sælger eller en kundeansvarlig. Hvilke kontrakter nævner test, hvilke spørgeskemaer venter på svar, og hvilke fornyelser kommer inden for det næste år? Notér for hvert krav, hvilket produkt det handler om, og hvornår kunden skal bruge dokumentationen.

Gennemgangen kan vise, at kravene klumper sig om et eller to produkter. Det er et stærkt argument for at begynde dér, fordi en rapport, der kan bruges i salget, giver værdi med det samme. → Flere kunder stiller forskellige krav til testen

Pas dog på med kun at følge salgskalenderen. Et produkt, som ingen kunde spørger til i dag, kan stadig rumme de mest følsomme data. Kundekravet afgør rækkefølgen inden for det, der er vigtigt, men det må ikke skubbe et risikabelt produkt ud af planen.

Vurder, hvad hvert produkt udsætter kunderne for

Det andet spørgsmål handler om kundernes risiko. For hvert produkt kan I spørge:

Data · rummer produktet personoplysninger, økonomiske oplysninger eller andet, kunderne ikke vil miste?
Adgang · kan produktet nås fra internettet af alle, eller kun fra kundernes egne net?
Delt miljø · deler mange kunder samme installation, så en fejl rammer flere på én gang?
Forbindelser · har produktet integrationer til kundernes egne systemer, som kan blive en vej ind til dem?
Ændringer · er produktet ændret væsentligt siden sidste test, eller er det aldrig testet?

Et produkt, der scorer højt på flere punkter, bør ligge tidligt, uanset hvad salget siger. Et produkt med få brugere, ingen persondata og kun intern adgang kan ofte vente. Penetrationtest.dk beskriver den generelle prioritering af flere systemer for køberen; her er det jeres egne produkter og jeres kunder, der skal vejes mod hinanden. Se penetrationtest.dk.

Fælles komponenter kan ændre regnestykket

Mange porteføljer bygger på det samme fundament: et fælles login, en fælles administrationsdel, et fælles API eller den samme platform for drift. En svaghed i fundamentet rammer alle produkter, der står på det.

Det kan tale for at teste fundamentet først, eller for at lade den første test dække fundamentet sammen med ét produkt. Så kan rapporten bruges som dokumentation for den fælles del, når de øvrige produkter testes senere. Det kræver, at omfanget beskriver tydeligt, hvilke dele der er fælles, og hvilke der hører til det enkelte produkt. → Omfangsafsnittet

Omvendt bør I ikke regne med, at en test af ét produkt dækker de andre, blot fordi de deler noget. Kunden, der køber produkt B, læser omfanget og ser, at produkt B ikke er nævnt. → Rapporten dækker ikke det modul, kunden køber

Fra vurdering til en plan

Læg vurderingerne sammen i en enkel plan. Et tænkt eksempel: et softwarehus har et bookingprodukt med mange erhvervskunder, et lille rapporteringsværktøj og et ældre produkt med få kunder tilbage. Bookingproduktet har både kundekravene og de følsomme data, og det deler login med rapporteringsværktøjet. Planen bliver at teste bookingproduktet sammen med det fælles login først, rapporteringsværktøjet året efter og det ældre produkt efter en særskilt vurdering. → En gammel version, der stadig har kunder

Planen skal have datoer, så den kan bruges over for kunderne. En kunde, der spørger til et produkt, som endnu ikke er testet, får et bedre svar, hvis I kan sige, hvornår testen er planlagt, og hvad den skal dække. Planen hører naturligt hjemme i jeres årshjul. → Et årshjul for sikkerhedstest i et softwarehus

Hvor meget, der kan nås i én opgave, afhænger af produkternes størrelse, antallet af roller og integrationer og af, om fælles dele kan dækkes én gang. Det er de forhold, der bestemmer → pris og tilbud.

Når to produkter konkurrerer om samme plads

Står to produkter lige, kan tre forhold afgøre det. Det ene er tid: hvilket produkt har et krav med den nærmeste frist? Det andet er udviklingsteamets kapacitet til at rette fund, så rapporten kan vise rettelser, før den udleveres. Det tredje er, om et af produkterne står over for en større ændring, så en test lige nu ville beskrive en version, der snart er væk.

Skriv begrundelsen ned, kort og med dato. Når en kunde, en ny produktchef eller ledelsen senere spørger, hvorfor produkt C ventede, skal svaret kunne findes.

Gør det også klart, hvem der ejer beslutningen. I et softwarehus med flere produkter kan hvert produkt have sin egen produktejer, og hver af dem vil gerne have sit produkt testet først. Når ledelsen eller den sikkerhedsansvarlige træffer valget ud fra de samme kriterier for alle, bliver det lettere at forklare internt, og lettere at holde fast i, når næste kunde presser på for et andet produkt. → Hvem i softwarehuset ejer kundekravet om test?

Det skal I lade være med

Teste det produkt, der er lettest at afgrænse · rækkefølgen skal følge krav og risiko.
Lade flagskibet stå først hvert år af vane · andre produkter kan have ændret sig mere.
Bruge én rapport som dokumentation for flere produkter · kunden læser omfanget.
Glemme det fælles login og den fælles administration · svagheder dér rammer hele porteføljen.
Love kunderne en test uden en dato · et løfte uden plan holder ikke i næste spørgeskema.

Hvad kan og ikke kan konkluderes

En prioriteret plan viser, at I har vurderet produkterne og valgt rækkefølgen bevidst. Den viser ikke, at de produkter, der venter, er sikre. Over for kunderne kan planen forklare, hvornår et produkt bliver testet, men den kan ikke stå i stedet for en rapport.

Tjekliste til porteføljen

☐ Står alle produkter på én liste med ejer, kunder og seneste test?
☐ Er kundekravene noteret pr. produkt med frister?
☐ Er data, adgang, delt miljø og forbindelser vurderet for hvert produkt?
☐ Er de fælles komponenter identificeret og placeret i planen?
☐ Har hvert produkt en planlagt testdato eller en skrevet begrundelse for at vente?
☐ Er der tid til rettelser, før rapporten skal bruges over for kunder?

Senest gennemgået: oktober 2026.