As a black box tester should I be asked to identify when defects were introduced and by who?

Question

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.

Answer 1

It depends on your environment and the circumstances.

Some rules of thumb I use:

WHEN

• IF I have an automated regression suite and distinct builds
• AND the bug breaks the regression suite,

• THEN I can give a "last known good" build as well as a "first known broken" build.

• IF I have been working on something and I am reasonably sure it worked two days ago

• AND dropping in an older build to check is quick and easy,
• THEN I can give a last known good build as well as a first known broken.

If it doesn't fall into those categories, it's usually not worth the time it takes to track the bug beyond a quick check in the most recent release build to determine if it's a pre-existing or new bug.

WHO

• IF the culture is NOT a blame the dev culture
• AND the bug is in an area being heavily modified for a project

• THEN I MAY identify that project as being the probable cause of the issue.

• IF the culture is NOT a blame culture

• AND the bug didn't exist until a correction for another issue came in
• THEN I MAY identify the correction as being the probable cause of the issue.

Reasons not to identify the cause

1. Any large application is going to be complex to work with. There will be unforeseen problems - blaming developers will cause resentment.
2. The developers typically want to produce high quality code. Having someone treating their oversights or mistakes as a fault - mistakes will happen. We're human.
3. Just because we think we know where something broke and who broke it doesn't mean we got it right. Sometimes the root cause is a completely different cause somewhere you wouldn't expect (I've seen this happen a few times).
4. Most of the time, it doesn't matter who - or what - caused a bug. What matters is fixing it.

Answer 2

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.

Answer 3

Here the way I would do that:

Who

Ask yourself exists the bug because of new features or changes? Bugs in specific sections of a software linked by specific changes. If you know that you can localize the number of developers they worked on this. In some cases it is just one. Go to the developer(s), show them the defect and ask for assumptions of the reason.

Where

If you can answer the question mentioned in the Who part, you can ask the developer(s) to take a look in there commits to find out what change the reason for the bug is. If you can not answer the question, try to keep in mind in which application version the defect was not present. Install the versions after that one by one until you see the bug. This is very time consuming... The best way to answer the Who question and avoid the Where question are daily short meetings with the developers. They share the current status and talk about troubles. You can listen and after some months - in the most cases - you can use that knowledge to link the bug reason with a change.

My opinion is, that as a tester it is very important to be up-to-date with what the developers currently do. This is not always possible. But if you can, do it.