Sunday, April 22, 2007

Empirix Launches QAZone for QA and IT Professionals

Empirix has announced today the availability of QAZone, a new online community that allows Web QA professionals to collaborate, communicate and address cutting-edge application quality issues. Visitors can get tips on methodologies, access test code samples and monitoring profiles, and obtain extensions to Empirix’s Web products, all while sharing their knowledge with others in the field through Empirix’s online forums.

Top QAZone features include:

1. a resource center containing best practices, code samples and test scripts, along with product extensions;
2. the ability to rate articles and authors and offer recommendations for new topics;
3. the opportunity to be notified as new content is added to a forum or category;
4. events;nupdates on Empirix product and industry news, as well as upcoming and
5. direct communication with Empirix experts within the forums.

Registration for QAZone is free and open to everyone. Anyone interested in joining can do so by visiting After registering, QAZone users have free access to the knowledgebase and resource center as well as the QAZone forums for Performance Testing, Test Management/Functional Testing, Performance Monitoring and Community feedback. While most forums are open to the public, special sections with detailed documentation are exclusively available for Empirix customers.

Saturday, February 03, 2007

Testing is everything !

It’s amazing how lousy software is. That we as a society have come to accept buggy software as an inevitability is either a testament to our collective tolerance, or—much more likely—the near ubiquity of crappy software. So we are guilty of accepting low standards for software, but the smaller we of software writers are guilty of setting those low expectations. And I mean we: all of us. Every programmer has at some time written buggy software (or has never written any software of any real complexity), and while we’re absolutely at fault its not from lack of exertion. From time immemorial PhD candidates have scratched their whiteboard markers dry in attempts to eliminate bugs with new languages, analysis, programming techniques, and styles. The simplest method for finding bugs before they’re released into the wild remains the most generally effective: testing.

Of course, programmers perform at least nominal checks before integrating new code, but there’s only so much a person can test by hand. So we’ve invented tests suites—collections of tests that require no interaction. Testing rigor is regarded by university computer science departments a bit like ditch-digging is by civil engineering departments: a bit pedestrian. So people tend to sort it out for themselves.
A great read...

Wednesday, January 17, 2007

Software Testing: Why is it so Difficult?

Software testing is probably the most complex task in the software development cycle. It often takes longer to test the software than it does to write the code. The problems discovered during the software testing phase add more time onto the coding phase, resulting in further delays in the product’s release, and so this vicious cycle goes.
It’s nearly impossible to attribute the problems that arise during the software testing cycle to any single factor. Before going any further, it’s important to clarify one point. Software that works, but not the way it is supposed to work, is not considered an error in the coding (also known as a bug). Rather, this situation is the result of an error in the design phase. Software engineers refer to these differences as a “fault” vs. a “failure”. Faults can turn into failures, but that’s a subject for another time.

So why is software testing such a time-consuming and frustrating process? One factor is the complexity of the software being developed. The more complex the project is, the more there is to test. Also, complex projects typically involve multiple development team members, including those working directly for the company and those working as sub-contractors.

Software testing troubles directly attributable to the human factor include poorly documented code and employee turnover. And if the person who is not properly documenting the project is the same person who leaves the company midway through the project cycle, the problem quickly compounds.

Another software testing difficulty arises when those developing the software are the same ones testing that software. These individuals have a much higher level of understanding about software and computer system. They’re not likely to make the same types of mistakes during the software testing phase that end users might make using the finished software. For example, software engineers understand that you never press the power button before you properly close all applications. End users, in their rush to burst out of the office at 5:00 pm just want the computer off, and some won’t wait until every application closes properly.

Plenty of software testing applications are available to help during the software testing phase. These products are designed to facilitate and enhance the software testing phase, provided they can be made to work with the software being tested.

The main purpose of software testing is to discover software failures. As failures are discovered, they can be corrected. However, software testing cannot guarantee that the software is problem-free. Testing finds many bugs, but even the most extensive testing processes can’t fix failures that are not uncovered. Never rely on software testing as proof that no problems exist. That’s considered software verification, an entirely different process.

Regardless of the difficulties involved with software testing, one truth remains. Software failures discovered early on cost far less to correct than those that occur in latter stages of software development, or worse, after the software has been released to the general public.

Tuesday, January 16, 2007

Black Box Testing Video Tutorial !

This educational video clarifies the difference between various types of software testing, including black box testing, glass box testing, acceptance testing, unit testing, system testing, integration testing and other types of software testing. Watch the Black Box Testing video.

Story of a Software Tester !

On a dark and foggy night, a small figure lay huddled on the railway tracks leading to the Chennai 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 meeting room number two. I have your appraisal letter ready"!!!

Friday, January 12, 2007

I have found this bug in Google !

Unbelievable! But 100% TRUE. I myself is a big fan of Google. Infact, my dream is to work as a Software Tester in Google. But today I was shocked (or rather delighted !) to see this bug in Google Suggest. I have already blogged about in my other blog. You can read it here .
I am proud to be able to catch a bug in Google, the great !
Please revert back with your opinions.

Thursday, January 11, 2007

Why Software Quality Stinks – Is it due to lack of Adequate Testing ?

According to a recent survey, it may not get better until attitudes change—from the top down. The Cutter Consortium, an Arlington, Mass.-based IT consulting and advisory service, recently surveyed more than 150 software development organizations across several industries (computer software, financial services, education and more) and found that 38 percent of developers said their companies do not have an adequate software quality assurance program. A startling 31 percent said their companies had no quality assurance personnel at all. In spite of this, the perception among developers is that most senior managers are satisfied with the quality of software that their companies are producing. It's time for senior management to provide visible support for software quality.

Top 5 Best Practices
If your organization doesn't have a software quality team in place, follow these five steps to get an effective group up and running.
1. Get support from senior management. If developers know that a CIO, CTO or CEO is backing the software quality assurance manager, they'll be more likely to produce cleaner code. Get the attention of executives by connecting software quality to the bottom line.
2. Establish a quality organization (with processes, staff and an experienced manager). You may be able to form a group from in-house staff; however, E.M. Bennatan, senior consultant at the Cutter Consortium, says having an experienced, strong quality manager is vital. "You need someone who has spent a few years in the trenches and has gotten products out the door," he says.
3. Train developers too (alongwith your testing team). Don't save quality training just for the quality assurance group. Developers will pay closer attention to quality issues if they know what to watch out for.
4. Listen to your customers (or user group). Get customers involved in the development process. Offer them a beta version of software to test. "Their feedback is invaluable," says Bennatan.
5. Collect metrics. The quality process should be data-driven, according to Bennatan. Demonstrate that the quality of your products is improving.