Tracking bugs before QA handoff

[the church lady]

The developers normally perform some integration testing before
handoff to QA.

The developers had been using their own bug tracking system to report
problems.

Now, they will report bugs into the same bug database which QA uses.

Is this the standard procedure? I have never been involved in a QA
project where developers report problems into the QA database.

Also, where does Unit Testing bugs fit in? How do developers normally
report and track unit testing bugs?

And is there any benefit to QA to know about these unit testing bugs?

Note that our QA department is not involved at the unit testing stage.
email: softwaretest underscore 2003 at hotmail

[Blue Jean]

For all the small companies I worked before, developers and QA
work pretty much closely, and they do share the same bug tracking
system. If unit testing is special and QA is not involved at all,
then make it a unitTest category or type (you might even hide
it from QA, not recommended though) so that QA may not bother
them too much. But for developers,
it is better to have a record of the unit test in the database
than to have it somewhere else and later forgot about it.

Or, one might create a separate project for pre-lease, or
pre-QA bugs in the same bug tracking system.
The idea here is that, it is perhaps not a good idea to ask
developers to use two diffent tracking systems (because developers
have to work on the bugs QA submitted, right?).

Bugzero all-in-one: bug tracking & help desk
Free try: http://www.websina.com/bugzero/


"Tom Schulenburg" <tschulenYour@Hatpacbell.net> wrote in message news:<cmUTa.4173$f26.30872831@newssvr14.news.prodigy.com>... "the church lady" <tcl@mail.com> wrote in message news:3f1fe653.25019788@netnews.comcast.net... The developers normally perform some integration testing before handoff to QA. The developers had been using their own bug tracking system to report problems. Now, they will report bugs into the same bug database which QA uses. Is this the standard procedure? I have never been involved in a QA project where developers report problems into the QA database. Many companies I've worked with do this. Developers may become aware of bugs before they're found in QA. QA is responsible for verifying the fixes and assesing the impact to other areas of the product. In addition, this practice will help give a complete picture of the overall stability of the product. Also, where does Unit Testing bugs fit in? How do developers normally report and track unit testing bugs? Same as above And is there any benefit to QA to know about these unit testing bugs? Yes. Knowing about the types of bugs encountered in unit testing will give a qa tester ideas for testing once the code has been integrated. It's possible that fixes in unit testing will impact areas of the product outside of the "unit". It's a good idea to understand how the logic has changed in order to know what the full impact is. Wherever you see a lot of bugs / fixes, you should assume there is a lot of risk as well. Give these areas more attention during integration testing. Note that our QA department is not involved at the unit testing stage. This is not uncommon. By tracking all the bugs in the same database, at least you'll have access to changes that are being made. Sometimes unit testing will produce fundamental changes in how the product works. The more information the QA dept has, the better. email: softwaretest underscore 2003 at hotmail -T

[Roy Smith]

bill_hen@hotmail.com (Blue Jean) wrote: For all the small companies I worked before, developers and QA work pretty much closely, and they do share the same bug tracking system.

That's what we did on the last big project I worked on. I can't imagine
wanting to do it any other way. A bug's a bug. It doesn't matter who
finds it, so putting it all in one database makes a lot of sense.

Often we would find, open, resolve, and close a bug all in the same day,
entirely within the dev team, before another build was handed off to
test. Having the fossil record in the bug database was a good heads-up
to the regression test guys that something had changed in that part of
the system so they might want to pay special attention to it. At the
bug review meetings, it would get a mention; probably take no more than
about 15 seconds, but at least it would be on the list of changes to the
system so everybody knew about it.

Having everybody work in a single bug tracking sytem also meant that
anybody on the team, down to the most junior developer, had the ability
to open a "stop ship" bug. It's not a power you want to abuse, but it's
a good thing (IMHO) that anybody can stand up and shout "Stop!" if they
find a problem.

