June, 2009

So I missed a lot of months update.  A lot of work. But I felt a lot of it just empty work as if nothing was learnt from that. Got very interested to healthcare industry and been doing a lot of reading on that.   There appear to be myriad of myths floating around.  It appears too many hard choices need to be made and the situation is not going to get better by default.  One of the need is for payment by outcome. Interestingly that is the model many in IT outsourcing industry are moving to.

Mar, 2009

Got folks working on ODS, now seized with IVR testing. TIBCO is on radar as well.

Feb, 2009

Conitnued work with ODS testing. After reviewing Functional testing moving off onto performance aspect.  The most exciting part of testing is the ability to report defects and issues without having the exercised the application. As an example if the Power Center commits by, say, 5000 records and waits for that, it could wait longer in low periods. It didn't take me any testing to prove out that this would break the SLA. The only issue was getting to this information. It wasn't shared by development team.  Found the 'commitinterval' configuration and discussed the same with developer.  Brings me to an interesting topic of how do you build knowledge of a product/technique.  I figured out one good way of doing that is by reading all the configuration and option settings. All the features are made to respond to situtations and scenarios that arise in usage of a product/technique. 

Presented on Offshore testing ROI at NJ SPIN. This paper also on my website and is no.1 return in Google and Ask.com. I am surprised by that. Ubiquitous multibillion dollar industry and no one has anything written on offshore/outsourced testing ROI?

A very similar conundrum is posed in Sahaja Yoga. The concept is of self realization and knowing oneself. Who needs to know oneself? Seems like I don't. Don't know about others.  Too much of coating of thoughts and past conditioning makes self-discovery pretty hard.

Jan, 2009

Started new gig near Baltimore. Started off working on Operational data store testing that's traversed me through Informatica Power Center and Informatica Power Exchange. Have many other stuff to catch on, but that's for later

Dec, 2008

Spent time writing a white paper on offshore testing ROI.

Nov, 2008

I have come to conlusion that constraint based planning is best suited for test planning. It's a technique more popular for supply chain management.

Nov, 2008

Total cost of testing is a pretty interesting exercise on lines of Total cost of operation (TCO). I asked a testing expert & friend of mine recently, if he were given $10 million for a testing program how would he divide the money between functional testing, automation, performance testing, back end testing, white box testing, security testing e.t.c.  It's tough working out the ratios. Consider Department of Homeland Security budgeting for sake of analogy. They have choices to make such as investing more in global container movement system or put more human intelligence on ground or have digital fingerprint reader for every border agent e.t.c. All contribute to security, but then how do we decide the proportion of money allocation?

So far the conclusion I have come to is to find out defect finding capability of each of the exercise and compute the cost of that defect in production. Then allocate the money in in proportion to the damage caused by the defect in production. Now it is not a straight forward exercise because it is not certain a defect found in say, code level testing would lead to how many defects in production.

 A related exercise I am undertaking is figuring out how much it would cost business, if they implemented all of the things that testing gurus want them to do. I have taken a sample application and I am calculating ideal versus realistic figure. So I started with ideal scenario and then would make tough choices in culling down testing budget to less than 20% of project budget.

 Oct, 2008

Productivity & estimation are topics of my interest.  Test case based productivity and estimations are hugely flawed.  There is much more to testing than test case designing and execution. My finding was that at onsite, whopping 60% of time is spent in non test case execution activities.

Sep, 2008

Testing ROI & Defect maximisation

Looked around various testing vendors for how they defined ROI on testing. It's pretty self mutilating. One promised to do all work with just two limbs, some promise with none. Then there is accelrated testing which will sort of complete testing before the application is developed. However this is all cost. ROI is return/cost. Low cost alone does not provide the value. 

I figure there are just two real returns from testing, enhancing requirements to make application serve the business better and reducing leakage of defects to production/UAT. There are other aspects such as being efficient and well managed, end to end etc but they are minor aspects and do not provide returns per se.

I checked a project and found that it cost them $3500 to find a defect. On other hand I found that average cost of fixing a defect in production from another project, was $10,000. It was interesting because we are told that the ratio is like 1:10 e.t.c. 

Anyway we undertook defect maximization exercise. I would be writing on that in detail some other time. However, we could boost up defect count by 50% and probably could have done more.

Aug, 2008:

Testers Career path

Earlier having been tool focussed I found it to be a much better career path to be to be QTP or Loadrunner specialist e.t.c. However now I have to come to believe that domain knowledge is the best bet. However one may not get the opportunity to specialize in a domain. Say you work for Wipro/Infy etc and you are on bench. It's unlikely that you wil be given any say in further allocation. Or, even if you join them afresh it will be a bit hard to ensure that you get domain of your choice.  A domain which has depth and educational courses that allow one to grow are the best. Thus insurance & cap market may be the best. I wouldn't say same thing about transportation or health care sector. Either way, note that one has to grow deep into one field. Dabbling in multiple domain isn't any better than focussing on a tool. Further working in a domain exclusively alone isn't enough. One needs to fully understand the business and that, so well that one is able to provide business consultancy in the domain.

Jul, 2008:

1. Building proposals can get time consuming.

My finding to report is that Automation is development conducted by testers. Hence it has not gotten very far.   Also it's value is not correctly determined.

2. Regression testing

Discovered different interpretations of regression testing by different folks.