søndag 8. mars 2009

ISTQB Certified Tester Advanced Level?

Hvis du ønsker å lære mer om hvordan man jobber effektivt som tester, anbefaler jeg kurs og sertifisering i regi av ISTQB. Foundation-kunnskapen burde alle få med seg (både testere, utviklere og prosjektledere), og et kurs i regi av en erfaren tester gir mye ekstra. Grove Consulting i England har jeg hatt utmerket erfaring med, og det var også de jeg var på kurs med nå sist for å ta Advanced Level. Og det gikk jo bra.

Les mer om ISTQB på deres internasjonale sider og på sidene til Norwegian Testing Board.

Man kan ta en liten prøveeksamen på Foundation nivå, forøvrig.

tirsdag 3. mars 2009

ISO 9126 Attributter for programvarekvalitet og karakteristikker

ISO 9126 er en internasjonal standard for evaluering av programvarekvalitet. Den garanterer en uniform tilnærming ved å definere en kvalitetsmodell. Denne modellen består av seks hovedgrupper karakteristikker for programvarekvalitet. Hver hovedkarakteristikk har igjen undertyper.

Funksjonalitet Er programvaren funksjonelt korrekt (validering) og fungerer den korrekt (verifisering)?
Pålitelighet Kan vi stole på ytelsen til programvaren i gitte situasjoner og i en gitt tidsperiode? Undertyper her er feiltoleranse, evne til gjenopprettelse, modenhet
Brukbarhet Er programvare lett å jobbe med og kan brukerne enkelt lære å jobbe med programvaren? Undertyper her er lærevennlighet, opererbarhet, forståelighet
Effektivitet Hva er relasjonen mellom ytelse og tid/ressurser? Undertyper her er oppførsel i tid og ressursoppførsel
Vedlikeholdbarhet Kan programvaren enkelt endres? Undertyper er stabilitet, testbarhet, endringsvennlighet, analysevennlighet
Flyttbarhet Kan programvaren enkelt overføres til et annet miljø? Undertyper er tilpasningsdyktighet, installasjonsvennlighet, evne til å følge sertifiseringer/godkjenningsregler, utbyttbarhet

Denne standarden er et rammeverk for organisasjoner å definere sine kvalitetsmodeller etter. Alle undertyper har et sett med attributter i sin tur. Bare attributter kan brukes for å måle og verifisere programvarekvaliteten. Når organisasjoner setter sammen deres egen modell kan de velge hvilke kvalitetsattributter de skal ta hensyn til.

Legg merke til at mange av kvalitetsattributtene er ikke-funksjonelle. Svært ofte er testaktiviteter fokusert på det funksjonelle, men oppmerksomhet bør også gis det ikke-funksjonelle siden det kan bli en stor risiko i et prosjekt.

lørdag 28. februar 2009

En time med Elisabeth Hendrickson om Agile Testing

Her er en video vel verdt å se, som fører deg fra forståelse for tradisjonell testing (vannfall) til smidig testing. Hendrickson er svært entusiastisk og forklarer ting svært klart.

Bruk en time på dette!

Agile Testing

fredag 27. februar 2009

Perfekt testing

James Back er velkjent for mange i “testverdenen”. En erfaren og kunnskapsrik mann, uten tvil, og har en holdning til omverdenen som ligner litt på “The Comic Book Guy” i The Simpsons. “Worst software ever”.

Jeg så nettopp en video av et foredrag han holdt for Google-folk på temaet “Hvordan bli en ekspert på programvaretesting”. Mye av tiden brukes på å fortelle hvem han er og hvorfor han betraktes som en ekspert, i litt morsomme ordelag. En definisjon var ganske interessant:

Perfekt testing=

Testing er den uendelige prosessen

med å sammenligne det usynlige

med det tvetydige

for å unngå det utenkelige

å skje med det anonyme

Ikke dårlig, Testing ER virkelig utfordrende!

Uendelig fordi perfekt testing slutter aldri…

Usynlig fordi du som tester ikke ser alt som foregår.

Er resultatet godt eller dårlig? Vet du absolutt hva kravene er? Derav tvetydighet. “We are in the center of the maelstrom of disagreeing customers”.

Og vi vil gjerne unngå at risker blir virkelige hendelser!

Og du aner ikke hvem hendelsene vil skje for. Hvem skal faktisk bruke løsningen du tester senere?

Litt mer praktisk definisjon:

Å teste er å eksaminere produktet for å evaluere det.

En annen igjen:

As a tester you must smell danger where others smell lilacs.

Høydepunktet i foredraget er kanskje når han forklarer hvordan en ekspert høres ut ved å sitere fra filmen “Towering Inferno” med tøffingen Steve McQueen. Det er lenge siden jeg så filmen, men jeg kjenner likevel samtalen hvor brannsjefen i Steves skikkelse kommer til brannstedet og spør ut folk om hva scenariet er.

James mener det viktigste du som tester kan gjøre er å bygge opp og beskytte ditt rykte. Kan ikke være helt uenig her. Det ligger mye i å jobbe med ryktet.

Dere kan se videoen her:

onsdag 25. februar 2009

Testbarhet i virkeligheten

På konferansen GTAC 2008 ble denne presentasjonen holdt om temaet testbarhet. Presentasjonen går gjennom konsepter rundt testbarhet, SOCK-modellen og tankeprosessene for testutvikleren.

Tester Bill of Rights

Fra før av har vi Customer Bill of Rights:

  • You have the right to an overall plan, to know what can be accomplished when and at what cost.
  • You have the right to get the most possible value out of every programming week.
  • You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify.
  • You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.
  • You have the right to be informed of schedule changes, in time to choose how to reduce the scope to restore the original date.  You can cancel at any time and be left with a useful working system reflecting investment to date.

Og vi har (XP) Programmer Bill of Rights:

  • You have the right to know what is needed, with clear declarations of priority.
  • You have the right to produce quality work at all times.
  • You have the right to ask for and receive help from peers, managers, and customers.
  • You have the right to make and update your own estimates.
  • You have the right to accept your responsibilities instead of having them assigned to you.

Men vi trenger da virkelig en for testerne også! Så her er den, Tester Bill of Rights:

  • You have the right to bring up issues related to testing, quality, and process at any time.
  • You have the right to ask questions of customers, programmers, and other team members and receive timely answers.
  • You have the right to ask for and receive help from anyone on the project teams, including programmers, managers, and customers.
  • You have the right to estimate testing tasks and have these included in story estimates.
  • You have the right to the tools you need to perform testing tasks in a timely manner.
  • You have the right to expect your entire team, not just yourself, to be responsible for quality and testing.

(Ref “Agile Testing” av Crispin og Gregory)

TDD med JavaScript

Dennis Bryne har skrevet en artikkel på InfoQ om TDD med JavaScript og bruk av JsUnit og JSMock. I Bekk er det mange som jobber med JavaScript daglig og det er sikkert mange andre som kan ha bruk for denne artikkelen også, så les her:

http://www.infoq.com/articles/javascript-tdd

assertequals