3 added 1375 characters in body
source | link

Saying "QA" as a job role is akin to saying "health care professional." You've got nurses, nurses assistants, physicians, physicians assistants, nurse practitioner, surgeons, midwives, etc...

Trying to answer "how far QA should go" is much like trying to answer "what does a health care professional do?" - it depends on the job description the person was hired for and their capabilities.

I've seen QA be people that are just supposed to click and verify. I've seen QA where its programmers who are writing automated tests. I've seen QA where they have to put their stamp of approval on every release (or it doesn't go out). I've seen QA that has tried to do as little as possible and not claim any responsibility for the end product. I've seen QA where they take the A part of the title very seriously and are involved in the process of assurance of quality (making sure code reviews are done, getting deep into ISO 9000).

So what should your QA department do? What they need to. This is completely dependent on what you need them to do and what they are hired to do and what their responsibilities are. This is probably a discussion you should have with your management chain if it is necessary. Many programers will find they have had similar discussions about if they should be gathering requirements, writing documentation, preforming tests themselves - the same needs to be done and said of QA.

For issues of how detailed a bug report QA should give, it is an issue of quality vs quantity. If they are finding one bug a cycle and the test suite takes less than one cycle to do, then they have the opportunity (given that they have the appropriate skill set - because you're hiring good employees and paying competitively) they can then write a sufficiently detailed bug reports such that programmers can work from them more easily.

On the other hand, if they are expected to do 7 days of testing in 5, there is no way that they can do a complete root cause analysis (RCA) on the bugs they find - being under time pressure to finish the regression suite.

If QA is finding that each cycle there are sufficiently many bugs that while they do finish the tests, they can't do an RCA on each one, you will likely find the quality of the bug reports varying greatly. This becomes especially prevalent when there are no automated tests that the coders run - each time a new build is being done QA is finding itself having to make sure that each bit of functionality is still the same. Depending on the size of the application, this can mean lots of testing.

Related reading:

Minor rant - we work in an industry where people go for "code ninja" or "java wizard" as job title and such and then try to tell the "QA" people they should or shouldn't do something because of their job title? Read the job description. Do what is needed. If the job description needs to change, change it. If something needs to be done, do it.

Saying "QA" as a job role is akin to saying "health care professional." You've got nurses, nurses assistants, physicians, physicians assistants, nurse practitioner, surgeons, midwives, etc...

Trying to answer "how far QA should go" is much like trying to answer "what does a health care professional do?" - it depends on the job description the person was hired for and their capabilities.

I've seen QA be people that are just supposed to click and verify. I've seen QA where its programmers who are writing automated tests. I've seen QA where they have to put their stamp of approval on every release (or it doesn't go out). I've seen QA that has tried to do as little as possible and not claim any responsibility for the end product. I've seen QA where they take the A part of the title very seriously and are involved in the process of assurance of quality (making sure code reviews are done, getting deep into ISO 9000).

So what should your QA department do? What they need to. This is completely dependent on what you need them to do and what they are hired to do and what their responsibilities are. This is probably a discussion you should have with your management chain if it is necessary.

Related reading:

Minor rant - we work in an industry where people go for "code ninja" or "java wizard" as job title and such and then try to tell the "QA" people they should or shouldn't do something because of their job title? Read the job description. Do what is needed. If the job description needs to change, change it. If something needs to be done, do it.

Saying "QA" as a job role is akin to saying "health care professional." You've got nurses, nurses assistants, physicians, physicians assistants, nurse practitioner, surgeons, midwives, etc...

Trying to answer "how far QA should go" is much like trying to answer "what does a health care professional do?" - it depends on the job description the person was hired for and their capabilities.

I've seen QA be people that are just supposed to click and verify. I've seen QA where its programmers who are writing automated tests. I've seen QA where they have to put their stamp of approval on every release (or it doesn't go out). I've seen QA that has tried to do as little as possible and not claim any responsibility for the end product. I've seen QA where they take the A part of the title very seriously and are involved in the process of assurance of quality (making sure code reviews are done, getting deep into ISO 9000).

So what should your QA department do? What they need to. This is completely dependent on what you need them to do and what they are hired to do and what their responsibilities are. This is probably a discussion you should have with your management chain if it is necessary. Many programers will find they have had similar discussions about if they should be gathering requirements, writing documentation, preforming tests themselves - the same needs to be done and said of QA.