Also, the test organization published criteria for what constituted the
various bug severities, and everbody used the same rules. Then you
never run into sillyness like "is 'critical' in test's database more or
less severe than 'high' in dev's database?"

[Vladimir]

One of possible reason why to log in all the defects found by all
kinds of testing is getting a reliable information about testing
stages effectiveness. Some companies are using this metric to find
holes and make correction in their testing cycle to find most of
defects at the early stages of testing (Reviews, Unit and
Integration).

----
Best Wishes,
Vladimir


tcl@mail.com (the church lady) wrote in message news:<3f1fe653.25019788@netnews.comcast.net>... The developers normally perform some integration testing before handoff to QA. The developers had been using their own bug tracking system to report problems. Now, they will report bugs into the same bug database which QA uses. Is this the standard procedure? I have never been involved in a QA project where developers report problems into the QA database. Also, where does Unit Testing bugs fit in? How do developers normally report and track unit testing bugs? And is there any benefit to QA to know about these unit testing bugs? Note that our QA department is not involved at the unit testing stage. email: softwaretest underscore 2003 at hotmail

[the church lady]

On Thu, 24 Jul 2003 17:06:16 GMT, "Tom Schulenburg"
<tschulenYour@Hatpacbell.net> wrote:
Also, where does Unit Testing bugs fit in? How do developers normally report and track unit testing bugs?Same as above

If I understand correctly, unit testing is most commonly performed by
the developer on his own code units.

Suppose a developer discovers an endless for loop.

Will these type of unit testing bugs be entered into the system? It
seems the developer would find it more convenient to simply fix the
error rather than formally reporting it.
And is there any benefit to QA to know about these unit testing bugs?Yes. Knowing about the types of bugs encountered in unit testing will give aqa tester ideas for testing once the code has been integrated. It'spossible that fixes in unit testing will impact areas of the product outsideof the "unit". It's a good idea to understand how the logic has changed inorder to know what the full impact is. Wherever you see a lot of bugs /fixes, you should assume there is a lot of risk as well. Give these areasmore attention during integration testing.

This requires that QA staff have the skills to understand the unit
testing comments and which system level test cases are affected..

In my experience, the developer comments can be cryptic (especially to
QA staff without development background and without knowledge of the
code design) and it is not obviously clear how unit testing fixes
apply to the system.


Note that our QA department is not involved at the unit testing stage.This is not uncommon. By tracking all the bugs in the same database, atleast you'll have access to changes that are being made. Sometimes unittesting will produce fundamental changes in how the product works. The moreinformation the QA dept has, the better. email: softwaretest underscore 2003 at hotmail-T

email: softwaretest underscore 2003 at hotmail

[Roy Smith]

In article <3f2d80d8.41550315@netnews.comcast.net>,
tcl@mail.com (the church lady) wrote:
If I understand correctly, unit testing is most commonly performed by the developer on his own code units. Suppose a developer discovers an endless for loop. Will these type of unit testing bugs be entered into the system? It seems the developer would find it more convenient to simply fix the error rather than formally reporting it.

Depending on your process, you might track "fixed in" versions of files.
So, the developer enters, "fixed in foo.cc, version 3.14". This could
be used by the build team to make sure they get the right version into
the build. It could be used by the test team to double-check the same.

It could also be used by the test team to design better tests. How did
we not notice that before? What test could we have designed that would
have caught it? Likewise, the test team could ask the developer, "what
broken behavior do you believe that bug fix correct?", and they could
then go test to make sure it got corrected.

Information is always good.

[Wayne Woodruff]

If I understand correctly, unit testing is most commonly performed by the developer on his own code units. Suppose a developer discovers an endless for loop. Will these type of unit testing bugs be entered into the system? It seems the developer would find it more convenient to simply fix the error rather than formally reporting it.

Our developers write them up. Our philosophy is to write up
everything.
Wayne Woodruff
http://www.jtan.com/~wayne