Screaming Penguin

I guess you are one of those still stuck in their old ways of using spreadsheets. I like QC because it saves me alot of time,as opposed to spreadsheets Imagine a scenario of 250 bugs all on a congested spreadsheet. How to do prioritize and coordinate with the Dev. Team. Also how the hell do external project auditors cope with all that paper work. My advice is get with the times its 2008 Cheers !!!

I am an SQA Engineer and current user/administrator of Quality Center and Quick TestPro. In previous positions I have used and administered Test Director (previous version of Quality Center), and other systems used for bug tracking. In my experience, the strength of Quality Center is in testing activities and Requirements tracking. I prefer the use of the Test Plan and Test Set modules to creating and tracking test results in spreadsheets (which are 100 times more tedious and error prone). Reporting my results, and archiving them is much simpler using QC. Its also a simple matter to copy test cases into a new project when I need to modify/re-use test cases. Its an advantage that I can give view only permissions to managers, or other group leads, and they can check in on work that is being done and get many of their questions answered by just accessing the system. Since everything is stored in one place, there is more reliability that the right version of the test is going to be reviewed, executed, reported on, etc. As an administrator of our system, I have not found any problems, nor have my users, in performance, as some people have posted above. The user that reported getting kicked out of the system too often should talk to their administrator. The length of time before getting kicked out is configurable. The user that said they had to wait hours to access a record locked by their login id should contact their administrator. This has rarely happened in my organization, but when it does, the administrator just needs to kill the previous session that was hung, the work of less than 1 minute. Where QC could be better is in the defects module. As someone mentioned before, the product was developed as primarily a test tool and this is where its strength lies. While the defects module is configurable to a large extent which allows for workarounds to many of the problems I have encountered in using it for tracking and reporting metrics, there are better bug tracking systems out there (I prefer Remedy). However, it is important to note that there are much worse bug tracking systems out there which I have had the misfortune to use/administer. As a whole the QC defects module is not perfect and on a scale of 1 to 10, I would probably give it a 5 to 6 rating, but it works well enough for our organization. To address one user’s comment about the email that comes from QC defects module where this user was getting ‘spammed’ with everything logged or changed for every defect [Send Mail on “All Defects” is probably checked, instead of a specific condition for this user], here again I will point out that this is configurable by the administrator. Most likely, the administrator for this user’s system didn’t take the time to configure the mail so that it, for example, only sent email to this user when the issue was assigned to their login ID. Also, when I get email from different defects associated with different projects, the project name is displayed first in the subject line, for example “Project 1 – Defect #10 Summary”. I can’t remember off-hand if this is a setup issue (I’m using version 8.2). Many of the complaints I see listed here could be resolved by having a better educated system administrator for QC, or by checking the hardware configuration of the implementation to eliminate performance issues. I also have to agree with the user that pointed out the absurdity of complaining about how this system doesn’t accept the same commands that vi does, for example. In my 10+ years in Software Quality I have yet to see a system that does it all and makes everyone happy. QC is not junk, it is useful, and it does have its quirks – just like any other system I’ve ever tested or used. No designer, developer, tester or user is perfect – so it follows that no system is either. Overall, the QC tool is a good one with some great features, and when used for what it is designed for, it makes my life as a tester much easier.

Right, the way to get QC to work is to get an admin that knows it, so you can pay someone else an exorbitant amount of money ON TOP of the money you paid for the tool, I see. Any tool that doesn't offer a good deal of value out of the box, or that at least can't just be configured by ANYONE using it, rather than a specialized admin, is bad news. Don't get me wrong, I think you are making some sense there, I am sure it could be configured better - but it shouldn't be that hard, that was part of my original point - the tool sucks if it takes that much configuration to make it useful (and then there is still the activeX nonsense, etc). I have worked in the software industry for nearly 20 years now, and I have worked FOR many of the biggest companies, and a few startups, and on my own - I have seen a lot too, and I still think QC is total crap.

It's still crash-prone and generally buggy. Still the same ActiveX shit. A word of advice for anyone considering QC/QTP: Take the tens of thousands of dollars that you'd normally spend annually (not exaggerating) on this garbage, train your QA staff in .NET, and get them automating anything they want with ease. (Using VBScript wouldn't be so bad if there were nearly as much documentation around as there is for .NET development. That aside, QC and QTP are seriously, egregiously unusable.) Teach your testers to use QTP, and they can eat for a day; teach them .NET, and they'll actually have a non-outsourced job in five years.