એક QA Engineer ની વાતો

My worst experience with one of reputed travels in India

2009-05-08T02:20:00.000-07:00

Last Sunday I was coming from Bhavnagar (Gujarat) to Mumbai after attending one of my friend's marriage. On the way from Bhavnagar to Ahmedabad i made a call to one of my Friend to book a Bus ticket from Ahmedabad to Mumbai for me in a good Travels agency. As it was Monday i was lil confident that i will get ticket easily. A friend of mine called me back after some times and then the story begins.....

Friend called me and tell that there is a sleeper birt available in Neeta travels. When i heared the name "Neeta" i told him to book ticket. (Till that date according to me Neeta was one of famous travels in Mumbai...and I think for you its still). They charged me 800 bucks for Non A.C. Sleeper birth!!!!. I reached to Travels office and showed them my tickets...and instead of taking me to BUS they guy over there told me to sit in an auto and that auto take us to CTM Char Rasta (One of famous area on Ahmedabad-Baroda Highway). We have to pay rent for auto rickshaw also :(. Finally we reached to the BUS (Neeta's Volvo was there in my mind that time). What i saw there is a simple dabba type luxury bus (Number – GJ – 3 W 9808) with all the seats full of dust. Ghosssss…It was horrible (remember friends it was Neeta Travels).

And finally my miserable journey started. Bus driver took the bus on the way through Nadiad-Anand instead of Express Highway and he stopped to each place where he saw any one waiting for BUS. (WTF….we booked ticked from morning and someone come on the fly and got a seat). BUS took three and a half hour to reach to Baroda (110 KM from Ahmedabad).It was 10 PM and still driver was interested in collecting more Passengers (money actually) instead of make a HALT so all the Passengers in the BUS can have some food. At 11 PM he took BUS to some weird Hotel on the highway for dinner and I had worst food of my life.

After having food I asked to driver if he would again stop to each station then he answered me “Saab ye to dhandhe ka time hai…gadi to rukegi hi..aapko pasand nahi hai to utar jao”.

With my luck I was deadly tired after attending marriage; I got sleep after dinner at 11.30 and wake up when Bus reached to Chembur (Mumbai) at 10.00 AM morning (16 hour to reach to Mumbai from Ahmedabad). I got huge stomach pain after having that worst food at BEKARR hotel on highway and have to take a single day off. (Will Neeta pay my one day salary??).

This was my worst experience with one of reputed Travels in India. I really don’t know wee to complaint about these and who will hear it. I am just posting this to my blog with the hope at least no one will suffer like me next time with “Neeta”

‘Touchy feely’:: article by Chetan Bhagat

2008-06-10T02:08:00.000-07:00

I remember the incident - I was in a restaurant and one girl in our group was especially charming. So I, like any other male, tried to put on a wooing act. You know the routine, a nanosecond extra eye contact, a few more nods to whatever she says, and attempts to throw in those one-liners which you know you wouldn’t if she weren’t there. And it seemed to be working. She leaned forward when she spoke to me, and every now and again, we’d have a small conversation of our own, separate from our group. She laughed at my approach with the fork and knife, and I teased her about her hair band, which had little teddy bears. Yes, we were flirting.

A while later, she asked me the question what did I study? I said engineering, without any particular meaning attached to it. And then like a cold metal rail, she went stiff.My jokes weren’t funny any more. Her eyes wandered to everyone else.

What was it?
Why? Why? Why?

Two days later, I still couldn’t get over my great start that had dissipated listlessly upon mentioning my education. Engineer? What was wrong with that? My mom had wanted me to become one since I was five! I had to call her. ‘So what happened to you that day, hot and cold, missie?’ And then she said, trying to be nice, ‘Well, it’s just that I am skeptical about engineers as friends. I don’t know, they can be, you know, very logical and everything…not very touchy feely’.

Not touchy-feely. Now what the heck did that mean? Well, she obviously did not mean it literally, since girls don’t really suggest that sort of stuff, certainly not in the first meeting across the table. I guessed it was something to do with feelings, sort of having an emotional side. The stereotype being, the nerdy guy who sees relationships like laws of physics, to whom love is just a bunch of chemicals going crazy in your brain, and getting to know a person means obtaining their bio-data.
It’s time to set the record straight.

It’s true that a lot of what engineers study (and they end up studying quite a lot), has to do with formulaes, laws and numbers. No matter how hard we try, some of the vocabulary we read all day gets into our language. So when my mother said, ‘Are you getting married next year or not?’ I was liable to say, ‘Well, at this moment in time, the probability is relatively low,’ and felt it was completely normal to say it. And when my sister went sari shopping and couldn’t explain the shade she wanted, I told the shopkeeper the percentages of pink, orange and red in the sari.

Yet, ladies, I don’t think we’re bad at relationships, love and getting to know people. We too, can be touchy-feely, as that is part of our education as well. The reason for this is that most engineering students live in the this ‘touchy-feely’ thing. Relationships.

Imagine eating, sleeping, brushing your teeth, bathing (ok rarely this one) and partying with the same people all the time. So, when you are kicking that bathroom door down for the tenth time, or when you stand in line for ‘gulab-jamuns’ in the mess, and when you are done with the vodka bottle and sharing all your secrets, you know it is good practice. Yes, hostels maketh the man. So, next time you are in a flirtatious situation with the techno types, go on, flirt a bit more. Of course, I am biased towards my kind, but if you find the conversation turning too geeky, just ask them, ‘So, what were your hostel days like?’ and chances are, you’ll see a heart behind the calculator.

Coming back to my missie, I thought of what would make me win her over. Flowers… too cheesy. Music… don’t know her taste (nor trust mine). Teddy bears… don’t even go there.Desperate for some good lines, I just turned it right back at her. ‘Yes, I know what you are saying about engineers. The thing is, unless people with depth like you start hanging out with us, we won’t get any better. Can you meet me some time for some touchy/feely… oops, I mean coffee/tea?’

She giggled. When they giggle, you have won

What shoul be a sccessful tester

2008-05-13T04:10:00.000-07:00

Source : thinking tester

Self Driven or high levels of Inner drive for learning new things – No fear of unknown.
Spontaneous – Thinks on the feet – Good in emergency response.
Agile and adaptable.
Love for Science (Physics/Chemistry), Mathematics and Philosophy.
Love for problem, Puzzles.
Hunger for self Expression – Writing, speaking.
Organized Skepticism and constantly challenge their own thoughts

U Me Aur Hum

2008-05-13T04:02:00.000-07:00

There is a good movie released 3 week ago. "U me Aur Hum". There was a nice line in the movie stating "Sometimes journey will become liong due to distance between two...." At the same time my mind strike that how its affecting in our work place. what i thought about that is.....

As per my view this line is perfectly matching to our work place our working style. We always working in a team but every body are working for individual (either for money/knowledge or whatever). Thinking that “Only I have to grow" take us to long journey.

What I have always observed in an organization (No only in V2!!) is understanding between QA and Dev. Although a team is said to be a combination of QA + Dev, but the fact is something else. When you compare their understandings, mentality etc we find a huge difference.

It’s the work nature which is forced to glue them together, but not a natural thinking in real sense. We find always a DEBATE mood when two comes at a single stage.

That affecting ultimately to the work we are doing and one more times a looong journey.

What’s the reason for that???

Some of the lines from Developers

"It is none of your job to know how did we write the code, all that you have to do is go and click some buttons!"

"If I do (UNIT) Testing, what will you do?"

What we are throwing back as the answers. Trying to produce more and more bugs and make a bug report as rigid as possible? (Without analyzing any root cause for that bugs). Have we ever sat with the developers and try to analyze Priority/Severity of that bug/release?

Guys is this the QA what are we doing?? Or is it the SDLC they are following?

That always creates distance in a team. And only we have to pay for that and we are paying (long nightmares, Huge pressure and of course poor Appraisal!!!).

Guys….Always try to co operating with your team and shortening your journey.

A Story of a Tester

2008-05-09T07:47:00.000-07:00

On a dark and foggy night, a small figure lay huddled on the railway tracks leading to the Mumbai station. At once I was held back to see someone in that position during midnight with no one around. With curiosity taking the front seat, I went near the body and tried to investigate it. There was blood all over the body which was lying face down. It seemed that a ruthless blow by the last train could have caused the end of this body which seemed to be that of a guy of around my age. Amidst the gory blood flow, I could see a folded white envelope which was fluttering in the midnight wind. Carefully I took the blood stained envelope and was surprised to see the phrase "appraisal letter" on it. With curiosity rising every moment, I wasted no time in opening the envelope to see if I can find some details about the dead guy. The tag around the body's neck and the jazzy appraisal cover gave me the hint that he might be a software engineer. I opened the envelope to find a shining paper on which the appraisal details where typed in flying colors. Thunders broke into my ears and lightening struck my heart when I saw the appraisal amount of the dead guy!!!!! My God, it was not even, as much as the cost of the letter on which the appraisal details were printed.... My heart poured out for the guy and huge calls were heard inside my mind saying "no wonder, this guy died such a miserable death"... As a fellow worker in the same industry, I thought I should mourn for him for the sake of respect and stood there with a heavy heart thinking of the shock that he would have experienced when his manager had placed the appraisal letter in his hand. I am sure his heart would have stopped and eyes would have gone blank for few seconds looking at the near to nothing increment in his salary.

While I mourned for him, for a second my hands froze to see the employee's name in the appraisal letter... hey, what a strange co-incidence, this guy's name is same as mine, including the initials. This was interesting. With some mental strength, I turned the body upside down and found myself fainted for a second. The guy not only had my name, but also looked exactly like me. Same looks, same built, same name.... it was me who was dead there!!!!!!!! While I was lost in that shock, I felt someone patting on my shoulders. My heart stopped completely, I could not breathe and sprung in fear to see who was behind......... splash!!! Went the glass of water on my laptop screen as I came out of my wild dream to see my manager standing behind my chair patting on my shoulder saying, "wake up man? Come to Opera meeting room. I have your appraisal letter ready"!!!

InSoLaTER - An Independent Testing Service from Infosys

2008-05-09T01:31:00.000-07:00

Source : indiatoday

In a bid to tap the $13 billion software testing market, Infosys has taken the wraps off a new outsourcing venture-InSoLaTER.

Infosys Technologies has launched an independent software test services offering, InSoLaTER (Infosys Software Labs for Test Execution and Research), targeted at software development firms. The company has already set up a full-fledged offshore laboratory in Bangalore-enabled to conduct tests on most hardware and software platforms and on all available browsers-at a cost of $1.5 million (around Rs 7 crore).

R. Arun, associate vice-president of Infosys and in-charge of the project, says, "Software testing typically accounts for 15 per cent of the total cost of an application's development. According to market research firm Gartner Group, the testing market is worth approximately $13 billion (Rs 62,000 crore). Our endeavor is to capture a small chunk of this huge market."

How is Infosys placed vis-à-vis other players in the market? Arun replies, "Our processes are based on our CMM Level 5 best practices, which allow our managers to start with the best-of-class practices and to constantly improve upon them as a project progresses. The various types of independent test services we offer include functionality, performance (reliability, availability, stress, load and volume), security, usability and certification." Arun says the new unit will contribute a revenue of $12 million (Rs 57.4 crore) in the current financial year itself.

India's Role In Software Testing

2008-05-09T01:24:00.001-07:00

Source : cxotoday

As per an IDC report, almost $1 billion of the estimated $13 billion global software testing market is accounted for by Indian companies. With the concept evolving considerably in the recent times, CXOtoday explores the industry and its future prospects in India.

"With software tools changing its landscape, testing has become a specialized discipline and is growing faster than it was even two to three years back," averred Shashi Reddy, CEO, Applabs Technologies.

He feels that CIOs are now beginning to understand the benefits of testing and are investing heavily in it. As a result the opportunities have grown substantially in recent past.

Speaking about attitudes towards software testing market, Oren Ariel, CTO and Chief Architect of Mercury Worldwide commented, "With an increased realization of the potential hitches that defective solutions can create, testing software is preferred to risking its failure later. However, despite growing awareness, software testing is still not a prioritized strategy for many enterprises."

"Many business applications are not tested properly before being released into market. As a result companies suffer due to application downtime. This becomes a key concern of the CIO," he added.

Meanwhile, India is becoming one of the leading destinations for offshore testing, with market opportunities for the offshore software testing companies currently at $2 billion, and expected to rise to $8 billion by 2008.

Arun Ramu, Head - IVS group, Infosys, perceives an increased reliance by global software vendors on India to save costs in terms of logistics and time
"The potential that exists in the software testing space is similar to the offshoring model offers. Our global delivery model has been a competitive advantage in the software testing space too."

Neeraj Singh, Test Project Leader, IBM, pointed out that quality of testing an major CIO concern. Hence, vendors are trying their best to optimize testing through several tried and tested as well as innovative techniques.

On other recent trends he pointed out, "Most organizations are also realizing that software testing is becoming an independent professional discipline. It not only brings objectivity and transparency to defect reporting process, but also improves the core business strategy."

Customers are ready to get their software tested by a company that has not played a part in the development process. Moreover it reduces costs by deploying cost-effective models and perceived risk of outsourcing testing is low, he remarked.

While traditional Indian software service players have concentrated on the BFSI domain, Mercury and Polaris have gone way ahead to address multiple segments such as wireless, mobile and embedded systems.

KLOC - What does it mean to Software Testing

2008-05-08T22:55:00.000-07:00

Introduction to KLOC

Lines of Code (LOC) is one of the software metric that is used by most of the people for Software Measurement. Thousand lines of code is treated as KLOC. This metric helps us in knowing the size and complexity of the Software Application.

What does it mean to Software Testing

We do test applications with the intention to see if the promised functionality works fine or not. Any deviation here will be considered as a Bug. So each of these bugs must be originated from some line of code in the product.

So it’s understood that when the size of the code is more there is a chance for more number of bugs in the prodcut. Even most of the process to talk about some % of issues is fine or acceptable quality per KLOC(even though there is lot of subjectivity).

The Defect Density is arrived at Number of Bugs / KLOC per the product under test. The defect density is one of the metric used to measure the quality of the product. Most of the Quality Process does talk about this metric.

Concerns

The concern in this approach is that how these values are measured. The general bias with KLOC is that people try to see that only the excutable lines of code in the product.

Each every line in the product may not be code at all & we may not execute each and every one of them. So it’s not taken care, then the issues related to documentation, images, installation etc might be misleading.

Since we are looking at KLOC as the size of the product it’s better to include each and every entity that effects the same. Then it’s helpful for both development and test teams.

Use Cyclomatic Complexity to determine the Risk and Test Scenarios

2008-05-08T22:40:00.000-07:00

Cyclomatic Complexity (CC) is a software metric (mostly code based metric) used to the number of independent path executions in the application. Introduced by Thomas McCabe in 1976, it measures the number of linearly-independent paths through a program module.

It helps the developers to determine the independent path executions and base line unit tests that they need to validate. Using this, the developers can assure that all the paths have been tested atleast once. It’s a great comfort for the developer and their respective managers.

It’s better to write JUnit Tests for all these linearly-independent paths and integrate it with any code coverage tool. These reports help to focus more on the un covered paths and improve the code coverage.

It also helps to evaluate the risk associated with the application. The following are the results published by SEI and they are being followed widely to determine the health of the code base.

Cyclomatic Complexity Risk Evaluation
1-10 A simple program, without much risk
11-20 More complex, moderate risk
21-50 Complex, high risk program
Greater than 50 Un testable program (very high risk)

Explore more at Cyclomatic Complexity in Software Technology Roadmap from SEI.

Use metrics to evaluate the risk early in the cycle & improve your test coverage

YouTube India is Launched

2008-05-08T22:03:00.000-07:00

Source : TechLads

With News Corp's MySpace having launched in India, can Google-owned YouTube be far behind? The popular video-sharing Web site today launched its local Indian version at www.youtube.co.in.

YouTube India is different in that it features a localized home page plus search functions, allowing users create and share videos, discover the most popular/relevant videos in India, and generally connect with other Indian and global users. Over time, YouTube India is expected to have an entirely 'local' flavor and feature content and functionality that is most desired by Indian users.

YouTube India sports local features like promoted videos, featured videos, home page promotions, localized user interface and help center, user support and community features (video ratings, sharing, and content flagging), and intends making easier for the Indian YouTube community to search and view videos from India. In addition, content uploaded by users in India would show up as 'top favourites' and 'recommended content' on the local YouTube Web site. YouTube India also aims at facilitating exchange amongst the large Indian NRI community.

Meanwhile, YouTube India has already inked partnerships with the likes of UTV, NDTV, India TV, Zoom TV, Rajshri Films, Eros Entertainment, IIFA, the Ministry of Tourism, IIT Delhi, and KrishCricket to name a few, with the objective of bringing exclusive Indian content to users in newer ways. Enjoy guys

Opera browser now has its own alternative to Firefox' Firebug

2008-05-08T22:00:00.000-07:00

Source : betanews

Recently, Opera's developers have been touting it as the most compliant browser with Web standards. Now they're using that as leverage to help introduce Dragonfly, a tool they hope will promote Opera as a kind of standards watchdog.

Easily among the most useful and well thought-out extensions to Mozilla Firefox has been Firebug, an add-on by independent developer Joe Hewitt which instantly converts any active Web site into a fully-fledged JavaScript/XHTML/CSS/DOM diagnosis studio. You can see why an element is parsed and laid out the way it is by pointing at it, and letting Firebug take you to the code in question. Up until now, no tool with similar functionality and reliability has existed within the browser context; Microsoft's Web development tools are centered around Visual Studio and Expression.
Today, it's Opera which is changing that picture, with the introduction of its own live development environment add-on called Dragonfly, whose alpha version was released yesterday. It's produced by the Opera team itself, is recommended for recent builds of version 9.5, and is being billed not only as a Web development environment but also as a standards conformance tool.

With Opera reportedly scoring very high or perfect in recent Web Standards Project conformance tests, its creators may see Dragonfly as a way to build Opera into more than just a browser, but a development tool in itself.

According to a blog post from Opera developer relationship manager Chris Mills yesterday, Dragonfly makes use of monitoring tools that are now actually built into Opera itself, called Scope. Like Firebug, Dragonfly includes a JavaScript debugger and CSS and DOM inspectors in a separate Developer Tools window, which also includes a command line that lets you interact with a JavaScript parser in immediate mode.

The script window permits line-by-line execution stepping through individual instructions or between procedures, with variable breakpoints. Once execution of JavaScript has reached a breakpoint and pauses, the window can give you a full report of the state of the page's DOM and the contents of any active JavaScript variables.

Perhaps most importantly, Dragonfly is capable of providing a very detailed error and warning report within its Console tab.

The early reviews are mixed, with some impressed by how quickly Dragonfly responds, others depressed with how slowly it can load. The developer of the Python Web site framework Django, Simon Willson, expressed on his personal blog a viewpoint that's currently somewhere in-between: "Out in alpha and it shows (slow to load and the interactive console leaves a lot to be desired)," Willson wrote, "but still looks incredibly promising, especially the remote debugging tools for working with Opera on phones and games consoles."

Dragonfly's Web site is also promising that, in order to keep it adherent to the latest standards at all times, its final release versions will be self-updating, without user intervention. It will be distributed freely under the BSD license.

JavaNCSS - A source metric suite for Java

2008-05-08T21:46:00.000-07:00

What is JavaNCSS ?

JavaNCSS is a command line utility which measures some standard source code metrics for the Java programming language. The metrics are collected globally, for each class and/or for each function.

What are the advantages ?

The following are some of the advantages that i have seen

1. Support for Ant Tasks, so easy to integrate with build process
2. Reports can be in Text, XML, HTML etc
3. Support for Stylsheets and easy to get nice HTML reports
4. Metrics at each level Package / Class / Method
5. Cyclomatic Complexity Number
6. List the number of packages / classes / functions / LOC counter at each level

Further Reading:

1. JavaNCSS Home
2. LOC Counters for C++ / Java on Joel Software Discussion group

Peeling the Performance Onion

2008-04-24T23:27:00.000-07:00

The Infernal Onion
When we run a performance testing scenario, we usually start with a light load and measure response times as the load increases. You would expect that the response time would increase as the load increases, but you might not anticipate the dreaded "knee" in the performance curve. Figure 1 shows the hockey stick shape of the typical performance curve.

Figure 1: The classic hockey stick

The knee is caused by non-linear effects related to resource exhaustion. For example, if you exhaust all physical memory, the operating system will start swapping memory to disk, which is much slower than physical memory. Sometimes a subsystem like a Java interpreter or application server might not be configured to use all available memory, so memory limitations can bite you even if you have plenty of free memory. If your CPU horsepower gets oversubscribed, threads will start to thrash as the operating system switches between them to give each a fair share of timeslices. If you have too many threads trying to access a disk, the disk cache may no longer give you the performance boost that it usually does. And if your network traffic approaches the maximum possible bandwidth, collisions may impact how effectively you can use that bandwidth.

Figure 2

When we tune the performance of the system, we try to move that knee to the right so we can handle increasing load as long as possible before the response time shoots off the scale. This tuning often happens near the scheduled end of a project when most of the system is functional enough to allow for system-level performance testing. When you improve the performance of the system, what should you anticipate to happen next? Sometimes you're still limited by the same kind of bottleneck, though the knee has moved and overall performance is better. Often, though, you'll uncover a new bottleneck that is now the limiting factor in your performance (shown in figure 2). It may be that you're now exhausting a different resource, or that a different part of the system is exhausting the same resource as before. Figure 2 shows a second bottleneck that was masked by the first one.

This is an application of "Rudy's Rutabaga Rule" from Jerry Weinberg's The Secrets of Consulting. The rule is "Once you eliminate your number one problem, number two gets a promotion." Maybe if you get enough bottlenecks out of the way, you can achieve your performance goals for your system. But don't get frustrated if each change to the system only improves performance by a small amount. Figure 3 illustrates why. (See below.)

If your system doesn't hog one resource significantly more than any other resource, then your bottlenecks will be stacked closely together. Removing each layer will only make a small improvement; you'll most likely slam into another bottleneck waiting nearby.

It Won't Go Fast if It Doesn't Go at All
Testing the system's performance tells us how fast each user can complete a task, and how many users it can support. A related concept is reliability, where we look at how long the system can operate before encountering a failure. You might want to devise a reliability test that doesn't step up the load the way a performance test often does. Not all projects do reliability testing, though, so you might be conducting performance testing before the system's reliability is solid. In that case, you'll usually find latent reliability issues in the system during performance testing. So, when you run a performance test, there's a chance that you'll encounter a failure that renders the rest of your test run invalid.

There is a random nature to most reliability issues: You will probably have more than one reliability issue in the same build of your software that can bite you during a performance test. Whether you encounter one of the latent reliability bugs and which one you see first depends on a roll of the dice. Also, be prepared for bug fixes to unmask hidden reliability bugs the same way performance bottlenecks can hide behind each other.

Another related system attribute that comes into play is robustness--the ability of the system to gracefully handle unexpected input. You can test the robustness of your software with a stress test, which may involve simply ramping up the load in a performance test until you encounter a failure. Robustness issues tend to be easier to consistently reproduce than reliability issues. If you keep hitting the same failure at the same point in your test, you probably have a robustness issue where the system doesn't respond with a reasonable error message when some system resource is completely exhausted. For example, if both your physical memory and swap space are exhausted, a request to allocate more memory will fail, and often the end user doesn't get a useful error explaining that the server is too busy to complete a requested task. Even if the system does fail gracefully, your performance test needs to watch for errors, because it's important to know if any of the simulated users didn't actually get the results they asked for.

Figure 3

Handling the Onion Without Tears
Here are a few tips to improve upon the typically slow progress of peeling off one bottleneck at a time.

Consider designing and running different types of performance-test scenarios that may each identify different bottlenecks. This changes the onion-peeling process so it's somewhat more parallelized. This presumes that the system is stable enough to survive these different tests and give meaningful, correlatable results.
Make sure your performance tests catch errors that indicate if the system isn't doing the work the test expects it to be doing (reliability or simple functional bugs). This takes a lot of extra work in most load-test tools, but it's important because failures can render your performance measurements invalid.
Perform stress testing early in your project to identify where the hard limits are. Run the tests all the way up to system failure--i.e., run "tip-over tests."
Balance reliability testing with performance testing. The less reliable the system, the more unpredictable your performance testing will be. If it crashes at any level of load, no matter how slight, your performance results are not meaningful. You are still on the outer skin of the onion.

The best approach is to do performance modeling hand-in-hand with performance tests that validate the model. Performance models identify bottlenecks before you even start coding. Do unit- and subsystem-level testing early in the project that covers resource allocation, performance, and reliability. Most performance issues should already be resolved before you start peeling the onion at the system level. Try using simple models like spreadsheets during design and then more sophisticated dynamic models, perhaps with the help of a commercial tool, (e.g., Hyperformix) to simulate and predict behaviors;. i.e., design for performance and reliability from the beginning to grow a smaller, fewer-layered onion. Make sure that resource allocation, performance, and reliability testing are part of unit and integration testing.

A Tester’s Tips for Dealing with Developers

2008-04-18T06:21:00.000-07:00

When I started my career as a software tester, I was made aware of an ongoing antagonism between developers and testers. And it took me no time or effort to be convinced that this is all too common. I received the kind of unwelcome response from developers that I think all testers experience at some point during their careers.

From indifferent shrugs to downright hostility (sometimes cloaked as sympathetic smiles), a tester has to endure a lot from developers. It can be hard to keep a positive attitude. But it’s up to us to keep our priorities straight, and push toward a quality project.

I picked up a beautiful line from Cem Kaner’s Testing Computer Software: “The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed.”

So how can we do that?

Be Cordial and Patient
As a tester you may find it more difficult to convince a developer about a defect you’ve found. Often, if a tester exposes one bug, the programmer will be ready with ten justifications. It’s sometimes difficult for developers to accept the fact that their code is defective—and someone else has detected it.

Developers need support from the testing team, who can assure them that finding new bugs is desirable, healthy, and important in making the product the best it can be. A humanistic approach will always help the tester know the programmer better. Believe me, in no time the same person could be sitting with you and laughing at mistakes that introduced bugs. Cordiality typically helps in getting the developer to say “yes” to your bug report. An important first step!

Be Diplomatic
Try presenting your findings tactfully, and explaining the bug without blame. “I am sure this is a minor bug that you could handle in no time. This is an excellent program so far.” Developers will jump and welcome it.

Take a psychological approach. Praise the developer’s job from time to time. The reason why most developers dislike our bug reports is very simple: They see us as tearing down their hard work. Some testers communicate with developers only when there is a problem. For most developers, the software is their own baby, and you are just an interfering outsider. I tell my developers that because of them I exist in the company and because of me their jobs are saved. It’s a symbiotic and profitable relationship between a tester and a developer.

Don’t Embarrass
Nobody likes mistakes to be pointed out. That’s human nature. Try explaining the big-picture need for fixing that particular bug rather than just firing bulky bug reports at developers. A deluge of defects not only irritates the developer, it makes your hard work useless for them.

Just as one can’t test a program completely, developers can’t design programs without mistakes, and they need to understand this before anything else. Errors are expected; they’re a natural part of the process.

You Win Some, You Lose Some
I know of testers who make their bug reports as rigid as possible. They won’t even listen to the developer’s explanations for not being able to fix a bug or implement a feature. Try making relaxed rules for yourself. Sit with the developer and analyze the priority and severity of a bug together. If the developer has a valid and sensible explanation behind her reluctance to change something, try to understand her. Just be sure to know where to draw the line in protecting the ultimate quality of your product.

Be Cautious
Diplomacy and flexibility do not replace the need to be cautious. Developers often find an excuse to say that they refused to fix a bug because they did not realize (or you did not tell them) how serious the problem was. Design your bug reports and test documents in a way that clearly lays out the risks and seriousness of issues. What’s even better is to conduct a meeting and explain the issues to them.

A smart tester is one who keeps a balance between listening and implementing. If a developer can’t convince you a bug shouldn’t be fixed, it’s your duty to convince him to fix it.

12 Bug writing tips

2008-04-18T04:51:00.000-07:00

1.Be very specific when describing the bug. Don’t let there be any room for interpretation. More concise means less ambiguous, so less clarification will be needed later on.

2.Calling windows by their correct names (by the name displayed on the title bar) will eliminate some ambiguity.

3.Don’t be repetitive. Don’t repeat yourself. Also, don’t say things twice or three times.

4.Try to limit the number of steps to recreate the problem. A bug that is written with 7 or more steps can usually become hard to read. It is usually possible to shorten that list.

5.Start describing with where the bug begins, not before. For example, you don't have to describe how to load and launch the application if the application crashes on exit.

6.Proofreading the bug report is very important. Send it through a spell checker before submitting it.
7. Make sure that all step numbers are sequenced. (No missing step numbers and no duplicates.)

8.Please make sure that you use sentences. This is a sentence. This not sentence.

9.Don’t use a condescending or negative tone in your bug reports. Don’t say things like "It's still broken", or “It is completely wrong”.

10.Don’t use vague terms like “It doesn’t work” or “not working properly”

11.If there is an error message involved, be sure to include the exact wording of the text in the bug report. If there is a GPF (General Protection Fault) be sure to include the name of the module and address of the crash.

12.Once the text of the report is entered, you don’t know whose eyes will see it. You might think that it will go to your manager and the developer and that’s it, but it could show up in other documents that you are not aware of, such as reports to senior management or clients, to the company intranet, to future test scripts or test plans. The point is that the bug report is your work product, and you should take pride in your work.

Banana Testing

2008-04-18T04:41:00.000-07:00

Once upon a time there was a man named Andy. Andy was a normal guy like any one of us, with strengths and weaknesses. His strength was that he did a great job at work, but his weakness was that he was a procrastinator, leaving everything for the last minute.

It was the beginning of December, and Andy realized that he had accumulated all his vacation days for the year and had to use them or lose them. Luckily, he wasn’t working on anything urgent, so he immediately got approval for a two-week vacation, and booked a flight to Hawaii. He went home, woke up the next morning and started to pack because his flight was that afternoon.

As soon as he took out his suitcase, he realized that he had no clothes to pack, so he ran out to the department store to pick us some vacation-wear, sunglasses, etc. He becomes hungry on his way back home and in a rush, stops in a fruit store to pick up something to eat. He wants to buy a banana, but the storekeeper will only sell him a bunch, not a single banana. They get into a small argument but in the end Andy gives in and buys whole bunch because he’s hungry and in a rush.

When Andy gets home he drops the bananas on the windowsill, throws his department store bags into the open suitcase, zips it up and runs out of the house to the airport.

Two weeks go by and Andy returns home. As soon as he opens the door, he is greeted by a strange smell. He walks around the house, and he sees something black on the windowsill that’s oozing and dripping, soggy and mushy. There are gnats and flies buzzing around it, and it smells fermented. He gets close, takes a good whiff, sticks his finger in it and tastes it, and declares “these must be rotten bananas” as he passes out.

Why did I tell you this story? To describe what software testing is. In its most generic form, there are three basic elements of testing.[1] They are:

Please see Comments for more........

Is Software Testing Advancing or Stagnating?

2008-04-18T02:38:00.000-07:00

Software Testing has been started in 1976 and we are still following same standards and methods. Here is an interesting article by Steve Whitchurch about is software testing Advancing or Stagnating?

In 1976, Michael Fagan published his first paper on Design and Code Inspections. He talked about how inspections could reduce errors in software. In the same year, Glenford Myers wrote Software Reliability Principles and Practices. In this book, Myers talks about testing philosophies—emphasizing the importance of designing good test cases. He goes on to describe test cases which test the code as if it’s in a sealed, black box. In 1979, Myers wrote his fifth book, The Art of Software Testing, which soon became the bible of the Software Quality movement. In this book, he talks about the importance of Inspections, Black and White Box testing, and the benefits of regression testing.

Sounds like a solid beginning. So, what’s my point?

My point is this. I don’t think testing has advanced since Fagen and Myers wrote their first papers and books. We are still using the same methods to perform our work. We are still asking the same questions.

Now, I’m not suggesting that there haven’t been any important books written in the time since the books Myers wrote. In fact, since then many fine books have been written on the subject of software testing.

In 1983, seven years after Myers' software reliability book, Boris Beizer wrote Software Testing Techniques, a very good book on the subject of software testing. Beizer gives the terms Black Box and White Box testing new names—Functional Testing and Structural Testing respectively. But for the most part he talks about testing methods similar to Myers.

In 1995, a full nineteen years after Myers’ book, Edward Kit wrote Software Testing in The Real World, another good book on software testing. But still, Kit talks about Functional Testing (Black Box) as well as White Box Testing.

But if you have been in the business for any length of time, you get a distinct sense of déjà-vu. If you don’t believe me, take a look at the next testing conference advertisement you get in the mail. Then think about that talk you attended years ago. The one where the speaker described a testing oracle that would create test cases for you. Have you ever seen such a tool that really worked on real code? I doubt it.

What about the CMM and ISO 9000? These processes were going to help us produce high-quality software. How many of you are still using them? Have they solved your quality issues?

Like most of you, I create functional test cases, update regression test suites, and attend
an occasional code review, all in the name of process improvement. But I haven’t seen anything new or revolutionary impact my world.

Again, I’m not minimizing or trying to downplay software quality process. But, like most of you, I work in the real world of tight deadlines and poor requirements. Most of the time I don’t even have real functional specifications. Software engineering documentation—what’s that?

So thinking back to Myers’ 1976 book and all the testing books and conferences since, have we advanced or are we stagnating?

Let’s just say, I feel the algae growing.

PLease put your comments.......... :)

An Uncomfortable Truth about Agile Testing

2008-04-18T02:22:00.000-07:00

There is a good article by Jeff Paton on some bitter truth of Agile Testing.

In organizations that have adopted agile development, I often see a bit of a culture clash with testers and the rest of the staff. Testers will ask for product specifications that they can test against to verify that what was built meets the specifications, which is a reasonable thing to ask for. The team often has a user story and some acceptance criteria in which any good tester can quickly poke holes. "You can't release the software like this," the tester might say. "You don't have enough validation on these fields here. And what should happen if we put large amounts of data in this?"

"This is just the first story," I'd say. “"We'll have more stories later that will add validation and set limits on those fields. And, to be honest, those fields may change after we demonstrate the software to the customer--that's why we're deferring adding those things now."

"Well, then there's no point in testing now," the testers would usually say. "If the code changes, I'll just need to re-test all this stuff anyway. Call me when things stop changing."

I can understand their concern, but I also know we need to test what we've built so far--even if it's incomplete, even if it will change. That's when I realized what testing is about in agile development. Let me illustrate with a story:

Imagine you're working in a factory that makes cars. You're the test driver, testing the cars as they come off the assembly line. You drive them through an obstacle course and around a track at high speed, and then you certify them as ready to buy. You wear black leather gloves and sunglasses. (I'm sure it doesn't work that way, but humor me for a minute.)

For the last week, work has been a bit of a pain. When you start up your fifteenth car of the day, it runs rough and then dies after you drive it one hundred yards from the back door of the plant. You know it's the fuel pump again, because the last five defective cars you've found have all had bad fuel pumps. You reject the car and send it back to have the problem properly diagnosed and fixed. You may test this car again tomorrow.

Now, some of you might be thinking, "Why don't they test those fuel pumps before they put them into the cars?" And you're right, that would be a good idea. In the real world, they probably test every car part along the way before it gets assembled. In the end, they'll still test the finished car. Testing the parts of the car improves the quality downstream, all the way to when the car is finally finished.

Testing in agile development is done for much the same reason. A tester on an agile team may test a screen that's half finished, missing some validation, or missing some fields. It's incomplete--only one part of the software--but testing it in this incomplete stage helps reduce the risk of failures downstream. It's not about certifying that the software is done, complete, or fit to ship. To do that, we'd need to drive the "whole car," which we'll do when the whole car is complete.

By building part of the software and demonstrating that it works, we're able to complete one of the most difficult types of testing: validation.

I can't remember when I first heard the words verification and validation. It seemed like such nonsense to me; the two words sounded like synonyms. Now I know the distinction, which is important. Verification means it conforms to specification; in other words, the software does what you said it would do without failing. Validation means that the software is fit for use, that it accomplishes its intended purpose. Ultimately, the software has no value unless it accomplishes its intended purpose, which is a difficult thing to assure until you actually use it for its intended purpose. The best person qualified to validate the software is a person who would eventually use it. Even if the target users can't tell me conclusively that it will meet its intended purpose, they often can tell me if it won't, as well as what I might change to be more certain that it will meet its intended purpose.

Building software in small pieces and vetting those pieces early allows us to begin to validate sooner. Inevitably, this sort of validation results in changes to the software. Change comes a bit at a time, or it arrives continuously throughout an agile development process, which agile people believe is better than getting it all at once in a big glut at the end of the project, when time is tight and tensions are high.

Being a tester in an agile environment is about improving the quality of the product before it's complete. It also means becoming an integrated and important part of the development team. They help ensure the software--each little bit that's complete--is verified before its users validate it. Testers are involved early to help describe acceptance criteria before the product is written. Their experience is valuable to finding issues that likely will cause validation issues with customers.

At the end of the day, an agile tester likely will pour over the same functionality many times to verify it as additional parts are added or changed. A typical agile product should see more test time than its non-agile counterpart. The uncomfortable truth for testers in agile development is that all of this involves hard work and a fair amount of retesting the same functionality over and over again. In my eyes, this makes the tester’s role more relied on and critical than ever.

What Are You Working On?

2008-04-18T02:00:00.000-07:00

Summary : Goals and requirements drive the work schedules of all projects. Some of these requests are necessary to the success of the current project, others are not so critical. Yet sometimes we lose sight of this and spend many work hours trying to complete more than what can be done within the timeframe of a project. There is a short story regarding how we running behind goals and missing requirements.

Story:Kris, a technical lead, saw Tom, one of her project's developers running down the hall. She was curious, but didn't interfere. A few hours later, she saw him running back. He stopped and made a U-turn into her cube.

"Kris, do you have a minute?" he asked.

"Sure, what's up?" she said.

"Well, Danny over in marketing wants me to add these things to the screen, and I was wondering if you could take a look at it?"

Kris started reviewing the changes and asked, "Tom, is this why you've been running around all day?"

"Uh, yeah. Why?"

"Because what Danny wants is something that's a goal, not a requirement for release. Remember the product roadmap? This feature is for the next release but was a goal for this release. We need to finish the requirements before we think about the goals. Let's go talk to the project manager and see if anything's changed."

Many projects have more requirements than can be finished in the desired project time. Some of those unfinished requirements turn into goals. Other times, the project team members have internal goals it wants to accomplish. Or marketing has said it would be nice if the team could achieve a certain performance or reliability greater than what it specified. Or the organization wants faster projects. All of these are goals, and the team should satisfy the goals after it satisfies the requirements.

Separate Goals from Requirements
It's easy, especially at the beginning of a project, for a project team and the people who request deliverables (some of which are requirements) to be unable to differentiate between goals and requirements. The project team might be excited about the project and want to do everything. The people who want the release might feel as if there's pressure for everything in this release. But it's too easy for the project team members to be sidetracked if they haven't differentiated between goals and requirements.

Here's how I do it. First, take your requirements (if you have them). Now, for each requirement, ask the person who gave you this requirement into which bucket this item belongs. The buckets are:

1. Product requirements required for this release
2. Product requirements for some time in the future
3. Project goals, such as a reliability or performance measurement that exceeds the product requirement
4. Team goals--things the team would like to do (e.g., pay down some technical debt by investing in more unit tests)
5. Organization goals, such as finishing this project before the next one needs to start

Only the first item in this list represents the project's requirements. Everything else is a goal.

Define Release Criteria
Now that you know the requirements, you can test whether or not you've bucketed everything correctly by defining release criteria. The release criteria should be a subset of the requirements. If you find anything creeping in from the goals, you know you either have more requirements than you thought or your release criteria are not actual release criteria--they're goals someone wants you to deliver.

Here's how this could play out in a project. Imagine you have an online store, and you have a requirement of improving the search for a specific set of items--say, canary cages--by ten percent to bring total search time for canary cages to less than two seconds. In addition, you know that for next quarter's release, you need to bring canary cage search to less than one second--as well as bring the search for all cages to less than 1.5 seconds. This is a goal for this release, but a requirement for next release. If you can see how to fulfill that requirement now for no more money and time than you're already spending, fine. But if you can't, you only work on canary cage search.

In addition, the team members realize they've incurred some technical debt by missing some unit tests, and they don't have all the performance tests they want for all cage searches. They do have performance tests for canary cages.

As a project manager, I would talk to the team and ask where the unit tests are missing. If team members were going to work in those areas of the code, I might ask them to timebox any additional unit test development--i.e., make sure that the team members develop unit tests for the code they're developing (only for code they're touching) and to timebox the time they spend doing that. We would agree on how much time to spend fulfilling the requirements for release because the time the team members spend developing tests for already-running code is time they're not spending on finishing the features for this release.

This conversation tends to be tricky. I don't want to prevent people from providing more information about the code base, and I don't want people to wander all over the code adding unit tests. I tell them that and ask them to monitor their time and let me know if adding more unit tests is taking more time than they thought. An organizational goal for this release might be to meet the quarterly deadline for the release.

Case In Point
One organization I previously worked with only had eighteen-month releases. They wanted to transition to quarterly releases but suspected that they first needed to transition. They thought moving from an eighteen-month release to a three-month release might be too difficult for them. So, they cut the goal in half as a requirement. For the first project, the requirement was nine months from start to release, with a goal of three months to finish the project. The project took twelve months to complete. At the retrospective, the team members discussed what they could do differently during the next project and planned for a six-month duration. They met that six-month requirement and learned what they needed to do for a three-month cycle. Having the original goal helped them learn what they needed to do, even though they couldn't meet the goal.

Summary
Once Tom realized what he was doing--working on a goal instead of a requirement, he asked Kris for help in discussing the issue with Danny. Danny thought the team should change what they were doing to accommodate his request to move the feature from goal to requirement for this release, so they checked with the project manager. The project manager explained to Danny that it was too late in this release to change the requirements, but she would be happy to discuss reordering his requirements in the future.

Your conversations might require more people to make a decision about whether this feature is a goal or requirement, but having the conversation will help everyone do what they need to for the current project. Remember, project requirements and goals are different, and you should treat them differently. Spend your time on the requirements, and then attend to the goals.

