How can I identify the quality of software ?
156489
Quality of software depends on testing. Also you have to make sure that requirment of softaware is fullfilled. Actually when you develop s/w you have requiremen specs, you have to match with final product to determine quality of software.\nThank you,\nMiral Patel
810080
something is wrong with your software
125857
er...\n\nGoogle\nYahoo\nAlta Vista\nExcite\n\nheck.. check a whole load at once with dogpile
911607
Reviewing the functionality of the software after it's been installed for production.  Doing a 'lessons learned' from the install to review any glitches that may have cropped up.
445101
A Well written program should be explaned clearly with comments, must be indented appropriately, must be efficient in code reuse (Use functions/procedures wherever possible) and be free of any errors ofcourse\n\nGood luck with your assignment
177372
Depends on the program you're using - can you give more details?
194544
software quality is a goal to reach.\nwhen you have reached that goal, then it's quality software.
1056656
You only want good, quality software.   Try http://www.Download.com
216226
rebuilt and tested for errors
321537
check out http://www.download.com/3120-20_4-0.html?tg=dl-20&qt=link%20checker&tag=srch
375314
Defect Density\n\nOne of the easiest ways to judge whether a program is ready to release is to measure its defect density—the number of defects per line of code. Suppose that the first version of your product, GigaTron 1.0, consisted of 100,000 lines of code, that you detected 650 defects prior to the software’s release, and that 50 more defects were reported after the software was released. The software therefore had a lifetime defect count of 700 defects, and a defect density of 7 defects per thousand lines of code (KLOC). \n\nSuppose that GigaTron 2.0 consisted of 50,000 additional lines of code, that you detected 400 defects prior to release, and another 75 after release. The total defect density of that release would be 475 total defects divided by 50,000 new lines of code, or 9.5 defects per KLOC. \n\nNow suppose that you’re trying to decide whether GigaTron 3.0 is reliable enough to ship. It consists of 100,000 new lines of code, and you’ve detected 600 defects so far, or 6 defects per KLOC. Unless you have a good reason to think that your development process has improved with this project, your experience should lead you to expect between 7 and 10 defects per KLOC. The number of defects you should attempt to find will vary depending on the level of quality you’re aiming for. If you want to remove 95 percent of all defects before shipping, you would need to detect somewhere between 650 and 950 pre-release defects. This technique suggests that the product is not quite ready to ship. \n\nThe more historical project data you have, the more confident you can be in your pre-release defect density targets. If you have data from only two projects and the range is as broad as 7 to 10 defects per KLOC, that leaves a lot of wiggle room for an expert judgment about whether the third project will be more like the first or second. But if you’ve tracked defect data for 10 projects and found that their average lifetime defect rate is 7.4 defects per KLOC with a standard deviation of 0.4 defects, you have a great deal of guidance indeed.
514671
These may help:\n\nhttp://www.google.co.uk/search?hl=en&q=types+of+software+testing&btnG=Google+Search&meta=
681044
go to your program files and look for them
604351
buy a copy...don't try to prirate software
454150
going through all the possible options in a program, and even some of the impossible ones, to see if there are any bugs in it
342724
cheap, software already built, user support, compatability with existing software
195978
Test Run seems to have a lot of nice stuff.  I recommended it to our QA people but they didn't seem too interested.  But I bet you could at least look at some of their samples.