Anne Mette Hass

En teststrategi skal være risikobaseret

Hej Henning,

Begge strategier, både den overordnede og den projektspecifikke (som du kalder 'den rigtige'), skal have et indhold, der er rettet mod risikonedsættelse. Jeg har kun forholdt mig til overskrifter i den overordnede strategi, og disse er ganske rigtig fra ISO 29119. Det kan overskrifterne i den projektspecifikke strategi også være. Indholdet i den overordnede strategi baserer sig på organisationens overordnede holdning til risikohåndtering, mens indholdet i den projektspecifikke strategi og i plan baserer sig på projektspecifikke produktrisici. Sådan går det hele op. Venlig hilsen Anne Mette

27. september 2013 kl. 15:40
Fagbøger er vist et overset gode

Hej Mia,

Hvor er det spændende, at I vil skrive om test og endda uden at have haft et fag om det. (Det er ufatteligt, at IT uddannelser stadig gennemføres uden test, men det er en anden historie).

Der er masser af test bøger på markedet, men svært at vide, hvor man skal begynde. Hvis I skriver til mid direkte på annemettehass@gmail.com kan jeg anbefale jer nogen og også tilbyde jer forskelligt materiale.

Rigtig god fornøjelse med jres projekt!

Venlig hilsen Anne Mette

24. september 2013 kl. 09:38
Mange virksomheder tester i mørke.

Hej Jens, Godt spørgsmål. Det lette svar er udarbejdelse af en testpolitik og -strategi. Med det mener jeg, at ledelsens aktive stillingtagen til hvordan man vil tilrettelægge sin test, er det første trin og et vigtigt signal om, at her tager vi test alvorligt. Det næste trin er, at ledelsen efterspørger tal, der viser, at ordentlig test ikke gør et produkt dyrere, men derimod billigere. Det er min erfaring og faste overbevisning, at det hænger sådan sammen. Det, det handler om for ledelse og testere, er at slippe den myte, der siger, at test gør et produkt dyrere. Det er simpelt hen forkert. Venlig hilsen Anne Mette

24. september 2013 kl. 09:33
Mange virksomheder tester i mørke.

Hej Henning, Tak for din kommentar. Jeg er helt enig med dig i, at kontinuerlig forbedring af testarbejdet er meget vigtigt, og den eneste grund til, at det ikke er med endnu, er, at de i ISO standarden er placeret i den overordnede strategi - så det kommer i næste ombæring. Tak for dine råd om testhåndbog. Jeg er dog lidt forvirret i forhold til, at en testhåndbog skulle være mere tilgængelig for ikke test-kyndige. Min forståelse af en testhåndbog er, at den er for de kyndige, mens politik og strategi er for de ikke-så-kyndige. Men jeg har måske misforstået dig?

I øvrigt bør en politik ikke fylde mere end 1-2 sider, og en strategi ikke mere end 8-10 sider, gerne mindre.

Mange hilsner og god weekend, Anne Mette

20. september 2013 kl. 15:39
Mange virksomheder tester i mørke.

Hej Jan,

Tak for dit spørgsmål. Det jeg mener er, at både politik og strategi skal være udformet sådan, at de ikke skal ændres tit. Men de skal selvfølgelig heller ikke være ridset i sten, så hvis organisationen f.eks. bliver omstruktureret eller begynder at fremstille en anden slags it-system, skal politikken og/eller strategien tilrettes.

20. september 2013 kl. 09:13
Fagbøger er vist et overset gode

Hej alle,

Tak for spændende indlæg!

Jeg kan anbefale mange testbøger, men det ville omfatte at anbefale min egen, så jeg tror, jeg afholder mig fra det.

Jeg er helt enig i, at bøger og internet supplerer hinanden på den beskrevne måde: bøger giver overblik og internettet kan give dybde på områder man gerne vil beskæftige sig mere med.

Måske er det med bøger som med (livs)erfaring i almindelighed. Vi gamle, der har samlet erfaring og overblik, vil gerne give det videre til de yngre, måske for at gøre deres indgang til test lettere og for at forsøge at undgå, at de begår nogle af de fejl, vi selv begik; mens de, der er på vej, gerne vil gøre deres egne erfaringer. Jeg tror, at en blanding af bøger, eget arbejde og sund fornuft er det bedste.

Er der nogen, der har erfaringer med fagbøger som e-bøger? Virker det?

(Og prøv at skrue ned for sarkasmen, det er en overflødig barriere i forståelsen mellem mennesker - især på skrift :-) )

Mange hilsner Anne Mette

29. april 2013 kl. 10:16
Hvordan kan man leve uden sporing?

Hej Lars, Det lyder meget spændende med dit værktøj - det vil jeg gerne høre mere om! Venlig hilsen Anne Mette

17. januar 2013 kl. 10:58
Er livet for kort til en softwaretest standard?

Udviklingen går ikke så hurtigt, som mange tror. Det grundlæggende i test forandres ikke over få år, og brugen af standarden kan altid tilpasses, hvis der skulle være noget, man ikke har lyst til at bruge.

