In the month of August 2010, Beyond Testing eMagazine was launched. This magazine is being hailed as India's first Software Testing magazine.
I too contributed to this magazine and my article- Why is Integrity foremost of Software Tester's skills ? got published here. It took a cue from one of my previous blog posts and came up with this piece.
Do go through this and let me know your comments.
As for the magazine, i must say its an honest attempt by the editorial board to launch this. I think the biggest challenge would be to sustain this for a longer time and also make the overall formatting and layout look even better and more professional that what it is currently. One (of many) good things that i found was that it was quite good content-wise and worth a read!
Subscribe to:
Post Comments (Atom)
12 comments:
I don't completely agree comparing the hand of god concept to the Testers way of thinking what testing really means to them.
Putting Ethical/Unethical part apart,
what I can compare it with is just a simple question:
When in doubt.. Do you let your instincts guide you?
I don't completely agree comparing the hand of god concept to the Testers way of thinking what testing really means to them.
I like disagreements. Thank you for the comments.
Putting Ethical/Unethical part apart,
what I can compare it with is just a simple question:
When in doubt.. Do you let your instincts guide you?
I probably won’t agree with you here but would like to discuss further. Instincts and gut feel are some good ways of making decisions when the facts available are limited. We do run into some such situations when taking decision is mandatory without all facts and figures or when the time is limited. Probably, in those situations one can trust Gut feel more. Trusting one's instincts is reflective of one's risk taking abilities. Also, one's instincts may tempt someone to take a shortcut whereas that option may not be ethical.
Again, there's a very fine line between ethical and unethical behavior but one cannot blame instinct for agreeing to do something that is not supposed to be done in first place.
It's a Quarter Final match and its a do or die situation and at such instance, "the hand of god" is a good choice according to me. I repeat, according to me!
Now coming to testing, do you think will be at such a situation? That's the reason I believe the you cant compare it in the first place.
Coming to your point
Also, one's instincts may tempt someone to take a shortcut whereas that option may not be ethical.
There is no such thing as a shortcut according to me, if your expecting a result out an execution. Either it should be a PASS or a FAIL.
If one's instinct is leading him to take shortcuts or I believe you intend to say "cheat" (more precisely), then the person is a cheater, rather than follower of the instinct, since your instinct, always warns you if you are picking a wrong choice. Then you supersede that instinct ignoring the warning and take a shortcut, as you said. At this point there wont be any fine line between Ethical/Unethical behavior, because as soon as you ignored the warning of your instinct, you are completely an unethical being.
And if a person falls under this category once, I will term him unethical for ever.
Let me be clear on one thing,there is a very fine line between committing mistake out of unawareness and committing mistake out of ignorance.
But knowingly committing a mistake when you know the result may turn out dangerous for you / or your team is Unethical.
Hand of God doesn't fit in this !
Thanks for sharing this article Anuj.
I read the article and the comments that followed and I had a few points from my side.
1st regarding the examples quoted:
“the testers would do aggressive tests just days before the release that would invariably find them highly critical bugs and eventually put the release in a jeopardy. And all this was done for a false sense of pride and showed lack of accountability of profession”.
How can a tester be held responsible for this. Typically the Project leads decide the test schedule with very little scope from tester other than just mentioning how much time it would take to run typical modules test, beyond that, testing engineers have little say in the schedule.
A typical schedule for a testing project would dedicate time in the Alpha phases for testing which mainly is “Test for Confirmation”. This is very little or no scope given for “Test to break” or testing “Out-of-box” scenarios. If the tester finds time only at the end of the cycle to do these testing and finds bugs, project owners share equal responsibility.
If it’s the same tester who has done the initial Alpha testing, discovers release blockers at the end, then the schedule and the project tracking needs to be re-looked.
This is where Testing has evolved and newer testing techniques help us accommodate this kind of testing in early phases (I am referring to Assembly, which helps you to free up time for this kind of testing early on and also Session Based exploratory is another good way)
One another example quoted was, “exercising undue power to log bugs that I experienced earlier. One tester who used to again take pride in logging as many trivial bugs in product as possible. Bugs which developers won’t even bothered to look at.”
I agree and also disagree to this.
I agree because, instead logging one bug for ever small deviation, it would be nice to first see if we could club them together logically in a sequence and log one bug and definitely this bug will have high priority as compared to each individual small issue.
Example (1): if a particular page in your product has some UI deviation, instead of logging low priority bug for each deviation, log the bug for the page and I believe that would serve the purpose of getting the issues fixed, which should be prime concern for the tester and not increasing the bug count number.
Example (2): Before logging a bug, do some root cause analysis. This not only helps to keep the count low, but giving a very good first hand information report to the dev to fix the bug.
I disagree because, there may be cases where tester has seen one off cases which he promptly reports and they are moved to “Cant Repro” state. Any deviation no matter how small is to be reported.
If the bug is trivial in nature, that is where Bug Severity and Priority will help the stake holders decide if the bugs can be moved to “Deferred State”.
Regarding the comments:
There is mention of instinct and gut feeling.
My view is:
Yes, these are decision guiding forces sometimes, but definitely not in engineering world. With the enveloped software testing engineering, we take calculated decisions based on the facts available. When the facts at hand are not adequate, we take educated decision based on the projections made with available data at hand. That’s my way of looking at engineering decisions.
In case we have no data at all, we take decisions based on past experience which we can directly / indirectly relate to, but still these would be well thought decision and definitely not instinct based.
The last comment says, “Knowingly committing a mistake when you know the result may turn out dangerous for you”, this is exactly where “Hand of God” fits in for me. More than committing mistake, it’s about giving oneself unfair advantage by twisting the rule book and definitely not just Software testing, “Hand of God” concept can be applied anywhere.
Thanks,
Vittal
Thanks for sharing this article Anuj.
I read the article and the comments that followed and I had a few points from my side.
1st regarding the examples quoted
“the testers would do aggressive tests just days before the release that would invariably find them highly critical bugs and eventually put the release in a jeopardy. And all this was done for a false sense of pride and showed lack of accountability of profession”.
How can a tester be held responsible for this. Typically the Project leads decide the test schedule with very little scope from tester other than just mentioning how much time it would take to run typical modules test, beyond that, testing engineers have little say in the schedule.
A typical schedule for a testing project would dedicate time in the Alpha phases for testing which mainly is “Test for Confirmation”. This is very little or no scope given for “Test to break” or testing “Out-of-box” scenarios. If the tester finds time only at the end of the cycle to do these testing and finds bugs, project owners share equal responsibility.
If it’s the same tester who has done the initial Alpha testing, discovers release blockers at the end, then the schedule and the project tracking needs to be relooked.
This is where Testing has evolved and newer testing techniques help us accommodate this kind of testing in early phases (I am referring to Assembly, which helps you to free up time for this kind of testing early on and also Session Based exploratory is another good way)
One another example quoted was, “exercising undue power to log bugs that I experienced earlier. One tester who used to again take pride in logging as many trivial bugs in product as possible. Bugs which developers won’t even bothered to look at.”
I agree and also disagree to this.
I agree because, instead logging one bug for ever small deviation, it would be nice to first see if we could club them together logically in a sequence and log one bug and definitely this bug will have high priority as compared to each individual small issue.
Example (1): if a particular page in your product has some UI deviation, instead of logging low priority bug for each deviation, log the bug for the page and I believe that would serve the purpose of getting the issues fixed, which should be prime concern for the tester and not increasing the bug count number
Example (2): Before logging a bug, do some root cause analysis. This not only helps to keep the count low, but giving a very good first hand information report to the dev to fix the bug.
I disagree because, there may be cases where tester has seen one off cases which he promptly reports and they are moved to “Cant Repro” state. Any deviation no matter how small is to be reported.
If the bug is trivial in nature, that is where Bug Severity and Priority will help the stake holders decide if the bugs can be moved to “Deferred State”.
Continued in next comment..
Thanks for sharing this article Anuj.
I read the article and the comments that followed and I had a few points from my side.
1st regarding the examples quoted
“the testers would do aggressive tests just days before the release that would invariably find them highly critical bugs and eventually put the release in a jeopardy. And all this was done for a false sense of pride and showed lack of accountability of profession”.
How can a tester be held responsible for this. Typically the Project leads decide the test schedule with very little scope from tester other than just mentioning how much time it would take to run typical modules test, beyond that, testing engineers have little say in the schedule.
A typical schedule for a testing project would dedicate time in the Alpha phases for testing which mainly is “Test for Confirmation”. This is very little or no scope given for “Test to break” or testing “Out-of-box” scenarios. If the tester finds time only at the end of the cycle to do these testing and finds bugs, project owners share equal responsibility.
If it’s the same tester who has done the initial Alpha testing, discovers release blockers at the end, then the schedule and the project tracking needs to be relooked.
This is where Testing has evolved and newer testing techniques help us accommodate this kind of testing in early phases (I am referring to Assembly, which helps you to free up time for this kind of testing early on and also Session Based exploratory is another good way)
One another example quoted was, “exercising undue power to log bugs that I experienced earlier. One tester who used to again take pride in logging as many trivial bugs in product as possible. Bugs which developers won’t even bothered to look at.”
I agree and also disagree to this.
Continued in next comment..
Continuing from my last comment..
I agree because, instead logging one bug for ever small deviation, it would be nice to first see if we could club them together logically in a sequence and log one bug and definitely this bug will have high priority as compared to each individual small issue.
Example (1): if a particular page in your product has some UI deviation, instead of logging low priority bug for each deviation, log the bug for the page and I believe that would serve the purpose of getting the issues fixed, which should be prime concern for the tester and not increasing the bug count number
Example (2): Before logging a bug, do some root cause analysis. This not only helps to keep the count low, but giving a very good first hand information report to the dev to fix the bug.
I disagree because, there may be cases where tester has seen one off cases which he promptly reports and they are moved to “Cant Repro” state. Any deviation no matter how small is to be reported.
If the bug is trivial in nature, that is where Bug Severity and Priority will help the stake holders decide if the bugs can be moved to “Deferred State”.
Regarding the comments:
There is mention of instinct and gut feeling.
My opinion:
Yes, these are decision guiding forces sometimes, but definitely not in engineering world. With the enveloped software testing engineering, we take calculated decisions based on the facts available. When the facts at hand are not adequate, we take educated decision based on the projections made with available data at hand. That’s my way of looking at engineering decisions.
In case we have no data at all, we take decisions based on past experience which we can directly / indirectly relate to, but still these would be well thought decision and definitely not instinct based.
The last comment says, “Knowingly committing a mistake when you know the result may turn out dangerous for you”, this is exactly where “Hand of God” fits in for me. More than committing mistake, it’s about giving oneself unfair advantage by twisting the rule book and definitely not just Software testing, “Hand of God” concept can be applied anywhere.
Thanks,
Vittal
Thanks for your detailed views, Vittal. I appreciate the time you spent thinking over the thoughts.
How can a tester be held responsible for this. Typically the Project leads decide the test schedule with very little scope from tester other than just mentioning how much time it would take to run typical modules test, beyond that, testing engineers have little say in the schedule.
A typical schedule for a testing project would dedicate time in the Alpha phases for testing which mainly is “Test for Confirmation”. This is very little or no scope given for “Test to break” or testing “Out-of-box” scenarios. If the tester finds time only at the end of the cycle to do these testing and finds bugs, project owners share equal responsibility.
If it’s the same tester who has done the initial Alpha testing, discovers release blockers at the end, then the schedule and the project tracking needs to be re-looked.
[Anuj] What i am citing here is a real life experience that i have observed and it was not now but probably a decade ago when the overall awareness levels were quitre low. What you seem to be mentioning is also a practical scenario but i have a slightly different perspective here.
If i understood correctly, the situation you explain seems to be a problem of a typical hierarchical setup where people are generally not encouraged to think beyond their theoritical roles, which obviously is not good.
There is one more aspect to it, I think one of the most underrated of Software Tester's skills are the "Inflencing skills" i.e. how to positively influence others even if that someone happens to be one's immediate superior.Whatever form it takes, being an excellent influencer makes a tester's job easier. Excellent influencing skills require a healthy combination of interpersonal, communication, presentation and assertiveness skills. These skills are more prominent in sales people, who are required to positively influence customers but being testers we are also sometimes required to play that role while dealing with Development team or ill-informed superiors.
One another example quoted was, “exercising undue power to log bugs that I experienced earlier. One tester who used to again take pride in logging as many trivial bugs in product as possible. Bugs which developers won’t even bothered to look at.”
I agree and also disagree to this.
I agree because, instead logging one bug for ever small deviation, it would be nice to first see if we could club them together logically in a sequence and log one bug and definitely this bug will have high priority as compared to each individual small issue.
Example (1): if a particular page in your product has some UI deviation, instead of logging low priority bug for each deviation, log the bug for the page and I believe that would serve the purpose of getting the issues fixed, which should be prime concern for the tester and not increasing the bug count number.
Example (2): Before logging a bug, do some root cause analysis. This not only helps to keep the count low, but giving a very good first hand information report to the dev to fix the bug.
I disagree because, there may be cases where tester has seen one off cases which he promptly reports and they are moved to “Cant Repro” state. Any deviation no matter how small is to be reported.
If the bug is trivial in nature, that is where Bug Severity and Priority will help the stake holders decide if the bugs can be moved to “Deferred State”.
[Anuj] I largely agree with you. Only one thing i would like to add is that Testing team should realize that importance of phase in which testing is carried out and prioritize testing accordingly. The example i cited was when a person kept looging UI bugs without any focus on functionality. And apparently at that phase, the Development team had introduced big functional code and were expecting functional bugs immediately. That lead to loss of credibility.
There is mention of instinct and gut feeling.
My view is:
Yes, these are decision guiding forces sometimes, but definitely not in engineering world. With the enveloped software testing engineering, we take calculated decisions based on the facts available. When the facts at hand are not adequate, we take educated decision based on the projections made with available data at hand. That’s my way of looking at engineering decisions.
In case we have no data at all, we take decisions based on past experience which we can directly / indirectly relate to, but still these would be well thought decision and definitely not instinct based.
[Anuj] Whether we agree or not, I have seen a lot of decisions that are extinct based in absence of the facts. Practical situations demand to take decisions when there is no data to support. Thats where instincts take over. More i am reading about, more i am getting an idea about the science relating to instincts. I have read "Blink" and"The Case of Bonsai Manager" on this topic.
Hi Anuj,
Thanks for the detailed reply. As always your views are were very informative.
Yes, I agree to you that some times its not the bad testing practices which are of concern but the hierarchical setup is.
Also it is always good to invest good amount of time planning the high priority test areas.
Regarding the last part about instinct, i agree to you but still i will stick to the point that engineering decisions should be taken based on facts.
I have a copy of "Blink" lying in my cup board for ages now. I guess, I should start reading it.
Thanks,
Vittal
Thanks for sharing such a very useful information.
Post a Comment