Our new QA section
explains how to make
your Website work the
way you need it to!
Fonts.com
 

2008


Home Page
Feature Archive
A&I Column Archive
Production Tools
State Marketing Data
US Marketing Data
World Marketing
Classifieds
Service Directory
Quality Assurance
3D Printing

Subscribe to Advertising & Marketing Review!
Contact Ken Custer at 303-277-9840.


Overcoming Objections Engineers Raise to Fixing Defects


By G.E. Morris

Engineers may stall fixing defects for a number of reasons. It is a testers job to overcome their objections to make fixing the defect a priority, especially in severity 2 and 3 defects. Engineers usually fix severity one defects without much need for encouragement.

The usual problem is getting engineers to fix the intermittent or lower severity defects because:
  • it may take significant effort to narrow the defect down on their part.
  • because they are falling behind in other assignments and don't have the time
  • they are in denial about the defect
Beneath the surface of a development team are undercurrents of various demands for engineer's time that will always affect the ease and speed of getting defects fixed. Those factors are beyond a tester's control. What a tester can do is to make the best possible argument for fixing the defect in question.

Low level blow off

Many engineers have adopted a standard set of objections to common types of defects. Junior QA people tend to fall for these objections, senior QA people usually won't.

My code couldn't have possibly caused that to happen.

The standard and classic counter is yes, it is possible, and for good reasons. An engineer's code could pass the wrong variable to another component that could pass it to a third component which then fails because it doesn't know how to handle the incorrectly formed parameter. Initially it will look like the third component is at fault, but in reality it is not the source of the problem.

If it were my code the defect would happen all of the time, not just some of the time.

This isn't necessarily true. One defect I reported once only happened sometimes. The engineer blew it off saying they had tried it several times but could not reproduce it, or explain it. The counter move is to try to reproduce the failure enough times to see a clear failure pattern, and the average number of times the defect can be reliably expected to happen in a given number of tries. The problem I reported happened about one in eight times over a series of 100 tests. When I reported this to the engineer, he took the problem seriously and soon determined that at one point in the code he had used a short address instead of long address, and the short address overflowed about one in eight times a certain process was executed.

The problem doesn't happen often enough to fix.

This is another case where statistics and metrics are your best weapon. Run the test enough times to be able to estimate reliably how often the problem will happen. This allows you to use the word always instead of sometimes. Until you can prove the frequency of the defect, you can only use the word sometimes. When you have established the frequency, say one in eight tries, you can use the word always, as in "The defect always happens one in eight tries.

The problem isn't serious enough to fix.

Solid statistics are only part of the answer here. Proving how often a failure happens isn't the same as proving how expensive it would be to ignore. To this end, the tester needs to determine the total effect of the defect including all direct and indirect loss of functionality. If this isn't enough to persuade the engineer, consider either dropping it, or escalating the problem to the project owner. If you choose the latter option, make sure you have all the data you need to prove your case.

Engineer Maneuvers in the Investigation Phase.

If the low level blowoff doesn't work engineers usually start fixing the defect or escalate in a way designed to get the ball back in the testers court, usually by asking for more information. Either way, the engineers often say:

I need more information to fix this

This response can be made in good faith, or simply to stall for time. A tester's response should consider several factors.

Begin by asking if the engineer can reproduce the defect on their system.

If the engineer can't reproduce the defect, it is generally held that it is the tester's responsibility to provide the engineer with enough additional information to allow the engineer to reproduce it. (A problem with this approach is that engineers will usually try to reproduce it by using their engineering server which may have a slightly different configuration that the QA server).

If the engineer can reproduce the defect, ask for specific details on what additional information the engineer is asking for. This will get the ball back in the engineer's court, and there's always a chance the engineer will find it easier to fix the problem than take the time to detail the information they would need from you. If the engineer counters with the information, get to work on it ASAP. If the engineer keeps asking for more information and you run out of ideas, escalate the problem to your team lead, or send the engineer an email, and document it in the DTS, telling the engineer you have provided all the information you can, and (you can leave this part out you are a junior level tester) you are bouncing the ball back to him for the last time.

The last resort

Taking a QA issue to the product manager is last resort of a QA engineer, and something that should only be done for serious problems with the product. It will lose points with the engineers, but if It is best if the QA team lead approaches the product manager with enough documentation to make a persuasive case.

Once you've escalated the problem to the product manager, whatever the results, you've taken the issue as far as it will go. At this point the responsibility is someone elses, and you have the satisfaction of knowing you've done all you can do to ship a good product.




For more advertising and marketing help, news, resources and information visit our Home Page.


Back to top



QA and the Software Development Lifecycle

CMMI Levels

Writing Repeatable Test Cases

Writing Thorough Test Cases

Writing Product Requirement Documents

Basing Test Cases on Requirements Documents

Test Case Formats

Multipart Test Cases



Constant Contact -- FREE Email Marketing

null