Mini me...

I will try to upload some pictures tomorrow from our trip to Kaprun! Cheers!

Night night!

They are still in the lead, but its getting closer and closer...

Hello all! Im back from vacation. 4 weeks of pure rain and clouds, yay.. well.. atleast 3weeks of that, since we went to Greece the last week which provided us with lots of sun, bathing and beers!

Anyway... just to let you know how things works at work now when Im back from vacation..

We now have 'trac' up and running on a nice little exlusive server setup only for my QA dept =).

I installed vmWare server on it and then setup a nice little VM running 'Ubuntu server ed' on it which inreturn hosts the trac server through apache2 and mod_python. Yeah, I know.. maybe some of you dont know jack shit of what Im rambling about there, but here are some links to the things which I used to setup our ticketing system for my new workplace, if you are curious and want to know more, have a look at the links below.

Trac can be read about here:

vmWare server can be read about here:

Mod_python can be read about here: and how to set it up with trac here:



So, currently, I have setup trac in a somewhat un-ortodox way I belive, but I think that the way I have made it creates the least overhead and is a good foundation to get trac to the least intrusive when developing software...

Traditionally, you created on trac setup per project each with different adresses/sqlite db's/modules/plugins running on the same server. This meas that you can have 4 bugs called bug 1000 if you have 4 projects(ofcourse on different adresses, but still...) I dont like that idea if being able to have 4 bug numbers with the same 'name' so I hade to work around that.

The solution was to have one 'meta-project' which covered each product, which fortuantly was possible thanks to some nice help on the trac irc chat but also through the excellent wikis on how to setup trac and such.


We now have a very good startpage when logging into trac. Here you can see a good overview of the current number of open bugs for each product, current unassigned bugs per project and also assigned bugs per project. Since trac also is a completel WIKI solution, anyway with access rights to create wiki pages, can go in and edit any page(even the startpag) and therefor also create new 'filters' to show results/content etc which they find usefull for there projects. One of these filters I made was a ticket filter which shows how many bugs is assigned to 'QA verification'.

When a bug is send to QA, that means that the developer have submitted the bug for QA'ing or 'Verification' to verify that the fix he/she have made actually adresses the reported problem/enhancement which is described in the ticket. This is brilliant, because QA get's directly send a note(mail/rss) when anyone sets a ticket to 'Submit to QA'


Ohwell.. enough rambling about QA and trac and setup's etc.. current status is that Im very pleased with the performance of trac, the stability of trac and how easy an trac admin can change/adapt and create new 'functions' by simply tweaking trac to suite a products needs. =)

So, if you are thinking about setting up a ticketing system of somesort, please, please consider to have a look at trac, because it's simply outstanding! =)

I got my photo blogging working again! W00T!

... I miss disco...

Ok, I know.. im old on the computer/it world... or.. well. sorta old.. been doing it the last 8 years now, with a direction against QA mostly, but also projectmanagement and group manager. I mean that Im quite comfortable in my clothing when it comes to QA and how to test things, however, Im completely fresh to this "scrum" business everyone is talking about.

When it comes to scrum, I really like the thinking about it and how it gives the thought controll back to the developers opposed giving the controll completely to the manager... However, with 2weeks sprints within scrum, Im sorta struggling with how to get the QA part of the scrum business working. A 'sprint' is a 2 week period where you have to complete a specific set of 'slices' which the dev decides to complete during a 2-4hour meeting. Each slice is a specific part(or goal) of the game/project which needs to be completed. A definition of a slice can for example be "Be able to run/control with a character inside the stadium and kicking/playing a ball"

That sounds fair enough you say? But what about from the QA side of things? How on earth should a QA be able to say that this definition for that slice is met? I mean, if you dont specify exactly what each thing in this highlevel definition is, how can I as a QA say that this is OK from a QA point of view? From the dev side, they can pretty much just put a qube which you control and you then just push a ball infront of you inside a big bowl and would still meet the definition of the slice...

Hmm.. Lets see what happends during the week =) I mean, what could possibly go wrong?