Change your strategy

2008-04-15T22:29:00.000-07:00

One day, there was a blind man sitting on the steps of a building with a hat by his feet and a sign that read: "I am blind, please help".

A creative publicist was walking by him and stopped to observe he only had a few coins in his hat, he dropped a few more coins in his hat and without asking for his permission took the sign,turned it around, and wrote another announcement. He placed the sign by his feet and left. That afternoon the creative publicist returned by the blind man and noticed that his hat was full of bills and coins. The blind man recognized his footsteps and asked if it was him who had re-written his sign and he wanted to know what did he write on it?

The publicist responded: "Nothing that was not true, I just rewrote your sign differently". He smiled and went on his way.The blind man never knew but his new sign read : "TODAY IS SPRING AND I CANNOT SEE IT".

Change your strategy when something does not go your way and you'll see it will probably be for the best. Have faith that every change is best for our lives.

ONE BEDROOM FLAT...

2008-04-15T22:12:00.000-07:00

ONE BEDROOM FLAT... WRITTEN BY AN INDIAN SOFTWARE ENGINEER..- A Bitter Reality

As the dream of most parents I had acquired a degree in
Software Engineering and joined a company based in USA , the
land of braves and opportunity. When I arrived in the USA , it
was as if a dream had come true.

Here at last I was in the place where I want to be. I decided I
would be staying in this country for about Five years in which
time I would have earned enough money to settle down in India .
My father was a government employee and after his retirement,
the only asset he could acquire was a decent one bedroom flat.
I wanted to do some thing more than him. I started feeling
homesick and lonely as the time passed. I used to call home and
speak to my parents every week using cheap international phone
cards. Two years passed, two years of Burgers at McDonald's and
pizzas and discos and 2 years watching the foreign exchange
rate getting happy whenever the Rupee value went down.