De spredte standarder, testere hidtil har brugt, er for fleres vedkommende over 20 år gamle; og de virker ikke specielt forældede - bare inkonsistente og mere ufuldstændige end den nye.

En standard er forøvrigt et levende dokument, der bliver opdateret løbende, når nye ideer har vist deres værd. AM

12. juni 2012 kl. 16:28
Er livet for kort til en softwaretest standard?

Erfaring - erfaring - erfaring. AM

12. juni 2012 kl. 16:23
Der er håb for de offentlige projekter!

Hej Kenneth Holm Nielsen!

Dejligt med en nysgerrig læser. Jeg skal med glæde forsøge at svare på dine spørgsmål.

550 krav er hverken meget eller lidt. Jeg har set projekter med 30 krav og projekter med over 1000. Det var bare for at give en størrelsesorden. I de offentlige udbud er kravene nummereret helt klart, så på den måde er det let at se, hvad der er et krav. Underliggende er der dog ofte det problem, at kravene ikke er atomare, dvs. at der i virkeligheden kan være mange krav under et nummer. En tommelfinderregel for at tælle er, at der er tale om ét krav, hvis man kan besvare om kravet er opfyldt med ÉT ja eller ÈT nej.

Jeg må ikke røbe for meget om projektet, men det er et ret forretningskritisk system forstået på den måde, at det almindelige daglige arbejde ikke vil kunne udføres for de over 5000 direkte brugere, hvis systemet ikke virker. Med op mod 1 mill. mennesker, der er mere eller mindre afhængige af, at disse brugere kan udføre deres arbejde, er konsekvensen af, at systemet ikke virker, alvorlig. I kontrakten står der faktisk at alle krav skal testes, så en håndhævet dækning på 80% skulle ikke vælte leverandøren af pinden.

Man kan spore mellem test og krav på mange måder. I dette projekt er der brugt Excel, og det virker nogenlunde. Det er ret nemt at udføre denne sporing, når man sidder og skriver testcases udfra kravene - og det er jo det, man skal gøre. Leverandøren bliver (i alt fald i dette projekt) udtrykkeligt bedt om at levere en sporingsliste i kontrakten, så det skulle helst ikke komme som en overraskelse (der er ikke krav om hvordan). Desværre er der ikke så mange hverken leverandører eller kunder, der ved hvad en sporingsliste er, så det er sjældent, at dette bliver håndhævet og checket.

Jeg håber, dette kaster lidt lys over sagen, og at brugen af sporing vil brede sig som en steppebrand hos kunderne. Det er et ret nemt og meget stærkt værktøj til at få information om leverandørens modenhed og generelle kvalitetsniveau.

Mange hilsner Anne Mette

3. maj 2012 kl. 10:00
Store huller i testen - hvad er problemet?

Ja, det har jeg. Og du har ret i dine 2 første påstande: emnet for min blog er test, derfor handler indlæggene om det, jeg oplever i forbindelse med test.

Test er vigtigt for mig; det er derfor jeg blogger om det. Test kan bære al den vigtighed, det skal være. Men jeg anerkender selvfølgelig, at test ikke er lige vigtigt for alle.

Man kan sagtens arbejde med at få en god brugeroplevelse inden man slipper et system løs; der er en del teknikker til at vurdere om et bud på en brugergrænseflade er godt i forhold til brugernes behov. Det kan gøres med simple prototyper, hvilket burde være en del af ethvert kravarbejde, og meget billigere end at kode noget, sende det ud, og få det tilbage i hovedet igen. AM

30. marts 2012 kl. 11:30
Store huller i testen - hvad er problemet?

Jeg synes, det er tankevækkende, at stort set alle mine indlæg om test lynhurtigt drejer over i diskussioner om krav!

Hvis vi nu antog, at kravene var udtryk for brugernes behov - hvordan skulle man så forholde sig til test?

AM

29. marts 2012 kl. 15:36
Påvirk fremtidens test

Hej Lucas,

Flere af deltagerne i ISO arbejdsgruppen har også deltaget i ISTQB arbejde, og de kender selvfølgelig ISTQB vældig godt. Der er i nogen grad taget udgangspunkt i ISTQB, bl.a. ordlisten. Herudover har alle, også ISTQB-folk haft rig lejlighed til at kommentere udkastene undervejs, og det har de også gjort.

ISO gruppen har aftalt med ISTQB, at de kunne sende en deltager til gruppen, men der er nu ikke kommet nogen. ISTQB har dog sagt, at de vil rette ISTQB mod ISO-standarden, når den kommer.

AM

28. februar 2012 kl. 18:00
Påvirk fremtidens test

Hej Frederik,

Jeg kunne godt tænke mig at høre, hvad du mener standarden forsøger at løse; det kunne måske afgøre, om vi taler forbi hinanden eller har fælles forståelse.

Vh Anne Mette

28. februar 2012 kl. 17:55
Påvirk fremtidens test

Hej Jan,

Du må meget gerne uddybe, hvad du mener med "softwareudviklingsprocessens natur". Jeg indrømmer, at jeg efter mere end 30 år i branchen ikke ved, hvad du mener.

