Fokus på softwarekvalitet

focusStørre fokus på softwarekvalitet har i sidste ende stor indflydelse på forretningen: bedre softwarekvalitet giver færre fejl, en bedre brugeroplevelse, et bedre omdømme for virksomheden, en større motivation for medarbejderne, og en større tilfredshed – både hos medarbejderne og hos kunderne. Sidst men ikke mindst får man en bedre forudsigelighed omkring softwaresystemet.

Definition

Men hvad er softwarekvalitet? Hvordan skal det defineres? Jeg vil mene at det afhænger meget af hvilken virksomhed der producerer softwaren, og specielt hvilket domæne man arbejder indenfor. Softwarekvalitet afhænger af mange parametre, og det er ikke alle parametre der er lige vigtige hos alle typer IT-virksomheder. Derfor er det meget vigtigt at der udarbejdes nogle retningslinjer om hvad man skal lægge vægt på mht. softwarekvalitet. Det er også vigtigt at hver projektgruppe snakker sammen om hvad de mener softwarekvalitet er for dem.

Værdier

Først er fremmest er det vigtigt at tale sammen om hvilke værdier, der ligger til grund for softwarekvalitet. Eksempler på værdier, der omhandler software, kan være:

  • Forståelig kode (hvor nemt er det at forstå koden? Er det en mordgåde man skal løse eller er der et flow man nemt kan følge?)
  • Simpelt design (læs denne artikel http://martinfowler.com/articles/designDead.html)
  • Robust kode (hvor robust er systemet når der opstår fejl, når det bruges?)
  • Fleksibelt design (er det nemt at tilføje nye moduler, eller skal der rettes mange forskellige steder pga. en lille ændring?)
  • Testbar kode (er klasserne nemme at teste?)
  • Business-værdi (tilføjer den nye feature reel værdi til selve produktet?)
  • Konsistens (hvor konsistent er den nye kode i.f.t. den eksisterende kode?)

software-quality-testing

(billedet er lånt fra dette blog-post)

 

 

 

 

 

Hvorfor

Næste spørgsmål lyder: Hvorfor er det værdifuldt at sætte softwarekvalitet så højt?

Det er en god ide at snakke på projektteamet hvorfor man gerne vil have bedre softwarekvalitet. Man kan opdele svaret på “hvorfor” i to kategorier:

  1. en objektiv og målbar kategori
  2. en mere subjektiv og knap så målbar kategori

Ang. punkt 1) så er følgende bud på hvorfor det er vigtigt at fokusere på sw-kvalitet:

  • Ønske om at minimere teknisk gæld
  • Ønske om at minimere risikoen for fejl
  • Virksomhedens omdømme forbedres når kvaliteten er i top
  • Bedre kode og design

Ang. punkt 2) :

  • Større motivation blandt medarbejderne
  • Mere indflydelse blandt sw-udviklerne
  • Valg af arbejdsplads

Hvordan

Men hvordan får man så en bedre softwarekvalitet i praksis. Her er en række forslag.

  1. Gå efter kode og design, der er nem at vedligeholde
  2. Review altid kodeændringer. Og udarbejd en reviewguideline så alle på holdet er enige om hvordan det gøres
  3. Ryd op i koden. Som Robert “Bob” Martin skriver: Don’t leave “broken windows” (i.e. bad designs, wrong decisions, or poor code) unrepaired.
  4. Brug spejderdrengsprincippet: “Always leave the campground cleaner than you found it”. Gør det til en vane at forbedre koden, designet eller et byggescript hver gang man tager fat på en ny opgave: fx ændre kode-stilen, opdatere gamle og forkerte kommentarer, bedre navngivning, sletning af død kode osv.
  5. Brug Continous Integration under udviklingen
  6. Hver enkelt softwareudvikler bør tage et større ansvar for softwaren
  7. Fix altid de vigtigste bugs først
  8. Undgå warnings (eller brug de samme regler for hvilke warnings der er tilladte)
  9. Refactor koden når det er nødvendigt
  10. Undgå at genopfinde eksisterende funktionalitet
  11. Bliv inspireret af eksisterende kode-guidelines (fx disse fra Google: Java og C++, og denne fra Microsoft: C#)
  12. Foretræk små klasser og korte metoder
  13. Fælles kode-formatering (fx et pr. sprog)
  14. Softwareudviklernes forslag skal prioriteres og lyttes til
  15. Brug open source tools til at monitorere duplikeret kode
  16. Lav en logging-strategi for systemet, så logging ikke ender med at blive noget rod
  17. Brug open source tools til fx code coverage (hvor stor en del af koden er dækket af unit-tests?)

En god måde at skabe mere fokus på synligheden af softwarekvalitet undervejs i et projekt er at oprette specielle tasks (eller sætte labels på tasks), der signalerer kvalitetsforbedringer.

Lær af dine fejl

Hvis softwaren bliver leveret hos kunden uden succes, så kan man skylde skylden på mange ting: selve udviklingsprocessen, medarbejdernes engagement, ledelsen, forholdene, manglende kravshåndtering, ingen eller meget lidt fokus på softwarekvalitet etc. Som Kent Beck siger i et interview angående agile processer og den vigtige læringsproces der ligger i at erkende fejl og lære af dem: (http://www.infoq.com/articles/kent-beck-interview-2006):

Somehow we think, “If I was a perfect programmer, the project would have been a roaring success.” If the project isn’t a runaway success, I must be a failure. In this mindset running and hiding becomes a reasonable response.

Det samme er gældende for udbredelsen af bedre softwarekvalitet. Det er sikkert umuligt at få 100% kvalitet i hvert eneste softwareprodukt, men hvis man kan lære af sine fejl, når det angår manglen på et af kvalitetsmetrikkerne, så har man lært noget til næste gang.

Det bør faktisk være et krav, at sætte fokus på softwarekvalitet, når man udvikler software – i stedet for at fokusere på en hurtigere udviklingscyklus. I sidste ende vil det altid kunne betale sig at have fokus på softwarekvalitet fra start til slut. Selvom det kan være svært at måle konkret hvilke fordele man fik ud af det.

“Quality begins on the inside… then works its way out.” ~Bob Moawad

3 comments for “Fokus på softwarekvalitet

  1. Der er også forskel på om det er software virksomheden producerer…

    om det er stand-alone løsninger (web sites) eller enterprise firma løsninger.. eller om det er klodser, eller mælk. Alle steder har brug for KVALITETSAFKLARING (aka Test, så de bliver klogere på hvad der ryger videre).

    Koden kan være perfekt mht coverage og de andre metrikker, men hvis den ikke løser problement pga andre omstændigheder, så har vi stadig en dårlig løsning. Så det skal god test også kigge på, og tage stilling til om krav og PBI’er er testbare.

    ps: Tests er svært at gøre objektivt målbare: http://www.developsense.com/blog/2013/12/counting-the-wagons/

    • Tak for kommentaren og linket til blog-postet om tests. Du har ret i at det er vigtigt at sørge for at kravene er testbare. Dvs. hvert krav bliver testet af en eller flere test cases, og at hver test case kan føres tilbage til et krav.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *