Determining who introduced a bug is without analyzing the code is:
Extremely time-consuming
- if you want to install previous versions of software, you need to also accordingly change data structures,
- or have a copy of your databases for every database change
- keep switching between different versions which might have different behavior
- and you still have to rely on developers to analyze code change, because quite often code change did not caused the error but unearthed hidden bug caused by different code change
Counterproductive
It creates wrong dynamic by pointing fingers and assuming blame, instead of working as a team with developers to eliminate inevitable bugs.
Bug are inevitable and we have to admit it is extremely expensive to prevent all of them (think space exploration projects). If it is possible and not prohibitively expensive to fix the code in production (like in-house application, bread and butter of most programming), best we can do is to prevent most obvious ones fast (by automating unit testing and system testing), and engineer the process to avoid repeating same kind of bugs over and over. Obviously, more rigorous (and more expensive) approach should be used for controlling nuclear power plant.
Responsibility of tester is to determine if bug is present (and it is not misunderstanding from a customer), document condition to reproduce it, and let developers to deal with it. Yes, often the person who wrote offending code is best positioned to fix it, at this is the reason why you should test code as quickly as you can after commit. But often, that person left, or is working on another project. For this reason, many companies have "maintenance team" who fixes bugs in production code (possibly asking developers what the intention of the code is if not documented in sufficient details). It is counterproductive to interrupt developers working on a new feature to fix a bug in different parts of the code, and such interruptions will cause more bugs.
This approach (to let more people be familiar with more parts of the code) removes silo boundaries and improves bus factor of your project by spreading the knowledge of code broader.