Here is another gem from Dr Kaner .. this time around it is about Software Metrics ...
A rare insight into metrics world ....
http://www.artima.com/forums/flat.jsp?forum=106&thread=218013&start=30#287847
This is in responce to a thread by Alberto Savoia
http://www.artima.com/forums/flat.jsp?forum=106&thread=218013&start=0&msRange=15
I keep looking for such insightful replies and posts ... I hope readers are liking it and getting benefited by it ...
Shrini
Wednesday, November 21, 2007
Saturday, November 17, 2007
Further on Testing as a career ..
Following this post on career in software testing , I found an interesting comment/viewpoint from Jeff Fry's post (more preciously a comment to his post by one "Steve Sandvik") on "why do you enjoy testing".
Jeff Fry's post itself is a very good post that goes in details about "Testing, Career, Enjoyment and few suggestions for tester to stufy read".
Following are Steve Sandvik's comments that worth "consideration"
"...Yes, it may be my first formal job testing software, but as so many people in testing like to point out, nearly any experience or learning has some translation to testing, if you know how to apply it. 15 years of power plant operation and maintenance experience provides an awfully large number of troubleshooting and investigation opportunities.
Identify the fields outside of your industry where, for lack of a better description, good forensic skills and an agile mind (not to be confused with an Agile mind) are at a premium. Industrial equipment field service, process and generation operations, and auditing are a few I can think of off the top of my head. "
And these comments about "in-born" testing qualities
" ...I’m not sure whether truly great testers are born or made, but I think there’s at least a component of most of them that falls firmly into the born camp–in the same way most writers would write whether or not they were paid to do it, I suspect that most people who seriously take up testing as a career for its own sake rather than as a stepping stone to something else approach the world in a certain way even when they’re not formally testing. I know I approach things from what seems to me to be a testing perspective most of the time."
I am filling my blogs with few interesting career related suggestions ... I hope my blog readers are enjoying ...
Shrini
Jeff Fry's post itself is a very good post that goes in details about "Testing, Career, Enjoyment and few suggestions for tester to stufy read".
Following are Steve Sandvik's comments that worth "consideration"
"...Yes, it may be my first formal job testing software, but as so many people in testing like to point out, nearly any experience or learning has some translation to testing, if you know how to apply it. 15 years of power plant operation and maintenance experience provides an awfully large number of troubleshooting and investigation opportunities.
Identify the fields outside of your industry where, for lack of a better description, good forensic skills and an agile mind (not to be confused with an Agile mind) are at a premium. Industrial equipment field service, process and generation operations, and auditing are a few I can think of off the top of my head. "
And these comments about "in-born" testing qualities
" ...I’m not sure whether truly great testers are born or made, but I think there’s at least a component of most of them that falls firmly into the born camp–in the same way most writers would write whether or not they were paid to do it, I suspect that most people who seriously take up testing as a career for its own sake rather than as a stepping stone to something else approach the world in a certain way even when they’re not formally testing. I know I approach things from what seems to me to be a testing perspective most of the time."
I am filling my blogs with few interesting career related suggestions ... I hope my blog readers are enjoying ...
Shrini
Friday, November 16, 2007
Michael Bolton on "Software Bugs"
Continuing my earlier post on Dr Cem Kaner's comment, this time is about sharing views about software bugs by another leading light of context driven testing community - Michael Bolton.
Here are his views about "software bugs" (Again, these Michael's views in response to a question on the forum about Bugs - whole his reply stands on its own, I believe)
Personally, this is best advise that I have ever seen with respect to handing bugs by testers and how that decision impacts other stakeholders ... Read on ...
[Michael Bolton : Quote]
When I'm a tester, I'm concerned about trying to drive the project. As a project manager, that was my job. As a tester, my job was--and is--to ferret out information of any kind about the application that helps the project manager to achieve her goals. For me, this has a couple of implications.
First, I don't merely observe the product; I have to observe the things around the product--the platform, the systems with which the product interacts, the business processes, the anticipated or unanticipated users of the product, and so on. I try to be leery of recommendations to fix specific bugs, because in the past I spent too long going the other way--believing that I'm running the project when I'm not. (I'm arguably not a multimillionaire at least in part because in one company where I worked, company project managers had abdicated quality decisions to the testers and developers, which meant that we had a great, largely bug-free product that missed its market window by about a year.)
Second, there is one particular kind of bug that I will try to sell: bugs that make testing harder or slow it down. My goal is to reveal information about the product. Even if we do great testing, there are some things that we won't know about the product. Things that impinge on testing pose the risk of us knowing even less than we would otherwise.
So, with at least one eye firmly fixed on the context and the best judgement I can muster, I will advocate strongly
- to fix immediately bugs that block deeper or broader testing;
- to add testability (logging, scriptable interfaces, configurability, controllability, installability) to the product such that we can increase test coverage;
- to fix immediately trivial-looking bugs that add distraction and noise to the project effort--for example, typos that absolutely everyone will notice and report, such that the reporting and processing of the report will take time away from other coverage.
However, I also remind myself that we testers are vulnerable to representativeness bias--bugs that look trivially simply might be hard to fix, bugs that seem gnarly might be insignificant to the end-user, bugs that look hideously complex might have easy fixes, and so on. So I try to tell the absolute best story that I can about the bug and its worst ramifications, but I also acknowledge that I might not have the whole story about the technical or business reasons to fix or to defer a bug
[Michael Bolton: Unquote]
Shrini
Here are his views about "software bugs" (Again, these Michael's views in response to a question on the forum about Bugs - whole his reply stands on its own, I believe)
Personally, this is best advise that I have ever seen with respect to handing bugs by testers and how that decision impacts other stakeholders ... Read on ...
[Michael Bolton : Quote]
When I'm a tester, I'm concerned about trying to drive the project. As a project manager, that was my job. As a tester, my job was--and is--to ferret out information of any kind about the application that helps the project manager to achieve her goals. For me, this has a couple of implications.
First, I don't merely observe the product; I have to observe the things around the product--the platform, the systems with which the product interacts, the business processes, the anticipated or unanticipated users of the product, and so on. I try to be leery of recommendations to fix specific bugs, because in the past I spent too long going the other way--believing that I'm running the project when I'm not. (I'm arguably not a multimillionaire at least in part because in one company where I worked, company project managers had abdicated quality decisions to the testers and developers, which meant that we had a great, largely bug-free product that missed its market window by about a year.)
Second, there is one particular kind of bug that I will try to sell: bugs that make testing harder or slow it down. My goal is to reveal information about the product. Even if we do great testing, there are some things that we won't know about the product. Things that impinge on testing pose the risk of us knowing even less than we would otherwise.
So, with at least one eye firmly fixed on the context and the best judgement I can muster, I will advocate strongly
- to fix immediately bugs that block deeper or broader testing;
- to add testability (logging, scriptable interfaces, configurability, controllability, installability) to the product such that we can increase test coverage;
- to fix immediately trivial-looking bugs that add distraction and noise to the project effort--for example, typos that absolutely everyone will notice and report, such that the reporting and processing of the report will take time away from other coverage.
However, I also remind myself that we testers are vulnerable to representativeness bias--bugs that look trivially simply might be hard to fix, bugs that seem gnarly might be insignificant to the end-user, bugs that look hideously complex might have easy fixes, and so on. So I try to tell the absolute best story that I can about the bug and its worst ramifications, but I also acknowledge that I might not have the whole story about the technical or business reasons to fix or to defer a bug
[Michael Bolton: Unquote]
Shrini
Dr. Cem Kaner on Software Testing as a Career
I take this opportunity to share few on great discussions happening at "software-testing" Yahoo group, to all my blog readers. For the purpose of focus, I am not sharing the entire thread and the beauty of the reply is such that you can read this without knowing or referring the original post that initiated this discussion....
There were actually two replies by Dr Kaner - I am taking the liberty of rearranging few paragraphs from both replies in order to givea specific flow to the whole thing. The purpose of this post is to share the words of wisdom and experience for all those who would like pursue the career in “Software Testing
[Dr Kaner: Quote]
Let me start by distinguishing between a CAREER and a JOB. A CAREER involves a long-term, intentional focus on a field or type of work. A JOB is a temporary assignment with a particular employer. My career is focused on improving the satisfaction and safety of software users and developers. My current job is as a professor. I have also held jobs as a tester, test manager, programmer, human factors analyst, software development manager, technical publications manager, development director, organization development consultant, salesperson, software development consultant, and attorney focused on the law of software quality. Each of these has addressed different aspects of what has been, to me, the same career. People define their own careers. Many people define their career in terms of traditional categories (programmer, tester, lawyer, teacher), but the choice belongs to the person, not the category.
When you make a choice ("I am an X" or "My career is X"), that choice is both inclusive (Xness is in your path) and exclusive (if Yness is not part of Xness, and Xness is not part of Yness, then "I am X" means also "I am not Y"). When someone defines their career as "tester," I think that definition is too narrow.
I see software development as a bundle of coordinated tasks, including programming, design, testing, usability evaluation, modeling, documentation, development of associated training, project management, etc. Very few people would do all of these as part of the same job. Fewer would do them all on the same project or in the same week. But working at one company as a tester and another company later as a programmer is not inconsistent with calling myself a software developer at either/both companies
I don't generally encourage my students to pursue software testing AS A CAREER. They can make that decision later, after they have more experience. I prefer to encourage them to try SOFTWARE DEVELOPMENT as a career -- to me, development includes testing. And that they take a job doing serious, skilled testing as PART of that career. Most of the best testers I know have significant experience outside of testing and apply that experience to what they do as testers or test managers.
I think that testing is a fine choice for a first job--for some people--but that doesn't make it a first career. It becomes a first career only for the person who says, "This, testing, is my career." I don't recommend that people make a decision to narrow their career that much, early in their career. Let them explore the field more, in their next few jobs, before they lock themselves into something.
I think that some people are good at both programming and testing, some people are good at both writing and testing, some people are good at design and testing, very few people are good at every software development task. So I think it is inappropriate to say that someone shouldn't be considered a software developer because they are good at some aspects of development but not others. Most (all?) of the hidebound process-pushers that I know in the field have never done serious professional work outside of testing. From their narrow perspective, they think they know more about how to manage a development project than the people who retain their testing services. Instead of trying out their ideas as project managers (where they will be accountable if they fail) these process advocates undermine the projects they work on by trying to control things they don't understand with rigid policies and procedures, standards and superstitions, whose costs and impacts are beyond their imagination. We have too many of these people in our field. We need more people who have a broader view of the tremendous value that testing can offer--within its limited role--and are glad to embrace a service-provider role that provides that value.
I think some fresh engineers should start their career with a job in programming, others with testing, others writing, others with human factors assessment, others with configuration management, others with data analysis. I think that choice should depend on what motivates the particular person.
What makes testing worth spending time on--as a job and maybe as a career?
We are professional investigators. Rather than building things, we find ways to answer difficult questions about the quality of the products or services we test. Our job--if we choose to do it well--requires us to constantly learn new things, about the product, its market, its implementation, its risks, its usability, etc. To learn these, we are constantly developing new skills and new cognitive structures in a diversity of fields. It also requires us to communicate well to a diverse group of people. We ALSO get to build things (test tools), but very often, we build to our own designs, which can be more satisfying than building an application that does something we'll never personally do (or want to do). Learning to do good software testing requires learning to do critical thinking well, and to back it up with empirical research. Not everyone will like to do testing. Not every engineer or programmer will have the skills or the interest to do professional-level testing. But for those of us who enjoy critical thinking, experimentation, and keeping the human relevance of what we do always in mind, there is nothing else like it in software development (except, for some people on some projects, requirements analysis backed with rapid prototyping and prototype-based research).
[Dr Kaner: Unquote]
Shrini
There were actually two replies by Dr Kaner - I am taking the liberty of rearranging few paragraphs from both replies in order to givea specific flow to the whole thing. The purpose of this post is to share the words of wisdom and experience for all those who would like pursue the career in “Software Testing
[Dr Kaner: Quote]
Let me start by distinguishing between a CAREER and a JOB. A CAREER involves a long-term, intentional focus on a field or type of work. A JOB is a temporary assignment with a particular employer. My career is focused on improving the satisfaction and safety of software users and developers. My current job is as a professor. I have also held jobs as a tester, test manager, programmer, human factors analyst, software development manager, technical publications manager, development director, organization development consultant, salesperson, software development consultant, and attorney focused on the law of software quality. Each of these has addressed different aspects of what has been, to me, the same career. People define their own careers. Many people define their career in terms of traditional categories (programmer, tester, lawyer, teacher), but the choice belongs to the person, not the category.
When you make a choice ("I am an X" or "My career is X"), that choice is both inclusive (Xness is in your path) and exclusive (if Yness is not part of Xness, and Xness is not part of Yness, then "I am X" means also "I am not Y"). When someone defines their career as "tester," I think that definition is too narrow.
I see software development as a bundle of coordinated tasks, including programming, design, testing, usability evaluation, modeling, documentation, development of associated training, project management, etc. Very few people would do all of these as part of the same job. Fewer would do them all on the same project or in the same week. But working at one company as a tester and another company later as a programmer is not inconsistent with calling myself a software developer at either/both companies
I don't generally encourage my students to pursue software testing AS A CAREER. They can make that decision later, after they have more experience. I prefer to encourage them to try SOFTWARE DEVELOPMENT as a career -- to me, development includes testing. And that they take a job doing serious, skilled testing as PART of that career. Most of the best testers I know have significant experience outside of testing and apply that experience to what they do as testers or test managers.
I think that testing is a fine choice for a first job--for some people--but that doesn't make it a first career. It becomes a first career only for the person who says, "This, testing, is my career." I don't recommend that people make a decision to narrow their career that much, early in their career. Let them explore the field more, in their next few jobs, before they lock themselves into something.
I think that some people are good at both programming and testing, some people are good at both writing and testing, some people are good at design and testing, very few people are good at every software development task. So I think it is inappropriate to say that someone shouldn't be considered a software developer because they are good at some aspects of development but not others. Most (all?) of the hidebound process-pushers that I know in the field have never done serious professional work outside of testing. From their narrow perspective, they think they know more about how to manage a development project than the people who retain their testing services. Instead of trying out their ideas as project managers (where they will be accountable if they fail) these process advocates undermine the projects they work on by trying to control things they don't understand with rigid policies and procedures, standards and superstitions, whose costs and impacts are beyond their imagination. We have too many of these people in our field. We need more people who have a broader view of the tremendous value that testing can offer--within its limited role--and are glad to embrace a service-provider role that provides that value.
I think some fresh engineers should start their career with a job in programming, others with testing, others writing, others with human factors assessment, others with configuration management, others with data analysis. I think that choice should depend on what motivates the particular person.
What makes testing worth spending time on--as a job and maybe as a career?
We are professional investigators. Rather than building things, we find ways to answer difficult questions about the quality of the products or services we test. Our job--if we choose to do it well--requires us to constantly learn new things, about the product, its market, its implementation, its risks, its usability, etc. To learn these, we are constantly developing new skills and new cognitive structures in a diversity of fields. It also requires us to communicate well to a diverse group of people. We ALSO get to build things (test tools), but very often, we build to our own designs, which can be more satisfying than building an application that does something we'll never personally do (or want to do). Learning to do good software testing requires learning to do critical thinking well, and to back it up with empirical research. Not everyone will like to do testing. Not every engineer or programmer will have the skills or the interest to do professional-level testing. But for those of us who enjoy critical thinking, experimentation, and keeping the human relevance of what we do always in mind, there is nothing else like it in software development (except, for some people on some projects, requirements analysis backed with rapid prototyping and prototype-based research).
[Dr Kaner: Unquote]
Shrini
Monday, November 05, 2007
Tester's world of Possibilities
Probable impossibilities are to be preferred to improbable possibilities. -- Aristotle
The future belongs to those who see possibilities before they become obvious. -- John Sculley
Recently, I challenged a fellow tester about testing “Notepad ->File -> Save As” functionality. I asked him to zoom on (focus) only Text files and investigating about file names (say base file name – one without the extension) and come up with testing ideas.
He started with domain testing approach and said that file names that can be supplied to the program could be classified as:
Valid File Names – those where file creation succeeds.
Invalid File names – where file creation fails and no new file gets created.
Then he went on thinking about possible values in terms of these “classes”. I argued with him about his classification – why only think about valid and invalid file names? Can you think about other possibilities …?
Few examples that I gave are –
What if file is created but it can not be opened to view?
What if the file is created but is read only?
What if the file is created but notepad application crashes during the file creation?
What if the file is created but notepad crashes while opening such a file?
What if the file is created but it takes 10 minutes to load the file?
what if the file is created but can not be searched using Windows – Search?
And so on …
My friend said “well all of these can be considered as invalid file names” … To that I said “But as per your initial classification, no file gets created for an invalid name ….!!!!”
My friend continued “ These all are possibilities but not real values …”. I said “That is exactly is my point. As a curious tester, I think about all possibilities and then investigate on those possibilities. My work starts from that point where other wash off their hands saying “We are done”.
What do you think are the possibilities when a file is entered for Notepad -> File->Save As dialog? Keep your investigations on the lines probing the file name parameter…Can you describe the "big picture"?
Shrini
The future belongs to those who see possibilities before they become obvious. -- John Sculley
Recently, I challenged a fellow tester about testing “Notepad ->File -> Save As” functionality. I asked him to zoom on (focus) only Text files and investigating about file names (say base file name – one without the extension) and come up with testing ideas.
He started with domain testing approach and said that file names that can be supplied to the program could be classified as:
Valid File Names – those where file creation succeeds.
Invalid File names – where file creation fails and no new file gets created.
Then he went on thinking about possible values in terms of these “classes”. I argued with him about his classification – why only think about valid and invalid file names? Can you think about other possibilities …?
Few examples that I gave are –
What if file is created but it can not be opened to view?
What if the file is created but is read only?
What if the file is created but notepad application crashes during the file creation?
What if the file is created but notepad crashes while opening such a file?
What if the file is created but it takes 10 minutes to load the file?
what if the file is created but can not be searched using Windows – Search?
And so on …
My friend said “well all of these can be considered as invalid file names” … To that I said “But as per your initial classification, no file gets created for an invalid name ….!!!!”
My friend continued “ These all are possibilities but not real values …”. I said “That is exactly is my point. As a curious tester, I think about all possibilities and then investigate on those possibilities. My work starts from that point where other wash off their hands saying “We are done”.
What do you think are the possibilities when a file is entered for Notepad -> File->Save As dialog? Keep your investigations on the lines probing the file name parameter…Can you describe the "big picture"?
Shrini
Subscribe to:
Posts (Atom)