www.softwaretestforum.dk Forum Index www.softwaretestforum.dk
Virtuelle netværks forum for dem som arbejder professionelt med QA og software test
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Pre and postcondition for løsningskrav

 
Post new topic   Reply to topic    www.softwaretestforum.dk Forum Index -> Teknikker til test
View previous topic :: View next topic  
Author Message
Kim Hjortholm



Joined: 29 Jul 2009
Posts: 2

PostPosted: Wed Aug 05, 2009 12:18 pm    Post subject: Pre and postcondition for løsningskrav Reply with quote

Spørgsmål til best practice for angivelse af pre- and postcondition for løsningskrav til et businessflow.

Vi er igang med at formulere testkrav til hvordan accepkriterier med tilhørende pre- og postcondtion specificeres i udvikling af en SAP løsning hvor vi har løsningskrav på procesniveau med mere eller mindre komplicerede procesflow.
I det enkelt flows kan være adskellige decionspoints der giver mulighed for forskellige varianter af gennemløb af det samlet flow (alternate flows). Eksempelvis indhentning af supplerende information fra anden myndighed/borger, beregning af skat, etc..

Hvis accepkriterier med tilhørende pre- og postconditions for den enkelte proces skal angives for valide kombinationer af gennemløb vil det for enkelte processer betyde 100+ varianter af accepkriterier med tilhørende pre- og postcondtioner.

Et alternativ til ovenstående er at angive accepkriterie for hvert endpoint i processen og for hvert decisionpoint i flowet angive pre- og postcondtion (hvoraf krav til data/startbetingelser kan udledes for at det pågældende alternate flow eksekveres)

Så for at summere op;
Hvad er best practice for løsningskrav mht angivelse af pre- and postcondition for et businessflow med flere alternate flows (muligheder for gennemløbsveje)?

_________________
"To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the good tester, the glass is twice as big as it needs to be."
Back to top
View user's profile Send private message Visit poster's website
Bjarne Lykkegaard
Bruger på niveau 1
Bruger på niveau 1


Joined: 01 Aug 2008
Posts: 14
Location: Randers

PostPosted: Wed Aug 19, 2009 1:18 pm    Post subject: pre- og postconditions Reply with quote

Jeg tror ikke du finder nogen nem måde at gøre det på. Hvis jeg forstår dig rigtigt, så vil du gerne undgå en stor mængde Test Cases med hver sine pre- og postconditions.

Man kan reducere antallet af test cases ved, at beskrive selve testaktiviteten på en generisk måde. Beskrivelsen kan således anvendes mange steder.

Et decionspoint der giver mulighed for, at bevæge sig i forskellig retning ren brugermæssigt, vil give en tilhørende postcondition for hver retning. Man må således kunne opbygge en matrix hvor de generiske testbeskrivesler indgår, og selve matrix’en angiver så hvilke pre- og postcondtions der er gældene i hver enket retning man kan bevæge sig.

Men for mig at se, må det være vanskeligt, at opsætte pre- og postcondions til løsningskrav og forretningsbaserede krav. Du må vel skulle nedbryde hver enkelt krav til noget der er brugbart til at definere dine pre- og postcondions. For mig at se, kræver det et team af folk der kender forretningsprocessen, folk der har indsigt i det tekniske setup/miljø, ABAP udvilkere, testere, samt gerne nogen der ved noget om usability. En pre-condition kunne vel f.eks. være stor load på en database, mens en given aktivitet udføres - hvordan vil du specificere dette load på en pålidelig måde ?

Der må være andre i dette forum som har erfaring med test af forretningsprocesser, og således kan bidrage med idéer. Det kuinne være spændende at høre om nogle måder at gøre det på.
Jeg har ikke selv erfaring med test af forretningsprocesser, men umiddelbart vil jeg mener, at man kan tage udgangspunkt i de traditionelle testmetoder.

