onsdag 26. november 2008

Hva er egentlig en enhetstest?

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.

onsdag 12. november 2008

Threat Modelling

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/

torsdag 23. oktober 2008

Krav til krav

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?

onsdag 22. oktober 2008

Testere er idioter. Slitsomme og pirkende!

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

"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

"... 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!

fredag 17. oktober 2008

Microsoft har blitt medlem i OMG

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!

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

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

torsdag 16. oktober 2008

Estimering og prosjektoppstart

Litt på siden av kvalitet, men likevel en god artikkel i prosjektsammenheng. Peter Clark kommer med et scenario som er altfor typisk:
Take Time to Make Time

Lover og prinsipper for testing

Det finnes mange forslag til en "lov om testing", men her er en som er grei å huske:


  1. Ikke alle tester som passerte første gang vil passere andre gang.
  2. Hva som vil fungere i hodet til en utvikler vil ikke nødvendigvis fungere i praksis.
  3. En datamaskin lar deg gjøre feil fortere enn noen annen oppfinnelse!
  4. Hvis du ikke kan teste programvaren du lager så bør du ikke lage den.
  5. Testing slutter aldri. Den bare stopper.
  6. Det finnes alltid omstendigheter hvor programvaren vil feile.

Hvilke andre har vi?

Så la oss se på noen nyttige prinsipper for programvaretesting:

  • En nødvendig del av et testcase er en definisjon av hva forventet output skal være.
  • En programmerer bør unngå å teste sin egen programvare. Vi ser bort fra standard enhets- og integrasjonstesting som programmereren gjør selv.
  • En programmeringsorganisasjon bør unngå å teste egne leveranser.
  • Gå nøye gjennom resultater fra tester.
  • Testcase bør skrives for å teste ugyldig og ikke forventet, samt gyldig og forventet, input.
  • Å teste om et program ikke gjør det den skal gjøre er bare halve jobben. Den andre halvdelen av jobben er å se om den gjør hva den ikke bør gjøre.
  • Unngå bruk-og-kast testcaser. Såsant programmet som blir levert ikke er bruk-og-kast programvare.
  • Planlegg ikke for en testinnsats under antagelsen om at ingen feil vil bli funnet.
  • Sannsynligheten for at det finnes flere feil i en del av et program er direkte proporsjonal til antallet feil allerede funnet i samme del.
  • Testing er en ekstremt kreativ og intellektuell øvelse!
  • Testing er jobben med å kjøre et program med intensjonen om å finne feil.
  • Et godt testcase er et med høy sannsynlighet for å finne uoppdagede feil.
  • Et suksessfullt testcase er et som finner uoppdagede feil.

Kan dere finne flere gode prinsipper?

onsdag 15. oktober 2008

Dejter du en tester?

Denne har vært postert "utallige" ganger, men jeg må nesten ha den med her også:

Fra http://www.romsteady.net/blog/2005/02/testing-top-10-lists-1.html

Top 10 Signs That You're Dating A Tester
10. Your love letters get returned to you marked up with red ink, highlighting your grammar and spelling mistakes.
9. When you complain about him spending too much time with you, he replies that he's in the middle of a soak test.
8. He keeps asking for a "spec" so he'll know how his "harness" should "interface" with you.
7. He'll always do something wrong twice so he can provide accurate repro steps.
6. When you tell him that you won't change something, he'll offer to allow you two other flaws in exchange for changing this one.
5. When you ask him how you look in an outfit, he'll actually tell you.
4. When you give him the "It's not you, it's me" breakup line, he'll agree with you and give specifics.
3. He won't help change a burned out lightbulb because his job is simply to report that it's burned out.
2. He'll keep bringing up old problems that you've since worked out just to make sure that they're still gone.

...and the number one way to tell you're dating a tester...

1. In the bedroom, he keeps "probing" the incorrect "input."

Hvorfor er prosess så viktig?

Innen IT, og mange andre områder, er det svært viktig at vi vet hva vi gjør. Det er like viktig å vite, registrere og forstå hva vi har gjort og hvordan vi gjorde det. Dette er essensen i balansert kontroll med god ledelse og for å oppnå dette må vi sikre at vi følger en definert, konsistent og repeterbar prosess.

Prosessen er der for å hjelpe folk og den har noen svært viktige attributter som er essensielle for kvalitetsleveranse av tjenester/løsninger.

Prosesser er:
  • Repeterbare
  • Konsistente
  • Pålitelige
  • Granskbare
  • Forståelige

Prosesser kan være:
  • Kontrollerte
  • Automatiserte
  • Strømlinjeformede
  • Overvåkede
  • Utviklet

Gode prosesser er:
  • Overensstemmende (følger lover, regler, rutinebeskrivelser, o.l.)
  • Mulige å vedlikeholde
  • Levende (videreutvikles, forbedres)
  • Felles for alle nødvendige
  • Støttet av organisasjonen(e) de tilhører

Et svært viktig attributt ved en god prosess er at den er målbar mot et akseptert kriteria eller en akseptert standard.

Si nå at vi har jobbet oss frem til et sett med prosesser som følger de ovenstående prinsipper for "gode prosesser", men det fungerer bare ikke ift tidsforbruk. Prosessene tar for mye tid og gir ikke de resultatene vi trenger. Hva gjør vi galt?

Typiske feil som gjøres (og har vært gjort av meg selv) er:
  • For mye detaljer! Du ønsker å lage en kjempefin prosess som tar med seg alle mulige veier i arbeidet og alle eventualiteter, og ender opp med noe som tar hensyn til alt....bortsett fra viktigheten av forenkling.
  • For mange prosesser! Spesielt et problem i store prosjekter der det ER mange prosesser i utgangspunktet. Prøv å forenkle arbeidsprosessene med et etablert sett med prinsipper. Dermed trenger ikke alle prosesser å defineres, fordi vi f.eks. følger Scrum, Evo, osv.
  • Altfor mange gir blaffen i prosessdefinisjonene dine! Metodikk og prosess må følges opp etter en initiell "buy-in" blant de involverte. Mange har grunner, og noen ganger gode grunner, for ikke å følge prosessdefinisjonene. Ta hensyn til disse! Snakk med de og se hva du kan lære og endre. Er det noen som ikke forstår prosessene?
  • Prosessene endres for ofte! Dette skaper ofte frustrasjon og spesielt (igjen) i større prosjekter hvor prosessendringer ikke blir opptatt så fort som i mindre. Vær sikker på at alle er med på endringene, følg opp personlig, og gjør justeringer.
Hva annet bør vi tenke på?