Sunday 20 March 2011

Indlæg 10 At være eller ikke være - en test arkitekt


At opnå en karriere indenfor softwaretest, anerkendes i dag, i et meget større omfang end for blot få år siden.
Man kan nu følge fastsatte karrieremål og ambitioner indenfor test, i takt med den voksende popularitet.
Nogle uddannelsesinstitutioner udbyder endda regulære uddannelser indenfor software test og management.

Meget generelt set, kan en testkarriere deles op i tre vejre:
1. fra junior testere til test manager eller team leder
2. fra junior testere til dyb teknisk tester
3. fra junior testere til andre stier indenfor softwaretest

Jeg har valgt at tage udgangspunkt i, at test udføres rent professionelt og efter fastsatte normer samt standarder. En juniortester er derfor defineret som værende helt ny indenfor test. Dette kan være fra en forretningstester til en mere erfaren tester.

Karrierestien indenfor test management anses oftest som klarlagt og fastsat. Dette med reference til, at en test manager oftest ses som en projektleders højre hånd. Man har en god forståelse og forestilling om, hvor man ender på denne sti.

Derimod er der mindre gennemskuelighed på det tekniske område. En teknisk tester, har oftest fokus på en eller anden form for automatisering af testen. Det kræver også til tider god udviklingsbaggrund, at kunne sætte sig ind i tekniske problemstillinger, en test automatisering kan give af udfordringer. Det forventes faktisk ofte, at en senior teknisk tester har en eller anden form for udvikler baggrund eller i det mindste kan selvkode i et populært sprog.

Hvis nu management af mennesker ikke ligger til ens højreben, og holdningen er, at kodning er forbeholdt udviklere. Hvor står man så i karrieren indenfor software test?

Indtil for få år siden, ville man måske have fundet en passende plads på organisationshylden, oftest som en senior tester.

Nu - i lyset af softwaretest populariteten - er der dukket et navn fra fra gemmerne. Det er som sådan ikke en ny titel der er opfundet, men blot en gammel disciplin. Nu med et mere moderne og tidspassende mærkat, test arkitekt.

"Karriere som Test arkitekt".
Hvilke opgaver bestrider en test arkitekt så?
Nedenstående liste er på ingen måde er komplet eller en fuld repræsentation af ansvar og krav for test arkitektens rolle. Hver organisation og grupper inden for en større organisation, har sine egne forventninger.

En Test Arkitekt:
- yder teknisk ledelse og strategisk ledelse af virksomhedens test organisation
- er ansvarlig for formuleringen af test strategien
- forventes at kunne analysere aktuelle processer og foreslå forbedringer
- definerer processer efter behov
- er involveret i organisationens kvalitetsproces og deres gennemførelse for at sikre kvaliteten af leverancer
- fastholder et overblikket over produktet, dets afhængigheder, organisatoriske mål, teknologi
- fungerer som kontaktperson med kunder og partnere, herunder justering af teststrategi
- hjælper med udarbejdelsen af test udviklingen
- er ansvarlig for design og udvikling af rammer og værktøj for test automatisering
- forstår forretningskrav og arbejder sammen med udviklingsarkitekten til at omsætte krav til løsningsarkitektur
- har den overordnede produktviden og er i stand til at guide både junior og senior teammedlemmer
- er resultatorienteret og har en høj grad af ansvarlighed, engagement og ansvarlighed.

Som person skal en test arkitekt:
- have omfattende tekniske færdigheder, der dækker produktet, teknologier og konkurrencedygtige viden
- have solidt kendskab til domæne / områder, der behandles
- have bred og temmelig dyb forståelse for spektret af test teknologier og test værktøjer
- have kendskab til aktuelle kvalitet & test processer, samt værktøjer og teknikker
- kunne arbejde i teams
- have gode kommunikations evner
- have gode forhandlings evner
- kunne fokusere og prioritere
- være selvmotiverende og selvstartende
- kunne se fremad og overskue det store billede
- have en solid baggrund i software kvalitet og test
- skal have udført både funktionelle og ikke-funktionelle test
- være i stand til at gennemgå krav, design og selvkode efter behov

Jobbet som en test arkitekt
Test arkitekt rollen er en ledende stilling i organisationen og behandles på lige fod med tilsvarende lederstillinger i form af belønninger, anerkendelse, synlighed og indflydelse. Dog en grundlæggende faktor, der adskiller en test arkitekt fra en manager, er fraværet af direkte ansvar for forvaltningen af mennesker.

Mens management har en tendens til at have ledelse af folk som et centralt element i jobbet, udøver test arkitekten ikke direkte styring folk. Test arkitekten har dog rollen som mentor, coach og giver retningslinjer til medlemmer af test organisation.


