Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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.

share|improve this question
    
Do you have continues integration with tests? –  dzieciou Jun 27 at 12:43
    
As a black box tester, why do you even have access to the code at all? Wouldn't that "muddy the waters"? –  corsiKa Jun 27 at 14:42
    
@corsiKa Maybe that was a bit broad of term but I can see code commits integrated into the defect report. I view but cannot modify. –  user8082 Jun 27 at 14:48
    
@dzieciou I am not certain what you mean, can you explain further please? –  user8082 Jun 27 at 14:52
    
@user8082, CI server with regression suite can give you some heuristics whose commit broke the build. Kate Paulk is saying about that in her answer. –  dzieciou Jun 27 at 18:51

3 Answers 3

up vote 2 down vote accepted

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.
share|improve this answer
1  
Fixing a bug may introduce another one, but it may also unmask old bug. This tends to happen in some projects, where people do workarounds instead of fixes and a dev who stops following this bad practice may open a Pandora's box. But he's not the one to blame. Instead the whole team should think what to do with all masked bugs. –  dzieciou Jun 28 at 5:39
    
@dzieciou - absolutely. Another case I've dealt with is where the application has been under continuous development for 25 years and was originally written in a way that isn't compatible with modern languages. The old code was grandfathered in and everyone was scared to try to change it. –  Kate Paulk Jun 30 at 11:05

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.

share|improve this answer
    
+1 for the database and counterproductive points. –  Twaldigas Jun 27 at 12:55

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.