Wednesday, February 17, 2010
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.
Monday, February 15, 2010
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 :).
Sunday, November 25, 2007
I have started to write this Blog from my little experience over Software Industries in
“To me the most important decision for a successful project is to choose right people at right time. Once you have a competent workforce, they should come up with what is best suited for them.”
This is right not only for SW development but also for all kinds of industries. But I don’t know Vaia whether you read the mails about ‘Lack of Quality People in IT Industry’ which was been discussed in SQABD few months ago.
Ok, let’s share some stories that I heard from one of my senior colleague. When he was in his previous company he used to take interviews to recruit new QA persons in that company. One of his most frequently asked question was: Why you want to join in QA? Mostly in reply he got answers like: “I need a job”, “I don’t know (or not good at) programming”, “Well I saw the advertisement and …….”, “It has a better offer (money)”, “Big company”, “Testing is easier than coding” bla bla bla… I guess these do mean something!
Well you can’t ignore these unless you change the view of QA and that must show the difference with Testers. QA’s task only to ensure the Quality of the Product but also to ensure the Quality of the Process (am I wrong?). I don’t know whether you met or not but I did, to whom Process is totally a new thing when they heard Process and even they question me back – ‘what is that?’ But I guess these should be in your considerations whenever you are thinking in perspective of
Well... well … I was in Process Maturity and now I’m with the recruitment, sorry. But recruitment should also be included in your process, in resource management plan. It should be defined in your process how much of the development gets delayed when you are in shortage of human resource (when someone from the team leaves the company) thus your success rate remains in a consistent state and you are not blamed from your management as they are getting as the process has been defined. And also recruitment time, quality, training these things also – so to get whatever is expected and process doesn’t get blamed and neither you.
Now one more scenario (also heard from my seniors): one big company (in
Now I have one question (I have my answers but it will be better to have some views from others) – Why processes are needed to be established in Software Development?
Tuesday, November 13, 2007
Well I don’t know whether I have the proper knowledge to write about it or not. 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. I’m trying to focus some point from my R&D and knowledge-base.
To develop software every software development company needs a process. This process may be defined in bookish language or undefined (customized). Thing is that you need at least a process to develop it. Big (and few middle) size companies most follow structured (defined or customized) processes. But what about the other companies (small size and rest of the middle size companies)? And specially when you are talking in perspective of
Small or most middle size companies which still starving for resources (both human and technology) are failing to meet the deadline and a quality delivery most time. Yet they maintain a process – their own process. How much matured their process is? – BIG QUESTION!
Now talking about Big and few middle size companies where structured processes are maintained. It may be few but not rare that some of these companies are also failing to meet deadline for a quality delivery. Less quality product delivered within time – I’m not counting those for these companies. So the process maturity is still a big question for these companies.
Now come to the Process Maturity Framework that we have around us. You can say – Follow CMM (I don’t know any other Maturity Framework exists or not). But then you have to think – how many companies can afford CMM (considering time and resource)? You can’t say all the companies which are not assessed for CMM (or follow CMM) don’t have a matured process to produce a quality product in time.
------------- To be continued …----------------------------