Velkommen til Softwaretestforum, et online portal og forum for alle der arbejder professionelt med Quality Assurance og softwaretest.
Formålet er at danne et forum for dig, hvor du kan dele dine erfaringer med andre og få endnu flere erfaringer med hjem.
Omdrejningspunktet er deltagernes karriere og erfaringer som du kan følge i online fora, blogs og interviews.
(denne article er fra Carsten Feilberg blog)
Go DaRE=M - a heuristic for testing plans
It suddenly struck me, that I might need to put this one out in the blog space. For years I have used this heuristic, and although it might contain influences from others, I actually consider this my very own, home-made heuristic. Since forming it I've taught it in classes and even presented it in a Lightening Talk once - so it's high time to put it more on "print"!
So, what is DaRE=M ? It's a heuristic I use for testing a plan, like when someone tosses you a bunch of papers: "can't you drop an eye on this plan I made, just to see if I left anything obvious out?"
That's when I start on the "D" - which of course is for Deliverables. It's the first letter in the heuristic and also the most important one. I readily flunk plans that do not highlight the deliverables in a clear and consistent way. And why shouldn't I ? The plan is supposed to bring us somewhere so if we cannot read "where" from the plan, I don't have high regards for anything else in it.
The next letter is "a" - notice, it's not a capital A - it's minuscule and stands for activities. Surely there may be some activities in a plan, sometimes we just have to point them out - but: they are not as important as Deliverables and furthermore must always "hang on" to a deliverable (otherwise: why are we doing this activity ?). Clearly, if the activities are so overwhelming in the plan, that you cannot figure the deliverables, the plan is probably not going to work (it should be minuscule, not capitalized).
"Da" is a set - unseparable. Funnily if you open up a project planning tool, guess what's the first thing you are invited to put into it is ? Yup - an activity..
I think that's backwards - figure what you want, then plan your steps to get there!
Mere info via link:
http://carstenfeilberg.blogspot.dk/2013/04/go-darem-heuristic-for-testing-plans.html
DWET står for Dansk Workshop om Exploratory Testing.
Det er en peer-konference, bestående af testere der har erfaring med eller interesse for brug af Exploratory Testing som tilgang til software test.
Sproget vil som udgangspunkt være på dansk.
Dette site sigter ikke imod at skabe et online-forum, men at skabe grundlag for at mødes.
Alle møder afholdes efter LAWST-principperne, dvs. med indlæg og efterfølgende faciliteret diskussion.
DWET er ikke et diskussionsforum angående hvorvidt scripted testing er bedre eller værre end exploratory testing, og om det ene eller andet foretrækkes. Udgangspunktet for DWET er at Exploratory Testing bruges, og vi diskuterer ikke scripted testing (medmindre det er Exploratory...)
Mere info via https://sites.google.com/site/dwetpeerconference/home

Hvorfor er det vigtigt, at vi kan spore fra krav til test - og hvorfor er det vigtigt at vi kan spore status på testene tilbage til kravene?
HP Test Brugergruppen arrangerer torsdag d. 27. juni 2013 brugergruppemøde omkring sporbarheden i Quality Center - gå ikke glip af dette møde!
mere info via link Tracing requirements to test is important