Finally I decided to get married. Told my parents that I have
only 10 days of holidays and everything must be done within
these 10 days. I got my ticket booked in the cheapest flight.
Was jubilant and was actually enjoying hopping for gifts for
all my friends back home. If I miss anyone then there will be
talks. After reaching home I spent home one week going through
all the photographs of girls and as the time was getting
shorter I was forced to select one candidate.
In-laws told me, to my surprise, that I would have to get
married in 2-3 days, as I will not get anymore holidays. After
the marriage, it was time to return to USA , after giving some
money to my parents and telling the neighbors to look after
them, we returned to USA ..

My wife enjoyed this country for about two months and then she
started feeling lonely. The frequency of calling India
increased to twice in a week sometimes 3 times a week. Our
savings started diminishing. After two more years we started to
have kids. Two lovely kids, a boy and a girl, were gifted to us
by the almighty. Every time I spoke to my parents, they asked
me to come to India so that they can see their grand-children.
Every year I decide to go to India ... But part work part
monetary conditions prevented it. Years went by and visiting
India was a distant dream. Then suddenly one day I got a
message that my parents were seriously sick. I tried but I
couldn't get any holidays and thus could not go to India ... The
next message I got was my parents had passed away and as there
was no one to do the last rights the society members had done
whatever they could. I was depressed. My parents had passed
away without seeing their grand children.
After couple more years passed away, much to my children's
dislike and my wife's joy we returned to India to settle down.
I started to look for a suitable property, but to my dismay my
savings were short and the property prices had gone up during
all these years. I had to return to the USA ..

