The week before this one, I commuted to work by train and got inspired for this blog.
So what's the story?
The last couple of weeks our national public transport train company - apparently- had loads of trouble keeping to their timetable (and IMHO still do but that is another story). Every single day for the past weeks the train has been delayed for 5 minutes and that made me 'tweet' the following:
"I find it more annoying to have a 5 min delay every day than to have 30 mins delay once in a while. "
and after that :
"I guess my last tweet about train travel, could very well apply to software testing too??" and "What do you think: Less annoying to have a huge bug once in a while, than numerous ones almost constantly"
I got the following responses:
@santhoshst : "True - I related it to Performance Quality criteria :) #softwaretesting
@santhoshst : "Depends on the context :)
@jahoving : "but even more annoying to have no bugs at all ;-)
@eddybruin : " 1 huge bug is better manageable than 100's of inconvenient little bugs"
There are not many replies, but all replies have something that made me think about this statement more. I have put down some thoughts/ questions that I had and would love you to respond on that!
- No bugs at all can mean a couple of things (amongst others): 1. the utopious perfect programmer has arrived to program the utopious perfect analyst's and designer's work. 2. you have not tested the right part of the software, are not performing the right tests or have automated your tests and this only checks things leaving the really important bugs unfound.
- It's annoying to get bug reports constantly. It's better to report once in a set time than to come running over to the programmer/ manager (etc.) with every single bug found. Also the 'huge bug-rule' can apply here; a huge bug can be reported immediately (it probably has to be fixed with high priority too) but all those little ones? Report it once a couple of days; else it will interrupt the programmers work (and attention) unnecessarily. It will also cloud a managers view; when you come to him constantly with every bug: the really important ones will not seem as important as they really are (famous fable of 'Peter and the Wolfe')
- When looking at performance issues. When you have - for example- a 7 seconds delay at every request this can be seen as not a big issue (in the margin) but a 1 minute delay is seen as problem. As a user 7 seconds can seem like a eternity when your on a deadline especially when you have 100's of request to work through every day. A minute delay once in a while can give you some coffee time; 7 seconds each request is simply a pain in the ...
- Of course the context has to be taken in consideration, as mentioned by santhoshst. Numerous bugs can also be very 'dangerous' when they are in a critical part of a system; even the smaller ones.
- I wondered if this one would be true: 1 bug is better manageable than 100's of little ones. I could think of a bug that had a very complex background: to get it solved it took a lot of time, management, politics and redesigning. In the same time at least 20 others with minor priority where fixed and closed. Overview can be complex for a lot of smaller ones, but it's the real big ones that can push your skill-limits. This is - mind- also related to the role and tasks you have within your organization. When this is only to report the bug and retest it when it's fixed, than the statement could well be true. When you also have to 'guide' the defect through the rework process it will probably be more like described earlier.
- When the timetable of the train at station X would be adjusted to 5 mins later, there wouldn't be a defect/bug. I wonder why they don't do this, because at the next station there is a - almost - ten minutes wait till the train leaves from there. So there is margin to set the time of departure at station X a bit later. And here comes (I know a bit unconventional) statement. Specifications can be changed to 'solve' a bug (dependent on the context/severity etc.).
I'm very anxious to see your replies. I so love discussions! and - needless to say-... please reply in one big one instead of lot's of smaller ones :-)
vrijdag 29 oktober 2010
vrijdag 8 oktober 2010
Continuous Quality Process Software- and Systems (CQPSS)
[Blog entry from CappingITOff]
I was not always into testing. My first choice of studies, before getting entirely intrigued by IT, was that of FoodEngineering. When I got into the testing matter, I was surprised to find that in IT, testing is mostly done during development or when changes occur in the software or system. In the foodindustry there's a continuous quality process during development and during operations, this is named HACCP, the abbriviation for Hazard Analysis and Critical Control Points. HACCP - and I quote Wikipedia here - is a systematic preventive approach to food safety and pharmaceutical safety that addresses physical, chemical, and biological hazards as a means of prevention rather than finished product inspection. HACCP is used in the food industry to identify potential food safety hazards, so that key actions, known as Critical Control Points (CCPs) can be taken to reduce or eliminate the risk of the hazards being realized. The system is used at all stages of food production and preparation processes including packaging, distribution, etc.
I started to wonder why in IT (Testing) there is no such process implemented; our business is riskmitigation isn't it? IT is becoming more and more (or is already) essential in our businessprocesses and daily lives. Failure has such a hughe impact that I find it scary to not have constant monitoring on IT solutions. It is a known fact that testing during development can't be done with a 100% coverage of system- or software, so there are still some flaws in there that could mean disaster to your business...
I thought up the Continuous Quality Process Software- and Systems, in short (because IT likes the use of abbreviations) CQPSS. Of course I used the seven basic principles of HACCP as my baseline, so let's look at those principles, which I will map to CQPSS.
Principle 1: Conduct a hazard analysis.
Plans determine the food safety hazards and identify the preventive measures the plan can apply to control these hazards. A food safety hazard is any biological, chemical, or physical property that may cause a food to be unsafe for human consumption.
In the CQPSS it's almost the same. Every business has critical processes. In the CQPSS plan these criticall processes should be described. When testing during development is done correctly, this riskanalysis should be there and is re-usable. Ofcourse these should be updated when changes occur.
Principle 2: Identify critical control points.
A Critical Control Point (CCP) is a point, step, or procedure in a food manufacturing process at which control can be applied and, as a result, a food safety hazard can be prevented, eliminated, or reduced to an acceptable level.
In CQPSS one should look at the process that has been automated and determine the point, step or procedure where one can perform a check. Preferably these checks should be designed in such a way that this check can be done automated. Checks should be done on various points in the process and not only on the outcome. For example: in data warehouse chains one should not only perform a check on the
reporting but should perform checks on staging, calculation outcomes, the data warehouse itself and the reporting.
Principle 3: Establish critical limits for each critical control point.
A critical limit is the maximum or minimum value to which a physical, biological, or chemical hazard must be controlled at a critical control point to prevent, eliminate, or reduce to an acceptable level.
Every checkpoint from principle 2 has got to have critical limits assigned. When for instance a normal incoming cashflow is reported from sourcesystems at 60K and 130K is highly unlikely than the system should have a critical boundary at 110 or 120K at the point of staging and the processing should be stopped or paused at least, the monitoring system should issue a warning so a business expert can check whether the cashflow is due to a frantic hype or perhaps some system has issued a batch of data twice.
Principle 4: Establish critical control point monitoring requirements.
Monitoring activities are necessary to ensure that the process is under control at each critical control point. In the United States, the FSIS is requiring that each monitoring procedure and its frequency be listed in the HACCP plan.
The output from principle 2 and 3 are used here and in this step the way HOW and HOW OFTEN these points are validated is established. For instance it can be described that a calculation check, described at principle 3, on cachflow is done at end-of-day each day at batch load point with a certain formula using a certain tool.
Principle 5: Establish corrective actions.
These are actions to be taken when monitoring indicates a deviation from an established critical limit. The final rule requires a plant's HACCP plan to identify
the corrective actions to be taken if a critical limit is not met. Corrective actions are intended to ensure that no product injurious to health or otherwise adulterated as a result of the deviation enters commerce.
Again a reference to principle 3; I here stated that for example the system should state a warning when the critical boundary is met. In principle 5 is is explicitly stated what the corrective action on this warning should be. In principle 3 it was stated that in that case a business expert should check the cause. Corrective actions could in this case be: stop load process, business expert check; frantic
hype -> continue batch processing or duplicate batch -> delete batch from flow and issue warning to delivering system.
Principle 6: Establish record keeping procedures.
The HACCP regulation requires that all plants maintain certain documents, including its hazard analysis and written HACCP plan, and records documenting the monitoring of critical control points, critical limits, verification activities, and the handling of processing deviations.
In CQPSS this means that the written CQPSS plan is published within the organisation is know to all the stakeholders of the process that is described and everybody is known with the actions to be taken. The results from the monitoring process should be archived as well; the way how to do this and how long data is to be kept is also to be described in the CQPSS plan. I like to mention here that it is especially of importance to highlight (or record extra in a specific overview) the derivations/ exceptions from the process, this way any changes in frequency or other anomalies in the process can be specificly monitored and acted upon; perhaps even a prediction can be made and adjustments (change request) can be issued.
Principle 7: Establish procedures for ensuring the HACCP system is working as intended.
Validation ensures that the plants do what they were designed to do; that is, they are successful in ensuring the production of safe product. Plants will be required to validate their own HACCP plans. FSIS will not approve HACCP plans in advance, but will review them for conformance with the final rule.
There are various monitoring ánd testtool that can be installed also on a production environment for monitoring purposes. These tools can be outfitted with specific testcases and checkpoints. When a fully automated process is in place, the control on the process is somewhat 'out of sight'. When this process is not working correctly it will never be noticed when regular checks on this process are
not in place. The CQPSS plan and its implemented process should be checked - preferably by an independent party- at regular intervals to check if the quality process is still working as intended. There should also be a validation on relevance of the process; are the checks being performed still covering all the risks that ought to be covered?
By implementing a process like CQPSS the measuring of quality of the system is not only done during the development phase (the traditional testing) but is extended to the complete lifecycle of the product/process. It makes the way to a more safer, more reliable and more trustworthy businessprocess where the monitored IT-component is implemented and - last but not least- makes it easier to apply for ((inter)national) certification of your business.
I was not always into testing. My first choice of studies, before getting entirely intrigued by IT, was that of FoodEngineering. When I got into the testing matter, I was surprised to find that in IT, testing is mostly done during development or when changes occur in the software or system. In the foodindustry there's a continuous quality process during development and during operations, this is named HACCP, the abbriviation for Hazard Analysis and Critical Control Points. HACCP - and I quote Wikipedia here - is a systematic preventive approach to food safety and pharmaceutical safety that addresses physical, chemical, and biological hazards as a means of prevention rather than finished product inspection. HACCP is used in the food industry to identify potential food safety hazards, so that key actions, known as Critical Control Points (CCPs) can be taken to reduce or eliminate the risk of the hazards being realized. The system is used at all stages of food production and preparation processes including packaging, distribution, etc.
I started to wonder why in IT (Testing) there is no such process implemented; our business is riskmitigation isn't it? IT is becoming more and more (or is already) essential in our businessprocesses and daily lives. Failure has such a hughe impact that I find it scary to not have constant monitoring on IT solutions. It is a known fact that testing during development can't be done with a 100% coverage of system- or software, so there are still some flaws in there that could mean disaster to your business...
I thought up the Continuous Quality Process Software- and Systems, in short (because IT likes the use of abbreviations) CQPSS. Of course I used the seven basic principles of HACCP as my baseline, so let's look at those principles, which I will map to CQPSS.
Principle 1: Conduct a hazard analysis.
Plans determine the food safety hazards and identify the preventive measures the plan can apply to control these hazards. A food safety hazard is any biological, chemical, or physical property that may cause a food to be unsafe for human consumption.
In the CQPSS it's almost the same. Every business has critical processes. In the CQPSS plan these criticall processes should be described. When testing during development is done correctly, this riskanalysis should be there and is re-usable. Ofcourse these should be updated when changes occur.
Principle 2: Identify critical control points.
A Critical Control Point (CCP) is a point, step, or procedure in a food manufacturing process at which control can be applied and, as a result, a food safety hazard can be prevented, eliminated, or reduced to an acceptable level.
In CQPSS one should look at the process that has been automated and determine the point, step or procedure where one can perform a check. Preferably these checks should be designed in such a way that this check can be done automated. Checks should be done on various points in the process and not only on the outcome. For example: in data warehouse chains one should not only perform a check on the
reporting but should perform checks on staging, calculation outcomes, the data warehouse itself and the reporting.
Principle 3: Establish critical limits for each critical control point.
A critical limit is the maximum or minimum value to which a physical, biological, or chemical hazard must be controlled at a critical control point to prevent, eliminate, or reduce to an acceptable level.
Every checkpoint from principle 2 has got to have critical limits assigned. When for instance a normal incoming cashflow is reported from sourcesystems at 60K and 130K is highly unlikely than the system should have a critical boundary at 110 or 120K at the point of staging and the processing should be stopped or paused at least, the monitoring system should issue a warning so a business expert can check whether the cashflow is due to a frantic hype or perhaps some system has issued a batch of data twice.
Principle 4: Establish critical control point monitoring requirements.
Monitoring activities are necessary to ensure that the process is under control at each critical control point. In the United States, the FSIS is requiring that each monitoring procedure and its frequency be listed in the HACCP plan.
The output from principle 2 and 3 are used here and in this step the way HOW and HOW OFTEN these points are validated is established. For instance it can be described that a calculation check, described at principle 3, on cachflow is done at end-of-day each day at batch load point with a certain formula using a certain tool.
Principle 5: Establish corrective actions.
These are actions to be taken when monitoring indicates a deviation from an established critical limit. The final rule requires a plant's HACCP plan to identify
the corrective actions to be taken if a critical limit is not met. Corrective actions are intended to ensure that no product injurious to health or otherwise adulterated as a result of the deviation enters commerce.
Again a reference to principle 3; I here stated that for example the system should state a warning when the critical boundary is met. In principle 5 is is explicitly stated what the corrective action on this warning should be. In principle 3 it was stated that in that case a business expert should check the cause. Corrective actions could in this case be: stop load process, business expert check; frantic
hype -> continue batch processing or duplicate batch -> delete batch from flow and issue warning to delivering system.
Principle 6: Establish record keeping procedures.
The HACCP regulation requires that all plants maintain certain documents, including its hazard analysis and written HACCP plan, and records documenting the monitoring of critical control points, critical limits, verification activities, and the handling of processing deviations.
In CQPSS this means that the written CQPSS plan is published within the organisation is know to all the stakeholders of the process that is described and everybody is known with the actions to be taken. The results from the monitoring process should be archived as well; the way how to do this and how long data is to be kept is also to be described in the CQPSS plan. I like to mention here that it is especially of importance to highlight (or record extra in a specific overview) the derivations/ exceptions from the process, this way any changes in frequency or other anomalies in the process can be specificly monitored and acted upon; perhaps even a prediction can be made and adjustments (change request) can be issued.
Principle 7: Establish procedures for ensuring the HACCP system is working as intended.
Validation ensures that the plants do what they were designed to do; that is, they are successful in ensuring the production of safe product. Plants will be required to validate their own HACCP plans. FSIS will not approve HACCP plans in advance, but will review them for conformance with the final rule.
There are various monitoring ánd testtool that can be installed also on a production environment for monitoring purposes. These tools can be outfitted with specific testcases and checkpoints. When a fully automated process is in place, the control on the process is somewhat 'out of sight'. When this process is not working correctly it will never be noticed when regular checks on this process are
not in place. The CQPSS plan and its implemented process should be checked - preferably by an independent party- at regular intervals to check if the quality process is still working as intended. There should also be a validation on relevance of the process; are the checks being performed still covering all the risks that ought to be covered?
By implementing a process like CQPSS the measuring of quality of the system is not only done during the development phase (the traditional testing) but is extended to the complete lifecycle of the product/process. It makes the way to a more safer, more reliable and more trustworthy businessprocess where the monitored IT-component is implemented and - last but not least- makes it easier to apply for ((inter)national) certification of your business.
donderdag 30 september 2010
Expo:QA 2010 - Discount and chance for an iPad
I will be doing the Software Testing Ethics Debate in Madrid, together with Wouter van Driel (Sogeti), at Expo:QA 2010 as Keynote!. And... we have a very exciting special/ mystery guest. So if you're there, be sure to attend!
If you register at this page http://www.expoqa.com/en/conference-inscripcion.php (English Page): With - Very important- this code : IPNAVADE you get a 5% discount on the admittance. If you do this before the 12th of October you also participate in a draw to win an iPad!
If you register at this page http://www.expoqa.com/en/conference-inscripcion.php (English Page): With - Very important- this code : IPNAVADE you get a 5% discount on the admittance. If you do this before the 12th of October you also participate in a draw to win an iPad!
dinsdag 28 september 2010
NoorderTest 2010
Last Thursday I attended 'NoorderTest'. This conference was held in the CJIB building in Leeuwarden and there were 160 participants. NoorderTest is a community of testers in the Nordic Region of the Netherlands consisting of testers working at (semi)governmental companies. Once every year they organize a larger conference so they can benefit from knowledge sharing.
This year my 'Ethics Debate' was selected on the program so I had the oppurtunity as non-Nordic-tester to attend!
The reception at the venue was very nice. Every speaker was guided through the building and their rooms were their track was given was inspected so it was made sure that everything was in order. There was coffee/tea and a piece of cake at the main hall were all attendees gathered till the kick-off was done. People were already in a conversational mood, because some effort had to be made to get everybody quiet for the opening speech :-)
The main thing that occurred to me that is was such a pleasant environment and mood.
The first track I attended was that of Rik Marselis. He had an interactive session about Chaintesting according to TMap. Different people participated in the different discussions which made it nice session to have visited. Although I have to make a remark that people who were not familiar with TMap or with the book about ChainTesting according to TMap had some difficulties with some material in the track and not all information came across to each participant.
Each track was seperated by a break in which people had plenty of oppurtunity to reflect on the track they attended. Some people found these breaks a bit too long, other people really liked the longer time in between. I was of the latter group; I liked the oppurtunity to reflect a bit longer on the track I just attended; it just seemed to make it more interactive as a whole.
The second track was my own :-) Together with Budimir Hrnjak, a colleague of mine I hosted the Ethics Debate, which was fully booked! (every track had to be booked beforehand). My Mystery Guest this time was Gerard Numan of Polteq; he had a great piece about the theory of Ethics and the relation to testers and the debates held just prior to his plea.
In the break after my track several groups were still debating the stuff from the session I heard in passing by the tables, so I found this very cool. Feedback was also very good; especially to the MysteryGuest :-) Maybe I'll have to hire him to do more Mystery/Ethics stuff in the future.
The last track I missed; alas. I was still so busy with all kinds of conversations that the next tracks already started and I didn't have the heart to interrupt any speaker. So I used the time to fill out the puzzle that was in the program booklet.
At the draw it seemed that I had not wasted my time: I won the romantic night for two that was the prize to be won with the puzzle :-)
After the last speech, people had the oppurtunity to have dinner (buffet). It was a ham-mellon cocktail for starters, than Macaroni/cheese or Ham/Potatoes or Rice/Goulash and a desert. I missed the desert and the drinks afterwards because I had another appointment nearby. But I can imagine it was still a good gathering then.
The farewell gift was a black chalkboardlike mug with a crayon (so you could write on the mug) and a small box of mints.
I had a good experience at this conference. Alas it's only for members of NoorderTest, for which you have to work at one of these Nordic Companies. But if you are in the oppurtunity to attend, I would certainly recommend this meeting!
This year my 'Ethics Debate' was selected on the program so I had the oppurtunity as non-Nordic-tester to attend!
The reception at the venue was very nice. Every speaker was guided through the building and their rooms were their track was given was inspected so it was made sure that everything was in order. There was coffee/tea and a piece of cake at the main hall were all attendees gathered till the kick-off was done. People were already in a conversational mood, because some effort had to be made to get everybody quiet for the opening speech :-)
The main thing that occurred to me that is was such a pleasant environment and mood.
The first track I attended was that of Rik Marselis. He had an interactive session about Chaintesting according to TMap. Different people participated in the different discussions which made it nice session to have visited. Although I have to make a remark that people who were not familiar with TMap or with the book about ChainTesting according to TMap had some difficulties with some material in the track and not all information came across to each participant.
Each track was seperated by a break in which people had plenty of oppurtunity to reflect on the track they attended. Some people found these breaks a bit too long, other people really liked the longer time in between. I was of the latter group; I liked the oppurtunity to reflect a bit longer on the track I just attended; it just seemed to make it more interactive as a whole.
The second track was my own :-) Together with Budimir Hrnjak, a colleague of mine I hosted the Ethics Debate, which was fully booked! (every track had to be booked beforehand). My Mystery Guest this time was Gerard Numan of Polteq; he had a great piece about the theory of Ethics and the relation to testers and the debates held just prior to his plea.
In the break after my track several groups were still debating the stuff from the session I heard in passing by the tables, so I found this very cool. Feedback was also very good; especially to the MysteryGuest :-) Maybe I'll have to hire him to do more Mystery/Ethics stuff in the future.
The last track I missed; alas. I was still so busy with all kinds of conversations that the next tracks already started and I didn't have the heart to interrupt any speaker. So I used the time to fill out the puzzle that was in the program booklet.
At the draw it seemed that I had not wasted my time: I won the romantic night for two that was the prize to be won with the puzzle :-)
After the last speech, people had the oppurtunity to have dinner (buffet). It was a ham-mellon cocktail for starters, than Macaroni/cheese or Ham/Potatoes or Rice/Goulash and a desert. I missed the desert and the drinks afterwards because I had another appointment nearby. But I can imagine it was still a good gathering then.
The farewell gift was a black chalkboardlike mug with a crayon (so you could write on the mug) and a small box of mints.
I had a good experience at this conference. Alas it's only for members of NoorderTest, for which you have to work at one of these Nordic Companies. But if you are in the oppurtunity to attend, I would certainly recommend this meeting!
donderdag 9 september 2010
Expo:QA 2010
I will be doing the Software Testing Ethics Debate in Madrid, together with Wouter van Driel (Sogeti), at Expo:QA 2010 as Keynote!. And... we have a very exciting special/ mystery guest. So if you're there, be sure to attend!
donderdag 15 juli 2010
Are we there yet?
I'm dragging myself towards the holidays, two more weeks left of work and then there will be two weeks of nothingness, well almost, the first couple of days I'll be at RockArea festival at the Loreley theatre in Germany, but after that: I'll just lay back on my garden chair with a lousy novelette. At least there are no suprises there: woman meets man, they come together, they fight and they come together again, and live happily ever after. Man is always handsome and rich of course and the woman always has had issues in her passed which are generously forgiven by the man. Finally issues that really get solved :-)
Why not a good book or literature? Well; I've read my share of serious knowledge at the beginning of this year, and it seems that I'll be reading a lot more in the months to come - believe me-, so I refuse to do any serious reading in between.
Last couple of weeks have been very hectic with my project, luckily it went live this week [successfully] so now the only tasks ahead are wrapping up the last bits-and-pieces; writing the end reports, evaluating, that kind of stuff. I think it has never been so relaxed in the weeks before my vacation; and I think I've never been more bored. I like some action at the workside; that makes it more rewarding to relax at home. I like the fact that I won't have any late-night chores for work (part of the hectic stuff) but now the project is delivered for this stage, the work is TOO slow. Makes me wan't to cry out: 'Are we there yet?'.
So what do you do when work is slow? Yes indeed: you relax at work, but that means you make pace at home (world turned around). This means I have loads of work at home and non-client related stuff. The stuff I don't come around to do when work's hectic.
So currently I'm working on a new presentation called "Unusual testing: Lessons learned from being a casualty simulations victim", to be held at Capgemini's TestEvent 2010. I'm still working on some sessions of the 'Software Testing Ethics Debate', one to be held at NoorderTest 2010 in Leeuwarden and one to be held at ExpoQA:2010 in Madrid. I still have some work on Business Intelligence Testing (formerly known as Data Warehouse Testing) and Test Architecture Framework, and some reviewing on NEN/ISO items that are test-related (or related to some other field of expertise which I'm familiar with). So now I'm so busy at home that I really look forward to my holiday and desperately cry out: "Are whe there yet???"
All : have a happy and relaxed vacation! I know I will :-)
Why not a good book or literature? Well; I've read my share of serious knowledge at the beginning of this year, and it seems that I'll be reading a lot more in the months to come - believe me-, so I refuse to do any serious reading in between.
Last couple of weeks have been very hectic with my project, luckily it went live this week [successfully] so now the only tasks ahead are wrapping up the last bits-and-pieces; writing the end reports, evaluating, that kind of stuff. I think it has never been so relaxed in the weeks before my vacation; and I think I've never been more bored. I like some action at the workside; that makes it more rewarding to relax at home. I like the fact that I won't have any late-night chores for work (part of the hectic stuff) but now the project is delivered for this stage, the work is TOO slow. Makes me wan't to cry out: 'Are we there yet?'.
So what do you do when work is slow? Yes indeed: you relax at work, but that means you make pace at home (world turned around). This means I have loads of work at home and non-client related stuff. The stuff I don't come around to do when work's hectic.
So currently I'm working on a new presentation called "Unusual testing: Lessons learned from being a casualty simulations victim", to be held at Capgemini's TestEvent 2010. I'm still working on some sessions of the 'Software Testing Ethics Debate', one to be held at NoorderTest 2010 in Leeuwarden and one to be held at ExpoQA:2010 in Madrid. I still have some work on Business Intelligence Testing (formerly known as Data Warehouse Testing) and Test Architecture Framework, and some reviewing on NEN/ISO items that are test-related (or related to some other field of expertise which I'm familiar with). So now I'm so busy at home that I really look forward to my holiday and desperately cry out: "Are whe there yet???"
All : have a happy and relaxed vacation! I know I will :-)
woensdag 19 mei 2010
A lot on my mind...
Lately I've visited some presentations and read some stuff about certification, standardisation, evidence and the different opinions about those, and I can't help myself but I feel anger and frustration when I read certain blogs and the comments on those blog entries.
I find that a certification like ISTQB doesn't make me a better tester, but it didn't make me a worse tester either. What makes me a better tester, in my opinion, is that I explore different possibilities and what I find important is that I have knowledge on all areas of testing and am capable to use that knowledge in the best way for the organisation I'm testing for.
I find both knowledge on ISO, IEEE and BS (ISTQB) as usefull as other information and knowledge about testing (exploratory, agile, etc),not matter what origination. What I DO with it and HOW I use this information most in the most valuable and effective way is quite another issue.
I NEED structure that schools, trainings and courses provide to learn. I don't have the discipline to set myself to learn it all, although I can sometimes set myself goals and learn about stuff, that is not always the case. Certificates give me a certain feeling of pride, I don't know why, it is just so. That doens't mean I don't value or practice self eduction. What pisses me off is the fact that certain people don't respect that.
A couple of months ago I had a discussion on Twitter, that person even disrespected me even more by saying that 'if I wanted to learn testing I was always welcome to attend his course'. It was perceived by me that, because I was proud on having learned and passed the ISEB Practicioner exam, I didn't know about testing. The person in question could judge me completely on those couple of tweets posted.
In the same way home-made-psychology is used, this person KNEW as a fact that I didn't know how to test apparently. This felt to me as complete disrespect, give me some credits please!
My 'plan of approach' or the way I work preferably is that I know about all historical and new developements, THAN I use the knowledge to get to a effective and - for the client comfortable and understandable- way of working. This isn't directed by the ISO standard, the ISTQB certification or the teachings about exploratory testing and storybased testing. I don't think either way is better or worse, I think 'traditional' ways are as usefull as 'new' ways, both should be added to our own knowledge base and be put to good use. That could be that one way is totally unusefull for that particular organisation, but at least I KNOW the contents of what I dismiss and if I have a discussion at least I know what the theory says and can compare it to practical usage.
A filosopher once said that by knowing more, we even know less. I think certain people forget about that basic principle, for it could also be used in other perspectives. By teaching 'non schooling' you become that what you oppose to: a teacher that gives an outlined (and scoped) teaching. By evangelising a way of working it becomes (or has a chance of becoming) a (defacto) standard and that standard was the thing the evangalist was all against in the first place.
In one of the comments it was mentioned that development of the standard was taking five years, it was mentioned with a certain amount of disbelief and in a way that it was the 'fault' of the person that leads that particular project. This triggered another 'pissed at' moment.
First of all the development of the standard takes that long because prescribed procedure of ISO/IEC doesn't allow it to be shorter.
Secondly a lot of arguments come from people from a country that doesn't provide any subject matter experts to the project (except for an ISO 'veteran' who doesn't have software testing as expertise apparently), it's easy to have comments on something, but it's - IMHO- better to participate and provide valuable input or feedback so we can get to a better product. And again I like to mention here: a standard isn't a commandment, it's a GUIDELINE! (there seems to be a lot of arguments on that)
Some other writings that I read have whole argumental epistels on what they THINK is about to be presented. Why do I put it like this? Well the subject discussed (a track at EuroSTAR 2010) has not been presented yet and still whole arguments are already written about it, based purely on what the abstract (!!) states. Mind: it still has to be presented, so the arguments are based on - in my opinion a very non-testing thing- assumptions. The most worrying thing about this is that the arguments are stated by visionairs and thoughtleaders in the software testing 'science'. (I myself don't think it's a science but a profession) . The arguments are also written in an agressive, non respective way in my perception.
I really don't like these kind of developments, they give me chills and make me sad and angry. I cannot help myself by finding that having read the pieces a personal vendetta is fought out. This has nothing to do with 'making your point' I feel, but more like 'I'm always right and everybody else (and in particular that person) is wrong'. BLERGH!
All this stuff: It gives me a bad taste in my mouth, something similar as with discrimination and generalizing.
So let me share some thoughts:
I think everybody is entitled to have his or her own opinion.
I think everybody should be able to practice the way of education he or she prefers, without being judged on what path is chosen
I think nobody should judge something on assumptions (let alone argument on that judgement!) [and yes, I'm guilty too I guess]
I think everybody is entitled to respectfull manners no matter if you agree or disagree
I think nobody should be excluded from oppurtunities based on 'a piece of paper', but everybody should have an oppurtunity based on (valid) experience
I think nobody is 'better' of 'worse' based on 'a piece of paper' (but that also counts for 'having done a course' or 'not having a piece of paper')
I think everybody has a right to speak his/her mind (but doesn't have a right to 'go for the man' or has a right to do so on anothers expense)
I think there isn't a right way or a wrong way; it's DIFFERENT ways that matter
I think I think a lot of things right now. But most of all I think of one word: RESPECT
Let's all cherish this in a grande way so we can all be passionate about -what we feel is the best and most fun- way to practice the profession of software testing.
I find that a certification like ISTQB doesn't make me a better tester, but it didn't make me a worse tester either. What makes me a better tester, in my opinion, is that I explore different possibilities and what I find important is that I have knowledge on all areas of testing and am capable to use that knowledge in the best way for the organisation I'm testing for.
I find both knowledge on ISO, IEEE and BS (ISTQB) as usefull as other information and knowledge about testing (exploratory, agile, etc),not matter what origination. What I DO with it and HOW I use this information most in the most valuable and effective way is quite another issue.
I NEED structure that schools, trainings and courses provide to learn. I don't have the discipline to set myself to learn it all, although I can sometimes set myself goals and learn about stuff, that is not always the case. Certificates give me a certain feeling of pride, I don't know why, it is just so. That doens't mean I don't value or practice self eduction. What pisses me off is the fact that certain people don't respect that.
A couple of months ago I had a discussion on Twitter, that person even disrespected me even more by saying that 'if I wanted to learn testing I was always welcome to attend his course'. It was perceived by me that, because I was proud on having learned and passed the ISEB Practicioner exam, I didn't know about testing. The person in question could judge me completely on those couple of tweets posted.
In the same way home-made-psychology is used, this person KNEW as a fact that I didn't know how to test apparently. This felt to me as complete disrespect, give me some credits please!
My 'plan of approach' or the way I work preferably is that I know about all historical and new developements, THAN I use the knowledge to get to a effective and - for the client comfortable and understandable- way of working. This isn't directed by the ISO standard, the ISTQB certification or the teachings about exploratory testing and storybased testing. I don't think either way is better or worse, I think 'traditional' ways are as usefull as 'new' ways, both should be added to our own knowledge base and be put to good use. That could be that one way is totally unusefull for that particular organisation, but at least I KNOW the contents of what I dismiss and if I have a discussion at least I know what the theory says and can compare it to practical usage.
A filosopher once said that by knowing more, we even know less. I think certain people forget about that basic principle, for it could also be used in other perspectives. By teaching 'non schooling' you become that what you oppose to: a teacher that gives an outlined (and scoped) teaching. By evangelising a way of working it becomes (or has a chance of becoming) a (defacto) standard and that standard was the thing the evangalist was all against in the first place.
In one of the comments it was mentioned that development of the standard was taking five years, it was mentioned with a certain amount of disbelief and in a way that it was the 'fault' of the person that leads that particular project. This triggered another 'pissed at' moment.
First of all the development of the standard takes that long because prescribed procedure of ISO/IEC doesn't allow it to be shorter.
Secondly a lot of arguments come from people from a country that doesn't provide any subject matter experts to the project (except for an ISO 'veteran' who doesn't have software testing as expertise apparently), it's easy to have comments on something, but it's - IMHO- better to participate and provide valuable input or feedback so we can get to a better product. And again I like to mention here: a standard isn't a commandment, it's a GUIDELINE! (there seems to be a lot of arguments on that)
Some other writings that I read have whole argumental epistels on what they THINK is about to be presented. Why do I put it like this? Well the subject discussed (a track at EuroSTAR 2010) has not been presented yet and still whole arguments are already written about it, based purely on what the abstract (!!) states. Mind: it still has to be presented, so the arguments are based on - in my opinion a very non-testing thing- assumptions. The most worrying thing about this is that the arguments are stated by visionairs and thoughtleaders in the software testing 'science'. (I myself don't think it's a science but a profession) . The arguments are also written in an agressive, non respective way in my perception.
I really don't like these kind of developments, they give me chills and make me sad and angry. I cannot help myself by finding that having read the pieces a personal vendetta is fought out. This has nothing to do with 'making your point' I feel, but more like 'I'm always right and everybody else (and in particular that person) is wrong'. BLERGH!
All this stuff: It gives me a bad taste in my mouth, something similar as with discrimination and generalizing.
So let me share some thoughts:
I think everybody is entitled to have his or her own opinion.
I think everybody should be able to practice the way of education he or she prefers, without being judged on what path is chosen
I think nobody should judge something on assumptions (let alone argument on that judgement!) [and yes, I'm guilty too I guess]
I think everybody is entitled to respectfull manners no matter if you agree or disagree
I think nobody should be excluded from oppurtunities based on 'a piece of paper', but everybody should have an oppurtunity based on (valid) experience
I think nobody is 'better' of 'worse' based on 'a piece of paper' (but that also counts for 'having done a course' or 'not having a piece of paper')
I think everybody has a right to speak his/her mind (but doesn't have a right to 'go for the man' or has a right to do so on anothers expense)
I think there isn't a right way or a wrong way; it's DIFFERENT ways that matter
I think I think a lot of things right now. But most of all I think of one word: RESPECT
Let's all cherish this in a grande way so we can all be passionate about -what we feel is the best and most fun- way to practice the profession of software testing.
Abonneren op:
Posts (Atom)