The column I wrote in the last newsletter of our COP is not translatable in English, so - alas- only the people who can read dutch are able to enjoy this one. Try not to translate this column with word or another program; you might end up shocked!
Tester zijn is onderworpen worden aan allerlei creatieve analogieën , uitgemaakt worden voor van alles en nog wat of verwijten krijgen voor zaken die gewoon je werk zijn. Tijd voor een ode *ahem* aan de ‘wat testers allemaal zijn’in ‘klare’ taal.
Azijnzeiker, Mierenneuker, Kommaprutser, Puntenpeller, Codezieker, Pretbederver, Partypooper, Saaie muts (of was die voor mijzelf bedoeld ;-) ), Geinvenijn, spelbederver, spelbreker, haarklover, pietlut, zemelkont, zeur, zeikerd,“Jezus” (veel gehoord vooral vanaf ontwikkelaars hoek), bridger en muggenzifter.
Ik vraag me af waarom deze benamingen ons allemaal gegeven worden, we doen immers gewoon ons werk en achteraf is men maar wat blij als we de organisatie voor (grote?) rampspoed hebben behoed. In tegenstelling tot de belastingdienst die dezelfde bewoordingen worden toegedicht, ook gewoon hun werk doen, maar over het algemeen wel grote rampspoed veroorzaken in plaats van voorkomen. Dat laatste is natuurlijk mijn eigen perceptie al denk ik zelf dat ik niet de enige ben die deze perceptie heeft.
De gemiddelde tester gaat gebukt onder vooroordelen. We zijn de brengers van – over het algemeen een slechte – boodschap (de goede worden vaak genegeerd) en worden toch neergeschoten, hoe vaak je ook zegt ‘don’t shoot the messenger’. We lijken het slechte imago maar slecht te kunnen lozen. Hoe goed we ook poetsen; de gaatjes die er nu eenmaal zitten krijg je niet weg. Wat we dus wel kunnen doen is voorkomen dat er nieuwe bij komen, dus toch blijven poetsen en misschien zelfs wat flossen, met het tonen van een specialisme kunnen we laten zien dat testen een net zo volwaardig vak is als alle andere IT professies.
Krijgt mijn mondhygiëniste me toch nog aan het flossen…
zondag 21 september 2008
vrijdag 19 september 2008
The aftermath
Yesterday was a very hectic day, with lots of discussions.
The collegue who started the whole fuss, did so because seemingly one of the attendees to my presentation had called me "an embarrassment" for the whole company.
I found this what 'stern'language, more so because I value this persons opinion with high egards.
But come on: one presentation embarrasses a whole company of thousands of employees? I find this very hard to believe!
Because of this choice of words other people within my company found it necessary to perform 'damage control' and to set strict rules for presenting at events (even the consultants who have allready got a trackrecord must now submit to a pre-screening), but not only that; the whole external communication policy was now a discussion (what one presentation can cause;
N’est-ce pas?)
There was also an evaluation of my presentation; what it was, what I intended and what it could have been. After some discussion I found out that some parts that I found logical and common knowledge where not in there so that the subject didn't land. Some other parts where also pointed out, like setting the definitions on the usage of jargon. For example: I used the word (test)Strategy which was then perceived as the high-level document on (test)policy within an organisation; I ment the chapter within the testplan on which your 'plan of attack' (strategy) is described).
I've allready made a visual lay-out with help of the V-model to explain the principle. I have even set a couple of new (re-worked) definitions and decided to write a paper on this (which will off course have to be evaluated by a lot of collegues, since this is new policy).
It is to be continued!
I would like to remarkt that I also got a compliment: the presentation technique was OK as was 'the guts' to present on such a controversery / innovative subject.
The collegue who started the whole fuss, did so because seemingly one of the attendees to my presentation had called me "an embarrassment" for the whole company.
I found this what 'stern'language, more so because I value this persons opinion with high egards.
But come on: one presentation embarrasses a whole company of thousands of employees? I find this very hard to believe!
Because of this choice of words other people within my company found it necessary to perform 'damage control' and to set strict rules for presenting at events (even the consultants who have allready got a trackrecord must now submit to a pre-screening), but not only that; the whole external communication policy was now a discussion (what one presentation can cause;
N’est-ce pas?)
There was also an evaluation of my presentation; what it was, what I intended and what it could have been. After some discussion I found out that some parts that I found logical and common knowledge where not in there so that the subject didn't land. Some other parts where also pointed out, like setting the definitions on the usage of jargon. For example: I used the word (test)Strategy which was then perceived as the high-level document on (test)policy within an organisation; I ment the chapter within the testplan on which your 'plan of attack' (strategy) is described).
I've allready made a visual lay-out with help of the V-model to explain the principle. I have even set a couple of new (re-worked) definitions and decided to write a paper on this (which will off course have to be evaluated by a lot of collegues, since this is new policy).
It is to be continued!
I would like to remarkt that I also got a compliment: the presentation technique was OK as was 'the guts' to present on such a controversery / innovative subject.
donderdag 18 september 2008
Never again and public service announcement
I hereby solemly plegde never to change an article or presentation again because a couple of colleagues say so.
What happened? In the beginning of this year I made a synopsis about HumanBasedAnalysis (then called HumanBasedTesting as it was intended as antagonist of Risk or Requirementbased Testing), it was reviewed, but some colleagues said I should narrow the subject down. I did so, by applying it to the Teststrategypart and calling it thus HumanBasedAnalysis, wrong, wrong, wrong.
I got to present my piece at the Najaarsevent of Testnet last tuesday, it became a fiasco. Technically it wasn't bad, but with respect to the content, basically: it Sucked!
Due to 'jibbers' I mixed up a technique; namely Functionpointanalysis and ProductRiskAnalysis, this wouldn't have happend if I had stuck to my original plan, the HumanBasedAnalysis is namely applicable within all phases of the test-trajectory, allthough mainly at the left-upper part of the V-model- and not only at Strategy definition.
So after a couple of sheets I was 'saved' by one of the audience who said he couldn't quite put his finger on the spot. I tried to explain, but again, the mixup of techniques was my 'millstone'.
Luckily I got a bit of explanation done, but also I discussion had arisen in the audience.
I thought the discussion was good though; it confirmed my original idea of Human Based Analysis (because part of the discussion broadened to the fact that this should also be used as soon as the phase where requirements are set; good; because requirements should be validated and verified (in my opinion with the end-user as reference). The discussion was also proof of that this kind of thinking is perceived as important but to put it in a context like I did, caused a great deal of controversy. Note: when looking at the V-model then the Human Based Analysis is done between Setting Requirements and Designing the FO.
OK, for keeping the peace: I'm solely responsible for the content on HumanBasedAnalysis. My company is not responsible and does not explicitly support me in this way of thinking, my idea is - seemingly - a bit difficult to understand and with controverse, so I still have a lot of explaining to do.
Let it be stated that when - in the future- it catches on; it was solemly my idea to introduce it
I stand by my subject and am proud of it.
For the people who attended: I'm sorry to have desillusionised you. Perhaps the following definition will clearify the intention somewhat more (I'm better on script than on speach)
Human Based Analysis
Human Based Analysis is a compilation of techniques where the end-users or experts - other than appointed stakeholders - are explicitly asked to point out the risks within the proces to be automated or the software to be developed or what requirements are the most important.
The Human Based Analysis is primarily done between Requirement Specification and Functional Design, but can be done on other part within the V-model allthough when at 'User Acceptance Test' level, you're (probably) too late.
The Human Based Analysis has in a lot of cases the consequence that two things are to be adjusted: 1. The requirements and 2. The testdesign
Hopefully to be continued....
What happened? In the beginning of this year I made a synopsis about HumanBasedAnalysis (then called HumanBasedTesting as it was intended as antagonist of Risk or Requirementbased Testing), it was reviewed, but some colleagues said I should narrow the subject down. I did so, by applying it to the Teststrategypart and calling it thus HumanBasedAnalysis, wrong, wrong, wrong.
I got to present my piece at the Najaarsevent of Testnet last tuesday, it became a fiasco. Technically it wasn't bad, but with respect to the content, basically: it Sucked!
Due to 'jibbers' I mixed up a technique; namely Functionpointanalysis and ProductRiskAnalysis, this wouldn't have happend if I had stuck to my original plan, the HumanBasedAnalysis is namely applicable within all phases of the test-trajectory, allthough mainly at the left-upper part of the V-model- and not only at Strategy definition.
So after a couple of sheets I was 'saved' by one of the audience who said he couldn't quite put his finger on the spot. I tried to explain, but again, the mixup of techniques was my 'millstone'.
Luckily I got a bit of explanation done, but also I discussion had arisen in the audience.
I thought the discussion was good though; it confirmed my original idea of Human Based Analysis (because part of the discussion broadened to the fact that this should also be used as soon as the phase where requirements are set; good; because requirements should be validated and verified (in my opinion with the end-user as reference). The discussion was also proof of that this kind of thinking is perceived as important but to put it in a context like I did, caused a great deal of controversy. Note: when looking at the V-model then the Human Based Analysis is done between Setting Requirements and Designing the FO.
OK, for keeping the peace: I'm solely responsible for the content on HumanBasedAnalysis. My company is not responsible and does not explicitly support me in this way of thinking, my idea is - seemingly - a bit difficult to understand and with controverse, so I still have a lot of explaining to do.
Let it be stated that when - in the future- it catches on; it was solemly my idea to introduce it
I stand by my subject and am proud of it.
For the people who attended: I'm sorry to have desillusionised you. Perhaps the following definition will clearify the intention somewhat more (I'm better on script than on speach)
Human Based Analysis
Human Based Analysis is a compilation of techniques where the end-users or experts - other than appointed stakeholders - are explicitly asked to point out the risks within the proces to be automated or the software to be developed or what requirements are the most important.
The Human Based Analysis is primarily done between Requirement Specification and Functional Design, but can be done on other part within the V-model allthough when at 'User Acceptance Test' level, you're (probably) too late.
The Human Based Analysis has in a lot of cases the consequence that two things are to be adjusted: 1. The requirements and 2. The testdesign
Hopefully to be continued....
woensdag 3 september 2008
Passed at a not wanted feature and long term requirements
I survived the weeks as "Management" and apparently I did a pretty descent job (not entirely on my own, but still...)
Now I'm back at my client's office again 'on the job' and I'm glad. I'm more in my element there, more on my territory. I'm just more a tech-person as a people-person, at least I know that now. My desire to specialize in the testprofession is now more profound then ever.
I set two goals for the future on my profession(al) development;
1. Get my master's degree (major: Quality/ Testing)
2. Becoming an absolute Testguru and TestArchitect
Not nescesarily starting with both tomorrow :-)
I challenge everybody to set their long-term goals and perhaps in a couple of years we can shake hands in our aspired roles!
MS Nathalie Rooseboom de Vries van Delft , Testarchitect. Has a nice ring to it doesn't it?
Now I'm back at my client's office again 'on the job' and I'm glad. I'm more in my element there, more on my territory. I'm just more a tech-person as a people-person, at least I know that now. My desire to specialize in the testprofession is now more profound then ever.
I set two goals for the future on my profession(al) development;
1. Get my master's degree (major: Quality/ Testing)
2. Becoming an absolute Testguru and TestArchitect
Not nescesarily starting with both tomorrow :-)
I challenge everybody to set their long-term goals and perhaps in a couple of years we can shake hands in our aspired roles!
MS Nathalie Rooseboom de Vries van Delft , Testarchitect. Has a nice ring to it doesn't it?
Abonneren op:
Posts (Atom)