Jeg syntes at opleve, at man ved SAP baserede systemer, ofte kun laver forretningsbaseret test. Det er selvfølgelig også vigtigt, at systemet kan håndtere de processer der måtte være hos en kommunal myndighed, eller anden form for organisation. Men jeg syntes at fornemme, at de tradiotionelle testmetoder er trængt i baggrunden - eller er det kun mig der oplever, at det er let at få en SAP application til at fryse, crashe eller på anden måde komme i en mystisk state ?
Eller også præsenterer systemet brugeren for fuldstændig irrelevante valgmuligheder, ved en given aktivetet/handling.
Nu har jeg ikke den store erfaring med disse systemer - men jeg fornemmer, at det ikke kræver meget testaktivitet, at få et sådan system i en uhensigtmæssig tilstand.
Der hvor brugeren har mulighed for at indtaste data, virker det som om man ikke har testet: data type, felt længde, standard værdier, obligatorisk eller valgfri, specielle tegn og formater.
Det ses også, at visse date skal indtastes selvom aktuelle data er tilgængelig i systemet. Dette må være et irritationsmoment og spiltid hos slutbrugeren.
Det virker ikke altid som om, at de mennesker der arbejder med disse systemer i det daglige (slutbrugere), er specielt tilfredse med dem - eller har jeg en forkert opfattelse ?
Hvis min opfattelse er rigtig, så må der være noget galt med den måde man håntere testen af systemerne på. Men det er en hel anden snak...

Generelt opbygger jeg selv tests således, at jeg udarbejder en række test cases der tester funktionaliteten "straight forward", samt en række validerings test, negative test, kollisionstest og stresstest. De negative tests skal afdække hvordan systemet reagerer, når en bruger gør noget som ikke er tiltænkt, eller udelader at gøre noget. Det kan eksempelvis være tests med invalide data, grænseværdi-test, aktivering af en funktion i et state hvor den aktuelle funktion ikke bør være valgbar, fuldføre en proces uden af have udfyldt alle obligatoriske felter, eller på anden måde udeladt en aktivitet, osv.
Det jeg ikke kan kategorisere som negativ tests, benævner jeg ”validerings test” - altså test cases der mere går på at teste, om vi har bygget det ”korrekte produkt”... hvorimod alle de andre test cases går på at teste, om vi har bygget ”produktet korrekt”. De to måder at formulere spørgsmålet på resultere i forskellig tilgang til testen. Jeg formulere således også test der ikke udelukkende er kravbaseret, eller kan henvise til et krav, men derimod er udledt af et krav. Man skal huske på, at kvalitet er når man både har opfyldt kundens krav, samt forventninger/behov.

Mange varianter af test tror jeg ikke du kommer uden om, da software en en ”spooky” ting at teste og validere. For test af en mobiltelefon havner man nemt på over 2500 test cases, så et SAP system med en kompliceret forretningsprocess, må være omfattende at teste.

Men under alle omstændigheder mener jeg, at ”Exploratory testing” altid bør være en del ens testaktiviteter, da du aldrig vil være istand til at forudse og beskrive testaktiviteter der overgår den menneskelige intuition, og man bliver jo også klogere under selve udførelsen af testaktiviteterne. Jeg tror at ”Exploratory testing” vinder mere og mere frem, efterhånden som det vi skal teste bliver mere og mere kompliceret. Det skal ikke forståes således, at ”Exploratory testing”” skal erstatte den planlagte og strukturerede test. Ulempen ved ”Exploratory testing” er, at den er svær at dokumentere. Det er ligeledes vanskeligt, at have nogen valid indikation af dækningsgraden. Men man skal absolut ikke tage fejl af værdien af ”Exploratory testing”.
_________________
Venlig hilsen
Bjarne Lykkegaard

Profile on linkedin.com:
http://www.linkedin.com/in/bjarnelykkegaard
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    www.softwaretestforum.dk Forum Index -> Teknikker til test All times are GMT + 2 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group