My wife refused to come back with me and my children refused to
stay in India ... My 2 children and I returned to USA after
promising my wife I would be back for good after two years.
Time passed by, my daughter decided to get married to an
American and my son was happy living in USA .. I decided that
had enough and wound-up every thing and returned to India . I
had just enough money to buy a decent 02 bedroom flat in a
well-developed locality.

Now I am 60 years old and the only time I go out of the flat is
for the routine visit to the nearby temple. My faithful wife
has also left me and gone to the holy abode.
Sometimes I wondered was it worth all this? My father, even
after staying in India , had a house to his name and I too have
the same

nothing more.

I lost my parents and children for just ONE EXTRA BEDROOM.
Looking out from the window I see a lot of children dancing.
This damned cable TV has spoiled our new generation and these
children are losing their values and culture because of it. I
get occasional cards from my children asking I am alright. Well
at least they remember me.
Now perhaps after I die it will be the neighbors again who will
be performing my last rights, God Bless them. But the question
still
remains 'was all this worth it?'

I am still searching for an answer...... ......... ...!!!

INDIAN SOFTWARE ENGINEER

Never listen with a predetermined notion

2008-04-08T23:42:00.000-07:00

A teacher teaching Maths to seven-year-old Arnav asked him, “If I give you one apple and one apple and one apple, how many apples will you have?”Within a few seconds Arnav replied confidently, “Four!”

