What is the role of QA in your eyes?
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
Personally, I think it's arrogant of a tester to attempt solving issues they discover as there could be factors and situations that the tester is not aware of as they have not been involved in all the development. That's where I believe this feeling of irritation stems from when people find a problem and want to fix it for you.
----------------------------------------------------------- Completion Deadline: two days before the day after tomorrow
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
AlaskaDan wrote:
What is the role of QA in your eyes?
QA? We don't need no stinkin' QA. Our software has no bugs. Now, trying to be serious: I don't think there is a norm. It all depends on a culture of the organization and the politics within it.
-
AlaskaDan wrote:
What is the role of QA in your eyes?
QA? We don't need no stinkin' QA. Our software has no bugs. Now, trying to be serious: I don't think there is a norm. It all depends on a culture of the organization and the politics within it.
Nemanja Trifunovic wrote:
Our software has no bugs.
microsoft? ;P
----------------------------------------------------------- Completion Deadline: two days before the day after tomorrow
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
QA here just test the whole solution if they find bugs i get an email if they think it could be better there is a meeting. meetings often end in changes to the spec which mean more work and more chance for bugs but keeps the QA department in a job. p.s i think they should check everything but change nothing. change management, if they change something which causes a bug they cant fix then its down to you to find the bug (good luck).
Code Project Lounge 101 by John Cardinal :beer::bob::beer:
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
QA testing, in a formal sense, is intended to verify that the product created by the developers meets the requirements originally specified. It is inherently a 'black box' test. Your QA group is attempting to do 'white box' testing. It sounds like your QA group is overshooting their bounds. Unless they have complete access to the development environment (source control, test data bases, etc.), they can't possibly do a reasonable job of suggesting solutions. If they do have that kind of access, then they aren't fulfilling a QA function. It's an engineering test, at best.
Software Zen:
delete this; -
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
[edit] Ah, sorry, I didn't read that right, the part "on what they feel the solution is" [/edit].
AlaskaDan wrote:
Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is?
It's QA's job to report the exact sequence of events that create the problem. After all, how are they going to verify that you fixed it if they can't remember how to reproduce it?
AlaskaDan wrote:
Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes?
I don't think it's necessarily QA's job to verify schema and data changes per se, but it is their job to verify that those changes don't break existing functionality.
AlaskaDan wrote:
This is the first company I've been at with a formal QA department, so I have no idea what the norm is.
Your company's QA department sounds worse than not having one at all. Marc
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
The answer really depends on your development process. In an iterative process like scrum or RUP, Test would be very involved with development, and suggesting solutions would make some sense. In most waterfall processes, QA gets the product at some defined point in the development, and is supposed to do "Black Box" testing to verify that it meets the customers requirements. In that kind of environment QA should absolutely not be involved in determining solutions (that's Design by Defect Report). Their interest should be "does it work as advertised, if not, describe the flaw accurately and reproducibly then move on".
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
Is QA's job to find the problem in the UI and simply report it back to development? QA should be able to tell you how to reproduce the problem. When they include screenprints it's even more helpful. Should they go further and give ideas on what they feel the solution is? In a strict sense? No But If the tester had something valuable to add why not? It really can depend on the value and skill of the individual. If the suggestion comes from previous experience it might save you time. If the QA person's time spent trying to solve the problem is impinging on the time that should be spent testing it can be a problem. If the QA person doesn't know what they are talking about it could be a problem. Unfortunately for you it sounds like the last two are happening. Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? I could see an argument for this. Most errors occur where there are changes. It could save the testers a lot of time if they know where to focus their testing rather than regression test everything all the time. If its a smaller organization then yes maybe. If it's a big organization you might have someone who validates changes. This is more of a developer task than a QA task.
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
I have worked in QA for some years and now working in development. To answer your question, as others here have said QA's job is to find a problem and report it as accurate as possible and not to attempt the fix. That's very first and basic requirement, but it could be lot more then that depending on the product and the company. In your case, if they are simply testing UI it will be very helpful if you listen to their proposed solutions, at least from the usability point of view. As testers are the one using the products most within the company and are trained (or at least should be) to look at the product from the customer's point of view. That said it should only be considered as constructive feedback not the solution. I work for the company that makes network test equipments and for us QA's job is even more involved. They are more involved in finding out the cause of the problem as it could be any of the network issues including the other vendor equipments and QA engineers are more familiar with those equipments. Ankita
-
QA testing, in a formal sense, is intended to verify that the product created by the developers meets the requirements originally specified. It is inherently a 'black box' test. Your QA group is attempting to do 'white box' testing. It sounds like your QA group is overshooting their bounds. Unless they have complete access to the development environment (source control, test data bases, etc.), they can't possibly do a reasonable job of suggesting solutions. If they do have that kind of access, then they aren't fulfilling a QA function. It's an engineering test, at best.
Software Zen:
delete this;exactly. QA is NOT supposed to touch the code in any circumstance what so ever...I don't care what company you work for. All they are supposed to do is test the product and report back any deffincies. Having access to the code could/will cause serious problems to all involved.
[ Don't do today what can be done tomorrow!! ;) ]
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
Start with this definition: Quality is conformance to specifications. Is there some part of the implementation of those specifications that you don't think should be verified for quality?
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
If all they do is test they should be called Quality Testing not Quality Assurance. QA should be involved in product development from start to finish with the goal being Testing not finding any problems. QA should not only be telling you why you had the problem but what you should be doing to prevent the problem from occuring in the first place. How could someone discovering a problem and giving a possible solution be a bad thing? This in not the norm, btw. That would be just testing and saying itz broke followed by a pissing match with development.
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
QA should never change ANYTHING (unless its for a test case). when doing a QA test it should be as similar to the production enviroment as possible, and when testing the software they should use it as close to production as possible. If they're doing development testing its alright to make changes, and troubleshoot a problem. Thats how we doing things at least :)
-
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
QA was invented to inhibit programmer's productivity and indefinitely delay the release of a given application.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
QA was invented to inhibit programmer's productivity and indefinitely delay the release of a given application.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001Indeed. Back when the company I work for had a 'real' QA department, I was blessed with The Stickler as the QA guy on my product. I had issues stay on the bug list for two years after the correction was released to customers, just because The Stickler hadn't retested the issue.
Software Zen:
delete this; -
I'm having conflicts between QA and development (go figure). Is QA's job to find the problem in the UI and simply report it back to development? Should they go further and give ideas on what they feel the solution is? Should they always be in the UI, or should they also be doing database comparisons from one version to the next to verify schema and data changes? Development feels like QA should point out the problem and leave the rest to them, but QA feels like they should do as much as possible to troubleshoot the problem, going as far as making their own database changes to test possible solutions. This is the first company I've been at with a formal QA department, so I have no idea what the norm is. Thanks
Wait, I know this one... To waste everyone's time? :)
-
If all they do is test they should be called Quality Testing not Quality Assurance. QA should be involved in product development from start to finish with the goal being Testing not finding any problems. QA should not only be telling you why you had the problem but what you should be doing to prevent the problem from occuring in the first place. How could someone discovering a problem and giving a possible solution be a bad thing? This in not the norm, btw. That would be just testing and saying itz broke followed by a pissing match with development.
QA does not have access to the code. They are testing items, and if it's broken, sometimes they simply kick it back as broken with how they broke it, or they will spend more time trying to figure out what the solution might be so they can go inform development of what they need to do to fix the issue. That's where the pissing match comes in. The time they're spending on troubleshooting the issue beyond running their tests and explaining how they broke something is time they're not spending on the remaining items. In almost all cases, the developer could probably find the real issue faster if the QA guy simply detailed what he did to break it. I spoke to the QA manager at another company, and he said that in most cases, QA should be testing the issues and kicking back any broken ones, and leave the developer stuff to the developers. He did however say that on the front end, when features and bugs are being listed to be included in a build, that QA should be sitting down with development and they should be defining the unit tests and QA tests together.
-
exactly. QA is NOT supposed to touch the code in any circumstance what so ever...I don't care what company you work for. All they are supposed to do is test the product and report back any deffincies. Having access to the code could/will cause serious problems to all involved.
[ Don't do today what can be done tomorrow!! ;) ]
ssmerk007 wrote:
Having access to the code could/will cause serious problems to all involved.
This isn't always the case. It depends upon the actual role that has been defined for the QA group and the technical skill of the QA testers. I have worked in some very large companies where QA was an integrated part of the project team. The QA person was part of the code reviews, did independant code reviews (looking at things like cohesion, cyclomatic complexity, etc.) and was perfectly able to read code and point out possible problems. He did not have check-in rights to the repositories, but it didn't matter for his role. That being said, a QA group like that is definately not the "norm" in 99.9% of software companies. The problem is that a lot of QA groups aren't clearly defined so no one knows where the boundaries are or what the skill sets of the testers is.
----------------------------- In just two days, tomorrow will be yesterday. http://geekswithblogs.net/sdorman
-
The answer really depends on your development process. In an iterative process like scrum or RUP, Test would be very involved with development, and suggesting solutions would make some sense. In most waterfall processes, QA gets the product at some defined point in the development, and is supposed to do "Black Box" testing to verify that it meets the customers requirements. In that kind of environment QA should absolutely not be involved in determining solutions (that's Design by Defect Report). Their interest should be "does it work as advertised, if not, describe the flaw accurately and reproducibly then move on".
Rob Graham wrote:
The answer really depends on your development process
It also depends on the defined role of the QA group and the technical skill of the testers. I have worked on large waterfall based projects where QA was an integrated part of the project team and was part of the code reviews, did independant code reviews (looking at things like cohesion, cyclomatic complexity, etc.) and was perfectly able to read code and point out possible problems. He did not have check-in rights to the repositories, but it didn't matter for his role. If QA is supposed to do only black box testing, then that is all they should do...but should be able to test against well defined test plans and requirements specs.
----------------------------- In just two days, tomorrow will be yesterday. http://geekswithblogs.net/sdorman