Kvaliteten af software kan aldrig blive høj nok!

Her på DBC forsøger vi altid på at levere software af en høj kvalitet, der er testet og veldokumenteret. Jeg skriver forsøger fordi jeg ganske udmærket godt ved at det ikke altid lykkes.

Når det så er sagt, så er test noget vi faktisk arbejder en del med i Brønd-projektet. Vi har inden for de sidste 1 1/2 år automatiseret flere af vores test. Lige fra det vi kalder unit-test, der tester en meget afgrænset del af en funktionalitet
i systemet, til de mere vidt favnende accepttest, der tester store dele af systemet i en sammenhæng.

Det betyder for systemet at vi nu skriver accepttests til systemet før vi skriver koden. Disse accepttest skrives af
personer med en dyb indsigt i forretningslogikken og ikke af java-udviklerne. Så når udviklerne har skrevet koden kan de
med samme se, at den virker som forretningslogikken ønsker, den skal virke.

Og hvad der er endnu bedre: Når vi ændrer koden kan vi med det samme se, at ændringen ikke har fået systemet til at ændre opførsel. Dette giver en meget positiv fornemmelse for alle i projektet og en sikkerhed mod fejl, som vi aldrig har haft før. Dermed ikke sagt at systemet pludseligt bliver fejlfrit. Det gør det ikke, men det sikrer at driften kan være sikker på at systemet - populært sagt - ikke opfører sig værre end den tidligere version gjorde.

Udover unit- og accepttest har vi i brøndprojektet også opsat en hastighedstest. Det er vigtigt, at vi ved at nye funktioner
eller rettelser i gamle ikke bare opfører sig korrekt, men også som minimum kører lige så hurtigt, som den forrige version. Eller hvis ny funktionalitet sløver systemet, så kan vi gøre driften opmærksom på hvad der er på vej.

Det sidste trin på stigen er automatisk deployment. Det er noget som vi har som mål, men vi er ikke nået så langt med
dette. Nye versioner med ny funktionalitet kræver tit omfattende omkørsler i brøndmiljøet, så det er ikke så nemt at lave
automatisk deployment. Men vi har også releases der ikke kræver omkørsler og det er helt klart vores mål at få disse
versioner automatisk lagt over på driftsmaskinerne, så vore kunder hurtigt kan få glæde af den ny funktionalitet.

Som tidligere skrevet så er dette noget vi arbejder med og som productowner for OpenSearch så lad mig med samme sige at det har ikke været billigt. Men det er efter min mening indiskutabelt at det har været alle pengene værd!

Hvor langt er vi så nået:
Indekseringsdelen af Brønden er unit-, accept- og hastighedstestet.
Den nuværende DataDock er der "kun" unit-test på.
Afløseren for DataDocken (Hive) er unit- accept- og hastighedstestet.
OpenSearch Webservicen bliver ikke testet automatisk. Den testes manuelt.

Og her er det så at jeg gerne vil bede om jeres hjælp:
Når vi sætter en next-version af OpenSearch i drift, så er det vigtigt at der er nogen af jer derude der begynder at tæve
løs på den. Det er den eneste måde - for nu - at vi kan undgå at der bliver sat noget i drift, der brækker jeres
grænseflade. Så det må være i vores alles interesse at dette sker. Jeg kunne godt tænke mig vi fik en metodik omkring test af webservicen ala dette forslag:

1) DBC sætter en ny version af OpenSearch webservicen i next-drift
2) En eller flere biblioteker melder sig/udpeges til at teste den via deres dev-sites.
3) I en 2-3 ugers periode testes der på webservicen via dev-grænsefladen.
4) Efter fejlrettelser og tests af disse sættes webservicen endelig i drift.

Jeg tror, at selv efter vi begynder at automatisere test til webservicen, så er ovenstående en nødvendighed, for at vi alle
kan være sikre på at vi får et stabilt system, som vi tør lukke slutbrugerne ind på.

Hvad synes I?
 

Mvh Kurt Poulsen

Projektleder brønd.TING

DBC.