As a black box tester should I be asked to identify when defects were introduced and by who?
At first thought I think I am being asked the impossible but as a black box tester I can quite easily see from a defect tracker who is responsible for the introduction of defects when retesting, however;
Does anyone have any ideas on identifying when a defect is introduced and by who if it is the first instance of the bug?
I have some access to code but I'm not a programmer, maybe if the defect spawns an error I can find the location the error is triggered and search for it finding the person who committed the last modification. What if it does not trigger an error?
The theory behind it is if testers can determine who created the problem then the responsibility to fix it lies with them and the process runs quicker.
Determining who introduced a bug is without analyzing the code is:
- 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
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.