Protecting from Bugs, in real life case, its kinda impossible. Bug is inevitable. If someone says, we dont have any bug in our product, then I would say - You must be joking. From functional to atleast cosmetic issue, you cant avoid them. Then why I wrote protecting? Its just a scenario I would like to share that I face most frequently.
Finding too many bugs after a fix is done or feature is implemented and re-fixing those and these goes on and on, dont you find its too costly? It doesnt make you a great tester as you are rich in bug finding on a scenario like this. Then you may ask, where else you can find a bug when its not at your hand to look through!
A while back, a client requirement came up for a very small feature - We need to add "Term of Services" for the end users. Its the same thing as we see while registering for a forum or mail like Yahoo or MSN - some terms of service and "I Accept" or "I Decline". Very simple one indeed. So what a developer could do, is to add this small fix and ask a tester whether this is working or not in registration feature. But -
In our process we maintain specs (Yes, this is time consuming) and we do go several discussions (what we call meetings for the project) over the spec before finalizing it. But it doesnt say it needs to be point to point detailed but fair enough to cover the feature. And spec is also in our client requirements list, they want to see it too. So when in the discussion it was claimed to be the simplest fix with a small modification in spec, there my testers came up
- Have you considered registered users who are already using the system?
- Have you considered the users who use desktop clients or add-ins?
- What about those different types of non-registered users who can use a limited number of features without getting registered?
and more (dont want to mention as those wont be very understandable for all). And came out, this is not the small fix as it was thought to be.
I think you have already got my points, what I wanted to say in my subject (or title). You cant stop it from getting it in the feature while its avialble for test, but you can minimize it.
Thank you.
Wednesday, February 17, 2010
Monday, February 15, 2010
Long time .....
Whew ... A long break.. well rather saying a break, I should say a new start. Its been more than 2 years since I posted my last writing, where I started to discuss about Process Maturity (in perspective of Bangladesh Software Industry). And yes, as I said in my 1st post, I’m just trying to share my views and that is all. My experience in software industry is not much but from some point of view some of may agree with me.
When I started writing this blog, I was in Metatude Asia Limited (A familiar name in BD Industry!). And then I switched to Nilavo Technologies Limited, and there I took this long break. But I wish to continue now, hope I will. And I will try to share my learnings from both of these companies, interesting or uninteresting scenarios, while also keeping the focus for Process Maturity.
I remember, I placed a question in my last writing "Why processes are needed to be established in Software Development?" ... yes I remember this. And I will put my answer for this question later and before that lets some expierences :) ..
When I joined in Metatude, I found that it used to a process oriented development house, but in Nilavo, they used to think formal processes only exist in book or not possible in Nilavo. But from that position to Nilavo in today, where an established QA team is working (where they used to know a blackbox tester is enough) and the whole development team maintaining a regular process and boosted successive outputs, yes for sure that was hell of a challanging task. And thanx to my colleagues, my teammates and My Boss (Our CTO). Without their help , co-operation and acceptable attitude it was not possible.
And while sharing experience, I think I should start from Metatude, coz I have found a lot learning areas (both good and bad) and I think those are not too uncommon for those companies those are process oriented for long time. And I think should start my writings about Metatude experience from tomorrow, coz as its getting bigger more its getting painful for readers to read :).
Thank you.
When I started writing this blog, I was in Metatude Asia Limited (A familiar name in BD Industry!). And then I switched to Nilavo Technologies Limited, and there I took this long break. But I wish to continue now, hope I will. And I will try to share my learnings from both of these companies, interesting or uninteresting scenarios, while also keeping the focus for Process Maturity.
I remember, I placed a question in my last writing "Why processes are needed to be established in Software Development?" ... yes I remember this. And I will put my answer for this question later and before that lets some expierences :) ..
When I joined in Metatude, I found that it used to a process oriented development house, but in Nilavo, they used to think formal processes only exist in book or not possible in Nilavo. But from that position to Nilavo in today, where an established QA team is working (where they used to know a blackbox tester is enough) and the whole development team maintaining a regular process and boosted successive outputs, yes for sure that was hell of a challanging task. And thanx to my colleagues, my teammates and My Boss (Our CTO). Without their help , co-operation and acceptable attitude it was not possible.
And while sharing experience, I think I should start from Metatude, coz I have found a lot learning areas (both good and bad) and I think those are not too uncommon for those companies those are process oriented for long time. And I think should start my writings about Metatude experience from tomorrow, coz as its getting bigger more its getting painful for readers to read :).
Thank you.
Subscribe to:
Posts (Atom)