Min holdning er, at test altid er nødvendigt - ligegyldigt, hvad vi mennesker foretager os - fordi vi ikker er perfekte, men begår fejl selv om vi gør os umage og har de bedste betingelser. Det er der ikke noget at gøre ved; vi må tage det til efterretning og tage vores forholdsregler, så så få fejl som muligt kommer ud til brugerne.

Tak for støtten, Mogens og Fredrik!

27. februar 2012 kl. 17:26
Påvirk fremtidens test

Hold da op, Jan; du har da vist 'a chip on your shoulder' - det må ikke være rart.

Jeg opfatter ikke mig selv som hverken en oldsag eller talentløs eller taber. Og sådan opfatter jeg heller ikke de andre i arbejdsgruppen - tværtimod! Vi er om ikke unge, så i vores bedste aldre, meget erfarne, og alle med (i al beskedenhed) ret fantastiske karrierer inden for IT.

Måske skulle du bidrage med din erfaring, så du kan få en lidt bedre fornemmelse af, hvordan sådan et arbejde forløber.

Jeg ville ønske, standarden blev om ikke obligatorisk så i alt fald vejledende, både for det offentlig og det private, så alt for mange ikke skal bruge tid på at opfinde mere eller mindre underlige dybe tallerkner igen og igen.

27. februar 2012 kl. 13:20
Lidt (test-)sjov til vinterferien

Så er jeg tilbage efter næsten en uge UDEN PC. Min PC 'døde' en af de første dage, og det blev en rigtig dejlig ferie.

Her er de faldgruber i IT udvikling, som jeg synes, Monty Python får mig til at tænke på (anden kolonne er tid inde i klippet):

  1. 0:10 Scope (”curtains” vs. ”all you can see”)
  2. 0:19 Stakeholder analysis and understanding (mix-up of names)
  3. 0:22 Goals (“all this will be yours” vs. “I don’t want any of that” and more examples)
  4. 0:40 Learning from experience (build two castles which sank into the swamp, despite warnings)
  5. 1:31 Glossary (body language Vs. spoken words)
  6. 1:43 Verifiable requirements (“to have that 'certain special something' ” is not easy to test objectively)
  7. 2:01 Documented requirements (orally expressed requirements are difficult to remember and agree on)
  8. 2:01 Risk analysis (there is a first sign of a risk here – and the general understanding between the stakeholders also suggests that a risk analysis would be of value)
  9. 2:35 Mixing expression techniques (the king does not change the way he expresses his requirement, though he is clearly not getting his message across)
  10. 3:46 Event handling (the hiccups of the guard finally makes the king ask him to leave in desperation, though he has just spend more than 2 ½ minutes asking him to stay)
20. februar 2012 kl. 13:24
Ud med V-modellen!

Lige en lille bemærkning med på vejen.

Mængden af test bestemmer, hvormeget man kan sige om produktets kvalitet. Det er det, der er formålet med testen: at skaffe information om, hvilken kvalitet produktet havde på det tidspunkt, hvor testen blev gennemført.

Herfra kan 'man' så vælge at leve med den opnåede kvalitet eller forbedre den.

Dette er IKKE for at starte en diskussion om, hvad kvalitet er - sådanne diskussioner er der allerede (for?) mange af.

AM

2. februar 2012 kl. 12:09
Ud med V-modellen!

Når jeg så tidligere sagde at vandfald (V-modellen er bare en anden måde at optegne vndfaldsmodellen på - man kan godt tro anderledes, men det er bedrag), godt kan give mening. Så er der projekter der kan laves i totalt vakum, hvor man kan lave en specifikation, og så implementere løsningen.

Uha, der er vist et par ikke helt ualmindelig misforståelser her. V-modellen er absolut ikke bare en anden mde at tegne vandfaldmodellen på! Det er netop derfor, vi må finde en anden måde at tegne test som en underliggende aktivitet under alle de andre aktiviteter - og her mener jeg både statisk test (altså review) og dynamisk test. Der kan desuden sagtens være tilbageløb i V-modellen; dummere er projektledere og udviklere altså heller ikke.

Og - NEJ - testere skal ikke diktere udviklingsforløbet. Vi skal passe testen ind i det udviklingsforløb der er besluttet for det projekt, vi deltager i, således at der bliver testet i forhold til formålet for alle de faser, der måtte være relevante i et projekt. Tegningerne er jo kun principskitser. Der kan være fra nogle få faser til mange faser i et givet projekt; det er bestemt af produktets natur og andre faktorer, men ikke af test.

Er der ikke andre, der har en holdning til V-modellen?

AM

1. februar 2012 kl. 16:31
Ud med V-modellen!

Hej,

Det var nu ikke min mening at hænge opfinderne af vandfaldsmodellen ud. Jeg ville bare give et historisk rids. Alting skal jo starte et sted, og derfra bliver vi forhåbentlig klogere og klogere på området. Det er der ikke noget galt i, tværtimod.
Med vandfaldsmodellen kom test på banen, og det var godt! Men det er da lidt trist at miste interessen, bare fordi udviklingen går videre. Det er da noget, man skulle glæde sig over, synes jeg. AM

31. januar 2012 kl. 16:37