Very short 'blog', well more of a message actually....
My first article in print got published in the Software Test & Performance, vol. 7 no. 4.
It's about the Software Testing Ethics Debate.
and I'm very proud of the result!
With thanks to Julian Harty and the crew of STP Collaborative!
http://www.stpcollaborative.com/knowledge/594-the-ethics-debate
donderdag 1 april 2010
zaterdag 27 maart 2010
Blooming of the Testing Garden
*** Column published in Capgemini's CoP IT Testing Newsletter ***
Days are getting longer and some of the bulbs my husband and I planted in autumn last year are already blossoming. As I watch this coming alive in our garden, I think of all the ideas that are blossoming in the testing industry. Creativity and innovativeness are qualities that particularly seem to bloom in the spring, as do the bulbs. Spring also seems the time that many professionals choose to share their experiences on usage of new ideas in practice. Currently I’m in the position that I get to see lots of these ideas, inspiring ideas and enthusiastic stories.
So let me share some insights with you.
Two years ago ‘Agile’ was just a hype word, a bulb that was planted but many could not see what the result would be, very conceptual. Last year Agile became more ‘solid’, it showed its potential and was applied in some projects with successful or not so successful results; like the bulbs you put in the ground in autumn, some come above the ground, but some of them didn’t seem to be ‘doing’ a lot. This year, ‘Agile’ is definitely grounded, all bulbs have fully bloomed. In fact, I read so much about ‘Agile’ now, that I get a bit tired of it, a bit numb. I even see some developments on Agile, specialized process improvement, specialized tooling, specialized test management. A lot is evolving around ‘Agile’, the bulbs are not only blooming, but they are also cultured more and more.
Another bulb that will bloom strongly this year is Chain testing and testing of software integrated in the actual organization. Not only from a testers perspective this is blooming, but also from the organizations’ perspective. It seems like organizations are now, more than ever, becoming aware of the importance of testing. Organizations with a solid test program in place are willing to share their stories and organizations that don’t have them, will – I expect- definitely be willing to have testing integrated in their processes.
Organization-wise there is also a need for quality in their information processes. BI(M) and Testing thereof will also be a flourishing field. Data warehouse testing will definitely have its roots solid in the soil this year. There aren’t yet that many specialists on this area it seems, so this will be an area that will have to be developed and teached. I encourage people to gather information on the subject and help develop this underestimated field of expertise.
Some other bulbs that will be planted or will start showing their beauty this year are ‘Testing as a Service’, Cloud related testing (testing of applications in clouds or cloudofferings in testing), Weekendtesting (just Google…) , other test process improvement methods than TPI and TMMi and all kinds of Exploratory-like testing techniques.
So this year will be a very colorful garden which will certainly need it’s gardeners, but will also provide beauty and enough flowers to pick from.
Get inspired to plant your own testing bulbs or to pick from those wonderful flowers that have already bloomed! I’m certain that something beautiful will bloom in our Testing Garden.
Days are getting longer and some of the bulbs my husband and I planted in autumn last year are already blossoming. As I watch this coming alive in our garden, I think of all the ideas that are blossoming in the testing industry. Creativity and innovativeness are qualities that particularly seem to bloom in the spring, as do the bulbs. Spring also seems the time that many professionals choose to share their experiences on usage of new ideas in practice. Currently I’m in the position that I get to see lots of these ideas, inspiring ideas and enthusiastic stories.
So let me share some insights with you.
Two years ago ‘Agile’ was just a hype word, a bulb that was planted but many could not see what the result would be, very conceptual. Last year Agile became more ‘solid’, it showed its potential and was applied in some projects with successful or not so successful results; like the bulbs you put in the ground in autumn, some come above the ground, but some of them didn’t seem to be ‘doing’ a lot. This year, ‘Agile’ is definitely grounded, all bulbs have fully bloomed. In fact, I read so much about ‘Agile’ now, that I get a bit tired of it, a bit numb. I even see some developments on Agile, specialized process improvement, specialized tooling, specialized test management. A lot is evolving around ‘Agile’, the bulbs are not only blooming, but they are also cultured more and more.
Another bulb that will bloom strongly this year is Chain testing and testing of software integrated in the actual organization. Not only from a testers perspective this is blooming, but also from the organizations’ perspective. It seems like organizations are now, more than ever, becoming aware of the importance of testing. Organizations with a solid test program in place are willing to share their stories and organizations that don’t have them, will – I expect- definitely be willing to have testing integrated in their processes.
Organization-wise there is also a need for quality in their information processes. BI(M) and Testing thereof will also be a flourishing field. Data warehouse testing will definitely have its roots solid in the soil this year. There aren’t yet that many specialists on this area it seems, so this will be an area that will have to be developed and teached. I encourage people to gather information on the subject and help develop this underestimated field of expertise.
Some other bulbs that will be planted or will start showing their beauty this year are ‘Testing as a Service’, Cloud related testing (testing of applications in clouds or cloudofferings in testing), Weekendtesting (just Google…) , other test process improvement methods than TPI and TMMi and all kinds of Exploratory-like testing techniques.
So this year will be a very colorful garden which will certainly need it’s gardeners, but will also provide beauty and enough flowers to pick from.
Get inspired to plant your own testing bulbs or to pick from those wonderful flowers that have already bloomed! I’m certain that something beautiful will bloom in our Testing Garden.
zaterdag 13 maart 2010
's been a while...
I realize it’s been a while – again- since I blogged. I’ve been just so very busy, that blogging just moved to the background.
Firstly I’ve been writing my first large article, which will be published in the Software Test & Performance of April. It’s about Software Testing Ethics and I’ve written about some feedback that I got in the debates I held till now, among others the Ethics Debate held at EuroSTAR 2009. It was a lot of work, but I’m pretty proud of the achievement.
Secondly I also worked on an article on Test Architecture, Test Architecture Framework and the use of Eclipse Method Composer, together with a colleague of mine, for Testing Experience. Alas the editing board thought it was a sales pitch so it was rejected for publication. So me and my colleague (mostly my colleague) are now rewriting the article so that it will be a more scientific article, as the article was intended to be. We never set out to write a ‘sales pitch’.
Although, also this project is a bit on the background now, due to....
The larger part of my time I’ve been – besides working a lot- busy with reviewing the EuroSTAR 2010 submissions. I’ve set out on a quest to review all the submissions. It just seemed fair to know them all, before making the decision on the final program.
And there have been a LOT of submissions, it’s a record number this year! 433 submissions have reached my mailbox and I’m only as far as 229 in my reviewing process.
It is a slow process, since I take a lot of breaks, every submission deserves a fresh review without being ‘numb’ of reading dozens before.
Qualtech has anonymized them all (I can’t even imagine the amount of work that must have been), so I review purely on contents, applicability, innovation and – what else – passion, so I’m not biased by the knowledge of who the submittee is.
It’s a fun progress to be engaged in, but again, it takes a lot more dedication and effort than I would have suspected. Nice is that by making small notes on the subjects and keeping ‘topic keywords’ I’m a bit able to make some statistics. Alas, I’m not able to share anything of content related material of information at this time. But perhaps later this year, I’ll write another blog about this or a small article in the STARtester, we’ll see.
So, until I’ve reviewed all the submissions on EuroSTAR, I guess blogging is on the second plan. Hang in there and take care!
Firstly I’ve been writing my first large article, which will be published in the Software Test & Performance of April. It’s about Software Testing Ethics and I’ve written about some feedback that I got in the debates I held till now, among others the Ethics Debate held at EuroSTAR 2009. It was a lot of work, but I’m pretty proud of the achievement.
Secondly I also worked on an article on Test Architecture, Test Architecture Framework and the use of Eclipse Method Composer, together with a colleague of mine, for Testing Experience. Alas the editing board thought it was a sales pitch so it was rejected for publication. So me and my colleague (mostly my colleague) are now rewriting the article so that it will be a more scientific article, as the article was intended to be. We never set out to write a ‘sales pitch’.
Although, also this project is a bit on the background now, due to....
The larger part of my time I’ve been – besides working a lot- busy with reviewing the EuroSTAR 2010 submissions. I’ve set out on a quest to review all the submissions. It just seemed fair to know them all, before making the decision on the final program.
And there have been a LOT of submissions, it’s a record number this year! 433 submissions have reached my mailbox and I’m only as far as 229 in my reviewing process.
It is a slow process, since I take a lot of breaks, every submission deserves a fresh review without being ‘numb’ of reading dozens before.
Qualtech has anonymized them all (I can’t even imagine the amount of work that must have been), so I review purely on contents, applicability, innovation and – what else – passion, so I’m not biased by the knowledge of who the submittee is.
It’s a fun progress to be engaged in, but again, it takes a lot more dedication and effort than I would have suspected. Nice is that by making small notes on the subjects and keeping ‘topic keywords’ I’m a bit able to make some statistics. Alas, I’m not able to share anything of content related material of information at this time. But perhaps later this year, I’ll write another blog about this or a small article in the STARtester, we’ll see.
So, until I’ve reviewed all the submissions on EuroSTAR, I guess blogging is on the second plan. Hang in there and take care!
maandag 1 maart 2010
STaaS on Request
Suddenly it was there in my mailbox: “How do you feel about Software Testing as a Service, a.k.a. STaaS and could you blog about that?”. A request for a blogpost, hmmm, that’s different. Especially since I haven’t had much to do with the subject (yet), other than reading the different articles and offerings on Cloud, SaaS and the sporadic services that are offered as ‘hosted testing software’. But I like a challenge and I’m also interested in the topic so I set out on my information-gathering quest, there’s no such thing in my world as giving an opinion without knowing the background of the subject under discussion.
Sure I got a feeling, but is that feeling realistic and based on founded grounds or is it just based on (false) assumptions?
First of all: is STaaS any different than SaaS? Well, simply said: NO. Bottomline is that SaaS is, for those of you who didn’t already know, software that is offered as an online service. So if looked at it black-and-white; STaaS is nothing more than offering software that can enable software testing activities offered as an online service.
When I look at it this way, I say: “Good initiative”. Organizations that don’t have testing as a core business or don’t have the infrastructure (or recources) to host that kind of software, this would be a great solution. Think about the possibilities: imagine a big library-like site where you can choose-and-click the software testing software you need and then make use of it as long as you like without having the pains of administration.
Alas, STaaS as term, is used for more types of ‘products’ or ‘services’. So with the explanation above, I won’t be giving a complete answer. There are at least two more perspectives.
The first one is the infrastructure for testing ones software itself (the space/ hardware), for which I find the STaaS term isn’t appropriate. This should be more like ‘Serviced Test Environment’ or something like that. You can think of ‘virtual environments’ and so on. For example: when more testruns are done where older versions have to be ‘frozen’, this is ideal, because you can temporarily upscale your infrastructural capacity without having to buy the whole hardware package yourself. When not needed anymore the virtuals are just ‘deleted’ and you don’t have the hardware still in your server room and thus no maintenance and administration costs.
The second one is the service of Software Testing itself (activity). I find, that there is nothing new here and certainly not worth naming ‘STaaS’. For one, the meaning of aaS is that of product-like nature and not activity-like nature. Secondly; when one hires people for doing their testwork one can call it ‘Consultancy’ or if one hires people who test their software off-site, than it’s called, among others, ‘outsourcing’, ‘offshoring’ or even ‘testfactory’.
I do – however- think there’s still some development in these kinds of offerings. I think there are still services to be offered that will fit much more to the business needs than just ‘hiring people’ or ‘letting the product be tested by a company’. All of these shouldn’t be named ‘STaaS’ though.
So, my conclusion (now), is that STaaS as term isn’t necessary at all, it’s redundant and confusing. SaaS will do just fine. The ideas behind the different explanations of STaaS are however worth developing or investigating, but should be named in a way it’s clear what is meant by it. I think organizations will benefit from products which will enable high qualitative software activities without having to be burdened by the administrative and organizational hassle. I think this kind of products, services and offerings are still scarcely out of the egg and need some serious development, but it has an important role in the way software testing will be done in the future.
Sure I got a feeling, but is that feeling realistic and based on founded grounds or is it just based on (false) assumptions?
First of all: is STaaS any different than SaaS? Well, simply said: NO. Bottomline is that SaaS is, for those of you who didn’t already know, software that is offered as an online service. So if looked at it black-and-white; STaaS is nothing more than offering software that can enable software testing activities offered as an online service.
When I look at it this way, I say: “Good initiative”. Organizations that don’t have testing as a core business or don’t have the infrastructure (or recources) to host that kind of software, this would be a great solution. Think about the possibilities: imagine a big library-like site where you can choose-and-click the software testing software you need and then make use of it as long as you like without having the pains of administration.
Alas, STaaS as term, is used for more types of ‘products’ or ‘services’. So with the explanation above, I won’t be giving a complete answer. There are at least two more perspectives.
The first one is the infrastructure for testing ones software itself (the space/ hardware), for which I find the STaaS term isn’t appropriate. This should be more like ‘Serviced Test Environment’ or something like that. You can think of ‘virtual environments’ and so on. For example: when more testruns are done where older versions have to be ‘frozen’, this is ideal, because you can temporarily upscale your infrastructural capacity without having to buy the whole hardware package yourself. When not needed anymore the virtuals are just ‘deleted’ and you don’t have the hardware still in your server room and thus no maintenance and administration costs.
The second one is the service of Software Testing itself (activity). I find, that there is nothing new here and certainly not worth naming ‘STaaS’. For one, the meaning of aaS is that of product-like nature and not activity-like nature. Secondly; when one hires people for doing their testwork one can call it ‘Consultancy’ or if one hires people who test their software off-site, than it’s called, among others, ‘outsourcing’, ‘offshoring’ or even ‘testfactory’.
I do – however- think there’s still some development in these kinds of offerings. I think there are still services to be offered that will fit much more to the business needs than just ‘hiring people’ or ‘letting the product be tested by a company’. All of these shouldn’t be named ‘STaaS’ though.
So, my conclusion (now), is that STaaS as term isn’t necessary at all, it’s redundant and confusing. SaaS will do just fine. The ideas behind the different explanations of STaaS are however worth developing or investigating, but should be named in a way it’s clear what is meant by it. I think organizations will benefit from products which will enable high qualitative software activities without having to be burdened by the administrative and organizational hassle. I think this kind of products, services and offerings are still scarcely out of the egg and need some serious development, but it has an important role in the way software testing will be done in the future.
maandag 1 februari 2010
The Way of Wishes
*** Column published in Capgemini's COP IT Testing Newsletter ***
As I’m writing this column the snow that has been ‘harassing’ me the last couple of weeks is retreating slowly from the garden and the streets. You should think that would make me some kind of happy, but that isn’t the case, not entirely. It isn’t that the snow is finally going away, that’s the part that’s OK. But it is the way it’s going. It should have been a temperature rise and a bit of sun perhaps that would initiate ‘the melt’, but in this case it’s rain that causes it to disappear. And I guess I like rain even less, in combination with melting snow that is.
In a time that a lot of people have made resolutions for the new year and are spreading ‘best wishes’ it started me thinking. What if some of it came true, but the way you intended it to come true wasn’t exactly what you had in mind.
For example; you have a resolution that says ‘this year I’ll quit smoking’, a very common resolution as I may add and normally a very healthy one. I guess everybody agrees with this resolution, because most people have the frame of reference that the way this is done is by a live person not lighting a cigarette anymore. But it’s another story when one ‘quits’ smoking because they die. I’m certain that nobody had dying in mind when setting this resolution.
The key point here is -I think- the accuracy and completeness that has not been made. And then it occurred to me that ‘requirements’ for software- and systems are set in the same way and that in some cases when we get to testing these requirements are implemented exactly as they are described, but the client isn’t happy at all with the solution. A lot of times this causes incomprehension and even arguments. I think that it is important to remember in these cases that maybe the requirement itself isn’t the most important part, but the way that the solution to this requirement is implemented is.
I know it isn’t the job of a tester to set up the requirements, but as tester we do have a lot to do with them, and in my personal experience I do have the occasional argument with a client that the solution to the requirement is exactly implemented as described but the client persists in not being satisfied with the solution.
I think the requirement specifier should be very specific by adding the way a solution is – process wise- implemented and as a tester we should be extra aware that when testing solutions the description of the corresponding requirement is in such a way documented that it is clear what the solution should exactly be, including the expectations of the client. Having said this, I think we can deliver a more satisfying product to our customer when applying this knowledge.
With regards to 2010 intentions and best wishes I would like to conclude with a very known saying: Be careful what you wish for, it might come true!
As I’m writing this column the snow that has been ‘harassing’ me the last couple of weeks is retreating slowly from the garden and the streets. You should think that would make me some kind of happy, but that isn’t the case, not entirely. It isn’t that the snow is finally going away, that’s the part that’s OK. But it is the way it’s going. It should have been a temperature rise and a bit of sun perhaps that would initiate ‘the melt’, but in this case it’s rain that causes it to disappear. And I guess I like rain even less, in combination with melting snow that is.
In a time that a lot of people have made resolutions for the new year and are spreading ‘best wishes’ it started me thinking. What if some of it came true, but the way you intended it to come true wasn’t exactly what you had in mind.
For example; you have a resolution that says ‘this year I’ll quit smoking’, a very common resolution as I may add and normally a very healthy one. I guess everybody agrees with this resolution, because most people have the frame of reference that the way this is done is by a live person not lighting a cigarette anymore. But it’s another story when one ‘quits’ smoking because they die. I’m certain that nobody had dying in mind when setting this resolution.
The key point here is -I think- the accuracy and completeness that has not been made. And then it occurred to me that ‘requirements’ for software- and systems are set in the same way and that in some cases when we get to testing these requirements are implemented exactly as they are described, but the client isn’t happy at all with the solution. A lot of times this causes incomprehension and even arguments. I think that it is important to remember in these cases that maybe the requirement itself isn’t the most important part, but the way that the solution to this requirement is implemented is.
I know it isn’t the job of a tester to set up the requirements, but as tester we do have a lot to do with them, and in my personal experience I do have the occasional argument with a client that the solution to the requirement is exactly implemented as described but the client persists in not being satisfied with the solution.
I think the requirement specifier should be very specific by adding the way a solution is – process wise- implemented and as a tester we should be extra aware that when testing solutions the description of the corresponding requirement is in such a way documented that it is clear what the solution should exactly be, including the expectations of the client. Having said this, I think we can deliver a more satisfying product to our customer when applying this knowledge.
With regards to 2010 intentions and best wishes I would like to conclude with a very known saying: Be careful what you wish for, it might come true!
vrijdag 8 januari 2010
Testing the Cloud, a thought on the fogginess.
***Column 'Capping IT Off', January 2010***
According to a large number of articles in different specialist journals ‘The Cloud’ will be (or already is) the next big thing in IT-land, so I guess it will be important in testing too. Most articles are very positive on the possibilities of this concept, but as is testers own, I get a little skeptic and weary.
Since the first publications on the subject a group of testers in Capgemini’s Community of Practice Testing started following the news. As I said; MOST articles are positive, but lately some doubts have risen. Companies seem to see the possibilities, but also have questions on subjects like ‘security’, ‘performance’ and ‘traceability’. These latter three are quality attributes typically covered by testing.
So will testing the cloud specifically for ones organization take away these doubts? Testing is all about giving the stakeholders insight in the degree of quality of their systems- and processes (and I mean this in ‘fit for purpose’-way, because there are a lot of definitions on quality). As a tester myself I find the name of this concept appropriate. One of the ‘–noun’ definitions in the dictionary states: “a dim or obscure area in something otherwise clear or transparent”. Things like system management that is normally in-house and controllable is now in some vague area out of sight of the organization itself.
Another one states: “a great number of insects, birds, etc., flying together: a cloud of locusts obscuring the sun.”, and I can’t help myself by thinking: THAT many bugs together? – that can’t be a good sign.
So does this cloud also has a silver lining? The process of testing itself will not be different, but the way testing is managed all the more, as are the emphasis on certain quality attributes. Is testing a regular complex system normally a challenge, testing a cloud related system will be more so, but certainly not impossible.
So yes, from a testers point of view, this cloud certainly has a silver lining, but it will take an experienced tester to make it so, else it will stay just as the dictionary also states: “anything that obscures or darkens something, or causes gloom, trouble, suspicion, disgrace, etc.” instead of being (-idioms definition): “on a cloud, Informal. exceedingly happy; in high spirits”
According to a large number of articles in different specialist journals ‘The Cloud’ will be (or already is) the next big thing in IT-land, so I guess it will be important in testing too. Most articles are very positive on the possibilities of this concept, but as is testers own, I get a little skeptic and weary.
Since the first publications on the subject a group of testers in Capgemini’s Community of Practice Testing started following the news. As I said; MOST articles are positive, but lately some doubts have risen. Companies seem to see the possibilities, but also have questions on subjects like ‘security’, ‘performance’ and ‘traceability’. These latter three are quality attributes typically covered by testing.
So will testing the cloud specifically for ones organization take away these doubts? Testing is all about giving the stakeholders insight in the degree of quality of their systems- and processes (and I mean this in ‘fit for purpose’-way, because there are a lot of definitions on quality). As a tester myself I find the name of this concept appropriate. One of the ‘–noun’ definitions in the dictionary states: “a dim or obscure area in something otherwise clear or transparent”. Things like system management that is normally in-house and controllable is now in some vague area out of sight of the organization itself.
Another one states: “a great number of insects, birds, etc., flying together: a cloud of locusts obscuring the sun.”, and I can’t help myself by thinking: THAT many bugs together? – that can’t be a good sign.
So does this cloud also has a silver lining? The process of testing itself will not be different, but the way testing is managed all the more, as are the emphasis on certain quality attributes. Is testing a regular complex system normally a challenge, testing a cloud related system will be more so, but certainly not impossible.
So yes, from a testers point of view, this cloud certainly has a silver lining, but it will take an experienced tester to make it so, else it will stay just as the dictionary also states: “anything that obscures or darkens something, or causes gloom, trouble, suspicion, disgrace, etc.” instead of being (-idioms definition): “on a cloud, Informal. exceedingly happy; in high spirits”
vrijdag 18 december 2009
Epilogue; EuroSTAR 2009, two weeks after
Currently I'm working from home, the snow and iciness made me think twice before commuting to Amsterdam again. Yesterday it took me two hours to get home, a journey that normally takes an hour. So I have (not so environmental friendly - I know) set the heater a degree higher, made myself I nice cup of coffee and started working on the planning and preparation of the chaintest which is to be executed next year March and will do some testing on a system.
It's been two weeks since EuroSTAR 2009 ended, and my mind has been racing with ideas since then. Not only that, I've been busy implementing a lot of stuff and tips I got in the conference too in my current projects.
Since I'm testing and managing a whole program, I really had use of the information provided in the 'Program Test Management- a survival kit' by Graham Thomas. I checked the 'best practices' lists in the sheets and checked the 'anti-practices' lists and set them beside the stuff I already did in my project.
One of the needed skills was negotiating and influencing, I noticed I hadn't been very strong in that department: I used the stuff learned in the workshop 'Chatterboxes and Cavedwellers' of Naomi Karten to pinpoint the problem; since I'm an introvert at doing things and my 'audience' is mostly extrovert, I suddenly understood why my message may not have been landing as I thought it did.
One of the other things in 'Survival kit' was that there should be a 'clear test organisation structure with matrixedrelationships' and another 'Clear and agreed interface with stakeholders and sponsors' and a third 'To ensure that your stakeholders and sponsors clearly understand what testing is doing for them', I realized that a part was missing: namely the program itself. I decided to combine all four (three from the track and my addition). In one large overview of the program: picturing the systems, what the connections are, who is responsible (owner, tester and users) and dates that are important. I'll also use these as 'talk-images' to align all stakeholders (first try-out was very positive!). In addendum with these images, I made a scenario with activities, time, input needed, output needed and who is responsible. Thirdly I made a gannt-diagram for time-overview. All three parts are aligned to eachother by use of colors, so the process of one piece may be 'blue' in all three documents. On the way I also made use of the things learned in 'Rik Teubens track; Many can quarrel, fewer can argue.
My 'testcase' pointed out that he really liked the overview; since he was able to place himself in the bigger picture in relation to other parts in the program (which was normally out of scope for him), he also like that he was able to easily identify the timelines and activities in the other documents because he only had to find 'his' colour.
(and I've been also thinking about another lay-over for the images like Neil Pandits' visualized Risk-based testing, heatmaps)
The second positive improvement I made in my workingarea, and this is the system I'm testing (not the program), Is the stuff on exploratory testing, the workshop of Michael Bolton really had loads of stuff in it I could use to stretch the abilities of the system under test. Resulting in some stress in the organisation though, but when I argued (;-) ) this was all beneficial to really get a good look on the quality of the system and preventing more 'pain' in the future, they were (mostly) convinced. And the secundary part of this, is that it made testing this (a bit dull but complex) system fun again.
So, I guess there's still a lot to implement from the EuroSTAR 2009 conference. I haven't been able to work out all the stuff yet, since I also had to catch up on the work I left behind when going to Stockholm, but I'm confident it will all has a place somewhere.
It's been two weeks since EuroSTAR 2009 ended, and my mind has been racing with ideas since then. Not only that, I've been busy implementing a lot of stuff and tips I got in the conference too in my current projects.
Since I'm testing and managing a whole program, I really had use of the information provided in the 'Program Test Management- a survival kit' by Graham Thomas. I checked the 'best practices' lists in the sheets and checked the 'anti-practices' lists and set them beside the stuff I already did in my project.
One of the needed skills was negotiating and influencing, I noticed I hadn't been very strong in that department: I used the stuff learned in the workshop 'Chatterboxes and Cavedwellers' of Naomi Karten to pinpoint the problem; since I'm an introvert at doing things and my 'audience' is mostly extrovert, I suddenly understood why my message may not have been landing as I thought it did.
One of the other things in 'Survival kit' was that there should be a 'clear test organisation structure with matrixedrelationships' and another 'Clear and agreed interface with stakeholders and sponsors' and a third 'To ensure that your stakeholders and sponsors clearly understand what testing is doing for them', I realized that a part was missing: namely the program itself. I decided to combine all four (three from the track and my addition). In one large overview of the program: picturing the systems, what the connections are, who is responsible (owner, tester and users) and dates that are important. I'll also use these as 'talk-images' to align all stakeholders (first try-out was very positive!). In addendum with these images, I made a scenario with activities, time, input needed, output needed and who is responsible. Thirdly I made a gannt-diagram for time-overview. All three parts are aligned to eachother by use of colors, so the process of one piece may be 'blue' in all three documents. On the way I also made use of the things learned in 'Rik Teubens track; Many can quarrel, fewer can argue.
My 'testcase' pointed out that he really liked the overview; since he was able to place himself in the bigger picture in relation to other parts in the program (which was normally out of scope for him), he also like that he was able to easily identify the timelines and activities in the other documents because he only had to find 'his' colour.
(and I've been also thinking about another lay-over for the images like Neil Pandits' visualized Risk-based testing, heatmaps)
The second positive improvement I made in my workingarea, and this is the system I'm testing (not the program), Is the stuff on exploratory testing, the workshop of Michael Bolton really had loads of stuff in it I could use to stretch the abilities of the system under test. Resulting in some stress in the organisation though, but when I argued (;-) ) this was all beneficial to really get a good look on the quality of the system and preventing more 'pain' in the future, they were (mostly) convinced. And the secundary part of this, is that it made testing this (a bit dull but complex) system fun again.
So, I guess there's still a lot to implement from the EuroSTAR 2009 conference. I haven't been able to work out all the stuff yet, since I also had to catch up on the work I left behind when going to Stockholm, but I'm confident it will all has a place somewhere.
Abonneren op:
Posts (Atom)