Testing

Forsøk å få utviklerne til å gjøre ferdig deler av nettsiden i biter slik at bitene kan testes. Det er ikke alltid så lett. Eksempel: Selv om søket på sidene teknisk sett er ferdig, kommer ofte innhold på plass mot slutten og det er først da søket kan testes.
​
Her igjen en advarsel høstet gjennom lang erfaring: Dere klarer ikke å teste alle funksjoner og se over alle sider på alle nettlesere på PC, Mac, Ipad, og tre ulike mobiler. Ingen nettsider er feilfri ved lansering, da har dere brukt alt for lang tid. Som ellers - de siste fem prosenten tar like mye tid som de foregående 95 prosentene. Så hvor mye er nok? 

 

Før viste ulike nettlesere frem den samme siden med på litt forskjellig måte. Nå er nettleserne blitt mye likere og testingen er blitt mye enklere. Det kan holde å teste i Chrome og Internet Explorer 11 og så ta en kjappere titt i Safari på en Iphone.

​

Se vedlegg Gjennomføringsplan for nettside-prosjekt.xlsx for utkast til testplan.

​

Grovt sett kan man dele funksjonstesting opp i to: Hvor kan dere leve med litt feil og hva må virke prikkfritt fra dag en?

​

Komponenter som må fungere prikkfritt, må det testes grundig. Da må den nye nettsiden brukes en stund før den gamle avlives. Dette krever at interne brukerne har tid til å bruke og teste. Når alle er fullt opptatt i hverdagen, kan det bli vanskelig. Sørg for at ledere setter av tid.

​

En populær løsning for å få hjelp til testingen er å legge ut den nye løsningen på dagens nettside med en knapp som sier “Test vår nye beta-versjon”. 
​
Ikke forvent at utviklingsselskapet gjør testingen. Hovedfunksjonaliteten skal fungere når utviklerne sier ferdig (les klar til test). Igjen: Det er dere som kjenner behovene og vet hvordan løsningen må fungere for ulike brukere. Det kan ikke en utvikler vite. Eksempel: Et søk kan virke teknisk sett, men er det innstilt slik at de besøkende finner det de trenger? Får man for mange treff? Er det noen målgrupper som trenger ekstra valg osv.
​

​

Drift og service

I dag er valg av drift mindre komplisert enn før, men dere må bestemme hvor trygge dere vil være. Utfordringen er at man ikke kan sikre seg helt mot nedetid, uansett hvor mye man betaler. Spør Google og de store norske bankene. 

​

Kjapt fra listen av hva jeg har opplevd selv: Gravemaskin som river over fiberkabler, hackere som vil ramme en nettside som også drives av vår leverandør, brann i koblingsskap, strømbrudd og selvfølgelig feil på utstyr som harddisk-kræsj og kjølefeil. Jeg var med på et oppkjøp av et suksessfylt gründerselskap som trodde alt var greit. Det viste seg at hele bedriften lå på en eneste, fysisk boks uten såkalt failover - at nettsidene leveres fra en annen server når første server havarerer.

​

De fleste utviklingsselskaper tilbyr ikke serverdrift selv lengre (og hvis de gjør det, så si nei takk). Helt enkelt er hovedregelen her at jo større leverandør, jo bedre. Det enkleste er om utviklerselskapet kan gi dere drift hos en av de store virkelig stor norsk eller europeisk driftsleverandør. Det aller tryggeste er sky-leverandørene Amazon, Microsoft (Azure), Google eller IBM. 
​

Man kan kjøpe ulike nivåer. I tillegg bør dere tenke på hva slags beredskap dere trenger fra utviklerselskapets side. Her er hva dere bør vurdere å betale for:

• Sørg for at dere er på en virtuell server som kan falle ned og at en annen server overtar uten at noen merker noe. 

• En litt større driftsleverandør har spredd serverne sine over flere lokasjoner, hvilket verner dere mot overgraving av kabler og slikt.

• I kontrakten med utviklerselskapet nedfelles ulike typer feil og hvor fort de skal rettes. Får ikke noen brukere logget på eller er hele nettsiden nede, må dette rettes umiddelbart, mens mindre kritiske feil rettes i vanlig arbeidstid.

• Det dyreste er å betale for at utviklingsselskapet skal kunne fikse feil 24/7/365. Definer krav dere har og betal deretter. Kan dere leve med det som så fint kalles litt “uplanlagt nedetid” på natten?  

​

​