For issues of how detailed a bug report QA should give, it is an issue of quality vs quantity. If they are finding one bug a cycle and the test suite takes less than one cycle to do, then they have the opportunity (given that they have the appropriate skill set - because you're hiring good employees and paying competitively) they can then write a sufficiently detailed bug reports such that programmers can work from them more easily.

On the other hand, if they are expected to do 7 days of testing in 5, there is no way that they can do a complete root cause analysis (RCA) on the bugs they find - being under time pressure to finish the regression suite.

If QA is finding that each cycle there are sufficiently many bugs that while they do finish the tests, they can't do an RCA on each one, you will likely find the quality of the bug reports varying greatly. This becomes especially prevalent when there are no automated tests that the coders run - each time a new build is being done QA is finding itself having to make sure that each bit of functionality is still the same. Depending on the size of the application, this can mean lots of testing.

Related reading:

Minor rant - we work in an industry where people go for "code ninja" or "java wizard" as job title and such and then try to tell the "QA" people they should or shouldn't do something because of their job title? Read the job description. Do what is needed. If the job description needs to change, change it. If something needs to be done, do it.

2 added 375 characters in body
source | link

Saying "QA" as a job role is akin to saying "health care professional." You've got nurses, nurses assistants, physicians, physicians assistants, nurse practitioner, surgeons, midwives, etc...

Trying to answer "how far QA should go" is much like trying to answer "what does a health care professional do?" - it depends on the job description the person was hired for and their capabilities.

I've seen QA be people that are just supposed to click and verify. I've seen QA where its programmers who are writing automated tests. I've seen QA where they have to put their stamp of approval on every release (or it doesn't go out). I've seen QA that has tried to do as little as possible and not claim any responsibility for the end product. I've seen QA where they take the A part of the title very seriously and are involved in the process of assurance of quality (making sure code reviews are done, getting deep into ISO 9000).

So what should your QA department do? What they need to. This is completely dependent on what you need them to do and what they are hired to do and what their responsibilities are. This is probably a discussion you should have with your management chain if it is necessary.

Related reading:

Minor rant - we work in an industry where people go for "code ninja" or "java wizard" as job title and such and then try to tell the "QA" people they should or shouldn't do something because of their job title? Read the job description. Do what is needed. If the job description needs to change, change it. If something needs to be done, do it.

Saying "QA" as a job role is akin to saying "health care professional." You've got nurses, nurses assistants, physicians, physicians assistants, nurse practitioner, surgeons, midwives, etc...

Trying to answer "how far QA should go" is much like trying to answer "what does a health care professional do?" - it depends on the job description the person was hired for and their capabilities.

I've seen QA be people that are just supposed to click and verify. I've seen QA where its programmers who are writing automated tests. I've seen QA where they have to put their stamp of approval on every release (or it doesn't go out). I've seen QA that has tried to do as little as possible and not claim any responsibility for the end product. I've seen QA where they take the A part of the title very seriously and are involved in the process of assurance of quality (making sure code reviews are done, getting deep into ISO 9000).

So what should your QA department do? What they need to. This is completely dependent on what you need them to do and what they are hired to do and what their responsibilities are. This is probably a discussion you should have with your management chain if it is necessary.

Related reading:

Saying "QA" as a job role is akin to saying "health care professional." You've got nurses, nurses assistants, physicians, physicians assistants, nurse practitioner, surgeons, midwives, etc...

Trying to answer "how far QA should go" is much like trying to answer "what does a health care professional do?" - it depends on the job description the person was hired for and their capabilities.

I've seen QA be people that are just supposed to click and verify. I've seen QA where its programmers who are writing automated tests. I've seen QA where they have to put their stamp of approval on every release (or it doesn't go out). I've seen QA that has tried to do as little as possible and not claim any responsibility for the end product. I've seen QA where they take the A part of the title very seriously and are involved in the process of assurance of quality (making sure code reviews are done, getting deep into ISO 9000).

So what should your QA department do? What they need to. This is completely dependent on what you need them to do and what they are hired to do and what their responsibilities are. This is probably a discussion you should have with your management chain if it is necessary.

Related reading:

Minor rant - we work in an industry where people go for "code ninja" or "java wizard" as job title and such and then try to tell the "QA" people they should or shouldn't do something because of their job title? Read the job description. Do what is needed. If the job description needs to change, change it. If something needs to be done, do it.

1
source | link

Saying "QA" as a job role is akin to saying "health care professional." You've got nurses, nurses assistants, physicians, physicians assistants, nurse practitioner, surgeons, midwives, etc...

Trying to answer "how far QA should go" is much like trying to answer "what does a health care professional do?" - it depends on the job description the person was hired for and their capabilities.

I've seen QA be people that are just supposed to click and verify. I've seen QA where its programmers who are writing automated tests. I've seen QA where they have to put their stamp of approval on every release (or it doesn't go out). I've seen QA that has tried to do as little as possible and not claim any responsibility for the end product. I've seen QA where they take the A part of the title very seriously and are involved in the process of assurance of quality (making sure code reviews are done, getting deep into ISO 9000).

So what should your QA department do? What they need to. This is completely dependent on what you need them to do and what they are hired to do and what their responsibilities are. This is probably a discussion you should have with your management chain if it is necessary.

Related reading: