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

fredag 20. februar 2009

Historiens verste programvarefeil

Wired har en interessant oversikt over de verste programvarefeilene gjennom historien. Ikke er de fullstendig fokuserte på amerikanske forhold heller, slik amerikanere ofte er.

Se artikken her:

http://www.wired.com/software/coolapps/news/2005/11/69355?currentPage=all

Den verste?

November 2000 -- National Cancer Institute, Panama City. In a series of accidents, therapy planning software created by Multidata Systems International, a U.S. firm, miscalculates the proper dosage of radiation for patients undergoing radiation therapy.

Statistikk har sin verdi

Her er litt statistikk som du kanskje ikke kjente til:

69% av de som ble spurt i en undersøkelse gjort av Dr Dobbs Journal sa at de brukte smidig metodikk i prosjekter. 15% av de som ikke gjorde det hadde det i planene.

72% av smidige prosjekter, 63% av tradisjonelle prosjekter og 43% av offshore-prosjekter var suksessfulle, ifølge en undersøkelse gjort av Dr Dobbs Journal. Jeg trodde tradisjonelle prosjekter gjorde det langt verre. Se http://www.ambysoft.com/surveys/success2007.html

45% av implementerte krav blir aldri brukt og 19% sjelden brukt. Altså, 64% av kravene som blir implementert blir aldri eller sjelden brukt!. Bare 7% av kravene som blir implementert blir alltid brukt. Dette ifølge Standish Group. Se http://www.agilemodeling.com/essays/examiningBRUF.htm

Når du gir noen et dokument, mistes 25% av informasjonen i det. Kanskje greit å presentere innholdet i dokumentet før du gir det videre?

90% av alle selskaper kjører fortsatt prosjekter etter vannfallsmetoden.

Bare 5-10% av definerte krav har kritisk innvirkning på løsningen. Det er disse du bør fokusere på først. Kan du finne dem?

Annen morsom (?) eller interessant statistikk?

Spørsmål om testing

Jeg har nettopp begynt å lese “Agile Testing” av Crispin og Gregory, og en av de første tingene de tar opp er spørsmål som test- og smidig-interesserte kanskje vil ha svar på.

Spørsmålene er:

  • Hva gjør testere hvis utviklerne skriver tester?
  • Jeg er en QA sjef, og mitt selskap implementerer smidig metodikk (scrum, XP, DSDM, e.l.). Hva er min rolle nå?
  • Jeg har jobbet som tester i prosjekter med tradisjonell vannfall-stil, og nå er jeg skikkelig gira på å teste ut smidig metodikk. Hva bør jeg vite for å jobbe på et smidig team?
  • Hva er en “smidig tester”?
  • Jeg er en utvikler på et smidig team, og mitt team har standardisert på å skrive tester først i utviklingen, men kunden er ikke fornøyd med leveransene. Hva er det vi går glipp av?
  • Jeg er en utvikler på et smidig team. Vi skriver testkode først og vi sørger for at all kode blir testet. Hvorfor trenger vi testere?
  • Jeg er Coach på et smidig prosjekt. QA-teamet klarer ikke å holde tritt med oss og testerne ligger også etter. Bør vi bare planlegge testing til etter utvikling?
  • Jeg er leder for en programutvklingsavdeling og vi gikk nettopp over til smidig metodikk. Så sluttet alle testerne. Hvorfor?
  • Jeg er en tester på et team som går over til smidig metodikk. Jeg har ingen kunnskaper om programmering eller automatisering. Har jeg noen plass på et smidig team?
  • Hvordan kan testing holde tritt med to-ukers iterasjoner?
  • Hva med lasttesting, ytelsestesting, brukervennlighetstesting, osv? Hvor passer disse inn?
  • Vi har krav til revisjon. Hvordan adresserer smidig utvikling og testing dette?

Etterhvert som jeg leser boka skal jeg forsøke å svare på disse og sikkert andre spørsmål!

lørdag 14. februar 2009

Hva er en god og smidig tester?

Jeg har tidligere skrevet litt om hvordan en god tester er. Men hvis man skal være en god OG smidig tester bør man kanskje ha noen tilleggsegenskaper? Eller er man egentlig en god tester om man ikke er smidig?

Noen karakteristikker av en god og smidig tester:

  1. Interessert i smidig metodikk (!)
  2. Diplomatisk
  3. Team-orientert (blandede team)
  4. Kan noe/mye om automatisering av testing
  5. Er ikke redd for endringer
  6. Er alltid ute etter å finne forbedringer

Jeg er ikke helt sikker på 2. Jo man skal være diplomatisk i all team-sammenheng, men også kunne stå for egne meninger og funn. Og selv om automatisering er ofte nevnt i smidig sammenheng, er det ikke bare smidig-interesserte som bruker dette, så 4 er heller ikke typisk for en smidig tester, men testere generelt.

Personlig synes jeg 3, 5 og 6 er de viktigste for smidige testere. Altfor mange utviklere og testere vil helst ikke jobbe i blandede team, jobber helst etter strikte planer og er overdrevent tro mot prosessene sine.

De 40 beste bloggene om automatisering av testing

Dmitry Motevich har laget en omfattende liste over blogger som inneholder godsaker for de med interesse for automatisert testing. Vel verdt en kikk!

Du finner lista her

Ta gjerne en titt på andre deler av bloggen hans. Det er mye verdi der.

Sitat:

Note: I understand that nothing is constant. And this list of Automated Testing Blogs should be updated periodically. Also I'm sure that some cool blogs are not present on this list.