The dismayed teacher was expecting an effortless correct answer (three). She was disappointed. “Maybe the child did not listen properly,” she thought. She repeated, “Arnav, listen carefully. If I give you one apple and one apple and one apple, how many apples will you have?”

Arnav had seen the disappointment on his teacher’s face. He calculated again on his fingers. But within him he was also searching for the answer that will make the teacher happy. His search for the answer was not for the correct one, but the one that will make his teacher happy. This time hesitatingly he replied, “Four…”

The disappointment stayed on the teacher’s face. She remembered that Arnav liked strawberries. She thought maybe he doesn’t like apples and that is making him loose focus. This time with an exaggerated excitement and twinkling in her eyes she asked, “If I give you one strawberry and one strawberry and one strawberry, then how many you will have?”

Seeing the teacher happy, young Arnav calculated on his fingers again. There was no pressure on him, but a little on the teacher. She wanted her new approach to succeed. With a hesitating smile young Arnav enquired, “Three?”

The teacher now had a victorious smile. Her approach had succeeded. She wanted to congratulate herself. But one last thing remained. Once again she asked him, “Now if I give you one apple and one apple and one more apple how many will you have?”

Promptly Arnav answered, “Four!”

The teacher was aghast. “How Arnav, how?” she demanded in a little stern and irritated voice.

