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

Ok, first off, as per the title, non-process based organizations mean companies, concerns etc that do not FOLLOW completely/partially a specific lifecycle for something. They also include such establishments that " advertise " that they have a so & so certification and/or they have such & such SOPs but when it comes down to the hard reality of it, they choose to ignore them. Definition done. Now, there are major establishments that actually do what they are supposed to do in terms of following a software development lifecycle as well as adapting their own operating procedures to best suit their work and make continuous improvements to cater existing issues as well as future prospects.  In my geographical location (country wise), these are normally big companies which have been running since way before I was born and some which sprouted up recently. Some have tons of employees, some have enough to form a football team, some don't even have that but what the

Multitasking, which is defined as simultaneously working on multiple tasks , exacts a horrible toll on productivity ! Clark and Wheelwright (1993) studied the effects of multitasking and found that the time an individual spends on value-adding work drops rapidly when the individual is working on more than two tasks. (some people are immune to this like Spock ( then again the vulcans will argue that this is illogical ), Robocop , Data , Jamie Madrox (well he can duplicate himself so its not exactly multitasking : P ) etc...) Logically, it makes sense that multitasking helps when you have two things to work on. With two value-adding tasks, if you become blocked on one you can switch to the other. It is also logical that the above figure shows a rapid decline in time spent on value-adding tasks after a second task. We’re rarely blocked on more than one task at a time; and, if working on three or more concurrent tasks, the time spent switching among them becomes a much more tangib

In the post , a little bit of background or what planning is normally taken as was covered, now we get into the nitty gritty of what was really meant by reducing risk, reducing uncertainty, supporting better decision making, establishing trust and conveying information. Reducing Risk Planning increases the likelihood of project success by providing insights into the project’s risks. Some projects are so risky that we may choose not to start once we’ve learned about the risks. Other projects may contain features whose risks can be contained by early attention. The discussions that occur while estimating raise questions that expose potential dark corners of a project. For example, suppose you are asked to estimate how long it will take to integrate the new project with an existing mainframe legacy system that you know nothing about. This will expose the integration features as a potential risk. The project team can opt to eliminate the risk right then by spending time learning about

The attached pics says it all! Good morning!

 “Planning is everything. Plans are nothing.” Estimating and planning are critical to the success of any software development project of any size or consequence. Plans guide our investment decisions: we might initiate a specific project if we estimate it to take six months and $1 million but would reject the same project if we thought it would take two years and $4 million. Plans help us know who needs to be available to work on a project during a given period. Plans help us know if a project is on track to deliver the functionality that users need and expect. Without plans we open our projects to any number of problems.  (I bet everybody knows this already) Yet, planning is difficult and plans are often (more or less) wrong . Teams often respond to this by going to one of two extremes: they either do no planning at all or they put so much effort into their plans that they become convinced that the plans must be right and anything done, even slightly, not as per plan is taken a