Automatisering av testing med Microsoft Hyper-V

Developer.com har en interessant artikkel skrevet av Jani Järvinen som beskriver hvordan man kan bruke Hyper-V i testautomatisering. Ganske interessant og kanskje nyttig for mange. Automatisering av testing er snart nødvendig i alle prosjekter av middels til stor størrelse.

Les artikkelen her

Sitat:

Because Hyper-V easily supports multiple virtual machines and dozens of checkpoints (snapshots), you can automate testing of your applications. Automating user interface testing is, of course, more difficult, but even with these applications, being able to automatically configure the virtual testing environment can save a lot of time.

onsdag 11. februar 2009

Analyserer du prosesser vitenskapelig?

Eller tror du bare at du gjør dette?

Med stor interesse leser jeg en bok på toget for tiden som heter “The Halo Effect”, undertittel “How managers let themselves be deceived”. Den omhandler ekspertenes (og forsåvidt alles) tendens til å peke på høy finansiell ytelse for et selskap og så la gløden fra dette spre seg til selskapets alle attributter.

Konklusjon:

Verden er ikke så enkel som vi ønsker å tro, og ekspertuttalelser er ofte farget av selskapers suksess eller mislykkethet.

Et selskaps handlinger blir f.eks. skrytt opp i skyene så lenge selskapet gjør det bra, men de samme handlingene blir dømt nord og ned dersom de begynner å gjøre det dårlig.

Forfatter Rosenzweig forteller med treffende vittighet og med bakgrunn i fakta hvordan marked, ledelse og eksperter lar seg lure og hvordan metodene deres for analyse av årsaker til suksess/mislykkethet har fundamentale svakheter.

Her er det mye å lære på andre områder også, og ikke minst prosessanalyse/-forbedring. Eksempler:

  • Intervjuer av personer for å vurdere prosessers vellykkethet kan være svært lite vitenskapelig. Hvis prosjektet går bra er deltakerne lett positive til prosjektets prosesser og arbeidsmetodikk. Hvor mye skal du stole på deres evne til objektiv analyse?
  • Ett prosjekts vellykkethet kan synes å komme fra en eller et fåtall årsaker, men vil samme handlinger ha samme effekt i ditt prosjekt?
  • Det er gjerne mange årsaker til suksess, men det er fristende å peke på én, f.eks. innføring av Scrum. Hvilke årsaker til suksess henger sammen og på hvilken måte?
  • Hvis du analyserer suksessfulle prosjekter for å finne ut hvorfor de lyktes, bør du samtidig gjøre samme analyse på mindre suksessfulle prosjekter og prosjekter som gikk “OK” (dvs. det gikk ikke superbra, men bra nok). Du får ikke fokusert på faktiske årsaker til suksess ellers.
  • Hvis du har masse data for analysen er det bra hvis dataene er gode. Data farget av Halo-effekten er dårlige som grunnlag uansett hvor mye av disse dataene du har…
  • Hvor mye påvirkes ditt prosjekts suksess av andre prosjekter eller organisasjoner?

Sum: Du kan vitenskapelig bevise at vann koker i en kjele ved 100 grader. Du kan ikke like lett bevise hvorfor en organisasjon gjør det bra/dårlig eller vil gjøre det bra/dårlig i fremtiden.

God bok!

fredag 6. februar 2009

Hvor mye koster en feil?

Jeg tror alle vet at det er mye mer kostbart å finne feil i produksjon enn under utvikling, men hvor mye koster det egentlig?

Følgende bør tenkes på og sikkert mye mer:

  • Hvor mye koster tapet av anseelse?
  • Hvor mye tid bruker helpdesk på å forklare og hjelpe brukerne som blir utsatt for feilen?
  • Registreringen av feilen koster tid
  • Verifisering av feilen (forståelse) tar tid
  • Utvikling av fix tar tid.
  • Retesting tar tid
  • Release tar tid (utviklingsmiljø – staging – produksjon)
  • Dokumentasjon bør oppdateres
  • Og hvor mye koster en utvikler eller tester egentlig?
    • Lønn
    • Rekvisita
    • Lisenser
    • Forsikringer
    • Møbler
    • Kurs
    • Bøker
    • PC!
    • Strøm
    • Varme
  • Ikke-produktiv tid

Hva annet koster?

torsdag 5. februar 2009

Blir alle bugs/incidents rapportert som “middels alvorlig”?

I det siste har jeg sittet gjennom et kurs i Test Management som et ledd i sertifisering som

ISTQB Certified Tester Advanced Level

En viktig del av dette kurset er Incident Management, og dermed rapportering. Vi kom i den forbindelse inn på alvorlighetsgrader, og hvilke man bør ha. Sertifiseringen krever ingen spesiell liste over nivåer eller et visst antall, men i kurset kom det fram et greit tips:

Alltid ha et partall antall nivåer alvorlighetsgrad

Altså, ikke velg 3, 5, 7, osv, men velg istedet 4, 6, 8, osv. Fire synes å være et greit antall, forøvrig. Grunnen til denne tommelfingerregelen er enkel:

Brukerne har altfor lett for å legge inn en feil som middels viktig. Enten fordi de ikke vet bedre, eller fordi de er late. Så velg istedet f.eks. disse nivåene:

  1. Kritisk
  2. Alvorlig
  3. Mindre alvorlig
  4. Kosmetisk

Noe annet er prosjekter hvor testerne/kunden synes det er best å rapportere alt som “kritisk” for å få fortgang i fiksingen, men det er et annet problem…