Last month I've been particularly busy with the subject 'Testing and Ethics'. Not that I'm involved in an issue with regards to 'Ethics', but because I'm curious - and I also would like to write an article or whitepaper on the subject.
So I've posted two discussions on two of the Groups in LinkedIn where I'm member of and I started organising a so called 'Lager Huys' discussion session(debating program in the Netherlands, lager not translated as 'beer' but as 'lower')(to be held in January/February).
At first I got answers like 'I'm always honest' etc. But these where not the answers I was looking for, they are (mostly) not true anyway for if it were true the whole world would be a much better and absolutely coruptless place. I started the discussion to get to the edge of things and preferably to that part of the edge that was the most shady. Luckily some colleagues from the testing community are prepared to think along the subject and answered more extensively and went with me into the hypothecial (!) cases c.q. situations.
For now it seems that I will get enough information to write something and publish in March or April 2009. So stay tuned in if you are just as curious as I'm on the matter.
vrijdag 24 oktober 2008
zondag 21 september 2008
De flossende Azijnzeiker
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…
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…
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?
zaterdag 16 augustus 2008
Putting myself to the test
Last week and upcoming week I have the lead of our testpractice for a couple of days. All other management teammembers are on holidays or away for other reasons, so that makes me the person in charge!
I have always claimed that I'm not a peoples-person or managementmaterial, but a real tech, so this is really a challenge, putting myself to the test sort of speak.
I have survived thursday and friday so far; and no accidents have happened (no really big ones anyway ;-) ), people are not threatening to resign, clients are not complaining and no issues are popping up, so far so good.
Oh... I would really like to thank my collegues who are helping me with some tasks/ assignments, I could not have done the job without you!
I have always claimed that I'm not a peoples-person or managementmaterial, but a real tech, so this is really a challenge, putting myself to the test sort of speak.
I have survived thursday and friday so far; and no accidents have happened (no really big ones anyway ;-) ), people are not threatening to resign, clients are not complaining and no issues are popping up, so far so good.
Oh... I would really like to thank my collegues who are helping me with some tasks/ assignments, I could not have done the job without you!
dinsdag 5 augustus 2008
Testing holiday cut short
Yesterday we arrived at home again. We were supposed to stay one more week at our vacation adress, but alas; our canine familymember had a tumour on its paw so we went home to let it be removed by our own vet (first we thought it was a simple abcess that a vet on our vacation adress could remove, but it turned out to be worse, the whole toe had to be amputated...). I just got home with the (druggy) patient and he is doing fine for now, so much for testing days out in 'the Veluwe'.
Last week we didn't do much either. We ate chicken at 'Juffrouw Tok' in Ede on Sunday (reservation not required, but highly recommended!) which was very good (and spicy).
We swam a little in the camping-pool , we rode some routes in the surrounding area by bike and I read 'Lichamelijke oefening' from 'Midas Dekker'.
On Wednesday we went to Friesland in search for a new (more dynamic) camping for next year (Burgumermeer in Sumar); it was hot, but testresult was 'Excellent!'.
On Thursday we ate a pancake at the Panoramahoeve in Bennekom (large portions of good quality! crowded!)
On Friday we went to the vet in Bennekom. Saturday we went to a place called 'De ommuurde tuin' a quite peaceful place with biologically grown vegetables, fruits and flowers.
Sunday we didn't do much because of the rain and yesterday - as allready said- we went home.
The rest of our vacation is dependent on how the patient is doing. We hope he will get well soon and that we'll be able to test some more days out.
Last week we didn't do much either. We ate chicken at 'Juffrouw Tok' in Ede on Sunday (reservation not required, but highly recommended!) which was very good (and spicy).
We swam a little in the camping-pool , we rode some routes in the surrounding area by bike and I read 'Lichamelijke oefening' from 'Midas Dekker'.
On Wednesday we went to Friesland in search for a new (more dynamic) camping for next year (Burgumermeer in Sumar); it was hot, but testresult was 'Excellent!'.
On Thursday we ate a pancake at the Panoramahoeve in Bennekom (large portions of good quality! crowded!)
On Friday we went to the vet in Bennekom. Saturday we went to a place called 'De ommuurde tuin' a quite peaceful place with biologically grown vegetables, fruits and flowers.
Sunday we didn't do much because of the rain and yesterday - as allready said- we went home.
The rest of our vacation is dependent on how the patient is doing. We hope he will get well soon and that we'll be able to test some more days out.
Abonneren op:
Posts (Atom)