In a voice that was low and hesitating young Arnav replied, “Because I already have one apple in my bag.”

“When someone gives you an answer that is different from what you expect. Don’t think they are wrong. There maybe an angle that you have not understood at all. You will have to listen and understand, but never listen with a predetermined notion.”

Folk Song Kondaliyu’s Glimpse-Remake-Remix

2008-04-08T23:21:00.001-07:00

From : DeshGujarat.com

Lucky day

2007-10-01T04:00:00.001-07:00

Today,
1st October 07. I can say one of the meorable day of my life. I like a girl for last few months. But as she was best frnd of my frnd i fear to tell her abt this an also to my friend. Today my friend tell me something about her and i tell her that i like her very much. And because its a lucky day today my friend told me that she is best match for me and i am for her.Now i got some guts to Propose her.i will do it soon once i will be in Gujarat. Hope things wil work and i will get my someone special.

Cheet Sheets - For all programming things...

2007-09-17T21:48:00.000-07:00

The Manual.su's project. All cheat sheets, round-ups, quick reference cards, quick reference guides and quick reference sheets in one page. The only one you need.

Cheetsheets.org

Pidgin 2.2.0

2007-09-17T21:43:00.000-07:00

Pidgin is an instant messaging program for Windows, Linux, BSD, and other Unixes. You can talk to your friends using AIM, ICQ, Jabber/XMPP, MSN Messenger, Yahoo!, Bonjour, Gadu-Gadu, IRC, Novell GroupWise Messenger, QQ, Lotus Sametime, SILC, SIMPLE, MySpaceIM, and Zephyr.
Pidgin can log in to multiple accounts on multiple IM networks simultaneously. This means that you can be chatting with friends on AIM, talking to a friend on Yahoo Messenger, and sitting in an IRC channel all at the same time.
Pidgin supports many features of the various networks, such as file transfer, away messages, and typing notification. It also goes beyond that and provides many unique features. A few popular features are Buddy Pounces, which give the ability to notify you, send a message, play a sound, or run a program when a specific buddy goes away, signs online, or returns from idle; and plugins, consisting of text replacement, a buddy ticker, extended message notification, iconify on away, spell checking, tabbed conversations, and more.
Pidgin runs on a number of platforms, including Windows, Linux, and other UNIX operating systems.
Download Pidgin from here or visit the official site.
[via Technoworld]

Love never Dies

2007-09-17T06:45:00.001-07:00

एक लड़का और एक लड़की एक दूसरे से बहुत प्यार करते थे.
दुर्भागया से लड़का मार गया………
मरने के बाद उसने लड़की से कहा

“एक वादा था तेरा हर वादे के पीछे,
तू मिलेगी मुझे हर दरवाज़े क पीछे,
पर तू मुझे रुसवा कर गयी
एक तू ही ना थी मेरे जनाज़े के पीछे”.

इतने में लकड़ी की आवाज़ आई,
उसने कहा . . . . .

एक वादा था मेरे हर वादे के पीछे,
मैं मिलूँगी तुझे हर दरवाज़े के पीछे,
पर तूने ही मूड के ना देखा,
एक और जनाज़ा था तेरे जनाज़े के पीछे……. ………

Use Notepad as a Diary

2007-09-17T06:26:00.001-07:00

1. Open a blank Notepad file
2. Type .LOG (caps) as the first line of the file, followed by a enter. Save
the file and close it.
3. Double-click the file to open it and notice that Notepad appends the current date and time to the end of the file and places the cursor on the line after.
4. Type your notes and then save and close the file.
5. Each time you open the file, Notepad repeats the process, appending the time and date to the end of the file and placing the cursor below it!

Time Table Search for Mumbai Local Train

2007-09-17T06:25:00.003-07:00

Time Table Search for Mumbai Local Train

-Thane-Vashi Track Time Table

-Suburban Rail Map

The link is http://www.sindhunagar.com/railway.php

Google search results say “This site may harm your computer?”

2007-09-17T06:25:00.001-07:00

Google states as follows ….

