How detailed should QA aim to be?
When QA discovers an issue during testing should they... Log the bug with the test case and scenario information and move on testing? Try investigating to determine why the bug is happening? I would think it is normally both, but some people are saying it is not QA's job to even try to find root causes. QA is just meant to point out bugs. Interestingly this sentiment is coming from QA not developers. Some background Imagine this is happening in a very small team (3-4 people) working in an agile-ish environment. The developers are continually adding new features and fixes. Unit test coverage is very low. This is mostly due to the fact the developers have been pushed to deliver features first. QA is relied heavily on verifying correctness and functionality. Generally the developers are open to working closely with QA on things. The QA team is testing in parallel. As soon as new builds show up they start their regression and new functional tests. However there are no automated tests. All tests are manual. Luckily most tests are quick to execute since they are simple comparisons against expected results. Added In the overarching organization, there are mostly two breeds of QA. There are the automation QA who do what their title suggests. And there are testers. Some float between the two from project to project, but for the purposes of this question, the QA are meant to be testing. Perhaps to rephrase, what is a appropriate level of detail QA should be recording about bugs when they come across it (only the Devs will read these details)? Is "Calculation X is wrong when using attached data file" sufficient? Or, "Calculation X was off by a some constant. When we change value Y1 in the data file, the difference is equal to the value of Y1."
When QA discovers an issue during testing should they...
- Log the bug with the test case and scenario information and move on testing?
- Try investigating to determine why the bug is happening?
I would think it is normally both, but some people are saying it is not QA's job to even try to find root causes. QA is just meant to point out bugs. Interestingly this sentiment is coming from QA not developers.
Some background
Imagine this is happening in a very small team (3-4 people) working in an agile-ish environment. The developers are continually adding new features and fixes. Unit test coverage is very low. This is mostly due to the fact the developers have been pushed to deliver features first. QA is relied heavily on verifying correctness and functionality. Generally the developers are open to working closely with QA on things.
The QA team is testing in parallel. As soon as new builds show up they start their regression and new functional tests. However there are no automated tests. All tests are manual. Luckily most tests are quick to execute since they are simple comparisons against expected results.
Added
In the overarching organization, there are mostly two breeds of QA. There are the automation QA who do what their title suggests. And there are testers. Some float between the two from project to project, but for the purposes of this question, the QA are meant to be testing.
Perhaps to rephrase, what is a appropriate level of detail QA should be recording about bugs when they come across it (only the Devs will read these details)?
Is "Calculation X is wrong when using attached data file" sufficient?
Or, "Calculation X was off by a some constant. When we change value Y1 in the data file, the difference is equal to the value of Y1."
