Testing With Ali!

OK! Call this a coincidence or not, but I just got the 2007-08 Real Madrid away shirt of the legendary Raul' yesterday at a discounted price ( if anyone is interested in getting other old kits then check out the shop on the left side of the main entrance of the original Pace, the price is PKR 595 )* and that too days after he (Raul) bid farewell to his long time football club (15 years) Real Madrid. The 2007-08 Real Madrid Away Kit Although he started out with cross-town rivals Atlético Madrid , he began the 1994-95 season in Madrid's C-team , but was promoted to first team status by coach Jorge Valdano after impressing with sixteen goals in nine games. He is the current top scorer of Real Madrid, netting 324 goals in 723 appearances, and has never received a red card in his 15 years at los blancos.  Raul and fellow long server teammate,  Iker Casillas were both awarded a "contract for life" in 2008. The club confirmed on 25th July 2010 that Raúl would be

The purpose of planning is to iteratively arrive at an optimized answer to the ultimate new product development question of what should be built. That is, what capabilities should the product exhibit, in what timeframe, and with which and how many resources? Unfortunately, the traditional ways in which we plan projects often let us down. In answering the combined scope/schedule/resources question for a new product, our traditional planning processes do not always lead to very satisfactory answers and products. As support of this, consider that nearly two-thirds of projects significantly overrun their cost estimates (Lederer 1992), 64% of the features included in products are rarely or never used (Standish 2002) and the average project exceeds its schedule by 100% (Standish 2001). Most causes are as follows; 1. Planning by activity, rather than feature. 2. Multitasking more than one can handle. 3. Features, not by priority. 4. Ignoring uncertainty. 5. Estimates turn into commitments.

Read this one a long time back... A developer/tester convention was being held. On the train to the convention, there were a bunch of developer majors and a bunch of tester majors. Each of the developer majors had his/her train ticket. The group of testers had only ONE ticket for all of them. The developer majors started laughing and snickering. Then, one of the testers said, "here comes the conductor" and then all of the testers went into the bathroom. The developer majors were puzzled. The conductor came aboard and said "tickets please" and got tickets from all the developer majors. He then went to the bathroom and knocked on the door and said "ticket please" and the testers stuck the ticket under the door. The conductor took it and then the testers came out of the bathroom a few minutes later.  The developer majors felt really stupid. So, on the way back from the convention, the group of developer majors had one ticket for the group. They started snic

Ok, the percentages are more of a gut feeling, but can be close to accurate... less then 50% of all software testers (global) have no idea how to program and from experience (that includes numerous companies as well as discussions with colleagues and friends in other companies).  It seems a bit odd since the testers do test the software and therefore should know how the damn thing was build. Or do they? One can also argue that a tester does not have to have any affinity with programming, coding and other development terms, but that he has to test whether the delivered software does what the customer asked for. And in a way these people are completely correct. Testers do have to show the customer that the software works according to the requirements set up or at least approved by the customer. Then why should a tester know more about programming and be less business oriented? My personal opinion would be that when you know what you are testing, you know where to put your testing effor