We want our users to feel safe when they search the web, and we’re continuously working to identify dangerous sites and increase protection for our users. This warning message appears with search results we’ve identified as sites that may install malicious software on your computer:

Innocence @ Its Best

2007-09-17T06:19:00.000-07:00

A little boy wanted Rs.500 very badly and prayed for weeks, But nothing happened.

Finally he decided to write a letter to GOD requesting the Rs.500 .
When the postal authorities received the letter addressed to ” God , India”,they decided to forward it to the Finance Minister of India as a JOKE.
The Finance Minister was so amused, that he instructed his secretary to send the little boy Rs.200.

The Finance Minister thought this would appear to be a lot of money to a little boy, and he did not want to spoil the kid.The little boy was delighted with Rs.200, and decided to write a thanking reply note to God, which reads:

“Dear God: Thank you very much for sending the money. However, I noticed that you sent it through the Finance Ministry in New Delhi, and those donkeys deducted Rs.300 as taxes!”

Proud to be Indian

2007-06-29T03:42:00.000-07:00

BE PROUD OF THIS INDIAN
RESUME

EDUCATION /Qualification:

Stood first in BA (Hons), Economics, Panjab University, Chandigarh,
1952; Stood first in MA (Economics), Panjab University, Chandigarh,
1954; Wright's Prize for distinguished performance at St John's College,
Cambridge, 1955 and 1957; Wrenbury scholar, University of Cambridge,
1957; DPhil (Oxford), DLitt (Honoris Causa); PhD thesis on India's export competitiveness

OCCUPATION /Teaching Experience:

Professor (Senior lecturer, Economics, 1957-59;
Reader, Economics, 1959-63;
Professor, Economics, Panjab University, Chandigarh, 1963-65; Professor,
International Trade, Delhi School of Economics,University of Delhi,
1969-71; Honorary professor, Jawaharlal Nehru University,New Delhi,
1976 and Delhi School of Economics, University of Delhi,1996 and Civil Servant

Working Experience/ POSITIONS :

1971-72: Economic advisor, ministry of foreign trade

1972-76: Chief economic advisor, ministry of finance

1976-80: Director, Reserve Bank of India; Director, Industrial Development Bank of India; Alternate governor for India, Board of governors, Asian Development Bank; Alternate governor for India, Board
of governors, IBRD

November 1976 - April 1980: Secretary, ministry of finance (Department of economic affairs); Member, finance, Atomic Energy Commission; Member, finance, Space Commission

April 1980 - September 15, 1982: Member-secretary, Planning Commission

1980-83: Chairman, India Committee of the Indo-Japan joint study committee September 16, 1982 - January 14, 1985: Governor, Reserve Bank of India

1982-85: Alternate Governor for India, Board of governors, International Monetary Fund

1983-84: Member, economic advisory council to the Prime Minister

1985: President, Indian Economic Association

January 15, 1985 - July 31, 1987: Deputy Chairman, Planning Commission

August 1, 1987 - November 10, 1990: Secretary-general and commissioner, south commission, Geneva

December 10, 1990 - March 14, 1991: Advisor to the Prime Minister on economic affairs

March 15, 1991 - June 20, 1991: Chairman, UGC

June 21, 1991 - May 15, 1996: Union finance minister

October 1991: Elected to Rajya Sabha from Assam on Congress ticket

June 1995: Re-elected to Rajya Sabha

1996 onwards: Member, Consultative Committee for the ministry of finance

August 1, 1996 - December 4, 1997: Chairman, Parliamentary standing committee on commerce

March 21, 1998 onwards: Leader of the Opposition, Rajya Sabha

June 5, 1998 onwards: Member, committee on finance

August 13, 1998 onwards: Member, committee on rules

Aug 1998-2001: Member, committee of privileges 2000 onwards: Member, executive committee, Indian parliamentary group

June 2001: Re-elected to Rajya Sabha

Aug 2001 onwards: Member, general purposes committee

BOOKS:

India's Export Trends and Prospects for Self-Sustained Growth -Clarendon Press, Oxford University, 1964; also published a large number of articles in various economic journals.

OTHER ACCOMPLISHMENTS:

Adam Smith Prize, University of Cambridge, 1956

Padma Vibhushan, 1987

Euro money Award, Finance Minister of the Year, 1993;

Asia money Award, Finance Minister of the Year for Asia, 1993 and 1994

INTERNATIONAL ASSIGNMENTS :

1966: Economic Affairs Officer

1966-69: Chief, financing for trade section, UNCTAD

1972-74: Deputy for India in IMF Committee of Twenty on International Monetary Reform

1977-79: Indian delegation to Aid-India Consortium Meetings

1980-82: Indo-Soviet joint planning group meeting

1982: Indo-Soviet monitoring group meeting

1993: Commonwealth Heads of Government Meeting Cyprus 1993: Human Rights World Conference, Vienna

RECREATION:

Gymkhana Club, New Delhi; Life Member, India International Centre, New Delhi
ANY Guesses
!
!
!
!
!
!

Name: Dr Manmohan Singh

DOB: September 26, 1932

Place of Birth: Gah (West Punjab)

Father: S. Gurmukh Singh

Mother: Mrs Amrit Kaur

Married on: September 14, 1958

Wife: Mrs Gursharan Kaur

Children: Three daughters

Our Prime Minister seems to be the most qualified PM all over the world.

My First article

2007-06-13T21:47:00.000-07:00

This is my first article in my blog.
I will start with some famous Software Quotes

UNIX is simple. But It just needs a genius to understand its simplicity.

--Dennis Ritchie

Before software can be reusable, it first has to be usable.

--Ralph Johnson

Good judgment comes from experience, and experience comes from bad judgment.

--Fred Brooks

Theory is when you know something, but it doesn't work. Practice is when
something works, but you don't know why it works. Programmers combine theory
and practice: Nothing works and they don't know why.

It's hard enough to find an error in your code when you're looking for it;
it's even harder when you've assumed your code is error-free.

-Steve McConnell Code Complete

If builders built buildings the way programmers wrote programs, then the
first woodpecker that came along would destroy civilisation.

-Gerald Weinberg

The Six Phases of a Project:

Enthusiasm
Disillusionment
Panic
Search for the Guilty
Punishment of the Innocent
Praise for non-participants

Good code is its own best documentation. As you're about to add a comment,
ask yourself, 'How can I improve the code so that this comment isn't needed?'
Improve the code and then document it to make it even clearer.

--Steve McConnell Code Complete

The trouble with the world is that the stupid are sure and the intelligent
are full of doubt.

--Bertrand Russell

No matter how slick (efficient) the demo is in rehearsal, when you do it in
front of a live audience the probability of a flawless presentation is
inversely proportional to the number of people watching, raised to the power
of the amount of money involved.

One of the main causes of the fall of the Roman Empire was that, lacking
zero, they had no way to indicate successful termination of their C programs.

--Robert Firth

Fifty years of programming language research and we end up with C++?

--Richard A. O'Keefe

C programmers never die. They are just cast into void.

If debugging is the process of removing bugs, then programming must be the
process of putting them in.

--Edsger Dijkstra

You can either have software quality or you can have pointer arithmetic, but
you cannot have both at the same time.

--(Bertrand Meyer)

(Thoughtful...)

There are two ways to write error-free programs; only the third works.

--Alan J. Perlis

Measuring programming progress by lines of code is like measuring aircraft
building progress by weight.

--Bill Gates

The first 90% of the code accounts for the first 10% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.

--Tom Cargill

Programmers are in a race with the Universe to create bigger and better
idiot-proof programs, while the Universe is trying to create bigger and
better idiots. So far the Universe is winning.

--Anon