Kilder:
http://blogs.sun.com/johnmorrison/entry/test_architect

Tuesday 8 March 2011

Indlæg 09 Concept of desire - Ønskekoncept

V-modellen
En af V-modellens mange fornemme opgaver er, at hjælpe til forståelse af den relative timing mellem udvikling og testaktiviteter. Har man et kendskab til V-modellen, ved man også, at helt øverst finder man, vedligeholdelsesfasen og den operationelle fase. Maintanence of the system. Denne fase er sjældent afbilledet som en helhed af selve V-modellen. En af mine tanker undslap de natlige lænker i går nat - ... men hvorfor egentlig ikke. Kunne man ikke "bare" gøre nogen frække antagelser og simplificere tilgangen hvorpå man tidligere har tænkt?

Som f.eks. moduldesign "hænger sammen" med unit testen, og kravanalysen "hænger sammen" med accept testen, kunne man jo egentlig godt fokusere lidt, hvad pendant der findes til Vedligeholdelsesfasen. Altså hele processen før kravanalysen og forretningsbehovet.

Jeg forestiller mig, at vi skal helt op i idé fasen - i konceptfasen. Derop hvor de første spæde frø plantes, og hvorfra ideerne spirer langsomt. Allerede på dette tidspunkt - er min holdning - at man bør gøre sig nøje overvejelser omkring, hvilke forestillinger man har om vedligeholdelsen i fremtiden. Før forretningsbehovet, så vedligeholdelsen bliver indarbejdet i forretningens ønsker og ikke udarbejdet i 11. time som et ”nice to have” og ups, det glemte vi faktisk.

Test niveau
- hvad er ønskerne (no limits)
- hvad er prioriteringerne
- omfang af nem vedligeholdelse
- hvilken platform og teknologi
- niveau af kundevenlighed

Ønskekoncept (Concept of desire) ---------------------------------------> Vedligeholdelse (Maintanence)

Hvorfor er det så oplagt altid at starte med systemkrav og forretningsbehov? Hvorfor lægge bånd på sig selv, allerede inden udviklingen er påbegyndt?
Start med en ønske session og åben op for ideerne. Sandsynligvis bliver de fleste ideer ikke realiseret, men vejen til en langtidsholdbar løsning, er snoet og fyldt med guldkorn, godt spredt ad tidsvariablen. Er man en klog innovativ forretning, så gemmer man de nedfældede idéer til andre tider. Hvem kan forudsige teknologien er om bare 5 år?

Tuesday 1 March 2011

Indlæg 08 Sweeping ET and Sweeping EG

Og hvad går det så ud på.
Jo, E.T. er en forkortelse for Eksplorativ Test og E.G. er en forkortelse for Error Guessing.

Test essensen i Sweeping, er som i ordets betydning, en fejende test. Nogle foretrækker sandsynligvis at kalde det for Monkey Testing, og det er helt fint med mig. Skraldemand er jo også blevet til Renovationsmedarbejder, "so there you go".

Den fejende test kan eksempelvis beskrive som følger:
- man ønsker at bestille en bog på en online boghandel. Bestillingsprocessen af denne bog, følger som regl en given process. Her skal denne proces altså overhovedet ikke overholdes, ligeledes total ukorrekt indtastning i givne felter. Alt er tilladt! Alt det som en vanvittig bruger kan finde på, eller blot en almindelig dygtig tester, bare på rekord tid.

Hvor Sweeping E.T. f.eks kan have fokus på browsernavigering (i.e. brugergrænseflade og forretningsprocesser) kan Sweeping E.G. have fokus på indtastninger (i.e. felt valideringer, datahåndtering)

Jeg mangler at udarbejde de overordnede retningslinjer på hvordan og hvorledes de skal anvendes endnu, eftersom jeg kontinuerligt forbedre metoderne. Dog kan de allerede bruges på alle test niveauer, fra UT (unit test) til UAT (unit accept test).


Kort test eksempel:

Sweeping E.T.
Mission: bestil bog med test angreb på selve bestillingsprocessen
Tid: 10 minutter
Mål: find defekts

Sweeping E.G.
Mission: bestil bog med test angreb på feltvalidering
Tid: 10 minutter
Mål: find defekts

Som test manager, er det meget fordelagtig at alliere sig med sådanne - ja lad os bare sige - trumfer. Hvis succeskriterierne er, at testen er afsluttet når de væste fejl er fundet, så lur mig, om ikke altid jeg finder nogle flere efter påstået afslutning. Og de er gerne kritiske - meget kritiske - som dukker op.