onsdag den 19. december 2012

Testarkitekten - En overset rolle?

Min kollega Steen Bang-Madsen gjorde mig her til morgen opmærksom på et spændende blogindlæg om 'The Test Architect'.

Når jeg en gang imellem ser definerede 'karriere-veje' for testerne - er de ofte angivet som enten en testledelses-vej eller en testspecialist-vej. Blogindlægget lægger op til en rolle som 'Test Architect'.

Testarkitekten har ikke et personalemæssigt ansvar, men er 'udvikler-arkitektens' modpart. Altså en person der tager sig af det testfaglige, herunder metoder, fremgangsmåder, værktøjer m.m.

Jeg synes det er en spændende tanke med en sådan rolle, og jeg mener også, at kan se et par stykker i mit netværk som allerede har den rolle (og i nogle tilfælde også den formelle titel).

mandag den 26. november 2012

Forretningen skal være en aktiv del af teststyringen

Det er vigtigt at sikre sig, at forretningen (eller kunden) tager en aktiv rolle omkring prioriteringen og fastlæggelsen af testfokus. I sidste uge havde jeg et hold kursister på TMap NEXT BDTM (Business Driven Test Management) kursus, hvor fokus netop er afstemningen af forventningerne mellem forretningen og testprojektet.

De 6 trin i BDTM-modellen er:

  1. Forstå testopgaven og fastlæg testmål
  2. Udarbejd produktrisikoanalyse (PRA)
  3. Fastlæg testintensitet
  4. Fastlæg budget, plan og omfang af testen
  5. Fastlæg brug af testdesignteknikker
  6. Giv indblik i styringsapekterne (tid, budget, produktrisiko, testresultat)
BDTM-processen understøtter den generelle teststyringsmodel i TMap NEXT.

En af styrkerne ved BDTM er det kommunikative - idet involvering af kunden/forretningen er essentiel for afstemningen af forventningerne, og det foregår i kundens/forretningens sprog og i den forretningsmæssige kontekst som giver værdi og mening for kunden. En anden klar fordel er, at kunden er i kontrol med processen - få indsigt i de fire styringsaspekter. Metoden sikrer også, at hovedtestplanen kan detaljeres efter behov.


Alt i alt en model jeg stærkt anbefaler - tjek mere på eng.tmap.net

torsdag den 15. november 2012

Testteknikker - igen igen

Endnu en uge, hvor jeg har nydt at sprede det glade budskab om struktureret test. Behovet er der fortsat. Hvis vi som testere ønsker at kunne kvantificere risikoen, så er der kun en vej, de formelle testteknikker.

fredag den 9. november 2012

Danske virksomheder underprioriterer test af apps

Sogeti har netop udgivet 'årets' World Quality Report (WQR), og som bygger på svar fra over 1.500 respondenter over hele verden.

På verdensplan vælter det frem med nye applikationer til smartphones og tablets. I hver af de første syv måneder af 2012 blev der indsendt 26.000 ansøgninger til iTunes App Store alene. Men meget tyder på, at virksomhederne ofte er for hurtige til at lancere nye applikationer – uden de er tilstrækkeligt gennemtestede.

Det er en af hovedkonklusionerne i undersøgelsen, WQR afslører, at virksomhederne kæmper for at klare udfordringerne i den mobile æra. Kun en tredjedel (31 pct.) af de adspurgte tester i øjeblikket formelt deres mobile applikationer. Og de testende virksomheder fokuserer 64 pct. primært på ydeevne, 48 pct. tester for funktionalitet, mens blot 18 pct. har fokus på sikkerhed.

Lav modenhed i Danmark

WQR viser, at flere virksomheder på globalt plan overvejer, at oprette deres eget testcenter til kvalitetssikring end forrige år. Det er en udvikling, som går stik imod tendensen i Danmark, hvor hele 65 pct. af de IT-ansvarlige angiver, at de ikke har overvejelser om at etablere et testcenter, der kan sikre en mere strategisk og systematisk tilgang til udviklingen af bedre software. På globalt plan er det tilsvarende tal blot 34 pct., hvilket også er gennemsnittet i de øvrige nordiske lande.

Der er sket meget over de seneste 5-10 år i Danmark, men meget tyder på, at vi fortsat har en opgave foran os med henblik på synliggøre den værdi, som tests skaber. Test i sig selv giver ikke et kvalitetsløft. Men det giver en indsigt, som er kritisk for at kunne professionalisere IT-branchen herhjemme og sikre en større produktivitet og mindre fejlmargin i udviklingen af nyt software. Derfor er det vigtigt, at vi sætter ind på netop det her område,