Once a defect is found, I think that the most important thing to do is to get it logged with the key information - a title or summary, details about the defect or problem is, what actually happens and what you expect should happen, the steps you need to reproduce it, and the environment where it was found (such as the OS, web browser, software version under test, etc). Depending on your process, the person submitting the defect report may also assign a priority and/or severity.
From a QA perspective, you are usually looking at software that is still under development, or at best a release candidate. Although the development team should be performing unit, integration, and some system tests before you get to it, their tests aren't perfect and you're going to find issues that the dev team should look at before they go to release. Ultimately, it's up to someone in the organization to prioritize identified issues and decide if something will be fixed in this release cycle or a later release cycle.
Throughout the development cycle, both the development team and the QA team should be changing their tests. There may be a regression test suite that always gets executed, but I would suspect that testing is more thorough and focused on features or parts of the software that have changed. Defects could be exposed for any number of reasons. A change could have introduced a defect. A change could have made defect more obvious, easier to trigger, or more common. The new test cases could have found a defect that has been latent in the software for a long period of time. Regardless of why the defect was detected by the testing isn't that important right now - the first priority should be to fix the defect.
In some environments, such as customer self-hosted software or where there is an obligation to support or maintain multiple versions, it may be necessary to test multiple versions of the software to determine when the defect was first introduced so that customers can be notified, especially if it is a significant defect. In environments such as these, I would expect more of a burden to be placed on the QA team in identifying affected versions(s) out of those that are currently supported and to address why the issue escaped from multiple levels and rounds of testing.
However, in environments where only one version of the software is supported, I'm not sure that it really matters what version the defect started in. If the defect was affecting users and they have a mechanism to report issues, then they will report it as a problem. However, from a quality perspective, it is important to understand known issues with the software. From a project management perspective, the amount of open issues can be used to determine if software is ready to be released or to plan work for a future development cycle. Even if it's not scheduled to be fixed prior to the end of the current development cycle, it could be reflected in user-facing documentation, along with workarounds, until it can be fixed.
At the end, after the defect has been fixed, you may choose to perform some kind of root cause analysis to determine when the defect was injected (in the current development cycle), why the defect wasn't discovered in previous development and QA cycles (if it wasn't recently introduced), and what types of tests should be created, executed, and managed to prevent this defect from returning in the future.
As an aside, I would like to note that there are multiple ideas for what a Software QA organization should be responsible for. In some organizations, Software QA is essentially a test team that is the last line of defense for software releases to ensure that it meets requirements and has no significant issues. In other organizations, Software QA is not only responsible for product quality, but also process quality and may be involved in every step of the development process to ensure that all work products (from requirements through the distribution media) are complete and correct per standards. There are other expectations, as well. This answer focuses more on Software QA being responsible for product quality.
