Om kvalitet

ISTQB Certified Tester Advanced Level?

2009-03-08T12:34:00.001+01:00

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.

ISO 9126 Attributter for programvarekvalitet og karakteristikker

2009-03-03T13:20:00.001+01:00

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.

En time med Elisabeth Hendrickson om Agile Testing

2009-02-28T13:18:00.001+01:00

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

Perfekt testing

2009-02-27T14:14:00.001+01:00

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:

Testbarhet i virkeligheten

2009-02-25T09:41:00.001+01:00

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

2009-02-25T09:23:00.001+01:00

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

2009-02-25T09:14:00.001+01:00

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

Historiens verste programvarefeil

2009-02-20T13:28:00.001+01:00

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

2009-02-20T13:18:00.001+01:00

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

2009-02-20T12:19:00.001+01:00

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!

Hva er en god og smidig tester?

2009-02-14T21:48:00.001+01:00

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:

Interessert i smidig metodikk (!)
Diplomatisk
Team-orientert (blandede team)
Kan noe/mye om automatisering av testing
Er ikke redd for endringer
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

2009-02-14T21:37:00.001+01:00

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

2009-02-14T21:33:00.001+01:00

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.

Analyserer du prosesser vitenskapelig?

2009-02-11T09:34:00.001+01:00

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!

Hvor mye koster en feil?

2009-02-06T10:50:00.001+01:00

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?

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

2009-02-05T13:39:00.002+01:00

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:

Kritisk
Alvorlig
Mindre alvorlig
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…

Hva er egentlig en enhetstest?

2008-11-26T09:35:00.003+01:00

Det kan synes rart for mange at det (fortsatt) er diskusjon om hva en enhetstest er og hva en integrasjonstest er. Flytende overganger mellom de to forkludrer forståelsen noe.

Mange utviklere mener alt som ikke kan enkelt automatiseres er en integrasjonstest. Som database og GUI. Men i det øyeblikket det er mulig å automatisere testing av slikt blir de enhetstester? For det er jo nok av verktøy og metoder for automatisering av både database og GUI.

Definert i f.eks. Wikipedia er enhetstester selvsagt all testing som verifiserer enkeltdeler i en applikasjon for seg. Tester du en funksjon isolert og ikke dens kommunikasjon med andre funksjoner eller objekter er det enhetstesting. Når blir en test av en funksjon til en integrasjonstest?

Integrasjonstesting handler om testing av modulers samspill i gruppe. Er du tester og leser dette tenker du sikkert "hva er en modul?". I utgangspunktet er dette bare de samme enhetene som i enhetstesting, men testet i gruppe.

Er det viktig å vite forskjellen? Kanskje ikke så mye for den enkelte utvikler, men i kontraktssammenheng kan det være fantastisk viktig. Kontraktsfester man et nivå av integrasjonstesting vil det jo selvsagt være viktig å vite hva man definerer som enhetstesting og hva som er integrasjonstesting, og det blir fort mye tester. Et stort system koster mye å teste.

Threat Modelling

2008-11-12T17:38:00.001+01:00

Jeg er en tur på TechEd2008 i Barcelona, og her er det ogå mye om kvalitet!

En av dagens sesjoner var
"How I learned to Stop Worrying and Love Threat Modeling" av Michael Howard

Sesjonen startet med en liten historie om hvordan MS har endret sine interne sikkerhetsanalyserutiner til å bli SDL-orientert og at Threat Modeling skulle gjøres av alle utviklingsteam. SDL = Security Development Lifecycle

SDL kan brukes på

Programvare som skal selges til sluttbruker, onlinetjenester, ja alt av programvare
Dekker alt fra start av utvikling til utsending/deployment og oppdateringer
Gjør Threat Modeling i design

Denne prosessen bør brukes av alle, mener Michael, og peker på følgende grunner:

Programvaren blir designet sikker
Angriperne tenker anderledes (enn du tror)
Finner sikkerhetsproblemer tidlig
Færre designfeil
Optimaliserer planlegging av sikkerhetstesting

SDL er iterativ, og man går gjennom fasene

Visjon
Modellering
Identifisering av trusler
Fjerne problemer
Validere

Det som er spesielt viktig å komme frem til er forståelse av sikkerhetsgrensesetting (sammensatte ord er flotte greier).
"Trust Boundaries" ligger på områdene

Integritet/rettigheter
Sesjon
Filsystem
Nettverk

For å finne sikkerhetsproblemer eller områder man bør teste for sikkerhet har MS laget et gratisverktøy de kaller Threat Modeling Tool (TMT). Det ligner på et vanlig modelleringsverktøy, men rettet mot modellering av applikasjoner og moduler ift sikkerhet.
Med TMT kan du

Modellere applikasjonen eller deler av den
Gi deg råd om modellen og dens innhold (et datalager kan ikke snakke med et annet datalager, så du trenger en prosess, som igjen kan ha sikkerhetsproblemer, osv)
Finne områder med potensielle sikkerhetsproblemer
Registrere defects for utviklerne slik at de kan jobbe videre med saken
Lenke til avhengigheter
Legge til antagelser (man ønsker å registrere hva designeren tenkte, spesielt når et sikkerhetsproblem blir ansett som lite)
Analysere trusler
Rapportere om trusler og applikasjonen ift trusler
Få forslag til områder som trenger kryptering/sikring
Lese hjelp for SDL
Se trusselmodellen til TMT!

TMT kan finnes her: http://msdn.microsoft.com/en-us/security/dd206731.aspx
Mer info her: http://blogs.msdn.com/threatmodeling/

Krav til krav

2008-10-23T10:40:00.001+02:00

Krav er et ladet ord og tolket forskjellig ift din bakgrunn og filosofi. Tradisjonell systemutvikling har en egen kravspesifikasjonsfase, hvor man forventer at alle krav skal finnes og beskrives. Vi vet alle at slikt sjelden fungerer særlig bra, og derfor har da også "Agile" dukket opp som en antatt bedre filosofi hvor krav stort sett utvikles underveis og beskrives som "user stories".

Men uansett hvilken filosofi du følger, må du ha krav i en eller annen form, og hvordan kan man si om et krav er godt spesifisert eller ikke? Her er det viktig at testerne kommer inn og verifiserer krav. I ett forum ble det foreslått en verifisering omtrent slik:

Er kravet

Specific
Measurable
Achievable
Relevant
Testable

?

Nei på en av disse bør føre til noe omskriving. Kravet er kun godkjent om alle SMART-kravene er oppfylt.

God ide?

Testere er idioter. Slitsomme og pirkende!

2008-10-22T15:07:00.001+02:00

En tester kommer med et hjertesukk fra en konferanse:
http://www.sdtimes.com/content/article.aspx?ArticleID=31789

That’s right: Testers are idiots. The practice of testing offers no innovation. Testing is boring, manual and repetitive. It’s not a career. Testers aren’t as smart as developers. They’re nit-picky, pencil-pushing quality/process geeks. They’re beside the point and are easily replaced. Testing is not a career; it’s a necessary evil between application users and the brilliance of developers.

Enda et sitat: Hvorfor utviklerne ikke kan "stoles på" som testere

2008-10-22T14:55:00.001+02:00

"If you think you can fully test a program without testing its response to every possible input, fine. Give us a list of your test cases. We can write a program that will pass all your tests but still fail spectacularly on an input you missed. If we can do this deliberately, our contention is that we or other programmers can do it accidentally."- Cem Kaner, Jack Falk, and Hung Quoc Nguyen,Testing Computer Software, Second Edition, 1999

The Antonym Of Testing

2008-10-22T14:41:00.000+02:00

"... one usually encounters a definition such as, 'Testing is the process of confirming that a program is correct. It is the demonstration that errors are not present.' The main trouble with this definition is that it is totally wrong; in fact, it almost defines the antonym of testing."- Glenford Myers, Software Reliability: Principles & Practices, 1976
Godt sagt!

Microsoft har blitt medlem i OMG

2008-10-17T11:10:00.002+02:00

Hvorfor har jeg ikke oppdaget dette før? Microsoft har meldt seg inn i OMG (Object Management Group). Dette sees som en av aksjonspunktene for fremming/forbedring av deres modelleringsspråk, og spesifikt Oslo.

Pressemelding

TDD er ikke testing!

2008-10-17T11:05:00.002+02:00

Pga sitt noe uheldige navn, blir ofte TDD - Test Driven Development, misforstått som testing. Men egentlig er det en designteknikk.

Som Jeff Patton beskriver her:
Test-Driven Development Isn’t Testing

Sitat:
For a few years I've been using unit testing frameworks and test-driven development and encouraging others to do the same. The common predictable objections are "Writing unit tests takes too much time," or "How could I write tests first if I don’t know what it does yet?" And then there's the popular excuse: "Unit tests won't catch all the bugs." The sad misconception is that test-driven development is testing, which is understandable given the unfortunate name of the technique.

Kommentarene er også verdt å lese.

F.eks.:
I'm sure there's a way to write unit tests that really "shine a light into every corner of the room." In practice, I haven't observed it.

Kansellering av teknologiprosjekter

2008-10-17T10:08:00.002+02:00

En undersøkelse gjort i USA viser skremmende tall på hvor mange teknologiprosjekter som bare blir stoppet og det er like skremmende, men ikke overraskende, hva årsakene er.

43% av de spurte bedriftene hadde avsluttet et teknologiprosjekt før normal avslutning! Det er nesten halvparten. Det skulle vært interessant å se statistikk fra Norge.

30% ble avsluttet pga endrede forretningsbehov
23% ble avsluttet fordi det ikke leverte som lovet
13% ble avsluttet pga budsjettoverskridelser (!)

Fæle tall. Jeg har forsøkt å finne mer informasjon om dette, men det er smått. Det hadde f.eks. vært interessant å finne litt mer detaljer om hvordan prosjektene ble styrt.

Kort artikkel:
http://www.itarchitect.co.uk/news/display.asp?id=426